About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
A retention rule answers how long a copy is kept. A restore path answers whether you can still turn that copy into working data. You need both. A copy kept for years, with no software that can read it, no key that can open it, or no ancestor backup that an incremental restore requires, has a duration and does not have a path.
NIST SP 800-34 asks "how long will the backup media be retained?" as one question in a list. The neighbouring questions are where the media are stored, who may retrieve them, who will restore them, how they are labelled, and what medium is appropriate. Retention is not the whole policy. The same section adds two limits that a calendar ignores: equipment has to be compatible with the systems and applications you will restore onto, and each medium has a storage life after which it cannot be relied on for recovery.
The September 2026 Information Security Manual splits the same idea across controls. ISM-1511 says backups of data, applications and settings are performed and retained in line with business criticality and business continuity requirements. ISM-1811 says they are retained in a secure and resilient manner. ISM-1810 says they are synchronised so you can restore to a common point in time. ISM-1515 says that restoration is tested. A retention setting that satisfies only the first of those sentences can fail the other three quietly.
No archive was opened for this article. No retention number is recommended, because none of the opened texts prescribe a universal number of years.
Why it matters
The controls discussed here apply where your organisation has selected or is required to meet them. They are not a blanket legal requirement for every business.
People negotiate retention as a single argument: legal hold, customer promise, or disk cost. The argument produces a number. SP 800-34's media-life note says the number can outlive the medium. Its interoperability note says the number can outlive the device and the application that knew how to read it. ISM-1510 requires a digital preservation policy because of data degradation and because removable media, hardware and software become obsolete. That control is the long-horizon version of the same warning. A backup catalogue that says "retained" is not a preservation policy. It is a flag.
The failure shows up at restore time, which is the worst time to discover it. SP 800-34 describes incremental backups as efficient to write and awkward to read: recovery can require the last full backup and every incremental since. Differential recovery can require the full backup and the latest differential. If retention deletes the full backup and keeps the incrementals, or deletes an incremental in the middle of the chain, the retained pieces are intact and unrestorable. The retention job succeeded. The path did not.
Encryption makes a second chain. SP 800-53 CP-9(8) says cryptographic mechanisms may be required to prevent unauthorised disclosure and modification of backup information, and the discussion says organisations that encrypt data at rest also have to consider key management. Rotation alone does not end recovery: systems may retain old keys, rewrap data keys or re-encrypt data through supported procedures. Recovery fails when the required decryption material is unavailable and no verified supported migration preserved access. The objects remain. ISM-1811's "secure and resilient" is not met by ciphertext nobody can open, and recovery availability is also lost if the only required key was on the server that failed. A publicly exposed key is a different failure: confidentiality is lost even if restoration remains possible.
ISM-1515 is the control that would have noticed. If restoration to a common point in time is tested, someone eventually has to pick a generation other than last night. A programme that only ever opens yesterday's copy has not tested the retention it claims. It has tested one generation. PRO-10 in ASD Essentials, published 15 October 2026, asks testing to be capable of meeting a recovery point objective. RPO concerns tolerable loss of recent data after a disruption. Retention horizon concerns how far back historical copies remain available. They are separate requirements: prove the RPO with recent consistent recovery points, and prove historical retrieval with older generations.
How it works
Draw the path, not only the calendar
For each class of backup, write the path as a list of things that must all exist on the day you restore. SP 800-34's policy questions are a usable spine.
- The data, including every ancestor the method needs. For incrementals, name each retained recovery point and every ancestor or shared block it requires. Keep those dependencies while any retained point needs them; a newer full backup does not remove the requirements of older retained points. For differentials, name the full backup and the latest differential.
- The label that lets a person find that set. The guide asks for a labelling scheme. An object store full of unnamed blobs is a retention pile, not a path.
- The software that reads the format, including the version. Interoperability in the guide means the backup device or method is compatible with the operating system and the applications, and can be installed onto the systems you will actually recover to. "We still have the installer from 2019" is part of the path if 2019 is the format you kept.
- The required decryption keys and, where applicable, the certificate and associated private key, kept recoverable for the lifetime of dependent ciphertext or migrated through a verified supported process, in a place that does not depend on the system the backup is for.
- The index or catalogue, if you cannot find the objects without it. A catalogue that is retained for ninety days in front of data retained for seven years is a ninety-day path with a seven-year warehouse.
- Someone authorised to retrieve, and someone who can restore. The guide asks both questions. A copy only the departed administrator could decrypt fails them.
- A place to restore to that still exists, or a documented way to create one. Retention of bytes without a landing zone is an incomplete path. This article does not describe how to build that zone.
ISM-1810 adds a cross-member constraint. If an application and its data are retained on different schedules, the common point in time disappears as soon as the shorter schedule deletes its half. Align the schedules for members of a set, or accept that the set's restorable horizon is the shorter one. Record the common historical retention horizon separately from the RPO. Compatible copies and a proven consistency method are still required; taking the shorter duration alone is not proof of a usable set.
Test a generation that is not the newest
CP-9(1) says to test backup information for media reliability and information integrity at a defined frequency. Apply at least some of those tests to a generation near the far end of retention, not only to last night. Last night does not exercise media life, old keys, or old software. SP 800-34's warning about storage life is untested if you never open an old piece of media or an old object.
The test does not need to be a full estate rebuild every month. CP-9(2) allows a sample of backup information in the restoration of selected functions. Once a quarter, or at whatever frequency you assign, select one system and restore from a generation near the oldest point in the historical retention period you advertise as "we keep a year." Record the software version and the key identity you needed. If you cannot, the retention of that class is longer than the path, and ISM-1511's appeal to business continuity requirements is not met for that class, whatever the disk report says.
Also test the deletion rule. A retention job that deletes by date, without understanding chains, will delete a full backup that incrementals still need. The corrective action is to delete sets, not orphans: a full backup and its dependent incrementals leave together, or the full backup stays until every dependent piece has gone. That rule is an editorial consequence of SP 800-34's own description of what an incremental restore requires. It is not a vendor feature name. If your product cannot express it, the path has a hole you should write down as a finding under CP-4, which requires review of test results and corrective action.
Obsolescence is a scheduled event
ISM-1510 is the place to put a decision you would rather defer: what happens when the backup product is replaced. The usual mistake is to start the new product, set a long retention on the new repository, and leave the old repository "until it ages out," with no licence, no staff, and no test. The old objects are still inside their retention number. They are outside any path.
When you change product, format, or key hierarchy, either:
- keep a tested reader, a licence, and a key for the old format until its retention ends, and open a sample on a schedule, or
- use a supported migration into the new path, reconcile completeness and metadata against the retained inventory, and test representative restores. Retire the old reader only after the evidence meets an approved acceptance plan and legal holds and retention obligations remain satisfied; a passing sample alone does not prove every object migrated.
Both options cost money. The option that is not available, if you claim the retention, is to keep the objects and discard the reader. SP 800-34's backup-software note is modest and still enough: the method you use to back up is part of choosing the solution, from a simple file copy to an application that schedules large transfers. Changing the method changes the path. Treat it as a change that triggers a test. SP 800-34 already says to repeat contingency testing after system changes.
Hardware follows the same logic. The guide says the backup device should be easy to install onto different systems, because recovery will not always be onto the original tin. A tape drive you no longer own, or an object-storage API your new tools refuse, is a device failure in that sentence even if the media are fine.
Security controls that can cut the path
Several controls that make retention safer can also make it unrestorable if they are applied without a test.
ISM-2151, in the September 2026 manual, says backups are stored with a technically enforced immutability mechanism that prevents modification or deletion for the retention period. Immutability protects the object from being changed or removed early. It does not restore it. An immutable unreadable object is still unreadable. Test the read. Do not treat the immutability flag as the test.
ISM-1708 says backup administrator accounts are prevented from modifying and deleting backups during their retention period. That is a control against a bad or coerced administrator. The people who are allowed to restore still need a path that is not "become the administrator who is forbidden to touch retention." SP 800-34 asks who is authorised to retrieve and who will restore. Write names or roles that still work when the backup administrators are unavailable. A break-glass arrangement is a design of its own. This article does not specify one. It says a retention rule with no living retriever is a rule you cannot execute.
CP-9(3) says store backup copies of critical software and other security-related information in a separate facility or a fire-rated container not collocated with the operational system. The reader software and the key material are candidates for that treatment. Leaving them only on the production backup server means the retention is collocated with the failure.
What to choose and why
Choose retention from the business continuity requirement ISM-1511 names, and from any legal retention your counsel has actually given you. This article is not that counsel. Then choose the path to be at least as long as the retention. If the path cannot meet the required duration, report the gap and fund or redesign preservation. Any change to a promised retention period needs the authorised business decision and must respect legal holds and statutory duties; do not delete protected copies to match a technical limitation. State the verified historical horizon separately from the RPO. A long number with no reader is a brochure.
Choose chain-aware deletion for any incremental or differential design, using SP 800-34's restore description as the reason. Choose a catalogue retention that matches the data. Choose key retention that matches the ciphertext.
Choose a scheduled open of an old generation, and put the result in the same evidence pack as last night's sample. If the old generation fails, either fix the path or stop claiming that horizon. PRO-10 requires demonstrated recovery objectives, while historical retention needs its own retrieval evidence. Testing an old generation supports the latter; it does not establish the permitted recent data-loss interval.
Choose, at each product change, one of the two options above, and write the end date of the old reader next to the end date of the old data. When those dates differ, the gap is the finding.
For a hypothetical simple forward-incremental chain with no synthetic fulls, consolidation or alternative restore path, a selected point needs its full backup and every required incremental through that point. Losing a required middle increment prevents later dependent restores; earlier complete points may remain usable. Modern backup designs can have different dependency structures, so determine retention from the product's verified restore requirements rather than assuming every incremental-forever system has this chain. The dashboard can still say retention is healthy. The path is not.
Risks and limits
The first risk is two policies that never meet. Records management sets seven years. The backup product sets thirty days because that is the licence. ISM-1511 says retention follows business continuity requirements. If those requirements include the seven years, the thirty-day product is not the whole answer. If they do not, do not advertise seven years because a folder was never cleaned up.
The second risk is testing only the near end of the window. It feels like assurance and leaves media life, old keys, and old formats unexamined. SP 800-34's storage-life sentence is the rebuttal.
The third risk is a conversion project that is assumed to have worked. A bulk copy into a new format is a new backup. It needs verified completeness, representative restore results and an approved retirement decision that preserves required records before the old path is retired. A conversion log that says "completed" is a job status. Job status is not an open.
The fourth risk is immutability theatre. ISM-2151 stops deletion during the retention period. It is valuable and it is not a reader, a key, or a test. Quote it for what it says.
The fifth risk is a universal retention number. None of the opened documents provide one. SP 800-34 leaves the duration as a question the organisation answers. The manual ties it to criticality and continuity requirements, which differ by system. A single estate-wide number will be too long for some paths and too short for some duties. Set it per class, and let the tested path be the constraint you are willing to show.
The manual points to the National Archives of Australia for further information on digital preservation and data retention, and to the privacy commissioner for personal information. Those publications were not opened for this article. Do not read this article as a statement of archival or privacy law.
This article was written with AI assistance. It is source research only. The factual claims have been independently checked against the cited sources. It does not set a retention period for any organisation and it does not describe a product's retention screen.
Sources
- NIST SP 800-34 Rev. 1, 11 November 2010, https://doi.org/10.6028/NIST.SP.800-34r1 — backup policy questions, incremental and differential restore sets, equipment interoperability, media life, and backup software as part of the solution. Opened 11 November 2026.
- NIST SP 800-53 Rev. 5, https://doi.org/10.6028/NIST.SP.800-53r5 — CP-9, CP-9(1), CP-9(2), CP-9(3), CP-9(8), CP-4. Opened 11 November 2026.
- ASD, Information security manual, September 2026, https://www.cyber.gov.au/ism/2026-09 — ISM-1510, ISM-1511, ISM-1515, ISM-1708, ISM-1810, ISM-1811, ISM-2151. Opened 11 November 2026.
- ASD, Essentials for enterprise IT, 15 October 2026, https://www.cyber.gov.au/publication/essentials-for-enterprise-it — PRO-10. Opened 11 November 2026.
This article was originally published on .