Responding to ICT Incidents

Responding to an ICT incident means acting, while a service is disrupted or under attack, to contain the harm, protect customers and data, and create the conditions for recovery. Response includes declaring the incident, assembling the right people, isolating affected systems, preserving evidence, communicating with customers and authorities as the regime requires, and deciding what can safely continue and what must stop. It is decision making under pressure, and its quality is set before the incident begins.

The distinction between response and recovery matters. Response contains and stabilises. Recovery restores. A response that rushes to restore systems before the cause is contained can reintroduce the same failure, or spread compromised data into a restored environment. Response therefore has its own discipline, and its success is judged by harm limited and options preserved, not only by speed of restoration.

Response begins with recognition and declaration. Detection hands over a picture of what is affected and what is known, and a named decision maker declares the incident and sets its severity in service terms. That declaration matters because it triggers the response structure, authorises the actions that follow, and creates a record of when the entity knew it had an incident. A response that drifts into action without a clear declaration often lacks a single owner and a shared picture of the incident.

The first period of response is about triage. Responders establish which services are affected, which systems are involved, whether data is at risk, and whether the cause is still active. Those questions shape containment. An incident caused by a compromised account calls for different containment than an incident caused by a failing platform or a supplier outage. Triage that jumps to a familiar fix before the cause is understood can waste the period when containment is easiest.

Containment involves limiting the spread of the incident and the harm it causes. It may involve isolating a system, disabling an account, blocking a route, switching traffic, or pausing a process that is propagating corrupted data. Each containment action has a service cost, and responders weigh that cost against the harm of letting the incident spread. Pausing a payment process protects data integrity but disrupts customers. Leaving it running preserves the service but risks wider corruption. Those trade offs are the substance of response.

Containment also involves preserving evidence. Systems are isolated in ways that retain logs and state for investigation, rather than being wiped or rebuilt before the cause is understood. Evidence preservation can conflict with the urge to restore quickly, and the response structure needs to hold that tension explicitly. An investigation that loses its evidence cannot explain the incident, and a recovery that restores without understanding the cause may restore the vulnerability too.

Response decisions are made by named roles with authority to act, not by whoever happens to be available. Technical responders assess systems and data. Service owners assess customer and business impact. Senior management, where the incident warrants it, decides on service suspension, external communication, and the acceptance of recovery risk. Suppliers are involved where the incident touches their systems, through agreed incident handling arrangements rather than improvised contact during the incident.

Clarity about decision authority prevents two common failures. The first is delay while responders seek permission for an action that should already be authorised. The second is conflicting action, where one team isolates a system that another team is trying to restore. A response structure that names decision makers, their authority, and the point at which decisions escalate gives responders a framework for acting quickly without acting at cross purposes.

Communication during response serves customers, staff, suppliers, and authorities, and each audience needs different information. Customers need to know whether a service is available, what is affected, and what they should do. Staff need to know what has changed and what is expected of them. Suppliers need technical detail that helps them act. Authorities need information in the form and through the channels the regime provides for. A single message rarely serves all audiences well.

Response hands over to recovery when the cause is contained, the affected scope is understood, and restoration can proceed without reintroducing the failure. That handover is a decision, not a drift. It is based on evidence that compromised systems are isolated, that data to be restored is sound, and that the restored environment will be protected and monitored. A handover made on hope, rather than on that evidence, risks a second incident that is harder to explain than the first.