Incident Management

Most alerts are events; only the dangerous subset that jeopardizes confidentiality, integrity, or availability is an incident, and that boundary is why Detection is step one of the lifecycle: you cannot respond to something you have not yet classified. Treating a detective control's alert as already an incident is the predictable misread. This section draws the event/incident line, anchors the (ISC)² seven-step lifecycle in order, and maps every step onto NIST's four phases, the two framings the exam swaps between.

Event vs incident: the boundary the whole lifecycle defends

Start with the definitions, because the first lifecycle step depends on them. NIST defines an event as "any observable occurrence in a system or network": a user connecting to a file share, a server receiving a web request, a firewall blocking a connection (NIST SP 800-61 Rev. 2, §2.1^[1]). Most events are routine. A computer security incident is the small, dangerous subset: "a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices" (NIST SP 800-61 Rev. 2, §2.1^[1]). The NIST glossary states the same idea in CIA terms: an incident "actually or potentially jeopardizes the confidentiality, integrity, or availability" of a system or its data (NIST CSRC glossary: incident (FIPS 200)^[2]). NIST also names the in-between category: an adverse event is simply an event with a negative consequence; an adverse event becomes an incident only once it crosses the policy-violation / CIA-jeopardy line.

The practical consequence is the reason Detection is step one, not Response: you cannot respond to something you have not yet classified as an incident. A predictable misread is to treat every alert as an incident: most alerts are events, and the lifecycle exists precisely to triage the flood of events down to the few incidents worth handling.

One lifecycle, two recitations

The (ISC)² CBK teaches a seven-step lifecycle: Detection → Response → Mitigation → Reporting → Recovery → Remediation → Lessons Learned. That exact order is the single most testable fact in this subtopic, so anchor it cold. The figure above walks those seven steps top to bottom and wraps each in its NIST phase, so you can read the flow and the mapping from one picture. NIST SP 800-61, the authoritative guide the (ISC)² sequence is built on, describes "the major phases of the incident response process, preparation, detection and analysis, containment, eradication and recovery, and post-incident activity" (NIST SP 800-61 Rev. 2, §3^[1]). These are not competing lists; they are the same work at two resolutions.

The mapping is what the exam tests:

• NIST Preparation wraps the whole cycle (build the plan, team, and tools before anything happens). It is implicit in the (ISC)² list rather than a numbered step, but if a question asks which phase is foundational/continuous, it is Preparation.
• (ISC)² Detection + Response sit inside NIST Detection and Analysis: recognize the incident, analyze and prioritize it, notify, and activate the team.
• (ISC)² Mitigation, Recovery, and Remediation are all inside the single NIST Containment, Eradication, and Recovery phase. NIST bundles three of the (ISC)² steps into one phase; that bundling is a favorite distractor (a stem may imply these are separate NIST phases; they are not).
• (ISC)² Lessons Learned is NIST Post-Incident Activity.
• (ISC)² Reporting is not a single NIST sub-phase; NIST treats notification and reporting as continuous activity that begins in Detection and Analysis and runs through the cycle.

Hold the two together as one model and you can answer either framing from the same mental picture.

This section walks each (ISC)² step in order and ties it to what NIST says you actually do. Read it after the definitions above; each step assumes the prior one completed.

1. Detection

Detection is recognizing that an event is, in fact, an incident. The raw material is precursors and indicators: NIST defines a precursor as "a sign that an incident may occur in the future" and an indicator as "a sign that an incident may have occurred or may be occurring now" (NIST SP 800-61 Rev. 2, §3.2.2^[1]). Detection feeds on alerts produced by the monitoring stack (covered under logging-monitoring) but is itself the human/process act of classifying. NIST is blunt that this is hard: indicators are noisy and not guaranteed accurate, which is why analysis and triage belong here.

2. Response

Response activates the incident-response capability: the team is engaged and begins handling the incident according to the plan written during preparation. This is also where the critical prioritization decision lives. NIST calls prioritization "perhaps the most critical decision point in the incident handling process" and states plainly that "incidents should not be handled on a first-come, first-served basis" (NIST SP 800-61 Rev. 2, §3.2.6^[1]). Rank by three factors: functional impact (effect on business operations), information impact (effect on the confidentiality, integrity, and availability of data), and recoverability (the time and resources recovery will take).

3. Mitigation (containment)

Mitigation is containment: stopping the incident from spreading or causing further damage before you build the full fix. NIST says containment "is important before an incident overwhelms resources or increases damage" and that it "provides time for developing a tailored remediation strategy" (NIST SP 800-61 Rev. 2, §3.3.1^[1]). The choice of containment strategy should be predetermined per incident type, weighed against documented criteria: potential damage and theft of resources; need for evidence preservation; service availability; time and resources to implement; effectiveness; and duration of the solution (NIST SP 800-61 Rev. 2, §3.3.1^[1]). NIST warns specifically against delayed containment (knowingly letting a compromise run to watch the attacker): it is "dangerous because an attacker could escalate unauthorized access or compromise other systems," and a redirect-to-sandbox approach must be cleared with legal first.

4. Reporting

Reporting is notifying the right people on the schedule the plan defines. NIST frames notification as: once an incident is analyzed and prioritized, "the incident response team needs to notify the appropriate individuals so that all who need to be involved will play their roles," and policy should specify "what must be reported to whom and at what times" (NIST SP 800-61 Rev. 2, §3.2.7^[1]). Typical recipients include the CIO, the head of information security, and other internal teams; at CISSP altitude, add senior management, legal, the privacy/DPO function, public relations, and any external parties that breach-notification law (e.g., GDPR's 72-hour authority notification), regulation, or contract requires. Reporting is shown as a discrete (ISC)² step but in practice runs continuously from detection onward.

5. Recovery

In recovery, "administrators restore systems to normal operation, confirm that the systems are functioning normally, and (if applicable) remediate vulnerabilities" (NIST SP 800-61 Rev. 2, §3.3.4^[1]). Actions include restoring from known-clean backups, rebuilding from scratch, replacing compromised files, patching, rotating credentials, and tightening the perimeter. Recovery should confirm normal operation and often raises logging/monitoring on the restored systems, because "once a resource is successfully attacked, it is often attacked again."

6. Remediation (eradication)

Remediation maps to NIST eradication: eliminating the components of the incident and closing the root cause. NIST: "eradication may be necessary to eliminate components of the incident, such as deleting malware and disabling breached user accounts, as well as identifying and mitigating all vulnerabilities that were exploited" (NIST SP 800-61 Rev. 2, §3.3.4^[1]). NIST adds that eradication and recovery should be done in a phased approach with prioritized steps, and notes that for large-scale incidents recovery may take months. (NIST also observes that for some incidents eradication is unnecessary or is folded into recovery, which is why the (ISC)² ordering of Recovery before Remediation is not contradictory: the steps interleave in practice.)

7. Lessons Learned

Lessons Learned is the structured post-incident review. NIST identifies it as "one of the most important parts of incident response" and "also the most often omitted," and gives concrete timing: the lessons-learned meeting "should be held within several days of the end of the incident" (NIST SP 800-61 Rev. 2, §3.4.1^[1]). It reviews what happened, how well staff and procedures performed, what was needed sooner, and what corrective actions prevent recurrence, then feeds those changes back into preparation. Multiple lesser incidents can be covered in one meeting. Skipping this step is the canonical process failure: the same incident recurs because no control or procedure was updated.

This section covers who runs the lifecycle and how the work is organized, the governance layer the CISSP expects a security leader to direct. Read it after the seven steps; it assumes you know what each step does.

The CSIRT and why it is built in advance

The Computer Security Incident Response Team (CSIRT), also seen as CIRT or CERT, is the standing capability that executes the lifecycle. The defining CISSP point is prepare before you need it: the team, the plan, the contact tree, and the tooling are all built during NIST's Preparation phase, so that during a live incident the team executes a plan rather than improvising one. NIST stresses that containment decisions are "much easier to make if there are predetermined strategies and procedures" (NIST SP 800-61 Rev. 2, §3.3.1^[1]); the same logic applies to escalation and notification paths.

Three team-structure models

NIST lists three possible team structures (NIST SP 800-61 Rev. 2, §2.4.1^[1]):

• Central Incident Response Team: a single team handles incidents across the whole organization. NIST says this "is effective for small organizations and for organizations with minimal geographic diversity."
• Distributed Incident Response Teams: multiple teams, each responsible for a logical or physical segment (one per division, region, or facility). NIST recommends this for large or geographically spread organizations, but insists the teams "should be part of a single coordinated entity so that the incident response process is consistent."
• Coordinating Team: a team that "provides advice to other teams without having authority over those teams"; NIST describes this as "a CSIRT for CSIRTs."

Staffing is an orthogonal choice: fully in-house (employees), partially outsourced (commonly 24/7 monitoring handed to a managed security service provider), or fully outsourced.

Escalation and notification

Escalation is the predefined path that moves an incident up the severity and authority ladder when it exceeds the current handler's scope or thresholds. Like the team itself, the escalation matrix and the notification list are set in the plan before an incident, because the middle of a crisis is the worst time to decide who must be told. Reporting (step 4) walks this predefined list; notification recipients run from the CIO and head of information security internally out to legal, the privacy office, and external regulators or partners as law and contract require (NIST SP 800-61 Rev. 2, §3.2.7^[1]).

A note on the current NIST revision

The four-phase model above is from NIST SP 800-61 Rev. 2 (2012), still the version the (ISC)² seven-step sequence tracks and the one the exam reflects. The newer NIST SP 800-61 Rev. 3 (April 2025) re-casts incident response as a CSF 2.0 Community Profile, aligning the work to the Cybersecurity Framework Functions (Govern, Identify, Protect, Detect, Respond, Recover) rather than the four named phases (NIST SP 800-61 Rev. 3 (2025)^[3]). For the exam, know that the four-phase lifecycle remains the canonical teaching model and that Rev. 3 maps the same activities onto the CSF; both can appear, and they do not conflict.

This section maps question shapes to the right answer. Read the others first; this is the pattern layer.

Pattern 1: "Put these steps in order." A stem lists incident-handling actions scrambled and asks for the sequence. Answer with the (ISC)² order: Detection → Response → Mitigation → Reporting → Recovery → Remediation → Lessons Learned. The trap option usually swaps two adjacent steps (e.g., Recovery before Mitigation) or drops Lessons Learned. If the stem instead uses NIST's words, the order is Preparation → Detection and Analysis → Containment, Eradication, and Recovery → Post-Incident Activity.

Pattern 2: "What do you do FIRST on an active compromise?" When a host is actively owned, the first action is contain (isolate / disconnect / disable the abused function), not eradicate and not rebuild. NIST: containment "is important before an incident overwhelms resources or increases damage" and buys time for a tailored remediation (NIST SP 800-61 Rev. 2, §3.3.1^[1]). The tempting wrong answers are "rebuild the server" or "patch the vulnerability" while the attacker is still live and able to spread.

Pattern 3: "Which incident do you handle first?" Multiple simultaneous incidents, limited staff: prioritize by functional impact, information impact, and recoverability, highest business impact first. NIST explicitly rejects first-come, first-served (NIST SP 800-61 Rev. 2, §3.2.6^[1]). The trap is the option that picks the incident reported earliest or the one that is technically most interesting.

Pattern 4: event vs incident. A stem describes a routine occurrence and asks how to classify it. Any observable occurrence is an event; only a violation or imminent threat to CIA / policy is an incident. The act that draws this line is Detection. The trap is treating any alert, or any adverse event, as automatically an incident.

Pattern 5: "What is most often skipped / what prevents recurrence?" The answer is Lessons Learned (NIST Post-Incident Activity), held within several days of the incident's end, feeding corrective actions back into preparation (NIST SP 800-61 Rev. 2, §3.4.1^[1]). The trap is choosing "more monitoring" or "another patch" as the recurrence fix when the stem is really testing the review step that decides which control to change.

Pattern 6: scope boundaries. A stem about chain of custody or forensic soundness is investigations, not incident management; a stem about SIEM correlation rules is logging-monitoring; a stem about RTO/RPO and restoring the business after a disaster is disaster-recovery / recovery-strategies. Incident management owns the lifecycle and the containment-vs-eradication ordering; it only references those neighbors.