9.1 Incident Response: Preparation, Detection, Analysis, and Escalation
Key Takeaways
- The SSCP outline (effective 1 October 2025) knowledge area 4.1 lists Preparation; Detection, analysis, and escalation; Containment; Eradication; Recovery; and Post-incident activities. That step list is authoritative for the exam.
- NIST SP 800-61 Revision 2 grouped handling into four phases: Preparation; Detection and Analysis; Containment, Eradication, and Recovery; and Post-Incident Activity.
- NIST SP 800-61 Revision 3 (April 2025) maps incident response onto CSF 2.0 functions: Govern, Identify, Protect, Detect, Respond, and Recover. Mapping is not permission to skip Preparation, Containment, or Eradication on the SSCP.
- Preparation means defining Computer Security Incident Response Team roles and running training programs before an incident, not assigning a commander after encryption starts.
- Detection, analysis, and escalation include incident communication and public relations: technical staff confirm and contain; named spokespeople talk to the press.
Why the incident response lifecycle is an operations exam topic
Domain 4 of the ISC2 Systems Security Certified Practitioner (SSCP) exam — Incident Response and Recovery — is weighted at 14% under the outline effective 1 October 2025. Knowledge area 4.1 is Understand and support incident response lifecycle, with the National Institute of Standards and Technology (NIST) and the International Organization for Standardization (ISO) named as example models. The SSCP is a practitioner credential. You are not being asked to recite a publication number so you can decorate a policy. You are being asked to staff a Computer Security Incident Response Team (CSIRT), decide when an event is an incident, and escalate without making the breach worse.
The outline's own step list is the exam's authority:
- Preparation (defining roles, training programs)
- Detection, analysis, and escalation (incident communication, public relations)
- Containment
- Eradication
- Recovery (incident documentation)
- Post incident activities (lessons learned, new countermeasures, continuous improvement)
This section teaches the first two steps in depth. Containment through lessons learned is the next section. Do not collapse those later steps just because some NIST diagrams group them. The SSCP outline lists them separately, and exam items will too.
NIST and ISO: cited models, not a license to rewrite the outline
NIST SP 800-61 Revision 2, Computer Security Incident Handling Guide (August 2012), grouped incident handling into four phases:
| NIST SP 800-61 Rev 2 phase | What it bundled | How the SSCP outline splits it |
|---|---|---|
| Preparation | Capability, policy, people, tools | Preparation |
| Detection and Analysis | Find, validate, scope | Detection, analysis, and escalation |
| Containment, Eradication, and Recovery | Stop spread, remove cause, restore | Three separate outline steps |
| Post-Incident Activity | Lessons learned, evidence retention | Post incident activities |
NIST SP 800-61 Revision 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile (April 2025), supersedes Revision 2. It does not invent a new six-step SSCP list. It maps incident response onto the six NIST Cybersecurity Framework (CSF) 2.0 functions: Govern, Identify, Protect, Detect, Respond, and Recover. Govern, Identify, and Protect are how you prepare and reduce incidents. Detect, Respond, and Recover are how you discover, contain, eradicate, restore, and improve. Revision 3 even maps the old Preparation phase onto Govern, Identify, and Protect — it does not say preparation vanished.
For the Computerized Adaptive Testing (CAT) exam, that mapping is background literacy. ISC2 did not drop preparation, containment, or eradication. If a stem says "according to the SSCP exam outline," answer with the outline steps. If a stem says "NIST SP 800-61 Rev 2 grouped phases," answer with the four-phase grouping. If a stem says "NIST SP 800-61 Rev 3," talk CSF 2.0 functions. Mixing those three sources is a common trap.
ISO's incident-management family is ISO/IEC 27035. ISO/IEC 27035-1:2023 describes a process with key activities to prepare for, detect, report, assess, and respond to incidents, and to apply lessons learned. A practical five-phase reading used in operations is:
| ISO/IEC 27035-oriented phase | Operations meaning |
|---|---|
| Plan and prepare | Policy, team, training, tooling — before the pager |
| Detection and reporting | Sensors, users, and a point of contact (PoC) that may be the help desk, not yet the CSIRT |
| Assessment and decision | Is this an incident, how severe, who decides |
| Responses | Contain, eradicate, recover — the work |
| Lessons learnt | Feed the next preparation cycle |
The SSCP outline is closer to a linear handler checklist. ISO emphasizes that the first reporter may not be the response team, and that lessons learned close the loop into preparation. Both ideas show up in scenario items.
Preparation: roles and training before the pager
Preparation is the work you do on a quiet Tuesday so Friday night's ransomware is a procedure, not a panic. The outline's examples are defining roles and training programs. Those are not optional decorations.
Define roles in writing
A CSIRT without named roles becomes a conference call where everyone talks and nobody owns the next action.
| Role | What the SSCP actually does | Failure if missing |
|---|---|---|
| Incident commander (or incident manager) | Declares the incident, sets objectives, assigns work, decides when to escalate to executives | Two directors give opposite orders; the sysadmin follows the louder one |
| Technical handlers | Host, network, identity, cloud, and malware analysis | Security operations center (SOC) tickets sit while "someone from infrastructure" is hunted on chat |
| IT operations / system administrators | Implement containment (disable a switch port, freeze an account) under the commander's direction | Admins "help" by rebooting production and destroying volatile evidence |
| Communications / public relations | Internal status, customer notice, press, social media | A well-meaning engineer posts a screenshot of the ransom note |
| Legal / privacy / compliance | Notification clocks, privilege, law-enforcement contact, contracts | You miss a regulator deadline or waive privilege in a chat dump |
| Business owner | Impact on payroll, clinics, shipping | You isolate the wrong virtual local area network (VLAN) and take down the warehouse scanners |
Roles include delegates and after-hours contacts. A role assigned only to a person on a two-week hike is not a role. Publish an on-call roster, an out-of-band channel that does not depend on the compromised mail tenant, and a severity table that says when the commander must wake the chief information security officer (CISO).
Preparation also includes the artifacts handlers will grab: current network diagrams, asset inventory and owners, data classification, identity-provider admin contacts, cloud-account break-glass procedures, cyber-insurance and managed-detection contacts, law-enforcement liaison, and playbooks for the incidents you actually see — ransomware on a file server, business email compromise, lost laptop, web defacement, insider data theft.
Training programs
A PDF playbook nobody has rehearsed is not preparation. Training for 4.1 is role-based:
- Tabletop exercises walk the decision path: who is commander, who talks to customers, when you isolate a file server that payroll still needs.
- Playbook drills walk the technical path: disable this VLAN, freeze this service account, snapshot this disk, open the war-room bridge.
- SOC and help-desk intake training so the first human to see a ransom note files an incident instead of arguing with the attacker.
- Executive briefings so leadership does not demand a public statement before analysis.
Measure preparation the way you measure a backup: you test it. An annual tabletop with no action items is theater. After the tabletop, update contact trees, close tool gaps, and put the next exercise on the calendar.
Scenario. You are the security administrator for a regional logistics firm. Accounting's file server has never been in a tabletop. The "CSIRT" is whoever is in the office. There is no out-of-band contact list. That is a preparation failure. When ransomware hits, you will spend the first hour figuring out who is allowed to disable a switch port. The exam will call that missing preparation, not bad luck.
The lifecycle is a loop, not a one-way checklist. Preparation feeds detection. Detection and later recovery feed lessons that change the next round of preparation.
Detection, analysis, and escalation
Detection is how you find out something is wrong. Analysis is how you decide it is an incident rather than noise. Escalation is how you get the right people and the right authorities into the problem without leaking it to the wrong audience.
Event versus incident
An event is an observable occurrence in a system or network — a failed login, a new process, a firewall deny. An incident is a violation, or imminent threat of violation, of security policy or acceptable-use policy (the NIST-style definition SSCP study materials still use). The SOC's job is to inspect events of interest and declare incidents when analysis supports it. Declaring too late lets the attacker encrypt the next share. Declaring every noisy signature as an incident burns the CSIRT.
Sources you will actually use:
| Source | What it is good for | Trap |
|---|---|---|
| Security information and event management (SIEM) correlation | Multi-source patterns: failed virtual private network (VPN) plus new admin plus unusual file-server writes | Untuned rules bury the real incident in noise |
| Endpoint detection and response (EDR) | Process trees, ransomware file-rename storms, credential dumping | If EDR is missing on the file server, you will detect late |
| Intrusion detection / prevention (IDS/IPS) | Known exploits, command-and-control beacons | Encrypted traffic and living-off-the-land activity hide |
| User and help-desk reports | Ransom notes, "my files are .encrypted," odd invoices | Help desk "fixes" it by restoring a single desktop and never pages the SOC |
| Threat intelligence / indicators of compromise (IOC) | Hashes, domains, techniques from MITRE ATT&CK | IOC matching without analysis produces false incidents |
| File-integrity and backup-job failures | Mass file changes, backup client stopped | People treat backup failure as storage, not detection |
Precursors are signs that an incident may occur (a new vulnerability on an internet-facing host, a threat actor scanning your VPN). Indicators are signs that an incident may have occurred or be occurring (a ransom note, a golden ticket, mass Server Message Block (SMB) encryption). Analysis uses both.
Analysis: confirm, scope, and classify
When EDR fires on FILESERVER01 because a process is renaming share files and dropping README_RESTORE.txt, analysis is not "reboot it." Analysis asks:
- Is it real? A mis-scheduled encryption backup, a developer testing a rename script, and ransomware can look similar in the first five minutes. Check the process tree, the parent, the user context, and whether the note matches a known family.
- What is the blast radius? Which shares, which workstations have the share mapped, which service account is writing, whether domain admin was used, whether the backup server is also encrypting.
- What is the severity? A single test share at 02:00 is not the same as payroll and customs documents at 09:00 on a shipping day.
- What evidence is volatile? Memory, open sessions, and the attacker's interactive console may vanish if someone pulls the power. That decision is shared with forensics (knowledge area 4.2); the handler still has to notice it during analysis.
Document as you go. Timestamps, host names, hashes of the note and the binary, accounts involved, and who you called. Analysis that lives only in a chat thread will not survive the later recovery and legal steps.
Escalation, incident communication, and public relations
The outline explicitly pairs incident communication and public relations with detection, analysis, and escalation. That is deliberate. Technical containment can still fail the organization if the wrong person talks, or if the right person is never told.
Escalation is not "CC the whole company." It is a controlled widening based on severity and need-to-know.
| Severity (example operations table) | Typical meaning | Who is brought in |
|---|---|---|
| Low | Contained malware on one non-critical host, no data loss | SOC plus local admin, standard ticket |
| Medium | Multiple hosts or a departmental server, limited data exposure | Incident commander, IT operations, business owner |
| High | Core file server, identity provider, or suspected data theft | CISO, legal/privacy, communications, executives |
| Critical | Ransomware across shares, hospital or clinic impact, confirmed customer-data exfiltration | All of the above, possibly cyber insurance, outside counsel, law enforcement |
Incident communication has three audiences that must not be mixed:
- Handlers — out-of-band bridge, facts only, no jokes about the ransom note in a channel that will be discovered.
- Internal stakeholders — what is down, what to do (do not pay, do not power off
FILESERVER01unless told, do not run random decryptors), when the next update is. - External — customers, regulators, law enforcement, press. Public relations and legal own the words. The SSCP's job is to feed them verified facts (systems, times, what is not yet known) and to stop unofficial statements.
Scenario continued. Accounting calls the help desk: "The Q drive is full of .encrypted files and a note wants Bitcoin." Help desk is the ISO-style PoC. They open a high-severity incident instead of restoring one spreadsheet. The SOC confirms EDR telemetry: an unknown process under the acct-batch service account is encrypting \\FILESERVER01\accounting. The analyst does not post the ransom note to the company social account "to warn customers," and does not email the whole firm from the possibly compromised tenant. They page the incident commander, isolate according to the playbook after a 60-second check that memory capture is or is not required, and let communications draft an internal holding statement: Accounting file shares are offline. Do not pay any ransom. Report similar notes to the SOC. Use the voice bridge in the incident response plan.
Common exam traps in this step:
- Treating preparation as optional because CSF 2.0 Protect exists.
- Claiming ISC2 dropped containment or eradication because Revision 3 maps to Respond and Recover.
- Letting the first analyst become the public spokesperson.
- Escalating to the press before analysis confirms the incident.
- Waiting for perfect attribution before escalating internally — you escalate on impact and confidence that it is an incident, not on the attacker's legal name.
When you sit the CAT item, name the outline step first, then the standard the stem actually cited.
NIST SP 800-61 Revision 3 (April 2025) maps incident response onto Cybersecurity Framework 2.0 functions. A colleague claims the SSCP therefore no longer tests Preparation, Containment, or Eradication. What is correct for the exam?
A regional hospital has never named Computer Security Incident Response Team roles, has no after-hours contact tree, and has never run an incident tabletop. Leadership asks what Preparation requires before the next ransomware event. What should the SSCP implement?
The security operations center confirms ransomware on accounting's file server. A junior analyst wants to post the ransom note on the company social account to warn customers. What does Detection, analysis, and escalation require?