CISSP Incident Management Steps: The Seven Outline Activities, NIST's Life Cycle, and First-Step Questions

Search for "CISSP incident response steps" and you'll find six, seven or eight steps, in different orders. The source that matters for the exam is short: objective 7.6 of the CISSP outline, "Conduct incident management," lists seven activities, and the outline that takes effect on April 15, 2027 lists the same seven in the same order. This guide explains them, shows how they line up with NIST's guidance, and turns them into rules for the sequence questions built on them. The outline lists the seven without numbering or defining them; the meanings below are those commonly used in CISSP study, labeled where they're Passy's reading.

The seven incident management activities in objective 7.6

Two details are easy to miss. Preparation isn't one of the seven. The work that prepares for incidents lives in other objectives: policies and procedures (1.6), awareness training (1.12), logging and monitoring (7.2) and detection and prevention measures (7.7). And recovery comes before remediation in ISC2's list, while NIST's older model named eradication before recovery. In practice the two overlap; on the exam, follow the outline's names and order.

Event or incident? NIST's definitions

Detection starts with telling the two apart. NIST SP 800-61r3 defines an event as any observable occurrence involving computing assets, such as a login attempt or a software update, and an adverse event as one with a negative consequence. A cybersecurity incident, in the federal definition NIST quotes, is an occurrence that actually or imminently jeopardizes the confidentiality, integrity or availability of information or a system without lawful authority, or that violates or imminently threatens to violate law, security policies, security procedures or acceptable use policies.

So an alert is an event until analysis shows it's an incident. That's why detection includes confirmation, and why "declare an incident and wipe the machine" is rarely a correct first step.

How the CISSP steps map to NIST's life cycle

NIST published SP 800-61r3 in April 2025, superseding SP 800-61r2 (August 2012). The old four-phase life cycle still appears in many study materials, so it helps to see all three side by side. The CISSP column mapping is Passy's; NIST's own table maps only its four old phases to the new Functions.

NIST explains why it moved away from the circular model: incidents are now frequent, recovery can take weeks or months, and lessons learned should be shared as soon as they're identified rather than after recovery ends. It also says organizations should use whichever life cycle model suits them best. That's a useful reminder for the exam: ISC2's seven activities are the vocabulary to answer in, even if your employer uses another model.

One incident, seven steps: a walkthrough

A fictional example. On a Monday morning, the security operations center sees an alert: a finance employee's cloud email account has created a rule forwarding all invoices to an outside address.

1. Detection. An analyst confirms the rule exists, that the employee didn't create it, and that the sign-in came from an unfamiliar location. It's an incident.
2. Response. The analyst opens an incident under the response plan and pages the on-call incident lead, who assigns roles.
3. Mitigation. The team disables the forwarding rule, revokes the account's sessions, resets its credentials and blocks the outside address, after capturing the rule and the sign-in logs as evidence.
4. Reporting. The incident lead informs management and legal. Legal assesses whether the forwarded data triggers any notification duty to customers or regulators.
5. Recovery. The employee's account returns to normal use with phishing-resistant multifactor authentication.
6. Remediation. The root cause turns out to be a phishing page plus a legacy sign-in method that bypassed MFA; that method is disabled for every account.
7. Lessons learned. A short review adds an alert for new external forwarding rules and updates awareness training with this phishing example.

Answering "what should you do FIRST" incident items

Rules that settle most sequence questions (editorial, built on the outline's order):

• An unconfirmed alert: analyze and confirm first. Containing or wiping a system on an alert alone skips detection.
• A confirmed, active incident: contain before you eradicate or restore. Restoring a system while the attacker still has access invites a repeat.
• Possible legal action or an investigation: preserve evidence before changing systems. Objective 7.1 covers evidence collection and handling, and 1.5 covers investigation types.
• Who acts: follow the incident response plan and its escalation path. An option where one administrator acts alone, or contacts the attacker, is usually a trap.
• Who speaks: reporting goes through designated channels, and legal or regulatory deadlines can make some reporting urgent. Read the stem for a notification duty.
• Before closing: remediation and lessons learned are part of the process, not optional extras.

These rules apply the process step of the think like a manager decision order to incidents.

Incident items sit in Security Operations, so it pays to practice Security Operations on its own with the CISSP prep planned for launch before you mix domains.

Incident response practice items written by Passy

These are original items, not ISC2 questions.

1. A SIEM raises an alert: a payroll clerk's account signed in from two countries within ten minutes. Nothing else is known. What should the analyst do FIRST?

Keyed answer: investigate the alert to confirm whether it's an incident, for example by checking sign-in details and contacting the user through a known channel. Disabling the account might follow; reimaging the clerk's laptop or notifying regulators is premature.

2. Malware is confirmed on several file servers and is spreading. Legal counsel expects litigation. Which action BEST fits this stage?

Keyed answer: isolate the affected servers while preserving evidence, such as capturing images before systems are rebuilt. Rebuilding immediately destroys evidence; waiting for a full forensic report lets the malware spread.

3. After service is restored, the team closes the incident ticket the same afternoon. Which two activities from objective 7.6 were skipped?

Keyed answer: remediation and lessons learned. Without fixing the root cause and reviewing the response, the same entry point stays open and the plan doesn't improve.

When you miss a sequence item like these, the fix is usually knowing which of the seven steps the stem describes. Every missed question waits in Fix It in the planned CISSP prep, so the ordering mistakes come back until they stick.

What the 2027 outline adds around incident management

The seven activities don't change on April 15, 2027. The tools around them do. Objective 7.2 adds security orchestration, automation and response (SOAR) and data loss prevention under egress monitoring; 7.7 adds endpoint detection and response (EDR), extended detection and response (XDR), DDoS scrubbing services and managed security service providers. Learn what each contributes to detection and response; the full list of changes is in the CISSP 2027 outline guide.

Learning the seven CISSP incident steps this week

Write the seven activities from memory each day until the order is automatic, then attach one concrete action to each from your own work or the walkthrough above. Recovery and disaster recovery questions often continue where incident items stop; the CISSP BCP and disaster recovery guide covers them. The 20 free CISSP practice questions include Security Operations items, and the 150-question mock exam planned for CISSP prep mixes Domain 7 with the other seven domains, as the real exam does.