7.6 Incident Management

Key Takeaways

CISSP 7.6 focuses on conducting Incident Management.

The current CISSP Exam Outline explicitly lists Detection, Response, Mitigation, Reporting, Recovery, Remediation and Lessons Learned.

The central purpose of Incident Management is to transform an unexpected cybersecurity event into a controlled organisational response.

A useful CISSP memory sequence is:

Detect → Respond → Mitigate → Report → Recover → Remediate → Learn.

Real incidents are not always perfectly linear.

Detection, investigation, reporting, mitigation and recovery can overlap and repeat as new information becomes available.

An event is something observable that happens.

An alert indicates that monitoring identified something potentially significant.

An incident requires coordinated security handling.

A breach generally involves compromise or exposure of protected information, but legal definitions can vary.

Event ≠ alert. Alert ≠ incident. Incident ≠ automatically reportable breach.

Incident readiness should exist before the incident occurs.

Organisations should define policies, roles, authority, communication channels, contacts, tools and likely playbooks in advance.

Incident-response exercises help determine whether plans actually work.

A plan defines the overall incident-management capability.

A playbook addresses a particular incident scenario.

A runbook provides detailed operational steps.

Plan = overall. Playbook = scenario. Runbook = exact procedure.

Serious incidents are cross-functional.

Security, IT, application owners, legal, privacy, communications, executives, HR, business continuity and third parties may all play roles.

Incident authority should be clear before a crisis.

Responders need to know who may isolate systems, disable accounts, activate recovery, contact external parties and make major business decisions.

Detection identifies activity that may represent an incident.

Detection can originate from SIEM, EDR, IDS, users, threat intelligence, third parties and many other sources.

Triage determines whether the signal is real and how urgently it needs to be addressed.

Incident scope should include affected systems, identities, data, services and attacker activity.

First compromised system discovered ≠ complete incident scope.

Severity describes how serious the incident is.

Priority determines how urgently resources should address it.

Response activates and coordinates the organisational capability needed to handle the incident.

Maintaining a reliable timeline of major events, actions and decisions supports coordination, investigation and accountability.

Mitigation aims to reduce the immediate damage or spread of the incident.

Mitigation activities can include isolating hosts, disabling accounts, revoking sessions, restricting network access and temporarily disabling vulnerable services.

In other incident-response frameworks, similar actions may be called containment.

Mitigation = control the problem now.

Containment decisions should consider more than technical security.

Business impact, availability, human safety and evidence requirements may all influence the best response.

Evidence should be preserved where appropriate and feasible before destructive remediation.

However, evidence preservation does not automatically override urgent safety or containment needs.

Incident plans should consider alternative communication channels because normal email or collaboration systems may themselves be compromised.

Reporting communicates incident information to the people and organisations that need it.

Internal reporting may involve technical, executive, legal, privacy and business stakeholders.

External reporting may involve regulators, affected parties, suppliers, insurers or law enforcement where applicable.

Early incident information is often incomplete.

Reports should therefore distinguish confirmed facts from assumptions and unknowns.

"No evidence identified yet" is not the same as "it did not happen."

Recovery restores affected systems and business capabilities.

Recovery should occur from systems and data that are sufficiently trusted to avoid restoring the attacker or the original compromise.

Recent backup ≠ known-good backup.

Attackers may have been present long before an incident became visible.

Staged recovery can reduce the risk of reconnecting a still-compromised environment all at once.

Enhanced monitoring during recovery can identify whether suspicious activity returns.

Incident recovery and Disaster Recovery are related but different.

Not every security incident requires activation of formal Disaster Recovery capabilities.

A major cyber incident may, however, cause sufficient disruption that DR mechanisms are required.

Remediation addresses the underlying causes and remaining attacker presence.

Remediation can include patching vulnerabilities, removing malware, eliminating persistence, rotating credentials and correcting insecure configurations.

Other incident-response frameworks often call attacker removal: eradication.

Within the ISC2 7.6 terminology, those activities fit closely with remediation.

Mitigation = reduce immediate damage. Recovery = restore service. Remediation = fix the underlying problem.

Restoring service without correcting the original weakness can cause recurrence.

Likewise, resetting one password may be insufficient if attacker tokens, keys, malicious accounts or persistence remain.

Lessons learned should analyse the incident after the immediate crisis has been handled.

The review should identify what worked, what failed, what was missing and what needs improvement.

Lessons learned should produce concrete improvement actions.

Those actions should have ownership, target dates and validation.

Lesson without action = observation.

Post-incident review should support learning rather than become merely a blame exercise.

Current NIST guidance is now based on SP 800-61 Rev. 3.

It superseded SP 800-61 Rev. 2 in April 2025.

Current NIST guidance places incident-response activity primarily within:

Detect → Respond → Recover.

Govern, Identify and Protect provide broader cybersecurity-risk-management activities that support incident-response preparation.

Lessons from incidents feed continuous improvement across the cybersecurity programme.

Older materials may still describe the former NIST model using Preparation, Detection & Analysis, Containment, Eradication, Recovery and Post-Incident Activity.

That older terminology remains useful conceptually, but SP 800-61 Rev. 3 is now the current NIST publication.

For CISSP 7.6, however, candidates should recognise the explicit ISC2 terminology:

Detection → Response → Mitigation → Reporting → Recovery → Remediation → Lessons Learned.

Ransomware demonstrates why Incident Management must be broader than simply restoring backups.

Responders must consider initial access, attacker persistence, credential compromise, lateral movement, possible data theft, containment, recovery and remediation.

Third-party incidents also require organisational response where supplier compromise affects your information or services.

Supplier owns its incident. Your organisation still owns its risk.

In environments where cyber systems affect physical processes, human safety takes precedence over purely technical preferences.

Automated response can accelerate repeatable actions but should have appropriate confidence thresholds, approvals and safeguards where actions could cause significant disruption.

Metrics such as detection, escalation, containment and recovery time can help identify weaknesses in the response capability.

The central CISSP principle is: detect incidents quickly, coordinate the right people, limit the damage, communicate accurately, restore operations safely, correct the underlying weaknesses and turn every incident into an opportunity to improve security.