5.2.1. Incident Declaration, Escalation, and Report Structure
💡 First Principle: Formal incident declaration triggers a cascade of obligations — legal notification clocks start, resource commitments are authorized, and communication protocols activate. Declaring too late delays these obligations; declaring too early wastes resources on non-incidents.
Incident Declaration and Escalation
Not every alert is an incident. Organizations define thresholds: a single failed login is an event; a credential spray attack against 500 accounts is an incident. Declaration criteria typically include:
- Confirmed compromise of a system or credential
- Evidence of data exfiltration
- Any ransomware execution
- Any system outage with suspected malicious cause
- Impact above a defined financial, operational, or reputational threshold
Escalation moves incidents up the chain of command as severity increases or when specific expertise is needed. Escalation paths: Tier 1 analyst → Tier 2 (incident lead) → CISO → Executive team → Board (for material incidents). Each level authorizes additional resources and communication.
Incident Response Report Structure:
A formal IR report documents the full incident for legal, regulatory, management, and future-prevention purposes:
| Section | Content |
|---|---|
| Executive Summary | 1–2 paragraph overview: what happened, business impact, key actions taken, current status |
| Who, What, When, Where, Why | Attacker (if known), attack method, timeline, affected systems, attacker objective |
| Timeline | Chronological sequence from initial access to detection to containment to recovery — includes specific dates/times |
| Scope | Which systems, data types, user accounts, and business functions were affected |
| Impact | Financial, operational, reputational, regulatory impact assessment |
| Evidence | Summary of evidence collected, chain of custody documentation reference |
| Recommendations | Specific improvements to prevent recurrence, with assigned owners and timelines |
Communications — Legal, Regulatory, and External:
| Communication Channel | When Required | Content Constraints |
|---|---|---|
| Legal counsel | Immediately upon incident declaration | Maintains attorney-client privilege over investigation communications |
| Customer communication | When customer data is affected; timing per breach notification laws | What data was affected, what the organization is doing, what customers should do |
| Media/PR | When incident becomes public knowledge or media inquires | Approved messaging only; no speculation about cause or attribution before confirmed |
| Regulatory reporting | Varies by regulation: GDPR 72hrs from awareness, SEC 4 business days from materiality determination, HIPAA 60 days | Specific content requirements per regulation |
| Law enforcement | When criminal activity is confirmed or suspected; when national security is involved | FBI for cybercrime; CISA for critical infrastructure; Secret Service for financial crimes |
⚠️ Exam Trap: Regulatory notification timelines are strict and start from discovery, not from confirmed attribution. Under GDPR, a data breach involving EU personal data must be reported to the supervisory authority within 72 hours of becoming aware of it — even if the investigation is incomplete. "We're still investigating" is not a valid reason to delay notification.
Reflection Question: During an IR investigation, the team discovers evidence suggesting an insider may have exfiltrated customer financial records. Legal counsel advises keeping the investigation confidential. However, the organization's GDPR DPO notes that if EU customer PII was involved, a regulatory notification may be required within 72 hours. What competing obligations are in tension here, and how should the organization navigate them?
