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.
Keep a pack that lets a person who was not in the room answer five questions. What did you set out to prove? Which backup generation did you use? What happened against the criterion you wrote beforehand? How long did it take, and what did you leave out? What was changed because of what you found?
If the pack cannot answer those, the test may have been real, but the pack alone does not substantiate its scope or result. NIST SP 800-34 says every test, training and exercise event produces an after-action report, and that lessons learned are captured so the plan is updated. NIST SP 800-84 says the after-action report contains the results and the corrective actions. A folder of job emails is raw material for that report. It is not the report.
This is a description of records, not a template mandated by a regulator. ISO 22301 is often the standard an auditor names. Its clause text was not available in this research session, so this article does not say what an ISO certificate requires. It says what the opened NIST and Australian documents already force you to be able to show, if you claim you followed them.
No audit was performed for this article.
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.
SP 800-53 control CP-4 has three parts: test the contingency plan at a defined frequency using defined tests, review the results, and start corrective actions if needed. The review is impossible if the results were not kept. The corrective action is invisible if nobody recorded whether it finished. A slide that says "DR test: pass" answers none of the three parts.
A relevant Australian control is specific. Information Security Manual control ISM-1515 says restoration of data, applications and settings from backups to a common point in time is tested as part of disaster recovery exercises. A pack that shows a meeting, or a single file copied from the production disk, does not show that sentence. ASD Essentials action PRO-10, published 15 October 2026, says the testing is regular and that it is capable of meeting defined recovery time and recovery point objectives. A pack with no clock and no backup timestamp cannot show those objectives. The transition note published the same day says current restoration results and disaster recovery exercises can be strong evidence for that action. "Can be" depends on the results being specific enough to read.
SP 800-34 also says the test plan itself is part of the value: objectives, success criteria, schedule, participants, scope, scenario, and logistics, with the scenario close to reality. If you throw the plan away after the event and keep only the outcome, a reviewer cannot see whether the outcome answers the question you started with. Teams change the question after a weak result. The dated plan is what makes that visible.
SP 800-84 separates the paperwork by event type, which matters because a tabletop pack and a restore pack prove different things. A tabletop's documents are a facilitator guide, a participant guide, and an after-action report. A test's documents include a test guide, a test plan with expected outcomes for each step, and an after-action report. For a larger test it also asks for an executive summary: what was done, what resulted, and what should change. Filing a tabletop pack under the title "restore test" is a mislabelling the documents themselves can prevent, if the first page states the event type in NIST's sense: discussion only, or a test that actually retrieved backup information.
How it works
One pack per event, with a stable identity
Give each event an identity before it starts: a name, a date, the system or group in scope, and the event type. SP 800-84's sample materials are built around a named exercise on a named date. Use that habit. A year later, "the DR test" is not an identity.
Bind the pack to the versions that existed that day.
- The contingency plan version, or the section, that was being tested. SP 800-34 says plans are reviewed when things change. A later plan must not be silently swapped into an old pack.
- The success criterion, copied from the test plan, not rewritten in the summary.
- The list of required participants and the list of who attended. SP 800-34's training and exercise guidance cares that the people with roles took part. A sign-in of observers is not the same list.
Store the pack where the people who must produce it during an incident can reach it, and where it is not only on the system being recovered. That last point is an editorial application of the same idea as offsite backup copies: evidence of the test should survive the loss of the system the test was about. SP 800-34 already says a copy of the plan is kept with the backup media and at the alternate site. The after-action pack belongs with that set or in the organisation's record system. This article does not name a product for that store.
The execution record a stranger can check
For any event that claims to be a restoration, the execution record needs these fields. They are the minimum that makes ISM-1515 and PRO-10 readable. They are not a software schema.
- Each member restored: system name, what it is (data, application, settings, or more than one of those).
- Backup identity: the job, the volume, or the media label, using the labelling scheme SP 800-34 says the backup policy should define.
- The time that backup represents, and the common point in time the test claimed, if it claimed one. If a member missed that point, the miss is in the record.
- Where the bytes were read from. CP-9(1)'s discussion example starts at the alternate or backup site. If you read from somewhere easier, write the somewhere.
- The path limits: isolated network or production, and any exception such as a live directory that was borrowed.
- The criterion result: met, not met, or not attempted, with the observation (what opened, what number matched, what error appeared). SP 800-84 says each test step should state the expected outcome. The record states the actual outcome beside it.
- The clock: start instant, stop instant, and the instants of stages that breached their expected time. SP 800-34 section 4.3.1 treats a missed expected time as an escalation event. The pack should show whether escalation happened.
- Samples that were not the whole system. CP-9(2) allows a sample and says the size follows the assurance you need. The pack states the sample and the functions not sampled. Otherwise a sample is later described as a full restore.
For a tabletop, do not invent these fields. Record the scenario, the decisions, the plan gaps, and the actions. SP 800-84 is explicit that a tabletop deploys no equipment. A tabletop pack that grows a fake restore log is worse than a thin one.
Corrective actions are part of the evidence, not a follow-up nobody owns
CP-4 does not end at the test. Results are reviewed and corrective actions start if needed. SP 800-34 says the after-action report's lessons update the plan. SP 800-84 includes corrective actions and recommendations in the report, and an executive summary for larger tests.
Each action in the pack needs an owner, a due date or a statement that none was set, and a later status: open, done, or accepted as a risk with a named accepter. An action that says "improve restore" is not reviewable. An action that says "the offsite copy of the ledger could not be decrypted; the key custodian will confirm the key is held offsite, by 30 November" can be reviewed. When the status changes, update the pack or link the pack to the item in whatever tracking system you use. A pack frozen on the test day does not by itself show later action closure. Preserve that original record and link dated follow-up evidence; a verbal promise is not evidence that a correction was completed.
If the recovery time was missed and the maximum tolerable downtime will not move, SP 800-34 says to open a plan of action and milestones. That plan is part of the evidence of the miss. Closing the miss by editing the objective in the summary, without that plan, is the behaviour the dated criterion is there to catch.
What does not belong in the pack
Do not put secrets in the pack. CP-9(8) is about cryptographic protection of backup information, and its discussion says key management has to be considered. The pack may say which key name was required and whether it was available. It should not contain the key, a password, or a token. A reviewer who needs to see that the key exists can see a record of a successful decrypt, not the key material.
Do not put production personal data into the pack beyond what the criterion required. The Information Security Manual points readers to the Office of the Australian Information Commissioner for the collection and retention of personal information. This article did not open those privacy principles. If the success criterion was "the customer record opens," record a minimised or pseudonymised identifier and a match result, not a dump of the record, unless a documented and authorised evidence requirement needs more. Identifiers themselves may be personal data; apply access controls and retention limits to the pack.
Do not include only the passes. CP-4's corrective action exists because tests find weakness. A pack of successes with the failures stored in a chat log is a pack that has already been edited.
What to choose and why
Choose a single index for the year, one line per event: date, type, scope, result, link to the pack. SP 800-34's maintenance habit is a review at a defined frequency and after significant change. The index is what makes that review possible without opening every file. The index is also what you hand over first. The pack is what you open when a line is challenged.
Choose the event type honestly on that line: tabletop, sample restore, group restore to a common point in time, or a closer exercise that touched production connectivity. The line should be boringly specific. "Passed" without the type is the sentence this article is trying to retire.
Choose retention of the packs to match two clocks, and write the choice down. One clock is the audit or assurance cycle in which someone may ask. The other is the life of the backup generations the pack describes. A pack about a generation you no longer hold can still matter, because it shows whether you ever opened that kind of copy. SP 800-34 asks, as a policy question, how long backup media are retained, and it warns that each medium has a storage life after which it cannot be relied on. The pack is subject to the same honesty: a record you cannot open because it sits in a format you abandoned is not evidence. The manual's digital preservation control, ISM-1510, is about a policy for long-term integrity and availability, including degradation and software obsolescence. It is aimed at organisational data, and it is a fair test to apply to the evidence as well. This article does not set a number of years. The September 2026 manual points to the National Archives of Australia for further information on retention. That guidance was not opened here, so no archival period is stated.
Choose who may add to the pack after the event. The test record stays as it was. Corrective-action status may change. SP 800-84's after-action report is written after the event and includes recommendations. Later edits to the narrative of what happened should be visible as later edits, with a date and a name. Silent improvement of the story is the failure mode of shared documents.
For a large test, write the one-page summary SP 800-84 describes for senior management: what was in scope, what the criterion was, whether it was met, the elapsed time, the recovery point achieved, and the open actions. Executives do not need the job logs. They need the sentence the logs support. The logs stay behind the summary so the sentence can be checked.
Risks and limits
The first risk is a pack assembled the week the auditor arrives. Memory will fill gaps with success. SP 800-34's instruction is that results are documented for each event. Build the pack the day of the event, while the backup identities are still on the screen.
The second risk is screenshots without the fields above. A console crop that shows a product name and a green mark does not show generation, scope, or criterion. Keep a screenshot if it helps. It is an exhibit, not the pack.
The third risk is scope inflation between the plan and the summary. The summary is allowed to be shorter. It is not allowed to be stronger. If the plan said "one file from the offsite copy," the summary does not say "full application recovery."
The fourth risk is losing the plan version. Testing a plan and then filing only the improved plan makes the test look as if it validated words that were written afterwards. Keep the tested text.
The fifth risk is treating this pack as an ISO 22301 certificate file. It is not. The catalogue page for that standard did not return the text on 11 November 2026. If a certificate is in scope, map this pack to the licensed standard with someone who can read it. Do not assume the NIST after-action report satisfies every clause.
SP 800-84 dates from 2006 and its samples include pagers in the emergency-contact list. Ignore the pager. Keep the idea: contacts, expected outcomes, early-termination procedure, results, and recommendations. SP 800-34 dates from 2010. CP-4 in SP 800-53 Rev. 5 still points at both documents. The September 2026 manual and the 15 October 2026 Essentials pages are the Australian texts. Old Essential Eight maturity ratings do not, on the transition page's own words, automatically become the new ratings. A pack that claims "maturity level three" because a test occurred is using a scale the transition publication says is not the new scale.
This article was written with AI assistance. It is source research only. The factual claims have been independently checked against the cited sources. It is not legal advice and it is not an audit report.
Sources
- NIST SP 800-34 Rev. 1, 11 November 2010, https://doi.org/10.6028/NIST.SP.800-34r1 — sections 3.5 and 3.6, after-action reports, test-plan contents, plan copies with backup media. Opened 11 November 2026.
- NIST SP 800-84, September 2006, https://doi.org/10.6028/NIST.SP.800-84 — tabletop documents, test guide, test plan, after-action report, executive summary. Opened 11 November 2026.
- NIST SP 800-53 Rev. 5, https://doi.org/10.6028/NIST.SP.800-53r5 — CP-4, CP-9(1), CP-9(2), CP-9(8). Opened 11 November 2026.
- ASD, Information security manual, September 2026, https://www.cyber.gov.au/ism/2026-09 — ISM-1515, ISM-1510, and the pointers to the National Archives of Australia and the Office of the Australian Information Commissioner. Opened 11 November 2026. Those external publications were not opened.
- ASD, Essentials for enterprise IT and Transitioning from the Essential Eight, 15 October 2026, https://www.cyber.gov.au/publication/essentials-for-enterprise-it and https://www.cyber.gov.au/publication/transitioning-from-the-essential-eight. Opened 11 November 2026.
This article was originally published on .