When the breach happens — and it will — your organization's ability to respond in an organized, documented, legally sound way determines whether the incident becomes a recoverable event or an existential crisis.
NIST SP 800-61 Rev. 2 defines the foundational incident response framework. The six phases are not sequential — in a real incident, you may Detect while still Containing, and loop back to Detect as new information emerges. The lifecycle is iterative, not linear.
Severity classification drives resource allocation and communication escalation. P1 (Critical): Active breach, data exfiltration ongoing, ransomware spreading — immediate executive and CIRT notification, 24/7 response. P2 (High): Confirmed compromise with limited scope — business hours response, daily executive updates. P3 (Medium): Suspicious activity requiring investigation — normal business response. P4 (Low): Potential precursor activity — monitor and document.
Immediate system shutdown stops the attack but destroys volatile memory evidence (running processes, network connections, encryption keys). Forensic preservation of live systems takes time but captures crucial evidence. GRC professionals must know when each approach is appropriate — legal hold requirements, regulatory forensic obligations, and operational recovery needs must all be balanced.
Build and maintain IR capability before incidents occur: IR plan, CIRT roster with 24/7 contacts, communication templates, forensic tools, legal retainer, pre-negotiated IR firm contract (reduced response time), tabletop exercises quarterly, IR playbooks for common attack types (ransomware, BEC, data exfiltration).
Initial triage: Is this a true positive? What type of incident? What is the scope? Who is affected? What data may be involved? Categorize and classify severity. Assign incident commander. Begin timeline documentation. Log all actions in the incident ticket — the documentation starts here.
Short-term containment: isolate affected systems from the network without powering off (preserve volatile evidence). Long-term containment: patch or remediate the root cause while keeping business operations running. Network segmentation, account disabling, access revocation. Carefully consider whether to notify the attacker (monitoring vs blocking).
Remove all attacker artifacts: malware, backdoors, unauthorized accounts, persistence mechanisms, rogue scheduled tasks. Verify clean state through forensic examination. Do not assume the initial malware removal is complete — sophisticated attackers deploy multiple persistence mechanisms.
Restore systems to operation from clean state. Test restored systems before returning to production. Increase monitoring during the recovery period — attackers often re-compromise recovered systems. Phased recovery: restore most critical systems first.
Conduct within 2 weeks of containment: what happened? What was the root cause? What went well? What failed? What would be done differently? Update the IR plan with lessons learned. Identify control improvements. Close the feedback loop. File a final incident report.
Forensic evidence collected during incident response may be needed for legal proceedings, regulatory investigations, or internal disciplinary action. Chain of custody requirements:
Use forensically sound acquisition methods: bit-for-bit disk imaging with write blockers, RAM capture tools for volatile memory, network packet captures. Hash verification (SHA-256) of all acquired evidence immediately after collection.
Document every person who accessed evidence, when, and why. Unbroken chain of custody is required for evidence to be admissible. Any gap in documentation may invalidate evidence in legal proceedings.
Store evidence in locked, access-controlled storage. Log all access. Maintain originals — work only from forensic copies. Retain evidence according to legal hold requirements (typically minimum 3 years for litigation).
Hardware or software write blockers prevent any modification to evidence media during acquisition. Without write blockers, acquisition tools may modify metadata (access timestamps), invalidating the evidence.
Incident communications are governed — not improvised. A structured communication plan prevents regulatory exposure and controls the narrative:
| Audience | Timing | Channel | Content |
|---|---|---|---|
| CIRT team | Immediate | Secure out-of-band (Signal, separate email) | Technical details, tasks, timeline |
| Executive leadership | Within 1 hour (P1) | Direct call + email | Business impact, scope summary, resource needs |
| Legal counsel | Within 2 hours (P1) | Attorney-client privileged channel | Full details — privilege protects forensic reports |
| Regulators (GDPR) | Within 72 hours of awareness | Formal regulatory notification portal | Scope, categories of data, approximate numbers |
| Affected individuals | Per regulatory requirement | Direct notification (email/mail) | What happened, what data, what to do |
| Public/media | Only through approved PR process | Press release / designated spokesperson | Controlled narrative, no technical details |
Never communicate incident details through normal email or Slack if the attacker may have compromised those channels. Establish out-of-band communication at the beginning of every P1 incident.
Your company has just detected a ransomware incident. You are the IR lead on a live CIRT bridge call at 3 AM. Complete each IR execution task — from containment through regulatory notification through post-incident deliverables — with the urgency and precision real incidents demand.