The incident response process, and the preparation that decides the outcome

Objective 4.7 asks you to summarise incident response: the stages an organisation moves through when something goes wrong, and the work done beforehand that decides how well it goes. This lesson takes the process, the preparation, negotiation and notification. Threat hunting, forensics, root cause analysis and the post-incident report are the next lesson.

Why this matters

The incident response sequence is one of the few things on this exam you can rely on being asked about by name and in order. Learn the stages, learn what belongs in each, and learn the transitions people get wrong, and you have a block of marks that does not depend on judgement.

The judgement questions are about sequence: given a scenario mid-incident, what do you do next. Those are answerable from the stage order, and the commonest wrong answer is doing something from a later stage too early.

SY0-801 also widens the process at both ends. Before the incident it expects playbooks and named roles; during and after it expects you to know how an organisation handles an extortion demand and who it is obliged to tell.

The lesson

Preparation, identification, investigation, containment, eradication and recovery

The stages, in order:

1. Preparation -- everything done before an incident: the plan, the team, the tooling, the logging, the contact lists, the exercises, the backups. This is where the outcome is decided, which is why it gets its own section below.
2. Identification -- recognising that something has happened. Detection from the monitoring in lesson 35, a user report, an advisory, a third party, or the attacker announcing themselves. Threat hunting also feeds this stage.
3. Investigation -- working out what it is, how far it reaches and how serious it is: which accounts, which hosts, what data, since when. SY0-801 uses "investigation" where older material said "analysis"; it is the same scoping work, now explicitly including digital forensics and preservation.
4. Containment -- stopping it getting worse. Quarantine or isolation is the core move: cut a host off the network (EDR can do this while leaving it running for evidence capture), disable an account, block a destination, take a service offline.
5. Eradication and recovery -- remove the cause (malware, persistence, attacker accounts, the vulnerability used to get in), then restore normal operation from known-good sources and watch closely for a return.
6. Post-incident -- lessons learned, root cause analysis and the post-incident report, which turn the incident into changed controls.

Two further activities run alongside rather than in strict sequence: negotiation, when there is an extortion demand, and notification and external reporting, which often has a legal clock running from the moment you become aware. Both have their own sections below.

Two transitions to be exact about.

Containment comes before eradication. Stop the bleeding first. A scenario where an attack is in progress, with options including "patch the vulnerability" and "isolate the affected host", wants isolation. Patching does not remove an attacker who is already inside, and eradicating while they still have access simply alerts them.

How much investigation precedes containment depends on the speed of damage. Against a patient intruder, evicting the one foothold you found lets them fall back to the one you missed. Against ransomware spreading across file shares, contain immediately and scope afterwards.

Training, testing, tabletop exercises, playbooks, simulations and named roles

Preparation is a set of activities, not a document.

Training makes sure people can do their part. The response team needs the technical procedures; wider IT staff need to know what to do and, crucially, what not to do; everyone else needs to know how to report something. The "what not to do" is where well-meaning staff destroy evidence: rebooting the machine, deleting the suspicious file, logging in to have a look. First responder guidance is do not power off, do not log in, do not delete -- report it and preserve it.

Testing proves the plan and tooling work: backups restore, EDR isolation cuts a host off, the contact list is current.

Tabletop exercises walk through a scenario around a table, with no systems touched. They find decision gaps: who declares an incident, who may take the payment system offline, who speaks to the regulator, and who is in charge if the incident starts at 2am on a public holiday or if the head of security is the person whose account is compromised. Run them often.

Simulations are more realistic: the team responds to injected events on real tooling, or staff receive simulated phishing that measures real behaviour. They cost more and test execution rather than decisions.

Playbooks are pre-written, step-by-step responses to a specific incident type -- ransomware, a compromised mailbox, a lost laptop, a leaked credential. They let a responder at 3am act correctly without inventing the procedure under pressure, and they are the natural starting point for automation in lesson 38.

Named roles settle authority in advance: an incident lead or commander who makes the calls, technical responders, a communications lead and single spokesperson, legal counsel, a scribe who keeps the timeline, and an executive sponsor who can approve business-level decisions. Each role needs a named deputy. The plan must also be reachable when the systems are down: an offline copy, a printed contact list, and break-glass credentials held securely.

Internal and external advisories, and detection that starts outside your network

Not every incident begins with one of your own alerts.

An internal advisory is a warning raised inside the organisation: the security team telling staff that a phishing campaign is circulating, that a particular system is suspected compromised, or that an urgent patch must be applied today. It shapes identification by telling people what to look for and report.

An external advisory arrives from outside: a vendor security bulletin, a national cyber security agency or CERT alert, an industry sharing group, or a threat intelligence feed (lesson 9). The useful response is a quick question -- are we exposed, and is there evidence it has already been used against us? -- which is identification work triggered by someone else's discovery.

Some incidents are detected entirely outside your network:

• a customer reports fraud that traces back to your systems;
• a payment card brand or bank notices a pattern pointing to you;
• law enforcement or a security researcher gets in touch;
• your data appears for sale or on an extortion group's leak site.

These mean your own detection missed it, but they are common. Preparation means a published, monitored way to report a security issue, and a habit of treating an unsolicited warning as a lead to verify, not a nuisance.

Ransom negotiation, and why it is a decision made before the incident

Ransomware and data extortion turn incident response into a business negotiation, and the worst time to form a position on that is while systems are encrypted and the board is panicking.

The organisation should decide in advance:

• Its stance on paying, and who has authority to change it. Many organisations adopt a strong presumption against paying; the decision is still an executive one, not the security team's.
• Legal checks. Paying a group subject to sanctions can itself be unlawful in some jurisdictions, so legal counsel must be involved before any payment is considered.
• The insurer's role. Cyber insurance policies often require prompt notification and the use of approved response and negotiation firms; engaging others first can affect cover.
• Law enforcement contact, which can bring intelligence about the group and its record.
• Who negotiates. Specialist negotiators are normal; an improvising executive is not.

Why defenders treat payment as unreliable: paying does not guarantee a working decryptor, does not make stolen data disappear, does not remove the attacker's access, and marks the organisation as willing to pay. Negotiation can buy time for recovery, but the control that actually removes the leverage is preparation -- tested, offline or immutable backups (lesson 28) -- so that restoring is a real alternative to paying.

Notification: stakeholders, customers, law enforcement and mandatory reporting deadlines

The communication plan is the part of preparation most likely to fail in practice. It must say who is told, in what order, by whom, and how.

• Stakeholders -- executives, the board, legal, the data protection officer, partners, insurers, and staff. Staff will talk regardless; silence is filled with speculation.
• Customers -- affected individuals told in plain language what happened, what data was involved and what they should do.
• Law enforcement -- reporting crime, especially extortion, ideally through a relationship established beforehand.
• Mandatory reporting -- obligations set by law, regulation or contract. Under the EU GDPR, a personal data breach must be reported to the supervisory authority within 72 hours of becoming aware, where feasible. Other laws, sectors and contracts set their own deadlines and thresholds, which is exactly why the plan must list them beforehand: an organisation that spends three days deciding whether to notify has often already missed the window. Lesson 45 covers the compliance side, including legal hold.

Two practical requirements: an out-of-band channel the attacker is not reading, in case email and chat are compromised, and a single spokesperson. A stakeholder who learns of your incident from a journalist or a leak site responds far worse than one you told early.

What to take into the exam

• Preparation, identification, investigation, containment, eradication and recovery, then post-incident -- with negotiation and notification running alongside.
• Containment before eradication, always. Isolating beats patching while an attack is live.
• Speed of damage decides how much investigation precedes containment: ransomware now, a patient intruder scoped first.
• Tabletops test decisions; simulations test execution; playbooks script a specific incident type; named roles settle who decides.
• An advisory or an outside party can be where identification starts.
• Decide the ransom position, legal checks and insurer steps before the incident. Paying guarantees nothing; tested backups remove the leverage.
• Notification deadlines are set by law and contract (GDPR: 72 hours to the authority), so they belong in the plan before you need them.