Purpose of the Checklist
Your team just brought systems back online after a security incident. Business units are celebrating, and the board wants an "all clear" statement. Your CEO is asking if you can return to normal operations.
Before declaring the breach closed, use this checklist to verify that you've completed three distinct forms of recovery: operational, adversary, and governance. This checklist helps prevent the common mistake of confusing service restoration with security recovery.
This isn't a technical rundown of forensic procedures. It's a decision framework to document the evidence you have, acknowledge remaining uncertainties, and assign accountability for residual risk before informing stakeholders that the incident is over.
Prerequisites
Before using this checklist, ensure you have:
- Completed initial containment: Immediate threat activity has stopped, even if the full scope of compromise isn't yet understood.
- Restored critical services: Business operations are running again, even if in a degraded or monitored state.
- Engaged forensics or incident response support: You have visibility into what the attacker did, even if the investigation isn't complete.
- Identified an accountable executive: Someone with authority to accept residual risk and approve closure.
You don't need perfect information to use this checklist. You need enough visibility to make an informed risk decision and document what you still don't know.
The Checklist
Copy this into your incident management platform or use it as a closure gate before your final executive briefing.
Operational Recovery
☐ Critical services restored
List which systems are back online and which remain offline or in degraded mode.
☐ Service restoration documented
Record whether systems were rebuilt from known-good backups, restored from snapshots, or brought back with in-place remediation. Note which approach was used for each critical system.
☐ User access re-enabled
Document which user populations have been granted access and which remain restricted.
☐ Business continuity plan executed
Confirm that your business continuity procedures were followed and that any deviations are logged.
Adversary Recovery
☐ Initial access vector identified
Document how the attacker first entered the environment. If unknown, state that explicitly and note what compensating monitoring is in place.
☐ Compromised credentials rotated
List which credentials were confirmed compromised and verify they've been reset. Include service accounts, API keys, cloud tokens, and privileged accounts.
☐ Persistence mechanisms removed
Document what persistence techniques were found (scheduled tasks, registry modifications, backdoor accounts, tampered monitoring agents) and verify removal with evidence.
☐ Identity systems validated
Confirm that Active Directory, Azure AD, or other identity platforms were checked for unauthorized changes, dormant privileged accounts, or group membership modifications.
☐ Network egress reviewed
Verify that firewall rules, VPN configurations, and remote access tools were audited for unauthorized changes or new outbound connections.
☐ Endpoint integrity confirmed
Document which endpoints were reimaged, which were forensically cleared, and which remain in a monitored-but-uncertain state.
☐ Residual adversary risk documented
If you cannot confirm complete eviction, state what uncertainty remains and what monitoring or containment controls are in place to detect re-entry.
Governance Recovery
☐ Root cause control failure identified
Name the specific control gap, governance decision, or risk acceptance that enabled the breach. Examples: unpatched vulnerability with a known CVE, weak MFA enforcement, unmanaged Business Associate access, delayed security logging.
☐ Ownership assigned
Assign a named executive or department head to own the remediation of the root cause control failure.
☐ Remediation deadline set
Establish a realistic timeline for closing the control gap and schedule executive review checkpoints.
☐ Compensating controls documented
If the root cause cannot be immediately remediated, document what temporary controls are in place and who is monitoring them.
☐ Board or executive briefing completed
Confirm that leadership understands the difference between operational uptime and security recovery, and that they have accepted documented residual risk.
Breach Closure Decision
☐ Evidence package prepared
Compile a summary document that includes: incident timeline, confirmed adversary actions, systems restored, credentials rotated, persistence removed, root cause identified, and residual risk accepted.
☐ Residual risk formally accepted
Obtain written acknowledgment from an accountable executive that they understand what uncertainty remains and accept the decision to declare recovery.
☐ Post-incident review scheduled
Set a date (typically 30-90 days post-closure) to review whether residual monitoring detected any signs of adversary return or whether governance remediation is on track.
Customizing the Checklist
If you operate in a critical infrastructure or OT environment, add a section for Safety and Operational Technology Recovery that includes:
- Verification that OT systems were isolated during the incident
- Confirmation that engineering workstations were validated before reconnecting to operational networks
- Documentation of any safety systems that were taken offline and the process used to restore them
If your organization is a Covered Entity or Business Associate, add a HIPAA Compliance Recovery section:
- Confirm whether the breach met the threshold for reporting under the Breach Notification Rule
- Document whether OCR notification and individual notification timelines were met
- Verify that any required Business Associate notifications were completed
If you're managing a ransomware incident specifically, add:
- Confirmation that decryption was completed or that affected systems were rebuilt
- Documentation of whether ransom was paid and, if so, which executive authorized payment
- Verification that any third-party decryption tools were validated and that decrypted data integrity was confirmed
Validation Steps
Before declaring the incident closed:
Review the checklist with your incident response team. Identify any items marked incomplete or uncertain. If more than two items in the Adversary Recovery section remain unresolved, consider whether you're declaring closure prematurely.
Present the evidence package to your executive sponsor. Walk through what you know, what you don't know, and what compensating controls are in place. If the executive asks "Are we back up?" follow it with "What evidence do we have that we're safe enough to be back up?"
Schedule your post-incident review. Don't let governance recovery drift into a lessons-learned document that no one reads. Assign a date, an owner, and executive oversight.
Archive the checklist with your incident documentation. If the same adversary returns or if a similar incident occurs, this record will show what you knew, what you accepted, and what you committed to fix.
Operational recovery is necessary. Rebuilding trust takes longer. Improving resilience requires changing the conditions that made the breach possible. This checklist helps you complete all three before you tell your organization the breach is over.
