Sitonce
Country: US
Show exams for United States Hong Kong
Sign in

CISM Incident Management and Recovery Decisions

Updated 8 min read
Key takeaway

CISM incident management spans readiness, response operations, recovery, and post-incident improvement.

  • The manager ensures plans align with business continuity and disaster recovery, defines roles and escalation, supports evidence-based decisions, coordinates communication, and learns from results.
  • During an event, activate the established process, establish facts, contain harm proportionately, and restore services safely.
On this page9 sections
  1. Incident management is a lifecycle
  2. Build readiness before an incident
  3. Respond using facts and assigned authority
  4. Worked scenario: a suspected supplier compromise
  5. Eradication, recovery, and continuity
  6. Post-incident review should change the program
  7. How to answer incident questions
  8. A second original practice question
  9. Common incident-management misconceptions

Incident management is a lifecycle

The CISM Incident Management domain covers more than reacting after an alert. ISACA's outline includes readiness, incident plans, business impact analysis, business continuity and disaster recovery coordination, classification, training and testing, investigation, containment, communications, eradication, recovery, and post-incident review. The manager's responsibility is to make those capabilities coherent and accountable before and during an event.

For candidates sitting before November 3, 2026, Incident Management is 30 percent of the outline; on or after the revised outline date it is 29 percent. The task statements and emphasis should be matched to the appointment date. The domain remains one of the four core CISM areas in both versions.

Lifecycle phaseManagement focusEvidence of readiness
PrepareDefine roles, plans, dependencies, resources, and escalation criteriaApproved plans, contact lists, training, exercises, and assigned owners
Identify and assessClassify the event and establish reliable factsIncident records, triage criteria, investigation process, and evidence handling
Contain and coordinateLimit harm while preserving business and investigation needsDecision authority, response coordination, technical options, and status reporting
CommunicateNotify internal and external parties through authorized channelsCommunication plan, approval path, and applicable notification criteria
Eradicate and recoverRemove cause and restore services safely with continuity needs in viewRecovery priorities, validated backups, recovery tests, and service criteria
LearnReview causes, response performance, corrective actions, and changed riskPost-incident review, owners, due dates, and tracked improvements

Build readiness before an incident

An incident response plan should assign roles and responsibilities, define how an event is declared and escalated, specify investigation and communication paths, and connect response to recovery. The plan should work with the organization's business continuity and disaster recovery arrangements. If separate plans conflict about who can shut down a service or notify customers, the organization may lose time during the event.

Business impact analysis helps identify critical business processes, dependencies, and the consequences of disruption. Those results inform continuity and recovery priorities. A service that is technically easy to restore may not be the first priority if another system supports customer transactions, safety, or a regulated process. Recovery objectives should reflect business needs and the organization's accepted risk.

Readiness includes people and practice. Assign incident team members and alternates, train them on roles, maintain current contact routes, and test plans at appropriate intervals. Tabletop exercises can reveal unclear decisions and missing information. A technical simulation can test different capabilities. Completing an exercise is only a starting point; findings need owners and follow-up.

The CISM manager also ensures the incident classification process is usable. Criteria can distinguish severity and required escalation so teams do not treat every alert identically. Classification should support consistent response, not suppress inconvenient events. Incident records should capture sufficient detail to investigate and learn while preserving confidentiality and evidence requirements.

Respond using facts and assigned authority

When an event occurs, teams should activate the established process and establish what is known. The incident lead coordinates investigation, containment, stakeholder engagement, and decisions. The CISM supports management, but should not take over every technical task or make a business risk acceptance that belongs to an authorized owner. Clear roles prevent parallel teams from making conflicting decisions.

Containment decisions balance immediate harm, business continuity, evidence preservation, and dependencies. Isolating a server may stop spread but interrupt a critical service or erase volatile information. The best response depends on the incident facts, plan, technical advice, and decision authority. Practice avoiding answers that prescribe the same action regardless of the scenario.

Communications should be prompt, accurate, and authorized. A response team may need to brief executives, legal counsel, regulators, customers, employees, suppliers, or law enforcement depending on the event and obligations. The security manager should not declare facts that have not been verified, but should not wait for a complete investigation before internal escalation or required notifications. Coordinate with the roles named in the plan.

Worked scenario: a suspected supplier compromise

A cloud supplier reports suspicious access to an administrative account used to support a customer-facing service. It cannot yet determine whether records were viewed. The service is operating, the supplier has disabled the account, and the business unit asks the CISM to announce that no customer information was affected. What should happen next?

The CISM should activate the established supplier and incident escalation process, coordinate with the incident lead and business owner, preserve relevant evidence, and establish verified facts about account activity and data access. The team should assess whether additional containment is needed without disrupting the service unnecessarily. Communications should follow the approved path and accurately state what is known and unknown. The organization must evaluate applicable notification duties with the appropriate legal and privacy stakeholders.

The supplier's account disablement is a useful containment step, but it does not prove that the service is safe. Saying no records were affected would overstate the evidence. Waiting for the supplier's complete investigation before internal escalation would delay the organization's response. Terminating the contract immediately may be considered later, but it is not a substitute for investigating and managing the active event.

Eradication, recovery, and continuity

Eradication addresses the cause, such as compromised credentials, a vulnerable system, or unauthorized persistence. Recovery restores systems and business processes in a controlled manner. Before returning a service to operation, the organization should have sufficient confidence that the threat is removed, access is controlled, monitoring is in place, and the recovery meets business needs.

Recovery decisions should use tested plans and dependencies. Validate backups before relying on them, confirm that restored data are complete enough for the business, and watch for indicators of renewed compromise. If a service must remain limited while recovery continues, communicate the operational impact and alternatives to business owners. A successful technical restore does not automatically mean business recovery is complete.

Business continuity and disaster recovery are related but distinct. Continuity helps maintain or resume critical business functions during disruption. Disaster recovery focuses on restoring technology infrastructure and systems. Incident response coordinates the security event and its immediate risks. The CISM helps align the plans so that teams know which process leads, how decisions connect, and where handoffs occur.

Post-incident review should change the program

After the immediate event, conduct a review that examines what happened, why controls did or did not work, how decisions and communication flowed, and what should change. Root-cause analysis should avoid stopping at the visible symptom. A late alert might stem from a monitoring gap, unclear ownership, supplier contract language, or inadequate training. Corrective actions need accountable owners and due dates.

Lessons can affect multiple CISM domains. A response gap may require a governance decision about accountability, a risk assessment update, program investment, or a revised exercise. Reassess risks after material changes. Track actions to completion and test that they improve capability. A report filed without follow-up does not create continuous improvement.

How to answer incident questions

  1. Identify the event, affected business process, and what is confirmed versus suspected.
  2. Determine whether the question asks about readiness, immediate response, recovery, or improvement.
  3. Locate the incident lead, business owner, security manager, and communication authorities.
  4. Choose a proportionate action that reduces harm while respecting evidence, continuity, and policy.
  5. Do not make unsupported public claims or delay required escalation while waiting for perfect certainty.
  6. After recovery, identify the root cause and assign measurable corrective work.

Many distractors are valid activities placed at the wrong stage. A post-incident review is too late when containment is still needed. Buying a new monitoring product may not be the first step if no one has confirmed the event or activated response. Restoring a system before establishing that the compromise is removed can reinstate the threat. Use lifecycle and sequence to distinguish the strongest option.

A second original practice question

An incident exercise shows that the response team can isolate systems, but no one knows who may authorize taking a customer service offline. The business continuity plan names a different executive from the incident plan. What is the CISM's best next action? A. Schedule another exercise without changing the plans. B. Reconcile the plans, clarify decision authority with accountable leaders, and update and test the procedures. C. Give the security manager permanent authority to shut down any service. D. Remove service availability from the exercise scope.

Best answer: B. The exercise exposed a governance and coordination gap. The organization should agree who has decision authority, align the response and continuity plans, communicate changes, and verify them in a later test. A second exercise alone repeats the same uncertainty. Giving security blanket authority may conflict with governance and business ownership. Removing availability would hide a critical dependency rather than solve it.

Common incident-management misconceptions

  • Incident response starts before an event through assigned roles, plans, training, and exercises.
  • The security manager coordinates and advises but does not automatically own every business decision.
  • Containment must consider service impact, evidence, and dependencies, not only technical isolation.
  • External communications should be accurate and authorized; internal escalation should not wait for perfect certainty.
  • Recovery is not complete merely because a server is online; business requirements and security conditions matter.
  • A post-incident report needs assigned corrective actions and follow-up to improve the program.

Incident management is an organizational capability. CISM candidates should be able to connect plans, business impact, incident authority, communications, recovery, and improvement. Learn the lifecycle and practise applying it to new facts. Then match the task statements to the outline effective on your test date.

Common questions

What does CISM Incident Management cover?

Readiness, response planning and operations, classification, exercises, investigation, containment, communications, eradication, recovery, and post-incident improvement.

How does incident response relate to business continuity?

Incident response manages the security event, business continuity sustains or resumes critical business functions, and disaster recovery restores technology. Plans should coordinate roles and handoffs.

What should the CISM do first when an incident is suspected?

Follow the established escalation and incident process, establish reliable facts, preserve evidence, and coordinate an appropriate response through assigned roles.

Should a CISM announce a breach before facts are confirmed?

Communications should be prompt and accurate, using authorized roles and applicable requirements. Do not state unverified conclusions, but escalate internally and meet required notification duties.

What happens after recovery?

Conduct a post-incident review, assess root causes and response effectiveness, assign corrective actions, reassess risk, and track improvements to completion.