Australian cloud for business software — built and run in Sydney since 2003

+61 2 8282 5656
support@netleverage.com
Talk to an engineer
Talk to an engineer
NetLeverage
NetLeverage

Small, frequent restore checks and the annual recovery exercise

Technical article
Backup & Recovery

Originally published:

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.

Run small restores often enough to notice a copy that no longer opens. Run a larger exercise often enough to practise the people, the dependencies, and the clock. A calendar full of tiny opens is not a disaster recovery exercise. A single annual exercise is not a test of the backups taken on the days in between.

"Continuous" here means a designed cadence, not a product feature and not a claim that every backup is restored every night. The cadence has two parts: a sample of backup information restored on a short cycle, and a broader exercise on the cycle your plan already names. NIST leaves both frequencies as decisions the organisation must write down. The Australian texts opened for this article say the testing is regular and that it sits inside disaster recovery exercises. They do not print a universal number of days.

No restore was run for this article. The weekly and annual figures below are illustrations of a design, not a recommendation that every organisation use those exact intervals.

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.

Backup information ages in storage. NIST SP 800-53 control CP-9(1) requires the organisation to test backup information at a chosen frequency to verify media reliability and information integrity. The discussion says the organisation needs assurance that the information can be reliably retrieved, and that reliability covers the systems that hold it, the operations used to get it back, and the integrity of what comes back. A test done once, on the day the system was installed, says nothing about a copy written eleven months later and left on a shelf.

CP-9(2) then asks for a sample of that backup information to be used when restoring selected system functions, as part of contingency plan testing. The discussion is explicit that the sample size follows the level of assurance needed. Assurance is not free, and it is not binary. A larger sample, taken less often, and a smaller sample, taken more often, are two ways of spending the same idea. They fail in different weeks.

SP 800-34 says test, training and exercise events should be conducted periodically, and also after organisational or system changes, after new guidance, or as otherwise needed. The same guide's maintenance section says the plan is reviewed at an organisation-defined frequency or whenever significant changes occur. A cadence that ignores a storage migration, a new application, or a new backup product is a cadence that kept its calendar and lost its point.

SP 800-84 says the same for tabletops and for functional exercises: periodically, and after organisational changes, plan updates, or new guidance. It also says the usual order is training, then exercise, then test. A weekly technical sample that nobody is trained to interpret will produce logs and no decisions. An annual exercise staffed by people who have not touched a restore since last year will spend the day remembering the tools.

The Information Security Manual of September 2026, control ISM-1515, requires restoration of data, applications and settings from backups to a common point in time, tested as part of disaster recovery exercises. The paragraph above the control gives the reason: so that backups can be restored when needed, and so dependencies are found beforehand. ASD Essentials action PRO-10, published 15 October 2026, asks for regular testing of backup and restoration procedures so backups are reliable and capable of meeting the defined recovery time and recovery point. "Regular" and "as part of disaster recovery exercises" are both in force in the texts that were opened. A stack of weekly samples can support "reliable" for the items sampled. The coordinated exercise is what the manual associates with data, applications and settings together.

How it works

What a sample is allowed to mean

CP-9(2) is the control that matches a small frequent restore. You select functions. You take backup information. You restore those functions. You do this as part of contingency plan testing, not as an unnamed side task. The discussion says the point is to know that the functions come back correctly and can support the mission, and that you choose how much to sample from the assurance you need.

A sample record needs five fields or it will be summarised later as "we test all the time":

  • Which function was selected, and which functions were not.
  • Which backup generation was read, and from which store.
  • Whether the open matched a success criterion written beforehand. SP 800-34 says tests are judged against explicit objectives and success criteria, and that tests use quantifiable metrics.
  • How long retrieval and the functional check took.
  • What failed, including a failure to start.

CP-9(1) can be narrower than a functional open. Its discussion gives an example: decrypt and transport a random sample from the alternate or backup site and compare it with the same information at the primary site. That example checks retrieval and integrity by comparison. It does not, by itself, show that an application function runs. Use it as a frequent integrity sample if comparison is possible. Use CP-9(2) when the question is the function. Do not file the comparison under the function's name.

Random, in that discussion, is one way to avoid always picking the easy file. It is not a command this article can give you, because no sampling tool was validated here. If you cannot sample randomly, rotate the selection on a written list so the same share is not the sample every week. State that the rotation is a convenience, not the random sample described in the control discussion.

What the broader exercise is for

SP 800-34's functional exercise, for moderate impact, includes a system recovery component. Its full-scale exercise, for high impact, includes failover and a full recovery and reconstitution to a known state. SP 800-84 says a functional exercise is often run in real or near-real time and asks people to carry out their roles. A fifteen-minute open of one file does not do that work.

ISM-1515's phrase "to a common point in time" is the part a stream of unrelated samples misses. If Monday's sample restores a file server from Sunday, and Thursday's sample restores a database from Wednesday, you have two healthy opens and no evidence that those two systems can be restored to one shared moment. The exercise is where the generations are chosen together. ISM-1810 requires the backups themselves to be synchronised so that common point is possible. The exercise tests whether the synchronisation you designed can actually be used.

PRO-10's testing action mentions recovery time and recovery point as the outcomes the test should be capable of speaking to. A weekly sample can measure both for its own small scope. The exercise measures them for the set of functions you claim the business needs. Publishing the small number as if it were the large one is how a cadence creates false assurance.

Triggers that should not wait for the calendar

Both NIST guides list change as a reason to run the event, alongside the periodic schedule. For a restore cadence, write the triggers in the same place as the calendar. Useful triggers, each of them a change to the recovery path rather than a change to a wallpaper setting, are:

  • The backup product, the repository, or the path to the offsite copy changes.
  • The format changes, including a new encryption method or a new key hierarchy. CP-9(8) puts cryptographic protection on backup information and points at key management. A sample that cannot decrypt after a key change is a failed retrieval, even if the job is green.
  • An application upgrade changes what "open" means, so last quarter's success criterion is now the wrong check.
  • A dependency is added. The manual's reason for testing is to find dependencies before the day. A new dependency that has never been in a sample or an exercise is an untested dependency.
  • A sample fails. CP-4 requires review of contingency plan test results and corrective action where needed. The next scheduled date is not a substitute for that review.

SP 800-34 also notes that planned maintenance can be documented as a functional exercise where a designed interruption would be unreasonable. A maintenance window can feed the cadence if the same five fields are written down. A maintenance window with no record is just maintenance.

How the two cycles use each other's results

SP 800-84 expects tabletops to come before functional exercises, and training before tabletops. A workable year, stated as an editorial pattern rather than as a NIST calendar, looks like this.

On the short cycle, restore a rotating sample from the store you would use in an incident, not from the production disk. Keep the success criterion stable until the application changes. File failures where the contingency plan owner will see them. CP-4 says results are reviewed.

On the long cycle, take the failures and the awkward timings from the short cycle and put them in the exercise scenario. If every weekly sample needed a manual decrypt that the runbook does not mention, the exercise that pretends decrypt is automatic is rehearsing a fiction. SP 800-84's functional exercises are scenario-driven and can receive additional situations during the event. Feeding them last quarter's real retrieval defects is a better use of that mechanism than inventing a novelty outage that dodges the known weakness.

After the long-cycle exercise, update the sample list. Functions that failed in the exercise go to the front of the rotation. Functions that have passed for a long time stay in the rotation; reduce their rate only where a documented risk assessment supports that change, because CP-9(1) is about ongoing reliability, not about a hall of fame. SP 800-34's after-action report is the place those updates are decided.

Automated checks and the line they must not cross

CP-4(3) says the organisation may test the contingency plan using automated mechanisms. The discussion says automation can give more complete coverage, more realistic scenarios, and more effective stress on the system and the business functions. That is permission to automate a real test. It is not permission to automate a status scrape and call it CP-4.

An automated sample still has to retrieve backup information and apply a success criterion a person can audit. A script that only checks that last night's job completed has automated the wrong control. A script that restores a listed file from the offsite copy and records a hash compare, or records that the file opened, is closer to CP-9(1) or CP-9(2), provided the scope is written honestly. This article does not include a script. No automated restore was validated here, and an untested script pointed at production backups is a change, not an assurance tool.

What to choose and why

Write the frequencies down as assignments, because that is how CP-4, CP-9(1) and the SP 800-34 impact table are structured. "Organisation-defined" is not a shrug. It is a blank the control expects you to fill, and then to meet.

Use the impact ladder in SP 800-34 Table 3-6 as a design aid, remembering it is a United States federal categorisation and not an Australian statute. At low impact, that table treats a tabletop as the applicable exercise and marks system-backup reliability testing not applicable. At moderate and high impact, backup-information testing is applicable, and the exercise includes an actual recovery component. High impact adds full reconstitution. If your own classification says low impact, record that, and then read ISM-1515 and PRO-10 before you drop retrieval testing. The passages opened in those Australian documents do not contain a low-impact exemption from restoration testing.

For a system that must meet ISM-1515, set and justify an exercise frequency that meets your applicable policy, regulatory obligations and risk assessment, and include an exercise that restores data, applications and settings to one common point in time. Use the short cycle to sample members of that set from the offsite store so you are not discovering, in the exercise, that the repository has been unreadable for months. The transition guidance of 15 October 2026 says current restoration test results and disaster recovery exercises can be strong evidence for the Essentials backup actions, and that testing should demonstrate the defined recovery objectives. A sample that records time and backup age is evidence toward that demonstration for its scope. Say the scope in the first line of the record.

Choose sample size from the harm of being wrong, which is the instruction in CP-9(2)'s discussion. A payroll calendar that is wrong by a month is a different assurance decision from a build cache that can be recreated. Do not hide a high-harm system in a low-harm sample pool so the dashboard stays green.

Prefer the copy at the alternate or backup site for the frequent test. That is the starting point of the CP-9(1) discussion example. If the only automated access you have is to a cache on the production network, label the result as a cache test and keep a slower test that actually recalls the offsite copy. SP 800-34 asks that copies be tested at the alternate site, where you have one, so the site's configuration can use them.

Risks and limits

The first risk is ritual. A sample that always restores the same small file can pass even when unsampled backup content is damaged. Rotate, or sample in a way you can explain. If you claim the CP-9(1) discussion's random sample, be able to show the selection was not hand-picked after the fact.

The second risk is scope creep in the summary. Fifty-two successful file opens are fifty-two file opens. They are not a full-scale functional exercise and they are not ISM-1515's coordinated restoration unless one of them actually restored the set to a common point in time.

The third risk is load and safety. SP 800-84 says operational systems are protected during a test and the organisation's core service is not brought down by the test. A "continuous" design that restores into production, or that mounts backups in a way that can write back, violates that constraint. Keep frequent restores on isolated capacity. Isolation is a safety decision. It also limits the claim: you have not proved the production network path. The annual or defined exercise is where you decide how much of that path you are willing to touch, with an early-termination rule written down before you start.

The fourth risk is a cadence that never looks at change. Both NIST guides tell you to repeat the event after the system or the plan changes. A quarterly schedule that survived a repository migration without a single extra sample did not follow that instruction.

The fifth risk is stale Australian labels. The September 2026 manual still prints Essential Eight tags beside ISM-1515. The 15 October 2026 transition publication says organisations no longer select a target maturity level in the new framework, and that old maturity ratings do not automatically convert. Use the control sentence and the PRO-10 action. Do not spend the year chasing a superseded level unless a regulator still requires it. The transition publication says that explicitly.

SP 800-84 is from 2006 and SP 800-34 from 2010. Their examples of media and of annual training habits are old. The controls in SP 800-53 Rev. 5 still point at those guides and still leave frequency to the organisation. The CP-4 and CP-9 controls leave test frequency to the organisation. SP 800-34 also includes annual testing in its sample policy and plan approval templates, and recommends at least annual training; those passages should not be overlooked. They do not establish a universal weekly or annual restore-sampling interval for every business. If you adopt those intervals, they are your assignment, and you should be able to say why they match the recovery point you claim.

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 authorise anyone to point an untested restore job at a live system.

Sources

This article was originally published on .