Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
How to document containment and recovery actions
Updated
Log every containment, eradication, and recovery action: who, what, when (UTC), why, and the evidence ID. Isolate, do not destroy. Eradicate before you restore. This page is not legal advice.
Operational guidance, last verified 7 September 2026 against NIST SP 800-61r2 (Computer Security Incident Handling Guide — guidance, not a statute; document what was done, who authorised it, and when), CISA's Federal Government Cybersecurity Incident and Vulnerability Response Playbooks (operational procedures written for US federal civilian executive branch information systems; CISA notes other organizations may use them to standardize practice), and ISO/IEC 27035 (information security incident management — a standard of guidelines, not a law; the full text is paywalled and this page does not reproduce it). The SANS Incident Handler's Handbook is a practitioner PICERL checklist, not a standard; it sequences containment, then eradication, then recovery. This page does not rank DFIR firms, does not start a notification clock, and is not a substitute for counsel, your insurer, or a retained DFIR firm. Not legal advice.
A log you can defend — this is not a statute
Audience: the incident commander logging the moves, the examiner who will later reconstruct them, and counsel who may have to show an insurer or a regulator what was done. The first-hour page on this site is the contain-versus-observe decision. The first-week page on this site is the recovery-you-can-defend timebox. The preserve-evidence page on this site is the capture list those rows must cite. The never-delete-after-breach page on this site is the do-not-destroy list. The incident-timeline page on this site is the UTC chronology. This page is the action log: what to record for every containment, eradication, and recovery action so the move is auditable, reversible where it still can be, and defensible later. It does not rank DFIR firms, does not name any, and does not start a notification clock.
NIST SP 800-61r2 is a guide to handling computer security incidents — guidance, not a statute. It sequences containment, eradication, and recovery, and it asks responders to document a chronology of detections, actions, and decisions: what was done, who authorised it, and when. CISA's playbooks treat containment and eradication as recorded operational steps, not silent cleanup. ISO/IEC 27035 is a standard of guidelines for information security incident management; it is not a law, the full text is paywalled, and this page does not reproduce it. Last verified 7 September 2026. Not legal advice.
- One row per action. Containment, eradication, and recovery are different moves. Mixing them in one line is how a wipe gets filed as isolation.
- Who, what, when (UTC), why, and the evidence ID. A Slack 'fyi' is not a log. A reconstructed write-up after restore is not contemporaneous.
- Isolate, do not destroy. Containment that wipes the image is eradication dressed as containment. The preserve-evidence page on this site is that capture list.
- Confirm eradication before you restore. Recovery onto a dirty primary is how you re-infect the estate and destroy the investigation.
- This page does not rank DFIR firms, does not interpret YOUR policy, does not start a notification clock, and is not legal advice.
Action-log template
Copy the columns. Fill a row when something is done or authorised — not when you have a complete story. Unknowns belong on the list. This product does not ship a downloadable template file and does not keep a containment action log; the table is the template. Last verified 7 September 2026. Not legal advice.
- Record whether the action is reversible and how to undo it (a firewall rule is; a disk wipe is not). Reversible where needed is a property of the move, not a hope.
- Corrections are new rows, not silent edits. The original line stays.
- Every recovery action is a new line, even when it is 'the same host, again.' NIST SP 800-61r2: acquire, preserve, secure, and document.
- Counsel-directed logging is common practice so working papers can sit under attorney-client privilege and work-product. That is practice, not a ruling that privilege will attach. The contact-breach-counsel page on this site is the privilege-and-engagement checklist.
| Who | What | When (UTC) | Why | Evidence ID |
|---|---|---|---|---|
| Named person and role who performed the action (and who authorised it, if different). A team name is not who. | The move in one clause, tagged containment, eradication, or recovery. Isolation, account disable, and a firewall rule are containment. Removing persistence and rotating credentials from a clean plane are eradication. Restore from known-good media is recovery. | ISO-8601 UTC (YYYY-MM-DDTHH:MM:SSZ). If the source was not UTC, convert here and keep the original in the timeline notes. The incident-timeline page on this site is that method. | The decision the action implements (contain-versus-observe flip, stop lateral movement, remove the persistence you actually found, restore service after eradication). 'Because we were scared' is not why. | The chain-of-custody ID, hash, ticket, screenshot, or export that a later reader can pull. Empty ID means the row is recollection until you attach one. The preserve-evidence page on this site is the field list. |
Isolate, do not destroy
Containment is isolation: take the host, account, or path off the production network so the actor cannot use it, while the evidence stays. Eradication is removal of what you found. Recovery is restore from known-good media after eradication is confirmed. NIST SP 800-61r2 and the SANS PICERL model sequence those three. Skipping the first two, or collapsing them into a reimage, is how the investigation ends and the actor gets a clean box to return to. Last verified 7 September 2026. Not legal advice.
- Network isolation, VLAN cut, security-group change, disable the account after export, revoke the token — those are containment. Log them.
- Do not power down a live host to contain it unless isolation is impossible and you record why. Volatile memory is gone when power is. CISA ransomware guidance treats power-off as last resort for that reason. The preserve-evidence page on this site is the order of volatility.
- Do not reimage, restore, or 'just rebuild' an affected host before a forensic image exists. That is eradication dressed as containment. FTC Data Breach Response guidance for US businesses: do not destroy forensic evidence during investigation and remediation. That is regulator guidance, not a statute that files a notice for you.
- Do not rotate, truncate, or delete logs to tidy the environment. Place a hold. Off-box SIEM still rotates.
- The never-delete-after-breach page on this site is the do-not-destroy list. This page is the log of the isolation you actually performed.
Recovery-validation checklist — confirm eradication before restore
NIST SP 800-61r2 sequences containment, then eradication, then recovery. The SANS PICERL model does the same. Recovery before a forensic image, or restore from a dirty primary, is how you re-infect the estate and destroy the investigation. Walk the checklist. Record who signed each row, in UTC. This product does not keep a recovery-validation checklist. Last verified 7 September 2026. Not legal advice.
| Check | What 'done' looks like | Do not restore yet if |
|---|---|---|
| Evidence preserved | Memory and disk images exist (or a trained handler recorded why they are not needed), hashes on the chain, original artifacts under hold. The preserve-evidence page on this site is the capture list. | The only copy of the host is the one you are about to rebuild onto. |
| Containment still in force | Scoped systems and accounts remain isolated or equivalently controlled. The contain-versus-observe decision is still the decision, or a logged flip. | The host is back on the production network 'so we can see if it is still broken.' |
| Eradication confirmed | The persistence, malware, or abuse you actually found is removed. Breached accounts are disabled. Credentials were rotated from a clean identity plane — not from the possibly compromised one. Record what you looked for and what you found. | You have not looked, or you are restoring in order to look. Absence of a scanner finding is not confirmation the actor is gone. |
| Restore from known-good | Known-good backup, clean image, or rebuilt media — not a 'refresh' of the copy that was live at detection. Note the backup date and why you believe it predates first access. | The restore source is the compromised volume, an untested snapshot from inside the dwell window, or a backup you have not integrity-checked. |
| Service, logging, monitoring | The service functions. Logging and monitoring are on. The persistence you found is gone on the restored path. Watch for reinfection on a defined window. | Logging is still off, or the only check is 'the site is up.' |
| Originals still held | The compromised artifacts stay under the evidence hold. Recovery of the production path is not permission to wipe the exhibit. | Someone 'cleaned up' the image, the mailbox, or the ticket because production is back. |
| Sign-off | Named person, role, UTC time, and which checks they signed. A later reader should be able to point at this row from the action log. | A group chat 'looks good' with no name and no time. |
What insurers and regulators later ask to see
The action log and the recovery-validation sign-off are how you show what you did, when, who authorised it, and which evidence supports the row. They are working papers, not a filing. Whether a notification duty applies, whether a claim is covered, and whether privilege attaches are questions for counsel on YOUR facts. This page is not legal advice, not coverage advice, and not a regulator form. Last verified 7 September 2026.
- Insurer: contemporaneous records of containment, eradication, and recovery are what a claims handler can reconstruct. Prompt notice and panel-vendor rules live in YOUR policy; the contact-cyber-insurance page on this site is that checklist. This page does not interpret YOUR policy.
- Regulators: FTC Data Breach Response guidance tells US businesses not to destroy forensic evidence during investigation and remediation. GDPR Article 33, when it applies, is a documentation and supervisory-authority filing duty — not this log, and not a clock this page starts. CRA Article 14, when it applies, is a 24-hour / 72-hour / 14-day ladder from recorded awareness; a named human still submits. The first-72-hours and first-week pages on this site walk those clocks.
- The log is evidence of the response. It is not a GDPR notice, not a CRA filing, not an insurance FNOL, and not a determination that any of those duties apply.
- Keep the log with the evidence package. Split folders are how a restore sign-off goes missing in week two.
Where this shows up in ShipReady Metrics
The signed-in app does not keep a containment action log, a recovery-validation checklist, or a forensic incident timeline. It does not isolate a host, eradicate malware, restore from backup, or file with a regulator or insurer. If you already have a session: signed-in app → Compliance → CRA reporting tracks the 24-hour / 72-hour / 14-day ladder from your recorded awareness for findings the org has classified as CRA-in-scope. That ladder is not an action log, it does not start a clock for you, and it is not a determination that CRA applies. A named human still submits. Compliance surfaces also hold evidence artifacts (control-mapped collection and review for SOC 2 / ISO 27001-style programs — not a containment action log and not a recovery-validation checklist). The cyber risk register lives under Security. The obligation map (frameworks you have marked in-scope) is under Compliance. None of those surfaces isolates a host or signs off a restore.
Primary sources (last verified 7 September 2026)
Every operational claim on this page is taken from one of these. If a later revision of a source changes the advice, the date above is how you can see we have not re-checked yet.
NIST SP 800-61 Revision 2 remains the current final Computer Security Incident Handling Guide (August 2012) this cluster cites for sequencing containment, eradication, and recovery, and for documenting what was done, who authorised it, and when — guidance, not a statute, last verified still final on 7 September 2026. CISA's Federal Government Cybersecurity Incident and Vulnerability Response Playbooks are operational procedures written for US federal civilian executive branch information systems; CISA notes other organizations may use them to standardize practice. ISO/IEC 27035 is a standard of guidelines for information security incident management (the current foundation part is ISO/IEC 27035-1:2023, principles and process); it is not a law, is not reproduced here, and the full text is paywalled. The SANS Incident Handler's Handbook (Patrick Kral) is a practitioner PICERL checklist, not a standard; this cluster cites it for containment then eradication then recovery. The FTC Data Breach Response guide is US regulator guidance: do not destroy forensic evidence during investigation and remediation.
Frequently asked questions
What should you record for every containment, eradication, and recovery action?
Who performed it (and who authorised it), what the move was, when in UTC, why it was taken, and an evidence ID a later reader can pull. Tag the row as containment, eradication, or recovery. Record whether it is reversible and how to undo it. Corrections are new rows. NIST SP 800-61r2 asks for a chronology of actions and decisions — guidance, not a statute. This product does not keep that log. Not legal advice.
When can you restore a system after a breach?
After evidence is preserved, containment is still in force, and eradication is confirmed — then restore from known-good media, not the dirty primary. Validate that the service functions, logging is on, and the persistence you found is gone. Keep the original artifacts under hold. NIST SP 800-61r2 and SANS PICERL put recovery after containment and eradication. A 'the site is up' feeling is not the checklist. Not legal advice.
Does isolating a host mean you can reimage it?
No. Isolation is containment: take the host, account, or path off the production network so the actor cannot use it, while the evidence stays. Reimaging before a forensic image exists is eradication dressed as containment and destroys volatile and disk evidence. The preserve-evidence page on this site is the capture list. FTC guidance: do not destroy forensic evidence during investigation and remediation. Not legal advice.
Does ShipReady Metrics keep a containment action log or recovery-validation checklist?
No. The signed-in app does not keep a containment action log, a recovery-validation checklist, or a forensic incident timeline. It does have Compliance → CRA reporting (the Article 14 24-hour / 72-hour / 14-day ladder from recorded awareness for CRA-in-scope findings), evidence artifacts on compliance surfaces, a cyber risk register under Security, and an obligation map under Compliance. None of those is an IR action log. Not legal advice.
Is this legal advice?
No. It is operational guidance distilled from NIST SP 800-61r2, CISA incident-response playbooks, ISO/IEC 27035 (named as a standard of guidelines; the full text is paywalled), the SANS Incident Handler's Handbook, and the FTC Data Breach Response guide. Whether a log is admissible, whether privilege attaches, whether a notification or coverage duty applies, and which firm to retain are questions for counsel on YOUR facts. This page does not rank DFIR firms and does not start a notification clock.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.