Boot Camp  ›  Lessons  ›  Lesson 6

Day 4 — Morning · Domain 4 (30%)

Incident Management — Part A

When prevention fails, management response defines the outcome. Part A covers the incident management program, how incidents are classified and prioritized, and the response lifecycle — with the manager directing, not performing.

Session: Morning, Day 4 Duration: ~3 hrs Exam Weight: 30% (Domain 4) Knowledge Check: 8 Questions

Overview

Prepare, detect, classify, respond — under management

Domain 4 is the second-largest at 30%, and it is intensely management-focused: the exam tests the security manager’s oversight of incident response, not the technical steps a responder performs. Part A builds the incident management program and its plan, defines how events are detected, classified, and prioritized, and works the response lifecycle from preparation through recovery. The recurring lesson: contain before you eradicate, preserve evidence, communicate to the right parties, and keep the manager directing the response while specialists execute.

Learning Objectives

By the end of this lesson you will be able to…

Key Terms

Incident management vocabulary

👈 Tap a card to flip it. Know the lifecycle order and the manager’s role cold.

Lesson Content

Study the material

1

Events, Incidents & the Program

Objective 1 · incident program

Not every event is an incident. An event is any observable occurrence; an incident is one that harms or threatens security and triggers the response process. The capability to respond is built before anything happens, in the incident management program and its plan.

  • The program provides governance, roles, plans, tooling, and training — readiness, not improvisation.
  • The incident response plan defines severity levels, roles, procedures, communication, and escalation, and is tested regularly.
  • The CSIRT/IRT is cross-functional: security, IT, legal, communications, HR, and business stakeholders.
  • The security manager coordinates and directs — specialists perform the technical work.
💡 Exam TipThe CISM lens on incidents is management oversight: the best answer is usually about coordination, decision-making, communication, and following the plan — not the specific technical command a responder would run.
2

Classification & Prioritization

Objective 2 · classification and priority

When an incident is reported, triage validates and classifies it, and severity is assigned by business impact and urgency so the response is proportionate. Detection comes from many sources — monitoring, users, third parties — and a clear escalation path ensures the right people engage fast.

  • Severity reflects impact to the business (data, operations, reputation, legal), not just technical noise.
  • Detection sources: SIEM/monitoring, user reports, threat intel, and external notification (e.g., a regulator or partner).
  • Escalation criteria are predefined — critical incidents (fraud, major breach, regulatory exposure) escalate immediately.
  • Prioritization ensures scarce response resources go to the highest-impact incidents first.
🔎 In practice

A single failed login is an event; thousands of failed logins followed by a success from a new country, against a finance system, is a high-severity incident. Severity is a business-impact judgment, which is why the manager owns the classification criteria.

Explore furtherAttacks (Malware, APT, Zero-Day), Ransomware, and Phishing — interactive modules on the threats behind the incidents you classify and respond to.
Attacks ↗ Ransomware ↗ Phishing ↗
3

The Incident Response Lifecycle

Objective 3 · response lifecycle

Incident response follows a defined lifecycle. Using the widely taught NIST model: Preparation → Detection & Analysis → Containment, Eradication & Recovery → Post-Incident Activity. The order matters, and the manager oversees the transitions and decisions.

  • Preparation: plans, tools, training, and relationships established in advance — the most important phase.
  • Detection & analysis: validate, scope, and classify; determine what is actually happening.
  • Containment → eradication → recovery: stop the spread first, then remove the cause, then restore.
  • Post-incident activity: lessons learned and improvements close the loop.
💡 Exam TipOrder is heavily tested: contain before you eradicate. Eradicating (or rebuilding) before containment lets the threat spread or tips off an attacker — and may destroy evidence you need.

Try it — why speed is the whole game

An incident’s cost is driven by dwell time — how long the attacker operates before you detect and contain them. The longer they run, the more data leaves and the higher the bill, until they’ve taken everything and the cost plateaus. Fast detection and containment is the single biggest lever a manager has.

Interactive · adjust & explore
The response

~50,000 records are exposed if the attacker runs long enough.

48 h
From intrusion to the SOC realizing it (MTTD).
24 h
From detection to stopping the spread (MTTR).
500 rec/h
How fast the attacker pulls data while active.
The damage
Total dwell time
—
Records exposed
—
Breach cost
—
If caught in 2 hours
—
— — Speed up detection and containment to cut the cost.
Breach cost vs. dwell time

Cost climbs as the attacker keeps exfiltrating — then flattens once they’ve taken everything. Your operating point (●) is your current detect + contain time. Getting left on this curve is the whole job.

Breach cost Your operating point
🔎 In practice

This is why preparation is the most important phase and why the manager invests in detection and a rehearsed response: the cost isn’t set at the moment of the breach, it’s set by how long the attacker dwells. And it’s why the order is contain first — stopping the spread is what ends the climb up this curve.

4

Containment, Eradication & Recovery

Objective 4 · containment and recovery

These three steps are where damage is limited and normal service is restored — in order, and with evidence preserved for investigation, regulators, or law enforcement.

  • Containment: isolate affected systems (short-term to stop the bleeding, long-term to allow controlled cleanup) before eradicating.
  • Evidence first: preserve volatile data and maintain chain of custody before wiping or rebuilding — powering off a system can destroy memory evidence.
  • Eradication: remove malware, close the entry point, and revoke compromised credentials so the incident cannot recur.
  • Recovery: restore from known-good backups, validate, monitor closely, and only then return to production.
🔎 In practice

Responders want to immediately re-image an infected server. The manager pauses for evidence preservation and containment first — otherwise the organization loses forensic data, may breach legal-hold duties, and may not even know how the attacker got in.

5

Communication, Notification & Review

Objective 5 · communication and review

How an incident is communicated often matters as much as how it is technically handled. The manager coordinates stakeholder and regulatory communication and ensures the organization learns from every incident.

🔎 In practice

When an incident is also a reportable breach, the plan must branch into the regulatory-notification path — the link between incident management and governance/privacy obligations (e.g., the GDPR’s 72-hour clock, which starts at organizational awareness). The manager pre-defines who declares a breach and who notifies each regulator, so the deadline is never missed while the technical response runs.

  • Notification: meet legal/regulatory timelines (e.g., GDPR’s 72-hour rule) and contractual obligations to customers and partners.
  • Stakeholder communication is controlled and consistent — legal and communications are part of the IRT for a reason.
  • Escalate critical incidents immediately to senior management; don’t wait for the final report.
  • Post-incident review finds root cause and feeds improvements back into controls, the plan, and training.
💡 Exam TipOn notification, the safe CISM instinct is to inform the appropriate internal and external parties through the proper channels within required timeframes — never to conceal, downplay, or delay disclosure of a reportable incident.

Scored Knowledge Check

Test your incident-management judgment

Eight questions on managing incidents. Direct the response and follow the plan — don’t reach for the keyboard.

Q1.During a malware incident, the response team prepares to eradicate the malware from infected hosts. What should happen FIRST?

Question 1 options
Correct: B. Containment precedes eradication: isolating affected systems stops the malware from spreading (and preserves evidence) before the cause is removed. Eradicating first risks propagation and lost forensics. Why the others fall short: A eradicating first risks spreading the malware; C restoring before containment can reintroduce the threat; D customer notification isn’t the first response step.

Q2.In CISM terms, the security manager’s role during incident response is BEST described as:

Question 2 options
Correct: D. The CISM operates as a manager: coordinating the IRT, making decisions, and overseeing the response. The hands-on technical work is performed by specialists under that direction. Why the others fall short: A performing containment personally is the technician role; B waiting for it to resolve is negligence; C handling all communications alone misstates the coordinating role.

Q3.Which phase of the incident response lifecycle is the MOST important for limiting damage when an incident occurs?

Question 3 options
Correct: C. Preparation — plans, tooling, training, and relationships built in advance — determines how well every later phase goes. An unprepared organization improvises and amplifies the damage. Why the others fall short: A eradication and B recovery occur after damage is done; D notification doesn’t limit damage — preparation determines how well every later phase goes.

Q4.Responders want to power off and re-image a compromised server immediately. From a management perspective, the concern is that this may:

Question 4 options
Correct: A. Powering off destroys memory-resident (volatile) evidence and can break legal-hold/chain-of-custody obligations. Evidence preservation and containment should precede eradication and rebuild. Why the others fall short: B it doesn’t meaningfully improve recovery; C it doesn’t reduce severity; D it doesn’t satisfy regulators — it destroys volatile evidence.

Q5.How should incident severity be determined?

Question 5 options
Correct: A. Severity reflects business impact — to data, operations, reputation, and legal exposure — and urgency, so the response is proportionate. Alert volume and technical novelty are not the measure. Why the others fall short: B alert count is noise, not severity; C how ‘interesting’ the attack is doesn’t matter; D time of day isn’t a severity criterion — business impact and urgency are.

Q6.A confirmed data breach triggers a regulatory notification requirement. The security manager should:

Question 6 options
Correct: C. Reportable incidents must be disclosed to the appropriate internal and external parties through proper channels within legal timeframes (e.g., GDPR’s 72 hours). Concealing or indefinitely delaying disclosure is never the CISM answer. Why the others fall short: A delaying past the deadline breaches the requirement; B ‘only if asked’ ignores mandatory reporting; D leaving it to IT’s discretion abdicates the obligation.

Q7.The PRIMARY value of a post-incident review (lessons learned) is to:

Question 7 options
Correct: D. Post-incident review turns an incident into improvement — identifying root cause and feeding fixes back into controls, the plan, and training. It is about learning, not blame or box-ticking. Why the others fall short: A assigning blame isn’t the purpose; B satisfying auditors is incidental; C closing the ticket faster isn’t the goal — root cause and improvement are.

Q8.Which BEST distinguishes an event from an incident?

Question 8 options
Correct: B. An event is any observable occurrence; an incident is an event (or series) that harms or threatens security and therefore triggers the response process. Distinguishing them prevents both over- and under-reaction. Why the others fall short: A the distinction isn’t technical-vs-managerial; C nor external-vs-internal; D they aren’t the same — an incident actually harms or threatens security.