CISM Incident Management: Readiness Through Recovery

When a ransomware event interrupts a hospital’s appointment platform, the first unanswered question may not be how to remove malware. It may be whether clinicians can access tomorrow’s schedules, who can authorize the shutdown of a connected system, which evidence must be preserved and when the hospital must notify outside parties. Those decisions belong to information security incident management: coordinated action under uncertainty, with consequences that extend beyond technology.

For ISACA CISM, incident management covers both readiness and operations. The current CISM outline assigns it 30% of the exam. ISACA’s announced November 3, 2026 revision adjusts the share to 29%, but the central obligation remains unchanged: prepare the organization to recognize, contain, communicate and recover from security incidents while managing business impact.

Incident readiness begins long before an alert

A response plan is only credible when it names decision-makers, defines how incidents are classified and describes how essential teams will work together. Security operations may investigate technical indicators; application owners understand dependencies; legal counsel determines notification obligations; communications teams handle public messaging; and business leadership decides how to balance service interruption against continued exposure. A plan that assumes everyone will meet at a normal office number during a network outage has not been tested against reality.

Readiness includes the ability to reach the right people outside normal channels. Contact lists, alternate communications, emergency authority and supplier escalation paths should be maintained and exercised. The hospital should know who can authorize isolation of a scheduling server at midnight, who can arrange manual booking procedures and who can decide that restoration is safe enough to resume operations.

A useful plan is specific about triggers rather than prescriptive about every command. The team needs criteria to declare a major incident, thresholds for escalating to executives and guidance on when legal or privacy specialists must join. Too much tactical detail can become obsolete after a system update, whereas clear roles and decision boundaries remain useful through different attack techniques.

Make business impact analysis operational

Business impact analysis identifies critical processes, the consequences of interruption and dependencies needed to sustain or restore them. It is distinct from a technical vulnerability assessment. A clinical scheduling workflow might depend on an identity service, database, network connection, staff contact lists and a third-party messaging provider. Restoring the database alone does not reestablish the service if staff cannot authenticate or appointment confirmations cannot be delivered.

Recovery time objective and recovery point objective are different promises. RTO concerns the targeted time for restoring a process or capability; RPO concerns the maximum targeted data loss measured in time. The distinction is discussed in detail in recovery time versus recovery point planning. Both objectives must be grounded in business needs and tested against what backup and recovery arrangements can deliver.

Business continuity planning addresses how essential operations continue during disruption, while disaster recovery concentrates on restoring supporting technology. Incident response must coordinate with both. For the hospital, a temporary paper scheduling workflow may provide continuity even while the affected platform remains isolated. A technically successful server restore that leaves appointment updates unreconciled could still create serious operational harm.

Classify severity by consequence, not headlines

Detection systems produce events, alerts and sometimes credible signs of a security incident. Classification turns those observations into a response priority. It should consider actual or plausible impact on safety, information, service continuity, legal obligations and the scope of compromise. A dramatic malware signature on a disconnected test machine may deserve less enterprise attention than a subtle but verified compromise of the identity system used by essential services.

Severity levels should trigger proportionate actions: response staffing, executive notification, outside expertise and communication frequency. They also need a way to change as evidence develops. An initially limited incident may become major if forensic analysis identifies lateral movement or data exfiltration. Conversely, escalation should not be sustained merely to avoid admitting that an early assessment was wrong.

A manager should distinguish incident declaration from certainty about root cause. Organizations may need to isolate a system based on credible evidence before investigators know exactly how access occurred. The record should separate observations, hypotheses and decisions, with times and owners. This helps avoid both paralysis and premature public claims that later prove inaccurate.

Containment is a business decision with technical inputs

Containment may involve disabling accounts, limiting network paths, suspending integrations or taking systems offline. Each action can reduce attacker opportunity but may also harm critical services. The security manager should understand the options and their effects well enough to coordinate an authorized decision. A blanket shutdown might protect sensitive data while delaying clinical appointments; a narrower restriction may preserve care but leave more room for attacker movement.

Teams should prepare emergency procedures for preserving volatile evidence and documenting changes. Evidence handling has consequences for investigations, insurance claims and legal proceedings. Not every incident needs full forensic collection, but critical cases require a deliberate balance among containment, evidence preservation and restoration speed. Personnel performing those tasks need procedures suited to the technology and their authority.

Containment does not mean eradication. An attacker may be blocked temporarily while compromised accounts, persistence mechanisms or insecure configurations remain. Declaring victory after isolation can expose the organization to a repeat incident. Incident records should track which indicators are confirmed, which systems are still suspect and what conditions must be satisfied before recovery.

Coordinate investigation, eradication and safe recovery

Investigation should establish the scope, probable attack path and affected assets sufficiently to guide remediation. Logs, endpoint observations, identity events and supplier evidence can help, but gaps in visibility are common. The team should communicate confidence levels and avoid treating absence of an alert as proof that a system was unaffected. Security management may need to commission specialist assistance when existing resources cannot establish the necessary facts.

Eradication targets the conditions that allowed compromise to persist. It may include removing malicious components, rotating credentials, correcting access paths or rebuilding assets from trusted sources. Recovery is a separate controlled process: validate the environment, restore dependent services in business-priority order and monitor closely for renewed malicious activity.

In the hospital scenario, clinical leadership should confirm that appointments are accurate and booking workflows function before the platform is declared fully restored. Technical teams must consider whether data entered manually during the outage have been reconciled. Recovery is complete when the service can meet its required business function, not simply when a server responds to a health check.

Communicate accurately while facts are changing

An incident communication plan should specify stakeholders, responsibilities, channels, authorization and escalation thresholds. Internal staff may need immediate operational instructions; executives need decisions and a realistic statement of uncertainty; customers may need clear service-impact information; regulators may require notification under applicable law. These messages are related but cannot be identical.

Early communications should distinguish known facts from working assumptions. Saying “we have found no evidence of exposure” may be misleading if logging is incomplete. A clearer internal message explains what has been confirmed, what remains under investigation, which services are affected and when the next update will occur. External statements should be coordinated with the appropriate legal, privacy and communications functions.

The timing of notification is sometimes governed by contracts or law. A security manager should not invent a universal deadline. The organization must know its actual obligations before an incident, maintain the necessary contact paths and record how notification decisions were reached. This is one reason legal and business functions must participate in response planning rather than being called only after the technical work ends.

Exercises reveal invisible dependencies

Tabletop exercises are useful because they test judgment and coordination without disrupting live systems. A scenario can begin with a suspicious privileged account, evolve into a suspected data exposure and then introduce an unavailable recovery service. Participants must explain who acts, what information they need and when decisions escalate. The objective is not to produce a perfect script but to discover where the organization would stall.

Technical recovery tests answer different questions. Can backups be restored? Are restoration permissions available during a major identity failure? Can the business tolerate the data reconciliation workload? A tabletop that assumes backups work cannot substitute for a restoration test. Likewise, a successful backup test does not prove executives can authorize critical containment quickly.

Exercises should lead to assigned improvements. If the emergency supplier number is wrong, correct it. If the business continuity plan depends on an untested spreadsheet export, test the process. If competing teams claim authority over the same restoration decision, clarify governance before the next incident.

Learn without reducing everything to blame

Post-incident review should separate immediate technical causes, underlying control failures and organizational conditions that allowed the incident to become severe. An unpatched server might be the visible trigger, but the deeper failure may be unclear ownership or a change process that repeatedly blocked maintenance. Corrective actions should address those drivers, not only demand that an individual “be more careful.”

Useful measures include detection and escalation delays, containment effectiveness, restoration outcomes, communication timeliness and the completion of corrective actions. These should be interpreted against case complexity and business impact. A lower average time to detect is not meaningful if low-severity alerts dominate the calculation while major incidents still go unnoticed.

CISM scenarios ask managers to recognize the appropriate relationship between planning, response authority, business continuity and learning. The strongest answer generally connects technical action to accountable enterprise decisions, rather than treating incident management as a sequence of security-tool commands. An organization cannot guarantee the absence of incidents, but it can deliberately reduce confusion, harm and repeated failure.