Incident Response

Introduction

Detecting a cyberattack is only the beginning. Once an organisation discovers suspicious activity, it has to determine what happened, how serious it is, which systems are affected, whether attackers are still present, how to stop them, how to restore the business safely, who needs to be informed, and how to prevent the same thing happening again. This is Incident Response (IR) — one of the areas of cybersecurity where technical skill and business decision-making genuinely meet.

During a serious incident, security analysts may work alongside SOC analysts, incident responders, security/network/cloud engineers, systems administrators, IAM engineers, malware analysts, digital forensic investigators, legal teams, data protection officers, risk and compliance teams, business continuity teams, communications/PR teams, cyber-insurance providers, external forensic companies, law enforcement, regulators, and senior executives. For a global company, an incident can become an international business crisis fast — a compromised administrator account in London might reach an AWS environment in Ireland, expose customer data belonging to people in Germany, compromise a software supplier in India, and disrupt manufacturing in the United States, all in the same incident.

Incident response is not simply removing malware from computers. It's the controlled management of a potentially serious business event.

Learning Objectives

By the end of this module (all 6 lessons), you should be able to distinguish an event from an alert from an incident; explain modern IR frameworks and how they relate to the classic PICERL model; classify incident severity and explain why that classification drives the response; describe detection sources across endpoint, SIEM, network, identity, cloud, SaaS and legacy environments; investigate an incident methodically, building a timeline and scoping the compromise; contain, eradicate and recover from an incident while balancing security against business risk; run a blameless post-incident review; explain incident metrics and communications, including regulatory reporting obligations; and work through a realistic, multi-stage ransomware incident end to end.

1❓ What Is a Security Incident?

Not every security event is an incident. An event is simply something that happened — a user logged in, a firewall blocked a connection, an endpoint generated a malware alert. An alert is something a security system has flagged as potentially suspicious. An incident exists once investigation determines security may actually have been compromised, or there's enough evidence to justify formal incident handling:

Event: User logs into Microsoft 365.
Alert: User logs in from an unusual country.
Investigation: The user confirms they are not travelling.
Incident: The account has probably been compromised.

Incident response begins the moment the organisation decides something needs structured investigation and management — not automatically the moment an alert fires.

2📋 Modern Incident Response Frameworks

Historically, IR gets taught as a fixed sequence of phases:

Preparation → Detection → Analysis → Containment
   → Eradication → Recovery → Lessons Learned

This remains a genuinely useful operational model — but frameworks keep evolving. NIST published SP 800-61 Rev. 3 in April 2025, superseding the 2012 Rev. 2, integrating incident response into the broader NIST Cybersecurity Framework 2.0 rather than treating it as an isolated process. CSF 2.0 has six functions: Govern, Identify, Protect, Detect, Respond, Recover. Preparation now spans Govern/Identify/Protect; active response centres on Detect/Respond/Recover; and lessons from incidents explicitly feed back into organisational improvement rather than sitting in a report nobody revisits.

The practical lifecycle this module uses:

Detection → Investigation → Containment
   → Eradication → Recovery → Lessons Learned

These stages are rarely perfectly sequential in practice. Real incidents move backwards and forwards constantly:

Investigation → Containment → New compromised server discovered
   → Back to Investigation → Additional containment

Incident response is iterative, not a straight line you walk once.

3📝 Preparing Before the Incident

Effective incident response starts long before any incident happens — trying to invent procedures mid-ransomware-attack is extremely difficult. Large organisations maintain an Incident Response Plan (IRP) defining who declares an incident, who becomes Incident Commander, who can isolate systems or disable accounts or shut down production, who contacts executives/customers/regulators/law enforcement, which external forensic firms can be engaged, where emergency contacts and backups live, and how evidence gets preserved.

The organisation should already know which systems are critical before an incident forces the question:

This matters enormously during ransomware — restoring the cafeteria booking app before Active Directory would be exactly the wrong priority, and you don't want to be figuring out the tiering scheme for the first time while it's on fire.

4👥 The Incident Response Team

Large organisations establish a formal or virtual CSIRT (Computer Security Incident Response Team) — you'll also see CERT, IRT, or DFIR used depending on the organisation. A serious incident might involve dozens or hundreds of people, which is exactly why clear ownership matters.

The Incident Commander coordinates the overall incident without necessarily doing the technical investigation themselves. Their job: keep work prioritised, ensure decisions get documented, keep teams communicating, give every action an owner, keep executives updated, escalate critical decisions, and prevent duplicate work. During major incidents, technical teams get overwhelmed with messages fast — the Incident Commander is the structure that keeps that from turning into chaos.

5🚨 Incident Severity

Companies call this SEV1, P1, Critical, Major Incident, or Cyber Crisis depending on the org — the label matters less than what it triggers. A SEV1 might immediately pull in the CISO, CIO, Legal, executive management, Communications, cyber insurance, external forensic investigators, regulators, and law enforcement, all at once.

📚 Lessons in This Module

Work through these in order — each builds on ideas from the last. Every lesson has its own "Mark lesson complete" button; your progress across all six is tracked below.