The worst time to design an incident response process is during a live incident. At that point, the organisation is under pressure, facts are incomplete, systems may be unavailable and senior leaders may be asking for certainty that no one can honestly provide. A good response depends on preparation.
A cyber incident response plan should identify who is involved, how decisions are made, which systems matter most, how evidence is handled, how communications will be managed and when external support should be engaged. It should include technical teams, security teams, senior management, legal, HR, communications, suppliers and insurers where relevant.
The plan should also be practised. Tabletop exercises, scenario walkthroughs and technical recovery tests reveal gaps that a document alone will not show. Can the team contact each other out of hours? Do they know who can approve downtime? Are backups usable? Is there an offline copy of the plan? Are supplier contacts current? These details matter when the incident is real.
Step one: identify and triage the incident
The first operational step is to understand what may be happening. Not every alert is a major incident, but every serious incident starts with signals that need assessment. Triage should establish what has been observed, which systems or users are affected, what data may be involved, whether the activity is ongoing and whether business operations are at risk.
Good triage is disciplined. The team should avoid jumping to conclusions, but it should also avoid delay. Early facts should be recorded clearly, including times, affected assets, accounts, alerts, actions already taken and assumptions. This creates a decision trail and helps external responders if they are brought in.
Severity should be based on impact and urgency. A single suspicious email that was not clicked is different from evidence of compromised administrator credentials. A malware alert on an isolated endpoint is different from encryption spreading across file servers. The response should match the risk.
Step two: contain the threat without destroying evidence
Containment is about stopping further harm. That may mean disabling accounts, isolating devices, blocking domains, removing remote access, revoking sessions, segmenting networks or taking systems offline. The right action depends on the incident type and the environment.
The challenge is that rushed containment can destroy evidence or make recovery harder. For example, wiping a device too early may remove useful forensic artefacts. Switching off systems without understanding dependencies may disrupt critical services. Communicating through compromised email may expose the response plan to the attacker.
This is why incident response needs experienced judgement. The team must balance speed, evidence, business continuity and safety. Where the incident is serious, organisations should consider engaging an assured cyber incident response provider or equivalent specialist support quickly, rather than waiting until the situation deteriorates.
Step three: communicate clearly and carefully
Poor communication can make a cyber incident worse. Staff need to know what to do and what not to do. Senior leaders need decision-quality information. Customers, regulators, suppliers and partners may need updates. The media may become interested. Internal rumours can spread quickly, especially if systems are unavailable.
Communication should be factual, calm and controlled. The organisation should avoid speculation, avoid over-promising and avoid saying an incident is resolved before recovery has been validated. A simple rhythm is useful: what we know, what we do not yet know, what we are doing, what we need people to do, when the next update will be provided.
Legal and regulatory duties should be considered early, especially where personal data, contractual reporting obligations or regulated services are involved. The communications team should be part of the response, not an afterthought brought in once the story has already escaped.
Step four: recover safely
Recovery is not just turning systems back on. The organisation needs confidence that the threat has been contained, the route of compromise is understood, vulnerable systems have been addressed and restored services are not immediately exposed to the same attack again.
In a ransomware incident, recovery may involve rebuilding systems, restoring from backups, rotating credentials, validating backups, checking for persistence, reviewing logs and prioritising critical services. Organisations should avoid assuming that a backup exists, is clean or can be restored quickly unless it has been tested before the incident.
Recovery decisions should be business-led and technically informed. Some systems may need to return before others. Some services may need temporary manual processes. Some evidence may need to be preserved. The goal is to restore safely, not simply quickly.
Step five: learn from the incident
Every incident should end with a post-incident review. This should not be a blame session. It should identify what happened, how it was detected, what worked, what failed, which decisions were difficult, what evidence was missing and which controls need improvement.
The review should produce clear actions with owners and dates. Common outputs include improved logging, stronger access controls, better backup testing, updated playbooks, revised supplier contact details, clearer escalation criteria, changes to user reporting routes and additional board-level risk visibility.
The best organisations treat incidents as expensive lessons. They do not waste them. They turn experience into better preparedness, better detection and better decision-making.
