COMP 6660 · Enterprise Cybersecurity Incident Response Planning

00 Introduction

Lesson 6.6 examined auditing — the independent verification that controls are designed and operating effectively. This lesson examines what happens when those controls fail: the incident that gets through, the breach that occurs despite prevention. Incident response planning is how the enterprise prepares for that moment.

Every enterprise will experience security incidents. Some will be minor — a phishing email that is reported, a malware detection that is quarantined, a vulnerability that is patched before exploitation. Others will be significant — a ransomware deployment that encrypts critical systems, a data breach that exposes customer records, a supply-chain compromise that provides an adversary with persistent access. The question is not whether incidents will occur; it is how quickly they will be detected, how effectively they will be contained, how decisively they will be recovered from, and whether the enterprise will learn from them.

Incident response planning is the discipline through which enterprises prepare for these moments. It defines the team, the authority, the procedures, the tools, and the communication channels that will be used when an incident occurs. It ensures that response is deliberate and coordinated rather than improvised and fragmented. It establishes the relationships — with legal, with communications, with executive leadership, with external specialists, with regulators — that must be in place before they are needed. And it recognises that the quality of preparation determines the quality of response, which in turn determines the consequence of the incident.

This lesson examines incident response planning in detail. It establishes why incident response planning matters and what happens in its absence. It distinguishes incident response from the activities it is frequently confused with — business continuity, disaster recovery, and crisis management. It examines incident classification and severity — how incidents are categorised and prioritised. It examines the principal frameworks — NIST SP 800-61, ISO/IEC 27035, and the SANS incident handling process. It examines preparation in detail — the team, the tools, the playbooks, the training, and the relationships that must exist before an incident occurs. It examines detection and analysis — how incidents are identified, triaged, and investigated. It examines containment, eradication, and recovery — the phases of active response. It examines post-incident activity — the review, the lessons learned, and the improvement. It examines communication and coordination — the internal and external communication that response requires. It examines regulatory notification and reporting — the obligations that apply when incidents occur. And it closes with the pitfalls that recur across incident response programmes.

The material here builds directly on the threat material in Unit 3, on the infrastructure material in Unit 5, and on the governance, risk, compliance, awareness, and audit material in Lessons 6.1–6.6. It prepares for Lesson 6.8 (business continuity and disaster recovery), which addresses the enterprise-level continuity that incident response feeds into, and Lesson 6.9 (cyber resilience), which addresses the enterprise's ability to withstand and recover from disruption.

01 Learning objectives

By the end of this lesson you should be able to:

These objectives contribute to Unit 6 outcomes U6.5 (incident response planning) and U6.6 (resilience), and to Module 3 outcomes M3.5 and M3.6. See the Unit 6 learning outcomes page for the full mapping.

02 Why incident response planning matters

Incident response planning matters because the difference between a contained incident and a catastrophic breach is frequently the quality of the response. The same initial compromise — a phished credential, an exploited vulnerability, a compromised supplier — can produce outcomes ranging from a brief disruption to a multi-year recovery, depending on how quickly it is detected, how effectively it is contained, and how well the enterprise is prepared.

What incident response failure looks like

Incident response failures are recognisable, and the patterns repeat:

• No plan. The organisation has no documented incident response plan — so response is improvised, inconsistent, and dependent on whoever happens to be available.
• No team. There is no defined incident response team, no clear roles, and no defined escalation path — so no one is accountable and no one coordinates.
• No rehearsals. The plan exists but has never been exercised — so the first time it is used is during a real incident.
• Slow detection. The incident is discovered by an external party — a customer, a journalist, a regulator, or the attacker — rather than by the enterprise's own monitoring.
• Delayed containment. Containment decisions are delayed by uncertainty about authority, by operational concerns, or by fear of the consequences of disconnection.
• Communication failure. Staff, customers, regulators, and the board learn about the incident from the media, from each other, or not at all.
• No evidence preservation. Systems are rebuilt and logs are overwritten before investigation — so the scope of the compromise and the identity of the attacker are never established.
• Premature recovery. Systems are restored before the attacker's access is fully eradicated — so the attacker returns, and the incident recurs.
• No post-incident review. The incident is closed when service is restored, with no analysis of what happened, why, and what should change — so the same incident occurs again.
• Blame rather than learning. The response focuses on identifying who was at fault rather than on what failed and how to improve — producing concealment and defensiveness rather than improvement.

03 What incident response is — and is not

Incident response is frequently conflated with the adjacent disciplines — business continuity, disaster recovery, and crisis management. The distinctions matter because each addresses a different problem, is owned by a different function, and requires a different type of preparation.

The adjacent disciplines distinguished

The disciplines are related and frequently operate simultaneously during a significant incident:

• Incident response addresses the security dimensions — detecting, containing, eradicating, and recovering from the attack.
• Business continuity addresses the operational dimensions — keeping the business functioning while systems are unavailable or degraded.
• Disaster recovery addresses the technology dimensions — restoring systems and data after disruption.
• Crisis management addresses the strategic and reputational dimensions — coordinating the enterprise's response and managing external communication.
• Emergency management addresses the safety and physical dimensions — where the incident has physical consequences.

A ransomware incident, for example, will involve all of them: incident response to contain the attacker and remove the malware; business continuity to maintain critical functions through manual workarounds; disaster recovery to restore encrypted systems from backup; crisis management to coordinate communication and manage the enterprise's response; and — where the organisation operates physical facilities or critical infrastructure — emergency management to address safety implications.

Common misconceptions about incident response

Characteristics of effective incident response

• Prepared. The team, the procedures, the tools, and the relationships exist before the incident occurs — and have been rehearsed.
• Documented. The plan, the playbooks, the roles, and the escalation paths are documented and accessible.
• Exercised. The plan and the playbooks have been tested through tabletop exercises, simulations, and — where feasible — live drills.
• Resourced. The team has the time, the tools, the training, and the external support contracts to respond effectively.
• Empowered. The team has the authority to make containment decisions — including the authority to disconnect systems — and the escalation path for decisions that exceed that authority.
• Coordinated. The response integrates with legal, communications, business continuity, and executive leadership — with defined roles and communication channels.
• Forensically sound. The response preserves evidence that supports investigation, regulatory reporting, and potential legal action.
• Proportionate. The response is proportionate to the severity of the incident — not every incident requires the full response apparatus.
• Learning-oriented. The post-incident review is non-punitive and improvement-focused — so that the enterprise learns rather than blames.
• Improving. The plan and the playbooks are updated based on what incidents and exercises reveal.

04 Incident classification and severity

Not all incidents are equal. An enterprise may receive thousands of security events per day — alerts, anomalies, and suspicious activities — of which only a small proportion are actual incidents, and only a fraction of those are significant. Classification and severity are how the enterprise distinguishes between them.

Events, alerts, and incidents

• Event. An observable occurrence in a system or network — a login, a file access, a network connection, a configuration change. Events are numerous, and most are benign.
• Alert. A notification generated by a monitoring or detection system when an event or pattern matches a defined condition — a rule, a threshold, or an anomaly detection model. Alerts require triage to determine whether they represent a true positive.
• Incident. A confirmed or suspected security event that could result in harm to the enterprise — a compromise, a disruption, a data breach, or an unauthorised action. Incidents trigger the incident response process.
• Near miss. An event that could have resulted in harm but did not — a phishing email that was reported before anyone clicked, a vulnerability that was patched before exploitation, a malware sample that was quarantined. Near misses are valuable learning opportunities and should be reviewed.

Incident classification

Incidents are classified by type, which determines the response procedures and the expertise required:

Incident severity

Severity determines the resources, the escalation, and the urgency applied to the incident. Severity is typically assessed across multiple dimensions:

Severity levels

Escalation criteria

Escalation criteria define when an incident moves from one severity level to another, and when the response escalates to higher authority:

• Initial severity. The severity assigned when the incident is first identified — based on the information available at the time.
• Reassessment. Severity is reassessed as the incident develops — as more is learned about scope, impact, and adversary.
• Escalation triggers. Defined triggers for escalation — data exfiltration confirmed, systems unavailable, regulatory notification likely, executive involvement required, media interest.
• De-escalation. Defined criteria for de-escalation — where the incident is contained and the impact is less than initially assessed.
• Authority. Defined authority for escalating — who can escalate, and to whom.
• Notification. Defined notification requirements upon escalation — who must be informed, and within what timeframe.

Incident categorisation in practice

In practice, classification and severity interact:

• Classification determines the playbook. The incident type determines which response procedures and which expertise are required.
• Severity determines the resources and the escalation. The severity determines who is involved, how quickly, and at what level.
• Both determine the communication. The classification and severity together determine who must be notified, both internally and externally.
• Both may change as the incident develops. Initial classification and severity are provisional — both are reassessed as more is learned.
• Misclassification has consequences. Under-classifying an incident delays the appropriate response; over-classifying consumes resources that may be needed elsewhere.

05 Incident response frameworks

Several published frameworks define how incident response should be structured. They share a common lifecycle — preparation, detection and analysis, containment, eradication, recovery, and post-incident activity — with differences in emphasis, terminology, and level of detail.

The principal frameworks

NIST SP 800-61 — the incident response lifecycle

NIST SP 800-61 defines the incident response lifecycle in four phases:

06 Preparation — the foundation

Preparation is the phase that determines the effectiveness of everything that follows. The team, the tools, the playbooks, the training, and the relationships that exist before an incident occurs determine how well the enterprise responds when it does.

The incident response team

The incident response team is the group of individuals who will coordinate and conduct the response. Its composition depends on the enterprise's size and sector, but typically includes:

The team's authority and mandate

The team's effectiveness depends substantially on its authority:

• Defined authority. The incident response manager has defined authority to make containment decisions — including the authority to disconnect systems — within defined limits.
• Escalation path. Decisions that exceed that authority — shutdown of critical systems, ransom payment, regulatory notification — have a defined escalation path to executive leadership.
• Access. The team has access to the systems, the logs, and the information required to investigate.
• Budget. The team has access to a defined budget for incident response — external specialists, forensic tooling, and emergency expenditure — without requiring approval during the incident.
• Executive sponsorship. The team has visible executive sponsorship — which gives it organisational standing and ensures that its recommendations are taken seriously.
• Protection from interference. The team is protected from interference — including from business units whose systems may be affected by containment decisions.

Tools and capability

The team requires specific tools and capabilities:

• Detection and monitoring. SIEM, EDR, network detection, and threat intelligence — providing the visibility required to detect and investigate.
• Forensic tooling. Disk imaging, memory capture, network capture, and forensic analysis tools — for evidence preservation and investigation.
• Analysis tooling. Malware analysis, log analysis, and timeline analysis tools — for understanding what happened.
• Containment tooling. Network isolation, endpoint isolation, and account disablement — for rapidly containing the incident.
• Communication tooling. Out-of-band communication — conference bridges, secure messaging, and a documented contact list — for coordinating the response when normal channels may be compromised or unavailable.
• Case management. A system for tracking the incident, the evidence, the actions, and the decisions — providing the record the investigation and the post-incident review require.
• Documentation. The incident response plan, the playbooks, the escalation contacts, and the reference materials — accessible when needed.

Playbooks

Playbooks are the documented procedures for responding to specific types of incident. They convert the general incident response plan into actionable steps:

Training and exercises

The team's capability is developed through training and maintained through exercises:

• Initial training. Formal training for team members — incident handling, forensics, tooling, and the enterprise's plan and playbooks.
• Continuing education. Ongoing training as threats, tools, and techniques evolve — including threat intelligence briefings and technical workshops.
• Tabletop exercises. Discussion-based exercises where the team walks through a scenario — testing the plan, the roles, and the decision-making without the pressure of a live environment.
• Simulation exercises. Live exercises where the team responds to an injected scenario — testing the technical capability, the tooling, and the coordination.
• Red team / purple team exercises. Adversarial exercises where a red team attempts to breach the enterprise while the blue team (defenders) responds — testing detection, response, and coordination against a realistic adversary.
• Lessons learned from real incidents. Every real incident — and every exercise — produces lessons that inform training and improve the plan.
• Executive participation. Executive leadership should participate in exercises — particularly those testing the decisions that require executive authority.
• External participation. Where external specialists will be engaged during an incident, they should participate in exercises — so that the relationship and the integration are tested before they are needed.

Relationships and external support

Relationships that must exist before an incident occurs:

• External incident response providers. Retained specialists who can provide surge capability, forensic expertise, or negotiation support — with a contract in place, contacts known, and integration tested.
• Legal counsel. External counsel with incident response, privacy, and regulatory expertise — engaged in advance so that the relationship and the engagement terms are established.
• Forensic specialists. For evidence preservation and analysis — particularly where the incident may result in litigation or regulatory action.
• Public relations. For external communication — particularly where the incident may attract media attention.
• Ransomware negotiation specialists. Where the enterprise may face a ransom demand — with the decision on whether to engage made in advance.
• Regulators. Relationships with the relevant regulators — so that notification is made through established channels, and so that the enterprise understands the regulator's expectations.
• Law enforcement. Relationships with national and local law enforcement — so that reporting and coordination are straightforward.
• Cyber insurance. The insurer and their preferred providers — with the policy terms understood, and the claim process known in advance.
• Cloud and service providers. The providers whose services the enterprise depends on — with their incident response contacts and escalation paths known.
• Critical suppliers. The suppliers whose incidents would affect the enterprise — with notification obligations and coordinated response arrangements.

Documentation and access

Documentation that must be accessible during an incident:

• Incident response plan. The overall plan — the process, the roles, the authority, and the escalation paths.
• Playbooks. The procedures for specific incident types.
• Contact lists. The team, the executive, the legal counsel, the external specialists, the regulators, and the law enforcement — with out-of-band contact details.
• Asset inventory. What systems exist, what they do, who owns them, and how they are connected.
• Network diagrams. How the network is structured, what is segmented, and where the trust boundaries are.
• System documentation. How systems are configured, how they are backed up, and how they are restored.
• Regulatory obligations. What must be reported, to whom, and within what timeframe.
• Contractual obligations. What customers, partners, and suppliers must be notified, and within what timeframe.
• Insurance details. Policy details, contacts, and claim process.
• Communication templates. Pre-drafted communication for common scenarios — internal, customer, regulatory, and media.

Accessibility during an incident

Documentation and tooling must be accessible when normal systems may be unavailable:

• Offline copies. Printed or offline copies of critical documentation — contact lists, playbooks, and escalation paths.
• Out-of-band communication. Communication channels that do not depend on the enterprise's own systems — mobile phones, personal email, secure messaging, and conference bridges.
• Alternate access. Alternate access to systems and tooling — where primary access may be compromised or unavailable.
• Credentials. Emergency credentials — break-glass accounts and emergency access procedures — with appropriate controls and monitoring.
• Location. A defined incident response location or virtual equivalent — where the team can convene.

07 Detection and analysis

Detection and analysis is the phase in which the enterprise determines that an incident has occurred or is occurring, and develops an understanding of what it is, how it happened, and what it affects. Everything that follows depends on the quality of this phase — a misdiagnosed incident produces the wrong response.

Detection sources

Incidents are detected through multiple sources:

Triage

Triage is the initial assessment of an alert or report to determine whether it represents an incident and, if so, how it should be prioritised:

• Validation. Is the alert a true positive? False positives are numerous and consume resources; distinguishing them quickly is essential.
• Classification. What type of incident is it? The classification determines the playbook to apply.
• Initial severity. What is the initial severity assessment? This determines the urgency and the resources.
• Escalation. Does the incident require escalation — to a higher tier of analysis, to the incident response manager, or to executive leadership?
• Assignment. Who will handle the incident? The assignment determines the expertise applied.
• Documentation. The triage decision is documented — what was assessed, what was decided, and by whom.

Investigation

Investigation develops an understanding of the incident:

• What happened? The sequence of events — how the adversary gained access, what they did, and what systems they affected.
• When did it happen? The timeline — when the initial compromise occurred, when the adversary acted, and when the incident was detected.
• How did it happen? The attack vector — the vulnerability, the technique, or the human factor that was exploited.
• What is affected? The scope — which systems, which data, which users, and which business processes.
• Who is responsible? The adversary — their capability, their intent, and their identity where it can be determined.
• What is the current state? Whether the adversary still has access, whether the incident is contained, and whether it is escalating.
• What is the potential for further harm? The trajectory — what the adversary could do next if not contained.

Evidence collection

Evidence collection is conducted throughout detection and analysis — and continues through containment and eradication:

• Preserve before you act. Where feasible, evidence is preserved before systems are changed, isolated, or rebuilt — because the changes may destroy the evidence.
• Evidence types. Disk images, memory captures, network captures, logs, configuration data, and artefacts — collected using forensically sound methods.
• Chain of custody. Evidence is documented — who collected it, when, how, and where it has been stored — so that it can be relied upon in investigation and in legal proceedings.
• Volatility order. Evidence is collected in order of volatility — from most volatile (memory, network connections) to least volatile (disk, backups).
• Scope. Evidence collection should be broad enough to support the investigation — including systems that may be affected but are not yet confirmed.
• Legal considerations. Where the incident may result in litigation, evidence collection should be conducted with legal guidance — and with privilege considerations in mind.

Analysis techniques

• Log analysis. Analysing logs from systems, applications, and security tools — to identify the sequence of events and the adversary's activity.
• Timeline analysis. Constructing a timeline of events — establishing the sequence and identifying the key moments.
• Malware analysis. Analysing malware samples — to determine their capabilities, their indicators, and their persistence mechanisms.
• Memory analysis. Analysing memory captures — to identify running processes, network connections, and injected code.
• Network analysis. Analysing network traffic — to identify command-and-control, lateral movement, and data exfiltration.
• Threat intelligence correlation. Correlating indicators and techniques with threat intelligence — to identify the adversary and their known capabilities.
• Root cause analysis. Determining how the adversary gained access — the vulnerability, the technique, or the human factor that was exploited.
• Scope determination. Determining the full extent of the compromise — which systems, accounts, and data are affected.

Investigation challenges

Investigation is conducted under difficult conditions:

• Incomplete information. The investigation begins with partial information — and the picture develops over time.
• Adversary countermeasures. Sophisticated adversaries take steps to impede investigation — clearing logs, using legitimate tools, and operating quietly.
• Time pressure. The investigation must be conducted while the incident is ongoing — and while decisions about containment may be required.
• Operational pressure. The business may be pressing for restoration — which may conflict with the investigation's need to preserve evidence.
• Scale. In a large environment, the investigation may need to cover thousands of systems — requiring automation and prioritisation.
• Complexity. Modern environments — cloud, containers, third-party services — complicate the investigation.
• Adversary deception. Some adversaries deliberately plant false indicators — leading the investigation in the wrong direction.

Communicating during detection and analysis

Throughout detection and analysis, communication is ongoing:

• Initial notification. The incident response manager, the CISO, and — where severity warrants — executive leadership are notified.
• Status updates. Regular status updates to the stakeholders — what is known, what is being done, and what is required.
• Escalation. Where the incident escalates — in severity, in scope, or in consequence — the escalation is communicated promptly.
• Legal and regulatory engagement. Legal counsel and, where necessary, regulators are engaged early — particularly where notification obligations may apply.
• Documentation. All decisions and communications are documented — providing the record for the post-incident review and for any regulatory or legal process.

08 Containment, eradication, and recovery

Containment, eradication, and recovery are the phases in which the enterprise acts directly against the incident — limiting its scope, removing the adversary, and restoring normal operation. These phases involve the most consequential decisions of the response.

Containment

Containment limits the scope and impact of the incident — preventing it from spreading and preventing the adversary from causing further harm:

• Short-term containment. Immediate action to stop the spread — isolating affected systems, disabling compromised accounts, and blocking malicious traffic. Short-term containment is applied quickly, sometimes before full analysis is complete.
• Long-term containment. Sustained measures — implementing temporary controls, applying temporary patches, and maintaining the isolation until eradication and recovery can be completed.
• Containment strategy. The approach to containment — which systems to isolate, which to disconnect, which to monitor, and which to leave in place under observation.
• Containment trade-offs. The decisions involve significant trade-offs — between speed and evidence preservation, between containment and operational continuity, and between security and business consequence.

Containment decisions and trade-offs

The appropriate decision depends on the circumstances:

• Where the adversary is causing active harm — data exfiltration, ransomware deployment, destructive activity — containment is urgent. Speed takes precedence over completeness.
• Where the adversary is dormant or is being observed — containment may be delayed to understand scope and to gather intelligence. Completeness takes precedence over speed.
• Where the adversary is sophisticated and persistent — containment must be complete before it is applied. Partial containment alerts the adversary, who may have other access and may adapt.
• Where the enterprise has inadequate visibility — containment may be the safest option. If the enterprise cannot see the adversary's full footprint, containing what is visible may be the prudent choice.
• Where operations are critical and cannot be interrupted — containment may involve monitoring and controlled degradation rather than disconnection. The operational consequence must be weighed against the security consequence.

Eradication

Eradication removes the adversary's access and the malicious artefacts from the environment:

• Remove the adversary's access. Revoke credentials, remove persistence mechanisms, remove backdoors, and remove malicious accounts.
• Remove malicious artefacts. Remove malware, remove malicious files, and remove unauthorised software.
• Address the vulnerability. Patch the vulnerability, correct the misconfiguration, or remediate the human factor that was exploited.
• Verify eradication. Confirm that the adversary's access has been removed and that the malicious artefacts are gone — through scanning, through analysis, and through monitoring.
• Rebuild where necessary. Where a system cannot be trusted — because the adversary had administrative access, or because the compromise is extensive — rebuild from a known-good state rather than attempting to clean.
• Coordinate with recovery. Eradication and recovery are frequently conducted together — with systems rebuilt from known-good images as part of both.

Recovery

Recovery restores affected systems and services to normal operation:

• Restore from backup. Restore data and systems from backups — verifying that the backups are clean and that they have not been affected by the incident.
• Rebuild from known-good images. Where systems cannot be trusted, rebuild from known-good images rather than restoring from potentially compromised state.
• Patch and harden. Apply patches and hardening before returning systems to service — to prevent recurrence.
• Verify integrity. Verify that restored systems are operating correctly and that the adversary's access has not been re-established.
• Monitor closely. Monitor restored systems closely for signs of recurrence — the adversary may attempt to return.
• Restore in phases. Where possible, restore systems in phases — so that problems are identified before the whole environment is returned to service.
• Communicate restoration. Communicate the restoration to users, to the business, and to external parties — including the status of any remaining limitations.
• Maintain heightened monitoring. Maintain heightened monitoring after restoration — because recurrence is common.

Decision-making under pressure

Containment, eradication, and recovery decisions are made under pressure — with incomplete information, with the adversary actively working against the enterprise, and with significant consequences for each choice:

• Defined authority. The decisions are made within a defined authority structure — so that the incident response manager can act and so that decisions exceeding that authority escalate promptly.
• Consultation. Where the decision has operational consequence, the business and operational leadership are consulted — and their input is weighed against the security consequence.
• Documentation. Decisions are documented as they are made — what was decided, why, by whom, and with what information.
• Escalation. Decisions that exceed the incident response manager's authority — shutdown of critical systems, ransom payment, public disclosure — escalate to executive leadership.
• Reversibility. Where possible, decisions are made to be reversible — so that options are preserved.
• Pre-decision where possible. Where decisions can be made in advance — ransom policy, shutdown criteria, disclosure policy — they should be made before the incident, when there is time to think clearly.

Ransomware-specific considerations

Ransomware incidents involve specific decisions that should be addressed in advance:

• Ransom payment policy. Whether the enterprise will pay a ransom — a decision that should be made by the board in advance, with consideration of legal, ethical, and regulatory implications.
• Legal considerations. In some jurisdictions, paying a ransom to a sanctioned entity is illegal. Legal counsel must be engaged before any payment decision.
• Negotiation. Whether to engage a negotiation specialist — and what the enterprise's objectives are in negotiation.
• Recovery from backup. Whether the enterprise can recover from backup — and how long that will take.
• Decryption. Whether to attempt decryption using attacker-provided tools — which may be incomplete or may introduce additional malware.
• Notification. Whether the incident triggers regulatory notification — and whether the ransom demand constitutes extortion requiring law enforcement notification.
• Communication. What to communicate — to employees, to customers, to regulators, and to the media.

Coordination with business continuity

Containment, eradication, and recovery are coordinated with business continuity:

• Continuity activation. Where the incident affects critical business functions, business continuity is activated — maintaining operations while systems are unavailable.
• Manual workarounds. Business continuity provides manual workarounds — permitting the enterprise to operate while systems are restored.
• Prioritisation. Recovery is prioritised according to business continuity requirements — restoring the systems that support critical functions first.
• Communication. Business continuity and incident response communicate continuously — so that the business knows the status of restoration and so that the incident response team understands the operational priorities.
• Unified command. Where the incident is significant, incident response and business continuity may operate under unified command — with clear leadership and coordination.

09 Post-incident activity

Post-incident activity is where the enterprise converts an incident into improvement. It is frequently the most neglected phase — because attention moves on once service is restored — and it is where the long-term value of the incident is realised.

The post-incident review

The post-incident review — frequently called a "lessons learned" session or a "post-mortem" — is a structured examination of the incident and the response:

• Timing. Conducted soon after the incident is resolved — while memories are fresh and while the details are available. Where the incident is prolonged, interim reviews may be conducted during the response.
• Participants. Everyone involved in the response — the incident response team, the business, IT operations, legal, communications, and any external specialists.
• Scope. What happened, how it was detected, how it was responded to, what worked, and what did not.
• Non-punitive. The review is conducted on the basis that the objective is learning, not blame. Participants must feel able to speak honestly about mistakes and near-misses.
• Documentation. The review is documented — the findings, the recommendations, and the actions — so that the improvements are tracked.
• Action. The review produces specific, owned, and tracked actions — not merely observations.

Questions the review should answer

Lessons learned and improvement

The review produces improvements across multiple dimensions:

• Detection improvement. New detection rules, new monitoring coverage, and new threat intelligence sources — addressing the gaps the incident revealed.
• Prevention improvement. New controls, hardened configurations, and closed vulnerabilities — addressing the root cause.
• Response improvement. Updated playbooks, improved procedures, and clarified authority — addressing what did not work in the response.
• Preparation improvement. Additional training, new tools, and new relationships — addressing the capability gaps the incident revealed.
• Communication improvement. Improved templates, clearer roles, and better channels — addressing the communication failures.
• Governance improvement. Updated policy, clarified authority, and improved reporting — addressing the governance weaknesses.
• Risk register update. The incident informs the risk register — updating the assessment of likelihood and impact, and adding risks the incident revealed.
• Audit and assurance. The incident informs audit planning — identifying areas that require independent assessment.

The improvement cycle

Post-incident improvement is a cycle, not a one-time activity:

10 Communication and coordination

Communication is one of the most consequential and most frequently mishandled elements of incident response. How the enterprise communicates — internally and externally, during and after the incident — has a significant and lasting effect on the outcome.

Communication principles

• Prepare in advance. The channels, the roles, the templates, and the approval processes are defined before the incident — so that communication is deliberate rather than improvised.
• Communicate early. Early communication — even when the facts are incomplete — is better than delayed communication that allows rumour and speculation to fill the vacuum.
• Be accurate. Communicate what is known, acknowledge what is not known, and commit to updating. Inaccurate communication damages credibility irreparably.
• Be consistent. All communication channels — internal and external — deliver consistent messages. Inconsistency creates confusion and erodes trust.
• Be timely. Different audiences require different timeframes — the executive, the board, the regulator, the customer, the employee — and each has defined timeframes for notification.
• Be transparent. Transparency about what happened, what is being done, and what the enterprise will change builds and maintains trust.
• Be compassionate. Where the incident affects individuals — customers, employees, patients — communication should acknowledge the impact and treat those affected with respect.
• Be coordinated. Communication is coordinated through a single function — so that messages are consistent and so that no stakeholder hears conflicting information.
• Be documented. All communication is documented — what was communicated, to whom, when, and by whom.
• Be legally informed. Communication is reviewed by legal counsel — particularly where the incident may result in litigation or regulatory action.

Internal communication

Internal communication ensures that the people who need to know are informed:

External communication

External communication requires coordination with legal and communications functions — and careful consideration of what to say, to whom, and when:

Communication roles and responsibilities

Communication roles must be defined in advance:

• Incident response manager. Coordinates internal operational communication — keeping the team informed and ensuring that information flows to the right people.
• Executive sponsor. Communicates with the board and with other executives — and makes the decisions that require executive authority.
• Legal counsel. Advises on legal obligations and reviews communication for legal risk — particularly with respect to regulatory notification, privilege, and litigation.
• Communications lead. Manages external communication — developing messages, coordinating with media, and ensuring consistency across channels.
• Customer relationship owners. Communicate with affected customers — with the information and the messaging provided by the communications lead.
• Spokesperson. A defined spokesperson — frequently the CEO or a senior executive — for external communication, particularly with the media.
• HR. Communicates with employees — particularly where employee data is affected or where insider involvement is suspected.

Communication challenges

• Incomplete information. Communication is required before the full picture is known — requiring careful framing of what is known and what is not.
• Legal constraints. Legal counsel may constrain what can be communicated — particularly where the incident may result in litigation.
• Conflicting priorities. Security may want to communicate one message; the business may want another; legal may want a third. These conflicts must be resolved in advance.
• Speed pressure. Regulatory and contractual notification timeframes are frequently short — requiring rapid communication.
• Adversary monitoring. Adversaries monitor communication — what the enterprise says may inform their actions.
• Media pressure. Media interest may be intense — requiring a defined media strategy and a prepared spokesperson.
• Employee anxiety. Employees may be anxious about job security, about their own data, or about what the incident means — requiring clear and reassuring communication.
• Customer trust. How the enterprise communicates may determine whether customers stay — requiring communication that demonstrates competence, honesty, and commitment.

Coordination with external parties

Significant incidents frequently involve coordination with external parties:

• External incident response providers. Coordinating the external specialists with the internal team — with clear roles, clear reporting, and clear integration.
• Legal counsel. Coordinating legal advice with the technical response — so that evidence is preserved and so that communication is legally sound.
• Law enforcement. Coordinating with law enforcement — which may have its own investigation, its own priorities, and its own requirements for evidence.
• Regulators. Coordinating with regulators — who may provide guidance, may require specific actions, and may have their own investigation.
• Other affected organisations. Where the incident affects other organisations — through a shared supplier, through a shared vulnerability, or through the adversary's campaign — coordinating with them.
• Cloud and service providers. Coordinating with the providers whose services are involved — for investigation, for containment, and for recovery.
• Cyber insurers. Coordinating with the insurer — for claim processing and for access to the insurer's preferred providers.

11 Regulatory notification and reporting

Incidents trigger notification and reporting obligations — to regulators, to customers, to affected individuals, and to other parties. These obligations have defined timeframes, defined content, and defined consequences for failure.

The obligation landscape

Assessing notification obligations

Determining whether an incident triggers notification requires assessment against multiple regimes simultaneously:

• Identify applicable regimes. Which jurisdictions, which sectors, which contractual relationships — each may impose its own obligations.
• Determine the trigger. Does the incident meet the threshold for notification under each regime — personal data breach, significant incident, material impact?
• Determine the timeframe. What is the timeframe under each regime — hours, days, or "as soon as feasible"?
• Determine the recipient. Who must be notified — regulator, data subject, customer, law enforcement?
• Determine the content. What must be included in the notification — facts, consequences, measures taken, contact information?
• Determine the consequences of failure. What are the penalties for late or inadequate notification?
• Document the assessment. Document the analysis and the decision — whether notification is required and why.

Notification content

Notification typically requires:

• Nature of the incident. What happened — described accurately and without unnecessary technical detail.
• Categories and volume of data. What data was affected, and how many individuals are affected.
• Consequences. What the likely consequences are for the affected parties.
• Measures taken. What the enterprise has done to address the incident and to mitigate its effects.
• Measures recommended. What the affected parties should do to protect themselves.
• Contact information. Where affected parties can obtain further information.
• Timing. When the incident occurred and when it was detected.

Preparing for notification

Notification obligations should be addressed in preparation:

• Identify the obligations. Determine which regimes apply, what the triggers are, and what the timeframes are — before an incident occurs.
• Establish relationships. Establish relationships with the relevant regulators — so that notification is made through established channels.
• Prepare templates. Prepare notification templates — so that notification can be made rapidly when required.
• Define the process. Define the process for assessing notification obligations — who assesses, who decides, who approves, and who notifies.
• Define the authority. Define who has the authority to determine that notification is required — and who has the authority to approve the notification.
• Rehearse. Exercise the notification process — so that it functions under pressure.
• Integrate with legal. Integrate the notification process with legal counsel — so that notification is legally sound.

Notification challenges

• Short timeframes. Notification timeframes of 24 or 72 hours are very short — requiring rapid assessment and decision-making.
• Incomplete information. Notification may be required before the full facts are known — requiring careful framing and a commitment to update.
• Multiple regimes. A single incident may trigger obligations under multiple regimes — with different timeframes, different recipients, and different content requirements.
• Conflicting obligations. Different regimes may require different or conflicting communication — particularly where legal privilege considerations apply.
• Uncertainty about the trigger. Determining whether an incident meets the threshold for notification can be difficult — particularly where the harm is uncertain.
• Consequences of failure. Failure to notify — or late or inadequate notification — is frequently treated more severely than the underlying incident.
• Adversary monitoring. Notification may inform the adversary — particularly where the notification describes the enterprise's response.

Reporting obligations beyond notification

Incidents may trigger reporting obligations beyond initial notification:

• Follow-up reports. Some regimes require follow-up reports — additional detail, investigation findings, and remediation status.
• Periodic reporting. Some regimes require periodic reporting on the incident and its remediation — until the incident is closed.
• Final reports. Some regimes require a final report when the incident is resolved — documenting the cause, the impact, and the remediation.
• Certification. Some regimes require the enterprise to certify that it has complied with its obligations — with executive accountability.
• Board reporting. Significant incidents are reported to the board — with the detail the board requires to exercise its oversight responsibilities.
• Audit committee reporting. The audit committee receives reporting on the incident — particularly where the incident reveals control weaknesses.

12 Common pitfalls

Incident response programmes fail in predictable ways. Recognising the pitfalls accelerates improvement.

Pitfall 1 — No plan, or a plan that has never been exercised

A documented plan that has never been tested — so that the first time it is used is during a real incident, when there is no opportunity to discover that it does not work.

Mitigation: Exercise the plan regularly — through tabletop exercises, simulations, and live drills. Update the plan based on what the exercises reveal.

Pitfall 2 — No defined team or unclear roles

No defined incident response team — so that during an incident, it is unclear who is in charge, who does what, and who escalates to whom.

Mitigation: Define the team, the roles, the responsibilities, and the escalation paths. Document them. Exercise them.

Pitfall 3 — Insufficient authority

An incident response team that lacks the authority to make containment decisions — so that the response is delayed while decisions are escalated.

Mitigation: Define the authority explicitly. Document what the incident response manager can decide and what escalates. Ensure the authority is understood and respected.

Pitfall 4 — Slow detection

Incidents discovered by external parties — a customer, a journalist, a regulator — rather than by the enterprise's own monitoring.

Mitigation: Invest in detection capability — SIEM, EDR, NDR, threat intelligence, and threat hunting. Measure and improve detection times. Monitor for the indicators that matter.

Pitfall 5 — Premature containment

Containing the incident before understanding its scope — alerting the adversary, who has other access, and destroying evidence of the full extent of the compromise.

Mitigation: Analyse before containing where the adversary is not causing active harm. Where containment is urgent, document the trade-off and accept that the investigation may be incomplete.

Pitfall 6 — Evidence destroyed

Systems rebuilt or logs overwritten before evidence is preserved — so that the scope of the compromise and the identity of the attacker are never established.

Mitigation: Preserve evidence before making changes. Define the evidence preservation procedure. Train the team on forensic evidence handling.

Pitfall 7 — Communication failure

Employees, customers, regulators, and the board learning about the incident from the media, from each other, or not at all.

Mitigation: Define the communication roles, channels, and timeframes. Prepare templates. Communicate early and honestly. Coordinate through a single function.

Pitfall 8 — Regulatory notification missed

Notification timeframes missed because the enterprise delayed its assessment while waiting for certainty — producing penalties and damaging the regulatory relationship.

Mitigation: Identify notification obligations in advance. Define the assessment process. Notify within the timeframe based on what is known. Commit to updating. Engage legal counsel early.

Pitfall 9 — No post-incident review

The incident is closed when service is restored, with no analysis of what happened, why, and what should change — so the same incident occurs again.

Mitigation: Conduct a post-incident review for every significant incident. Document the findings and the actions. Track the actions to closure. Report to governance.

Pitfall 10 — Blame culture

The post-incident review focuses on identifying who was at fault rather than on what failed and how to improve — producing concealment and defensiveness.

Mitigation: Establish a non-punitive review process. Focus on systemic causes. Communicate that the objective is learning. Protect the participants from blame.

Pitfall 11 — Insufficient external support

No retained external specialists — so that during an incident, the enterprise is negotiating contracts and establishing relationships while the adversary is operating.

Mitigation: Retain external incident response capability in advance. Establish the relationships. Test the integration. Know the contacts.

Pitfall 12 — Insurance not engaged

The cyber insurer not notified in accordance with the policy — jeopardising the claim and losing access to the insurer's preferred providers.

Mitigation: Understand the policy terms in advance. Notify the insurer promptly. Use the insurer's preferred providers where appropriate.

Pitfall 13 — Incident response disconnected from business continuity

Incident response and business continuity operating independently — so that the business is not supported during the response and the response is not informed by operational priorities.

Mitigation: Integrate incident response and business continuity. Define the coordination. Exercise them together.

Pitfall 14 — No playbooks

A general incident response plan but no specific playbooks for the incident types the enterprise is most likely to face — so that the response is improvised each time.

Mitigation: Develop playbooks for the most likely and most consequential incident types. Exercise them. Update them based on experience.

13 Key concepts

The terms below are used throughout Unit 6. Capture them in your own words as you work through the lesson.

Incident response

The organised response to a security incident — detecting, analysing, containing, eradicating, recovering, and learning — to limit the impact and restore normal operation.

Event

An observable occurrence in a system or network — a login, a file access, a network connection. Most events are benign.

Alert

A notification generated by a monitoring or detection system when an event or pattern matches a defined condition — requiring triage to determine whether it represents an incident.

Incident

A confirmed or suspected security event that could result in harm to the enterprise — triggering the incident response process.

Near miss

An event that could have resulted in harm but did not — a valuable learning opportunity and an input to improvement.

False positive

An alert that does not represent an actual security event — numerous in most environments and requiring efficient triage.

Incident classification

Categorising an incident by type — unauthorised access, malware, data breach, denial of service, phishing, insider, supply chain, and others — determining the playbook and the expertise required.

Incident severity

The significance of an incident — assessed across business, data, regulatory, financial, reputational, and safety dimensions — determining the resources, the escalation, and the urgency.

Incident response plan

The documented plan for responding to incidents — the process, the team, the roles, the authority, the escalation paths, and the communication arrangements.

Playbook

The documented procedure for responding to a specific type of incident — converting the general plan into actionable steps.

Incident response team

The group of individuals who coordinate and conduct the response — including security, IT, legal, communications, HR, and executive leadership.

Incident response manager

The individual who leads the response — coordinating the team, making decisions within defined authority, and escalating decisions that exceed that authority.

Triage

The initial assessment of an alert or report — validating whether it represents an incident, classifying it, assessing severity, and determining escalation.

Detection

Identifying that an incident has occurred or is occurring — through monitoring, user reports, threat intelligence, or external notification.

Analysis

Developing an understanding of the incident — what happened, when, how, what is affected, and who is responsible.

Containment

Limiting the scope and impact of the incident — preventing it from spreading and preventing the adversary from causing further harm.

Short-term containment

Immediate action to stop the spread — isolating affected systems, disabling compromised accounts, and blocking malicious traffic.

Long-term containment

Sustained measures — implementing temporary controls and maintaining isolation until eradication and recovery can be completed.

Eradication

Removing the adversary's access and the malicious artefacts — and addressing the vulnerability that was exploited.

Recovery

Restoring affected systems and services to normal operation — from backup, from known-good images, or through rebuilding.

Post-incident activity

Reviewing the incident and the response — identifying lessons learned and implementing improvements.

Post-incident review

A structured examination of the incident and the response — conducted non-punitively, documented, and producing specific improvement actions.

Lessons learned

The findings and recommendations from the post-incident review — implemented as improvements to detection, prevention, response, and preparation.

Root cause

The underlying reason the incident occurred — the vulnerability, the control failure, or the human factor that was exploited.

Chain of custody

The documented record of evidence — who collected it, when, how, and where it has been stored — so that it can be relied upon in investigation and legal proceedings.

Evidence preservation

Collecting and retaining evidence in a forensically sound manner — before systems are changed, isolated, or rebuilt.

Incident communication

Internal and external communication during and after an incident — with defined roles, channels, templates, and approval processes.

Regulatory notification

Reporting an incident to a regulator or national authority — with defined timeframes, content, and consequences for failure.

NIST SP 800-61

The Computer Security Incident Handling Guide — the most widely used incident response framework, defining the incident response lifecycle.

ISO/IEC 27035

The international standard for information security incident management — defining the incident management process and its relationship to the ISMS.

SANS six-step process

The practical incident handling process — preparation, identification, containment, eradication, recovery, and lessons learned.

Tabletop exercise

A discussion-based exercise where the team walks through a scenario — testing the plan, the roles, and the decision-making without the pressure of a live environment.

Simulation exercise

A live exercise where the team responds to an injected scenario — testing the technical capability, the tooling, and the coordination.

Red team / purple team exercise

An adversarial exercise where a red team attempts to breach the enterprise while the blue team responds — testing detection, response, and coordination against a realistic adversary.

14 Activities

The activities below help you test your understanding and prepare for the unit discussion and Assignment 3. They are not graded, but completing them will substantially improve your preparation.

15 Self-check

Answer the questions below before moving to Lesson 6.8. If you cannot answer a question confidently, revisit the corresponding section.

16 Summary

This lesson has examined incident response planning — the discipline through which the enterprise prepares to detect, respond to, and recover from security incidents. The essential points are:

• Every enterprise will experience incidents. The question is not whether incidents will occur, but how quickly they will be detected, how effectively they will be contained, how decisively they will be recovered from, and whether the enterprise will learn from them.
• Incident response is not business continuity. Incident response addresses the security dimensions — detecting, containing, eradicating, recovering. Business continuity addresses the operational dimensions — keeping the business functioning while systems are unavailable. They are related and operate simultaneously.
• Classification and severity determine the response. Classification determines the playbook and the expertise; severity determines the resources, the escalation, and the urgency. Both are decision-support tools, not bureaucratic labels.
• The frameworks define the process. NIST SP 800-61, ISO/IEC 27035, and the SANS process share a common lifecycle — preparation, detection and analysis, containment, eradication, recovery, and post-incident activity.
• Preparation determines effectiveness. The team, the tools, the playbooks, the training, and the relationships that exist before an incident occurs determine how well the enterprise responds when it does.
• Detection speed determines consequence. The longer an adversary has access, the more they can achieve. Faster detection compresses the window in which the adversary can operate.
• Containment involves difficult trade-offs. Between speed and evidence preservation, between containment and operational continuity, and between security and business consequence. The appropriate decision depends on the circumstances.
• Post-incident activity is where the value is realised. The review, the lessons learned, and the improvement cycle convert the incident into organisational learning.
• Communication is consequential and frequently mishandled. Prepared in advance, communicated early and honestly, coordinated through a single function, and reviewed by legal counsel.
• Regulatory notification has defined timeframes. Short deadlines, multiple regimes, and significant consequences for failure. Notify within the timeframe based on what is known.
• Common pitfalls recur. No plan or a plan never exercised; no defined team; insufficient authority; slow detection; premature containment; evidence destroyed; communication failure; regulatory notification missed; no post-incident review; blame culture; insufficient external support; insurance not engaged; incident response disconnected from business continuity; no playbooks.

These ideas prepare for Lesson 6.8, which examines business continuity and disaster recovery — the enterprise-level continuity that incident response feeds into. Lesson 6.9 examines cyber resilience and enterprise recovery — the ability to withstand and recover from disruption. Lesson 6.10 examines emerging trends, including the evolving threat landscape and the response capabilities required for it.