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.

Severity levels. An IR plan defines levels (for example Sev1 critical, Sev2 significant, Sev3 minor) so each level triggers pre-defined response resources, escalation paths and communication requirements in proportion to business impact (functional, information and recoverability impact, see 4.2.1). Classify on current impact and re-rate when facts change: ransomware confined to non-production servers may rate below the top level and be raised if it reaches production or exfiltration is confirmed. No threat category is automatically the top level, and no confirmed compromise skips formal IR. Typical flow: triage and validate the alert as a true positive, declare an incident against the organization's criteria, escalate to the IR lead and notify required stakeholders, then engage the response team according to severity. A confirmed compromise that meets the policy definition (for example active C2 beaconing from a workstation) is declared at once; do not wait for confirmed exfiltration.

Incident Response Report Structure:

A formal IR report documents the full incident for legal, regulatory, management, and future-prevention purposes. It is produced after the incident is resolved, not as a real-time response tool, and it is distinct from the post-incident review meeting, which uses the report as input for lessons learned:

Communications — Legal, Regulatory, and External:

⚠️ 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.

Communication Plan: Designated Contacts

The communications table above shows when each party is told. A communication plan also identifies the stakeholders and names who speaks to each outside party, before an incident happens:

• Legal team — engaged at declaration; can direct the investigation to protect privilege and decides notification obligations.
• Public relations — one designated spokesperson (with a backup) for the media. Everyone else refers media callers to PR and does not comment.
• Regulatory reporting agencies — a formal notification with the required content, by the statutory deadline.
• Law enforcement — contacted by a designated IR contact working with legal, not by users, administrators or system owners. Build the relationship in advance, and normally report to one appropriate agency, since reports to several can cause jurisdictional conflicts.
• Customers — what data was affected, what the organization is doing, and what customers should do.

Notification Order and the Analyst's Role

For a breach of personal data, a typical sequence is legal counsel first (with the cyber-insurance carrier, whose policy may require prompt notice), then regulators within statutory deadlines, then affected individuals with specific protective steps. Law enforcement is contacted through the designated IR contact working with legal; it is not automatically first, and notification does not wait for remediation. The analyst does not decide whether the legal notification threshold is met and does not draft or send customer notices; the analyst supplies the technical facts: which systems were affected, what data was accessible, the timeline, and when the attacker's access was closed. Never delete evidence to limit legal exposure.

Reporting to the Board or Executives. Report a significant incident transparently: what happened, how effective the response was (such as how quickly it was contained), the root cause and the specific improvements under way. Do not minimize a contained incident, omit it to show only positive metrics, or hand the whole report to counsel.

Operational Security Awareness: Communication Channels

Attackers often monitor a victim's email and chat to see whether they have been detected. If those platforms may be compromised, coordinate the response out-of-band: a phone bridge, an in-person war room, or a separate platform the attacker cannot reach. Plan these channels and contact lists in advance. Announcing the response on a compromised channel can prompt the attacker to move laterally or deploy ransomware before containment.

Shift and Incident Handover

Incidents outlast shifts. A handover transfers the incident's full state so the next analyst can continue without repeating actions (such as re-notifying legal) or missing pending ones (such as a host waiting to be reimaged). Record it in the case or ticketing system, not just verbally:

• Current status and a summary of the incident
• Actions taken, by whom and when
• Notifications already made
• Evidence collected, where it is held, and chain of custody
• Related indicators and cases
• Open questions and planned next steps
• Contacts for the system owners involved

Keep one case per incident across shifts. Closing and reopening cases at shift change breaks the record and distorts time-to-close metrics.

Internal Threat Intelligence Reports

An internal threat intelligence report turns outside intelligence into guidance for this organization. It follows the intelligence lifecycle: requirements agreed with stakeholders → collection → analysis against the organization's own assets and exposure → dissemination to the right audiences → feedback. A tailored report states:

• What applies and what does not, and why (the products, sectors and access routes named, compared with what the organization actually runs)
• Whether the organization is actually exposed (for example, are the targeted services internet-facing?)
• Specific actions and owners, written for the audience: business risk for executives, detections and indicators for the SOC

Forwarding a vendor report unchanged, or dismissing it on the first mismatch, is not analysis.

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?