CISM Incident Communications, Eradication, Recovery and Post-Incident Review

This part of CISM domain 4B covers the second half of incident operations: telling the right people the right things at the right time, removing the cause of the incident, restoring the business safely, and learning from the incident so it does not happen again. The official outline names three areas: incident response communications (reporting, notification and escalation), incident eradication and recovery, and post-incident review practices. They correspond to the supporting tasks on the incident handling process (notification, escalation, eradication and recovery), on contributing to communication plans for internal and external parties, and on post-incident reviews that include root-cause analysis, lessons learned, corrective actions and reassessment of risk.

The CISM view is a manager's view throughout. The information security manager makes sure the communication plan, escalation criteria and recovery priorities exist before an incident, coordinates the response, advises decision-makers on risk and runs the review afterwards. The big decisions belong to others: senior management decides on escalated business trade-offs and law-enforcement involvement, legal counsel decides what the law requires the organization to notify, and business owners decide when their systems go back into service and which risks they accept.

Neighbouring material has its own lessons: writing the incident response plan, classification and testing (4A); the business impact analysis and the continuity and disaster recovery plans (4A); and detection tools, investigation, evidence handling and containment (4B, first part). This lesson starts where containment ends.

An incident communication plan is the part of incident readiness that decides, before any incident, who must be told what, by whom, through which channel and with whose approval. Its purpose is speed and consistency. Messages drafted from nothing in the middle of a crisis are slow, because every sentence has to be negotiated, and they drift apart, because each team writes from its own version of events.

A sound plan settles in advance:

• Audiences and contacts: executives, the board, staff, customers, regulators, partners and providers, insurers, law enforcement and the media, with current contact details.
• Roles and approvers: who drafts, who approves (typically the incident manager for facts, legal counsel for legal exposure, a designated executive for external statements) and who sends.
• Pre-approved templates for likely scenarios, such as customer breach notices, regulator notifications, staff briefings and holding statements. Structure and legal wording are agreed calmly; only incident-specific facts are added under pressure.
• One authoritative fact base: a single approved statement of what is known, kept current by the incident team, from which every audience's message is drafted.
• Channels, including out-of-band channels for when corporate systems cannot be trusted.

Different audiences need different messages, but the facts inside them must match, and the shared fact base is the control that makes them match. When incident messages are consistently slow or inconsistent, the lasting fix is usually in the plan itself (templates, approvers and the fact base agreed beforehand), not in changing who handles messages during the crisis.

Who speaks for the organization

External statements, and above all statements to the media, come only from the spokesperson designated in the communication plan, usually someone from corporate communications or a senior executive, working from facts approved by the incident manager and legal counsel. Every other employee, however senior or well informed, supplies facts to the response but refers media enquiries to the spokesperson. The rule is about who speaks, not whether the content is accurate: a correct statement from the wrong person still creates legal and reputational exposure and breaks the single voice. Staff briefings should therefore say plainly what to do if a reporter calls.

Out-of-band channels when systems may be compromised

Out-of-band communication means coordinating the response through channels that do not depend on the systems the attacker may control. If an attacker can read corporate email, chat or tickets, they can watch the response, change tactics, destroy evidence or lock responders out before containment completes. Protecting messages inside a platform the attacker controls does not help, because the platform itself is in question.

The plan arranges these channels before any incident: separate phones, an externally hosted messaging or conferencing service, and contact lists held outside the corporate environment. The test of a channel is its dependencies, not its name or provider. A channel is only independent if its accounts, authentication and contact data do not run through the compromised environment. For example, an emergency call tree stored only on a corporate file share is useless when the file share is encrypted, and any service whose sign-in passes through a compromised identity provider can be joined by the attacker. Out-of-band accounts need their own identities and credentials, tested in exercises.

Escalation is the predefined transfer of an incident, or of a decision about it, to a higher level of authority when set criteria are met. Two kinds of trigger matter:

• Impact approaching tolerance. Incidents change severity as they develop, so classification is revisited as facts emerge. When the business impact approaches or exceeds what the business can tolerate (for instance, an incident first treated as a single lost laptop turns out to expose regulated health records), the escalation criteria are met. Escalating comes first: decisions such as invoking the disaster recovery plan, approving customer messages or accepting a long outage belong to senior management, not to the responder.
• A decision beyond delegated authority. Plans pre-authorize some actions so responders can act fast within defined limits. When the response needs something outside those limits, for example cutting a payment interface that a partner contractually depends on, the decision goes to the executive who owns that business impact, at the level the plan names. Delegated authority is a boundary: inside it responders act; outside it they escalate, whichever option they personally favour.

Law enforcement is an escalation decision. Reporting a crime such as extortion or theft of intellectual property can make the incident public, hand parts of the investigation to the authorities, require systems or evidence to be surrendered and shape later civil action. Senior management decides whether and when to report, advised by legal counsel; the information security manager makes sure the decision is put to them with the facts. (Preserving the evidence itself is part of investigation, covered in the investigation and containment lesson.)

Incident reporting is tailored to its audience: each group receives the information it needs to act, at the level of detail it can use. The communication plan defines this in advance.

The post-incident report to senior management translates the incident into business terms: what it did to operations, customers and finances, why it happened, and what must change, with the decisions and funding that requires. Its job is to support decisions, so material that neither explains the cause nor points to a fix adds little, and anything that grades individuals pushes the report toward blame. Program-level security metrics reporting is a separate subject covered in domain 3.

Breach notification is the legal or contractual duty to inform regulators, affected individuals or business partners of certain incidents, and legal counsel determines whether, whom and when the organization must notify. Laws and contracts differ in what triggers a duty, who must be told and how fast. The information security manager supplies the facts of the incident, corporate communications helps prepare the wording once a duty is established, and the legal determination itself rests with counsel.

Key principles, using the EU General Data Protection Regulation (GDPR) as the common reference:

• Deadlines run from awareness, not from the end of the investigation. Under GDPR Article 33(1), a controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to individuals. A notification made after 72 hours must be accompanied by the reasons for the delay, so lateness is a breach of the expected timing that has to be justified, not an option to plan around.
• Notification can be phased. Article 33(4) allows information to be provided in phases where it is not all available at once. The organization notifies on time with what it knows and sends updates as findings emerge; an incomplete picture is not a reason to wait.
• Statutory timing is not a business preference. Concern about alarming customers does not change a legal deadline. Where several jurisdictions or contracts are involved, the first step is for counsel to establish each regime's obligations and deadlines, because every later decision depends on that analysis.
• Individuals are a separate duty. Under GDPR Article 34, the controller informs affected individuals without undue delay when the breach is likely to result in a high risk to them.

Who notifies whom: controllers and processors

Who reports to whom depends on the law. The table shows the GDPR split, which many privacy laws resemble; other regimes, such as sector rules or NIS2-style incident reporting, can place direct reporting duties on service providers too, which is another reason counsel maps each applicable regime.

Outsourcing processing does not outsource the controller's duty to notify. If a marketing agency that runs an organization's mailing list loses that list, the agency tells the organization, and the organization, as controller, notifies the regulator using the information the agency supplies. Contracts should therefore require providers to report breaches promptly and in enough detail. Notices owed under insurance policies or commercial contracts are separate obligations and do not replace the statutory one.

Eradication is the phase that removes the cause of the incident, including malicious code, attacker accounts and persistence, stolen credentials and the exploited weakness, so that recovery does not restore a system the attacker can use again. The order is contain, eradicate, recover. Containment stops the spread; eradication removes the cause; only then are systems returned to service. The post-incident review, plan updates and full cost reporting come after recovery.

Eradication is complete only when every access path is closed:

• Malicious code and persistence: malware, web shells, scheduled tasks, altered binaries, rogue services.
• The entry vector: the vulnerability patched, the misconfiguration fixed, the third-party connection restricted.
• Credentials and tokens: every password, session token, API key and certificate the attacker may have harvested is reset or revoked. This is the step most often missed, especially after phishing or credential theft. A stolen credential needs no malware and no vulnerability, so an attacker can walk back in through normal remote access after every machine has been cleaned and every flaw patched. Activity on a legitimate account after eradication is the classic sign that a credential was missed.
• Attacker-created accounts and privilege changes in directories and applications.

The depth of eradication follows the depth of compromise. An attacker who held administrator-level rights for a long period, especially over identity infrastructure, could have planted persistence that security tools are not designed to find, so a clean scan proves little about such a system. Those systems are rebuilt from trusted images rather than cleaned (see recovery below), and the credentials they could reach are treated as compromised.

Recovery restores affected systems and business processes to normal operation from trusted sources, in the order the business needs them, with the business owner deciding when each returns to service.

Restore from known-good

Recovery uses sources the attacker cannot have touched: systems rebuilt from trusted, hardened images, and data restored from backups verified free of the attacker's tools. Dwell time decides which backups can be trusted. Anything backed up after the attacker got in may carry their accounts, tools or scheduled tasks, even if it scans clean, so the investigation's findings on when and how the attacker entered set the boundary. The right source is the most recent backup verified clean against those findings; data created after it is re-entered or rebuilt.

Restore in business priority order, with dependencies

The aim of recovery is to restore the business, not the largest number of servers. Restoration order follows the business criticality agreed before the incident, typically from the business impact analysis, so the processes with the least tolerance for downtime return first. Ordering by technical convenience or visible progress risks leaving the most critical process waiting.

Criticality applies to the whole chain a process needs. An order-handling application cannot take orders if the message queue, certificate service or identity service it relies on is still down, however healthy its own servers are. Restoration plans therefore bring shared infrastructure back before, or together with, the critical applications that depend on it, and dependency maps are kept current for that reason. (Setting recovery objectives and building the BIA belong to the continuity lesson; here they are inputs.)

Who decides a system returns to service

Returning a restored system to production means accepting whatever risk remains, and that decision belongs to its business owner, advised by security. The response team and the security function provide evidence that eradication is complete and the system is sound; IT operations performs the restoration. Neither the response leader nor the information security manager owns the decision.

Business pressure does not move the decision, but it shapes the security manager's job. When an owner wants a system back before the evidence is in, the manager's role is to make the residual risk clear (for example, that a system restored while its entry point is unknown can be compromised again straight away), propose options that reduce it, and make sure the owner's decision is informed and documented. The manager advises; the owner decides.

Heightened monitoring after restoration is how the organization confirms that eradication worked and detects any recurrence before the incident is closed. Eradication can only remove what the team found; a missed backdoor, a stolen credential or a second entry point shows up only when the attacker tries to use it.

After recovery, the team raises monitoring on the restored systems, related accounts and connected networks for a defined period, using the specific indicators of compromise and attacker behaviours identified in the investigation. Recurrence shows eradication failed and reopens the response; a quiet period builds the evidence needed to close. General assurance activities, such as scanning for known vulnerabilities or reviewing changes, answer different questions and do not show whether this particular attacker is gone.

The longer the dwell time, the more this matters. After a long intrusion, the attacker has probably harvested credentials and may hold footholds on systems never identified as affected, so work done only on the known systems cannot prove the incident is over. Closure criteria, including the length and scope of post-recovery monitoring, are best set in the incident response plan so that they are not negotiated away under operational pressure to return to normal.

A post-incident review (lessons-learned review) is a structured examination, held soon after an incident is resolved, of what happened, why it happened and how well the response worked, so that controls, plans and risk treatment can be improved. Its primary purpose is improvement: reducing the chance of recurrence and making the next response better. Legal, disciplinary and insurance processes may draw on its records, but they have their own purposes and owners.

Timing: the review is held within days of resolution, once the team is no longer fighting the incident but while records and participants are still at hand and details of who did what and when have not faded. Delay leaves the exposed weaknesses open for longer.

Typical questions: how and when the incident was detected; whether classification, escalation and notification worked; how containment, eradication and recovery performed against plan; what the incident cost the business; what the root cause was; and what should change in controls, the incident response plan, training and the risk register.

Root cause, without blame

Root-cause analysis keeps asking why until it reaches a process or control that can be fixed, not a person to blame. Suppose attackers entered through a firewall rule opened for a project and never closed. The immediate cause is the open rule; asking why it stayed open may reveal that rules had no owner or expiry date and were never reviewed. That missing process is the root cause, and fixing it (owned, time-limited rules with periodic review) protects every future rule, while blaming the engineer who opened it protects none.

The review's value depends on honest accounts. When participants fear disciplinary action, they give guarded, incomplete accounts and the real causes stay hidden. The remedy is for management to make clear that reviews examine processes and controls, not individuals, and to handle genuine misconduct separately through HR processes.

Lessons learned only improve security when they become corrective actions with an owner and a due date, tracked to closure, and when the incident's evidence is fed back into the risk assessment.

Corrective actions

A recommendation without an owner and a date is not a corrective action. Reviews commonly produce sound findings that are never implemented; what makes them happen is accountability, not more analysis. Actions are tracked in the same system used for audit findings or risk treatment, and their progress is reported to management until closed. The incident response plan, playbooks and contact lists are updated from the findings too.

Reassessing risk

An incident is new evidence about a risk's likelihood and impact, so the affected risks are reassessed and the register updated. The normal risk process then resumes: the reassessed risk goes to its risk owner, who chooses the treatment (mitigate, transfer, avoid or accept) with the security manager's advice. Two patterns show up often:

• Likelihood was underrated. An attack succeeded through a path the register treated as unlikely, for example a remote-support tool. The likelihood rating is revised before anyone decides what to do about it.
• Impact was underestimated. The incident cost far more than the register assumed, for example because recovery took longer than planned. The impact estimate is revised and the revised risk reported to its owner.

In both cases the security manager's job is to correct the assessment and put it to the owner; choosing a treatment on the owner's behalf, or only recording the incident, skips a step. The same applies to risks that were formally accepted: an acceptance is valid only for the risk as it was presented, so when an incident shows the risk was materially larger, the acceptance no longer stands and the owner makes a new decision on the reassessed risk.

Judging whether reviews work

Activity measures, such as how many reviews were held or how many actions were closed on time, show that the process is running. The outcome measure is recurrence: incidents that repeat a root cause already identified in an earlier review. That shows whether the lessons actually changed anything, which is what effectiveness means.