SaveMyCert
Log in
5 of 5 free questions left today·for 10 a day
CISM · Domain 4

Incident Management practice questions

Incident Management is worth 29% of the CISM exam — the 2nd-heaviest of the 4 domains. Readiness (incident response, business continuity and disaster recovery plans, the BIA, classification and testing) and operations: tools, investigation, containment, communications, eradication, recovery and post-incident review. Official weighting 29% from 3 November 2026 (30% before). 6 fully worked examples are further down this page, answers included.

Exam weight
29%
the 2nd-heaviest of the 4 domains
Questions
140
across 4 topics
Free, no account
5/day
a free account allows 10 a day
Explanations
Every option
right and wrong

Build a practice session

5 free questions left today.

Domains

How many?

Mode

Ready when you are

10 fresh questions drawn across 1 of 4 domains, in Learn mode.

Review what you missed

Every question you answer incorrectly, and every question you flag while practising, is saved here automatically. Finish a session and you can come back to re-drill just those.

6 sample Incident Management questions, fully explained

Questions from the CISM bank mapped to domain 4, with the answer key and the reasoning behind every option. None of them repeat the examples on the main CISM practice page.

Question 1Incident Management

During a ransomware outbreak, the response team contains the malware, but the payment system stays down far beyond what the business can tolerate. The post-incident review finds that every step in the response plan was followed. What should the information security manager do to prevent a repeat?

Choose one.

  • a
    shorten the recovery time objective for the payment system in the business impact analysis

    A tighter RTO does nothing if no one invokes the recovery plan. The problem was the missing trigger, not the objective.

  • b
    add the payment system's restoration procedure to the incident response playbook for ransomware

    Copying recovery steps into the playbook duplicates the DRP and lets the two drift apart. The plans should stay separate and be linked by invocation criteria.

  • c
    define impact-based criteria in the response plan for invoking the disaster recovery plan Correct

    The failure was the missing trigger between the plans. Impact-based invocation criteria tell the team when a security incident must be escalated into disaster recovery, so recovery starts in time.

  • d
    require the response team to notify senior management of each ransomware event as soon as it occurs

    Notification keeps leaders informed but still leaves no agreed criteria for invoking recovery, so the same delay could happen again.

The concept

The incident response plan hands over to the disaster recovery and continuity plans through predefined, impact-based invocation criteria.

Why that’s the answer

Containment succeeded and the plan was followed, yet the business still suffered. That points to a gap in the plan itself: nothing in it said when a security incident must be escalated into disaster recovery. Alignment means each plan keeps its own job and the link between them is defined. Changing the RTO, copying procedures into the playbook or notifying management are all reasonable-sounding but leave the trigger undefined.

How to reason it out
  1. Locate the failure: the outage lasted past tolerance although the plan was followed.
  2. Conclude that the plan, not its execution, is missing something: the point at which recovery takes over.
  3. Prefer the fix that links the plans rather than one that duplicates or bypasses them.
  4. Check that the chosen fix would actually have started recovery sooner.

Exam tip: Link the incident response plan to the DRP with impact-based triggers; don't merge or duplicate them.

CISM Incident Response Planning, Classification and Testing — the lesson that teaches this.

Question 2Incident Management

An incident response plan is MOST likely to be followed and resourced during a crisis when it has been:

Choose one.

  • a
    reviewed in detail by internal audit

    An audit review can improve the plan's quality, but auditors cannot give it authority or commit resources.

  • b
    written by the security operations team

    Who drafts the plan matters less than who endorses it. A plan owned only by the operations team lacks business authority.

  • c
    formally approved by senior management Correct

    Senior management approval gives the plan authority and commits the resources it relies on, so it is followed when pressure is highest.

  • d
    benchmarked against an industry framework

    Benchmarking checks completeness against good practice, but it does not give the plan management backing.

The concept

Senior management approval gives the incident response plan its authority and resources.

Why that’s the answer

During a crisis, people follow a plan that carries management's authority and has the budget and people it needs. That comes from formal senior management approval. Audit reviews and benchmarking improve the content, and the security team may draft it, but none of these gives the plan authority.

How to reason it out
  1. Ask what makes people follow a plan under pressure: authority and resources.
  2. Ask who can grant authority and resources: senior management.
  3. Treat quality reviews and drafting as useful but secondary.

Exam tip: A plan gets its authority from management approval, not from who writes or reviews it.

CISM Incident Response Planning, Classification and Testing — the lesson that teaches this.

Question 3Incident Management

Which element of an incident response plan BEST allows the response team to isolate a critical business server during an attack without first consulting the server's owner?

Choose one.

  • a
    an up-to-date contact list for the owners of the critical servers

    A contact list makes consulting the owner faster, but the team would still be waiting for the owner's decision.

  • b
    a documented escalation path from the team to the chief information officer

    An escalation path adds a decision-maker instead of removing the need for one, so the team still waits.

  • c
    pre-approved authority for defined actions at each incident severity level Correct

    When management has approved in advance which actions the team may take at which severity, the team can act at once and inform the owner afterwards.

  • d
    a communication plan for informing affected business units of outages

    A communication plan governs who is told and when. It grants no authority to take the action itself.

The concept

The plan pre-authorizes defined response actions by severity so the team can act quickly on critical systems.

Why that’s the answer

Speed in an attack depends on the team already having the authority it needs. A well-designed plan, approved by management, states which actions (for example isolating a server) the team may take at which severity level without further approval. Contact lists, escalation paths and communication plans all assume someone else still has to decide.

How to reason it out
  1. Identify the delay: the team needs someone's permission before acting.
  2. Ask which element removes the need to ask at that moment.
  3. Reject options that make asking faster rather than unnecessary.

Exam tip: Decide in advance, in the plan, who may take which action at which severity.

CISM Incident Response Planning, Classification and Testing — the lesson that teaches this.

Question 4Incident Management

Incident severity levels are MOST appropriately based on:

Choose one.

  • a
    the technical sophistication of the attack technique used

    A sophisticated technique against a low-value system can matter less than a simple one against a critical system, so sophistication is a poor basis.

  • b
    the number of security alerts raised by monitoring tools

    Alert volume reflects tool tuning and noise. It does not measure the harm to the business.

  • c
    the business impact on the affected assets and processes Correct

    Severity should reflect how much the incident harms the business, which depends on the criticality of the assets, processes and data involved.

  • d
    the type of threat actor believed to be responsible for it

    Attribution is often uncertain early on and does not by itself indicate how much the business is affected.

The concept

Incident severity is set by business impact, not by technical characteristics of the attack.

Why that’s the answer

The purpose of severity is to decide priority, escalation and resources. Those decisions should follow how much harm the incident causes the business, which depends on the criticality of the affected assets and processes and the sensitivity of the data. Technique, alert counts and attribution are useful facts for investigation but are not a sound basis for severity.

How to reason it out
  1. Ask what severity is used for: priority, escalation and resources.
  2. Ask what should drive those decisions: harm to the business.
  3. Reject purely technical measures as the basis.

Exam tip: Severity measures business impact; the technical details inform the investigation.

CISM Incident Response Planning, Classification and Testing — the lesson that teaches this.

Question 5Incident Management

An organization's incident classification scheme defines severity levels but not who must be informed at each level. What is the MOST likely consequence?

Choose one.

  • a
    senior management learns of high-impact incidents later than it should Correct

    Without escalation steps tied to each severity level, the decision to tell management is left to individual judgment, so serious incidents reach leaders late.

  • b
    analysts assign different categories to incidents of the same type

    Inconsistent categorization comes from unclear category definitions, not from missing escalation steps.

  • c
    evidence collected from serious incidents is ruled inadmissible in court

    Admissibility depends on evidence handling and chain of custody, which the classification scheme does not govern.

  • d
    low-impact incidents take up a large share of the response team's time

    Severity levels already exist to separate low-impact incidents. The gap is about who is informed, not how effort is allocated.

The concept

Each severity level in the classification scheme carries predefined escalation and notification requirements.

Why that’s the answer

Classification is useful only when each level triggers defined actions: who is notified, how quickly, and what response applies. When severity exists but escalation is not defined, people must decide on the spot whether to involve management, and serious incidents are escalated late. The other options describe problems with category definitions, evidence handling or effort, which the stated gap does not cause.

How to reason it out
  1. Note the gap: severity levels with no defined notification per level.
  2. Ask who is most affected when notification is left to individual judgment.
  3. Reject options caused by other parts of the process.

Exam tip: A severity level should always say who is told and how fast.

CISM Incident Response Planning, Classification and Testing — the lesson that teaches this.

Question 6Incident Management

The organization's scheme records how each incident occurred as its category and rates its severity separately. An analyst logs a single compromised mailbox as 'credential compromise, low severity', but the mailbox belongs to the payroll manager and holds employee bank details. What should the information security manager conclude?

Choose one.

  • a
    the severity should be raised and the category kept as recorded Correct

    The category correctly records how the incident occurred, but severity must reflect the business impact, and exposure of employee bank details is far more than low impact.

  • b
    the category should be changed to data loss and the severity kept as low

    The scheme categorizes by how the incident occurred, so credential compromise is right. Keeping a low severity ignores the sensitive data exposed.

  • c
    the category and the severity both fit an incident affecting one mailbox

    Counting affected mailboxes ignores what the mailbox holds. Severity is driven by business impact, not by the number of accounts.

  • d
    the category should be changed to data loss and the severity raised as well

    Raising the severity is right, but under this scheme the category describes how the incident occurred, so changing it to the consequence breaks consistent categorization.

The concept

Category and severity are separate dimensions: category records what kind of incident it is; severity records how much it harms the business.

Why that’s the answer

The scheme categorizes by how the incident occurred, and this one was a credential compromise, so the category is correct. Severity is a separate rating, and in incident classification it is driven by business impact: a mailbox holding employee bank details makes the impact significant regardless of the number of accounts involved. Only the severity needs to change. Treating the two dimensions as one leads to the near-twin answers.

How to reason it out
  1. Read how the scheme defines category: how the incident occurred.
  2. Check the category against that definition: credential compromise stands.
  3. Recall what drives severity: business impact, not the number of accounts.
  4. Change only the dimension that is wrong.

Exam tip: Category says what kind of incident it is; severity says how much it hurts. Correct them independently.

CISM Incident Response Planning, Classification and Testing — the lesson that teaches this.

What CISM domain 4 tests, topic by topic

The official exam guide breaks Incident Management into 4 topics. The question bank follows the same split, so a weak topic shows up as a cluster of misses you can go back and read.

Published CISM practice questions per topic in Incident Management
TopicWhat it coversQuestions
Incident response planning, classification and testingOfficial CISM 2026 outline, section 4A Incident Management Readiness (first part): Incident Response Plan; Incident Classification/Categorization; Incident Management Training, Testing, and Evaluation.35
Business impact analysis, continuity and disaster recoveryOfficial CISM 2026 outline, section 4A Incident Management Readiness (second part): Business Impact Analysis (BIA); Business Continuity Plan (BCP); Disaster Recovery Plan (DRP).35
Incident tools, investigation and containmentOfficial CISM 2026 outline, section 4B Incident Management Operations (first part): Incident Management Tools and Techniques; Incident Investigation and Evaluation; Incident Containment Methods.35
Incident communications, recovery and post-incident reviewOfficial CISM 2026 outline, section 4B Incident Management Operations (second part): Incident Response Communications (e.g., reporting, notification, escalation); Incident Eradication and Recovery; Post-incident Review Practices.35
Total140

Revise Incident Management before you drill it

Other CISM domains

Incident Management: your questions

Incident Management is domain 4 of the CISM exam guide and carries 29% of the scored content — the 2nd-heaviest of the 4 domains. On a 150-question paper that works out to roughly 44 questions, though ISACA does not publish an exact per-domain count and individual exam forms vary.

Source

The domain weight and topic list on this page come from the official CISM exam guide.