Incident response begins before the incident and continues after recovery

Preparation changes the outcome

Teams need roles, decision authority, trusted communication, logging, asset context, contact paths, recovery priorities, legal and privacy coordination, and exercises before a crisis. A document nobody can access during an outage is not a working plan.

Respond to evidence, not adrenaline

Validate the event, protect people and critical services, preserve evidence, contain affected access, understand scope, and choose eradication and recovery steps appropriate to the incident. Containment can change evidence or operations, so the reason and timing should be recorded.

Recovery is not the finish line

Verify restored systems and identities, monitor for recurrence, communicate bounded facts, meet applicable obligations, and review what failed across technology, process, and decisions. NIST SP 800-61 Rev. 3 places incident response throughout CSF 2.0 risk management rather than treating it as a standalone emergency checklist.

Keep a decision log during the incident

Record what was known, who had authority, which action was taken and what consequence the team expected. A short contemporaneous note is more reliable than rebuilding the reasoning after recovery. The log also helps legal, privacy, communications and business owners coordinate without turning an unverified indicator into a public fact.

Verify normal operation before declaring recovery

Restoring service is not the same as restoring trust. Confirm critical identities, dependencies, data integrity, monitoring and the absence of the known access path before returning to ordinary operations. Then convert lessons into owned changes with dates. A post-incident review should improve the system, not merely retell the chronology.

Example: containment can disrupt the business

Disabling a shared identity service may stop attacker access and also lock out responders or critical operations. The team needs asset context, alternative communication and an authorized decision owner before taking a broad action. A narrower containment may preserve service but leave more risk. Recording the tradeoff makes the decision reviewable even when the evidence is incomplete.

Turn the review into owned change

A lesson such as “improve logging” is too vague to close. Name the missing event, affected system, owner, due date and test that will show the change works. Do the same for contact paths, recovery dependencies and policy gaps. The after-action process is successful when the next exercise or incident has better options, not when the meeting produces a polished summary.