Incident Response

Events and incidents

An event is any observable occurrence in a system or network: a login, a blocked connection, a file being opened. Organizations log millions of them a day, and almost all are harmless. A security incident is an event, or a series of events, that actually or potentially jeopardizes the confidentiality, integrity or availability of information or systems, or that violates security policy. A failed login is an event; an attacker logging in with a stolen password is an incident. So is an employee emailing a customer file to a private address, or a ransomware note on a file server.

The distinction matters because declaring an incident sets things in motion: an incident handler is assigned, a record is opened, clocks for legal notification may start, and people are allowed to take disruptive actions. Security monitoring turns events into alerts; triage decides which alerts are incidents.

The incident response lifecycle

The most widely used model comes from NIST Special Publication 800-61, the Computer Security Incident Handling Guide of the United States National Institute of Standards and Technology. Its Revision 2 describes four phases:

The arrows back are as important as the arrows forward. Containing one infected laptop often reveals a second one, which sends the team back to analysis. And the final phase feeds the first: every incident should leave the organization better prepared for the next.

Preparation

An incident is the worst moment to find out who is allowed to shut down the order system, or that nobody has the phone number of the internet provider's security desk. Preparation is everything that has to exist before the incident:

• A plan. An incident response plan is the documented, management-approved description of how the organization detects, handles and recovers from security incidents: scope, definitions, severity levels, roles and decision rights, communication and reporting duties.
• Roles. An incident manager who coordinates, technical responders, a communications lead, and a management representative who can make business decisions such as taking a service offline.
• Contacts. Internal on-call numbers, legal counsel, the data protection officer, suppliers and providers, the cyber insurer, the police and the relevant government computer security incident response team (CSIRT). Kept outside the systems that may be down: a printed copy or a separate phone list.
• Tools and access. Forensic and endpoint tools installed in advance, accounts for responders, a clean laptop, a communication channel that does not depend on the possibly compromised email system.
• Backups and logging. Tested, offline or immutable backups, and logs retained long enough to look back weeks; see what to log.
• Exercises. Tabletop exercises in which the team talks through a scenario reveal gaps in the plan at no cost; see business continuity for exercise types.

The response team: CSIRT

A CSIRT (computer security incident response team) is a team that receives reports of security incidents, analyzes them and coordinates the response, either for its own organization or for a sector or country. The older term CERT (computer emergency response team) means much the same. In a small organization the CSIRT may be two administrators and a manager with an external specialist on contract; in a large one it is a permanent team that works closely with the SOC.

Detection, analysis and triage

Incidents are detected by monitoring tools, but very often by people: a user who reports a strange email, a customer who receives a fake invoice in your name, a supplier who notices odd traffic. Analysis answers three questions: is this really an incident, what is affected, and how bad is it? The answers are rarely complete at first, so analysis continues throughout the response.

Severity classification

A severity level decides who is called, how fast, and how much disruption is acceptable. Most organizations use three to five levels, with criteria such as business impact, involvement of personal data, whether the incident is still spreading, and whether critical or safety-related systems are affected. The program below scores a few fake incidents with such criteria and sorts them by urgency:

IMPACT = {"none": 0, "low": 1, "medium": 2, "high": 3}

incidents = [
    {"id": "INC-101", "summary": "Phishing email reported, nobody clicked",
     "impact": "none", "personal_data": False, "spreading": False, "critical_system": False},
    {"id": "INC-102", "summary": "Laptop with encrypted disk lost on train",
     "impact": "low", "personal_data": True, "spreading": False, "critical_system": False},
    {"id": "INC-103", "summary": "Ransomware note on two file servers",
     "impact": "high", "personal_data": True, "spreading": True, "critical_system": True},
    {"id": "INC-104", "summary": "Malware alert on one office PC, quarantined",
     "impact": "low", "personal_data": False, "spreading": False, "critical_system": False},
    {"id": "INC-105", "summary": "Unknown admin login on control room server",
     "impact": "medium", "personal_data": False, "spreading": False, "critical_system": True},
]


def score(incident):
    points = IMPACT[incident["impact"]] * 3     # effect on the business so far
    if incident["personal_data"]:
        points += 2                              # possible legal notification
    if incident["spreading"]:
        points += 4                              # gets worse every minute
    if incident["critical_system"]:
        points += 4                              # safety or essential service
    return points


def severity(points):
    if points >= 12:
        return "SEV-1 critical"
    if points >= 7:
        return "SEV-2 high"
    if points >= 3:
        return "SEV-3 medium"
    return "SEV-4 low"


for incident in sorted(incidents, key=score, reverse=True):
    points = score(incident)
    print(f"{incident['id']}  {points:>2}  {severity(points):<14}  {incident['summary']}")

INC-103  19  SEV-1 critical  Ransomware note on two file servers
INC-105  10  SEV-2 high      Unknown admin login on control room server
INC-102   5  SEV-3 medium    Laptop with encrypted disk lost on train
INC-104   3  SEV-3 medium    Malware alert on one office PC, quarantined
INC-101   0  SEV-4 low       Phishing email reported, nobody clicked

A scoring scheme makes decisions consistent, but it is a starting point for judgment, not a replacement. The lost laptop is a good example: if the disk was strongly encrypted and the key was not with it, the personal data is probably not exposed and no notification may be needed. A person checks that and adjusts the severity. Severity is also revised as facts come in: the "nobody clicked" phishing email becomes a different incident when one user turns out to have entered a password.

The help desk as first reporter

For many incidents the first contact is a call to the service desk. What the help desk records in those first minutes can save hours later. Useful questions:

• What exactly did you see, and when? (Ask for a screenshot or the exact text of the message.)
• What did you do? Did you click a link, open an attachment, enter a password, approve a multi-factor authentication (MFA) prompt?
• Which device and which account were involved? Is it a work device?
• Is it still happening? Have colleagues received the same thing?

Record the answers, the time (with time zone) and the caller's details in the ticket, and escalate according to the playbook. Typical first instructions are to leave the device switched on but disconnect it from every network (cable, Wi-Fi, virtual private network (VPN)), and not to forward the suspicious email to colleagues. What not to do matters as much: do not investigate on your own, do not delete the evidence, and do not tell the user they "probably caused it". People who feel blamed report later, or not at all.

Containment, eradication and recovery

Containment

Containment limits the damage of an incident and stops it from spreading, while the team works on a permanent fix. Typical containment actions, each with its own trade-off:

Timing is a decision too. Acting at the first sign stops damage early, but an attacker who notices may switch to other footholds the team has not found yet, or start destructive actions. Against a careful attacker, teams sometimes first establish the full scope and then contain everything at once. Against ransomware that is actively encrypting, speed wins.

Eradication

Eradication removes the cause of the incident from the environment: malicious software, attacker accounts, persistence mechanisms such as scheduled tasks, and the vulnerability or weakness that let the attacker in. Removing the malware but not the way in invites a repeat a week later.

For a compromised system the main choice is clean or rebuild. Cleaning (removing the known malicious files) is faster but leaves doubt: did we find everything? Rebuilding from a trusted installation image, then restoring data from a backup made before the compromise, gives much more certainty and is the usual choice for servers an attacker controlled with administrator rights.

Recovery

Recovery returns systems to normal operation: restoring from backups, resetting credentials (often far more than the obviously affected ones), patching, and bringing services back in a controlled order. Before a system goes back into production it is validated: patched, scanned, and checked for the indicators found during the investigation. After that it is monitored more closely for a while, because a returning attacker is most likely in the first weeks.

Evidence, forensics and chain of custody

Digital forensics is the collection, preservation and analysis of digital evidence in a way that keeps it reliable, so that findings can support decisions, insurance claims or legal proceedings. Even when nobody expects a court case, forensic care is worth it: it is how the team knows what really happened, and the decision to involve the police is often made later.

Order of volatility

Some evidence disappears by itself. Request for Comments (RFC) 3227, a long-standing guideline for evidence collection, advises collecting the most volatile data first:

1. CPU registers and cache
2. Memory contents, running processes, network connections, routing and ARP tables
3. Temporary file systems
4. Disk
5. Remote logging and monitoring data
6. Physical configuration and network topology
7. Archival media such as backups

This is why "pull the plug" is usually the wrong reflex: switching a machine off destroys memory, which may hold the decryption key of fileless malware, active network connections, and the commands an attacker ran. Isolating it from the network and leaving it running preserves both. Disk images are made with tools that do not change the original, and their hashes are recorded so anyone can later verify the copy is identical.

Chain of custody

Chain of custody is the documented, unbroken record of who collected a piece of evidence, when and how, and everyone who handled, transferred or stored it afterward. A gap in the record lets anyone question whether the evidence was changed. A minimal entry might look like this:

Item     E-003  laptop LT-0447, serial on label, power on, network unplugged
Hash     SHA-256 of disk image recorded in case file INC-103
2026-10-01 09:35 UTC  memory image  J. de Vries (IR team)   captured, hash recorded
2026-10-01 09:42 UTC  collected by  J. de Vries (IR team)   at office, desk 3.14
2026-10-01 10:15 UTC  handed to     A. Meijer (forensics)   sealed bag 0091
2026-10-01 10:20 UTC  stored in     evidence safe B         log signed by both

Playbooks

A playbook is a documented, step-by-step procedure for responding to one specific type of incident, listing actions, decision points and responsible roles. The plan says who decides; the playbook says what to do. Playbooks make responses consistent and fast, and they are the natural input for automation in SOAR tools. Two outlines, defensive steps only:

1. Acknowledge the report; thank the reporter.
2. Analyze the message in a safe environment: sender, links, attachments.
3. Search all mailboxes for the same message; remove it everywhere.
4. Block the sender, domain and link at mail filter and proxy.
5. Find out who clicked or replied (mail and proxy logs, user reports).
6. For anyone who entered credentials: reset the password, revoke sessions,
   check MFA registrations and mailbox forwarding rules.
7. Check affected devices with the EDR tool if an attachment was opened.
8. Record the indicators; close or escalate; brief users if it was widespread.

1. Isolate affected systems from every network (cable, Wi-Fi, VPN); leave them
   powered on. If a system cannot be isolated, powering it down is the
   fallback, to stop the spread.
2. Declare a major incident; call the incident manager and management.
3. Protect the backups: verify they are offline or immutable and untouched.
4. Determine scope: which systems, accounts and data are affected?
5. Disable compromised accounts; reset privileged credentials from a clean device.
6. Preserve evidence (memory, disk images, ransom note, logs).
7. Assess notification duties (GDPR, NIS2, contracts); involve legal counsel,
   the insurer, the police and the national or sector CSIRT as applicable.
8. Eradicate the way in; rebuild systems; restore data from clean backups.
9. Monitor closely; hold a lessons-learned review.

Whether to pay a ransom is a decision for management, with legal advice, not for the technical team. Authorities generally advise against paying: payment does not guarantee working decryption or deletion of stolen data, and it funds the next attack. Good backups and a rehearsed playbook are what make "no" a realistic answer.

Communication and notification

Every incident has audiences, each with its own needs. Internally, the response team needs a channel that the attacker cannot read; if the email system may be compromised, switch to a separate one. Management needs regular, short updates in business terms: what is affected, what are we doing, what decisions do we need from you. Staff need to know what to do and what not to do. Customers and partners need honest, timely information when they are affected; one designated spokesperson prevents contradicting stories. Keep a log of every message sent and every decision taken, with the time.

Legal notification duties

Some notifications are required by law, with deadlines that start when the organization becomes aware of the incident. That is why the plan must name who assesses them, and why a lawyer and the data protection officer are on the contact list. The main rules at the time of writing (October 2026):

Lessons learned

The post-incident phase is where an incident pays back. Within a few weeks, the people involved review what happened in a structured meeting and a short report: the timeline, what worked, what did not, and what will change, with an owner and a date for each improvement. Typical outcomes are a new detection rule, a fixed backup gap, an updated contact list or a clearer decision right.

Good reviews are blameless: they ask how the system and process allowed the problem, not who is at fault. "Why could one clicked link lead to domain administrator rights?" leads to improvements; "who clicked?" leads to people hiding their mistakes next time. Blameless does not mean consequence-free for deliberate misconduct, but honest mistakes are treated as information. The same review also feeds back into the incident response plan, closing the loop in the lifecycle.

For outages rather than attacks, the same review is called a postmortem: Postmortems; running the incident itself: Incident Response in Practice.