Most organisations have an incident response plan. Fewer have tested it under pressure. And fewer still can answer the question that actually matters once the dust settles: was the underlying issue fixed, or just contained?
Containment stops the bleeding. It does not close the wound.
In 2026, that distinction is becoming one of the most important in Cyber Security, because the data shows that how quickly and completely you resolve an incident has a direct, measurable impact on what it costs you.
According to IBM's 2026 Cost of a Data Breach Report, UK organisations now take an average of 225 days to identify and contain a breach. Breaches that ran beyond 200 days cost an average of £4.24 million, compared with £3.24 million for those resolved sooner. That is a £1 million difference tied directly to speed and completeness of response.
This guide covers what incident response actually involves, what a mature IR process looks like in practice and why the gap between containment and verified closure is where most programmes fall short.
Incident response (IR) is the structured process an organisation follows when a Cyber Security event occurs. The goal is to detect what happened, limit the damage, remove the threat, restore normal operations and prevent the same thing from happening again.
It applies to a wide range of events:
A Cyber Security incident is any event that compromises the confidentiality, integrity or availability of your systems, data or services and requires a deliberate response.
A well-run IR process does not just react. It moves through defined stages, with clear ownership at each step, so the organisation can act decisively rather than improvise under pressure.
The standard incident response lifecycle
Most frameworks, including those published by NIST and NCSC, organise incident response into four or five phases:
|
Phase |
What happens |
|
Preparation |
Policies, playbooks, tools and team roles are defined before an incident occurs |
|
Detection and analysis |
The incident is identified, scoped and assessed for severity |
|
Containment |
The threat is isolated to prevent further spread or damage |
|
Eradication and recovery |
The root cause is removed and affected systems are restored |
|
Post-incident review |
Lessons are documented and the IR process is improved |
Most organisations invest heavily in the first three phases. The last two, particularly eradication and the post-incident review, are where gaps tend to appear.
Containment is often treated as the finish line. The attacker is isolated, the affected machine is taken offline, the compromised account is disabled. The immediate crisis is over.
But containment does not address the question of how the attacker got in. A misconfigured firewall rule, an unpatched vulnerability, a weak identity control, an overprivileged service account - These remain in place after containment.
The incident is contained. The exposure is not.
This is the gap that makes organisations vulnerable to repeat incidents. The attack surface that enabled the first breach is still there.
Genuine eradication means working back from the incident to identify and remove the root cause. That typically involves:
The last point is where many teams fall short. A patch applied to one server but not to twelve others does not close the finding. Closure requires confirmation that the fix is in place everywhere it needs to be.
Recovery is not just restoring systems. It is confirming that restored systems are clean and that the conditions that enabled the incident no longer exist.
A mature IR process includes a verification step: re-scanning affected assets, checking that the misconfiguration or vulnerability no longer appears and retaining evidence of the remediation for audit and reporting purposes.
Without that step, "recovered" and "fixed" are not the same thing.
Speed matters, but so does structure. The organisations that handle incidents most effectively tend to share a few common characteristics.
The worst time to decide who does what is during an active incident. A mature IR programme defines roles in advance: who declares an incident, who leads the technical response, who handles communications, who engages legal or compliance teams and who has authority to make containment decisions.
Playbooks take this further by mapping specific incident types to specific response steps. A ransomware playbook looks different from a BEC playbook. Having them written and tested before an incident occurs compresses response time significantly.
Incident response only works if detection is fast and accurate. A team responding to an alert that is 48 hours old is already working at a disadvantage.
According to the UK Government's Cyber Security Breaches Survey 2025/2026, 57% of UK organisations are prioritising investment in incident response plans and testing. That is a positive signal, but detection capability and response capability need to develop together. One without the other creates a bottleneck.
Automation can compress the time between detection and initial containment. Isolating a compromised endpoint, disabling a flagged account, blocking a known malicious IP: these are actions that can happen in seconds with the right tooling in place.
Human judgement is needed for scoping, root cause analysis, remediation decisions and anything that carries risk of business disruption. The best IR processes combine both: automation handles the immediate, analysts handle the complex.
A post-incident review is not a blame exercise. It is a structured opportunity to understand what happened, why the detection or response took as long as it did, and what needs to change to prevent recurrence.
The findings from that review should feed directly back into the organisation's security posture: updated playbooks, patched vulnerabilities, revised access controls. If the review produces a report that sits in a folder, it has not closed the loop.
Many mid-market organisations do not have the internal resource to run a full incident response capability. Building a SOC, hiring experienced analysts, maintaining detection tooling and keeping playbooks current is a significant operational investment.
Managed Detection and Response (MDR) services address this by providing continuous monitoring, detection and response capability as a managed service. When an incident occurs, the MDR provider leads or supports the response, reducing the burden on internal teams.
The part most coverage misses: not all MDR services are built the same way, and the difference matters most during and after an incident.
Most MDR services are designed to detect and contain. They identify the threat, alert the customer and take defined containment actions. That is genuinely valuable and for many organisations it represents a significant capability uplift.
The limitation is that containment is not remediation. Once the threat is isolated, the underlying issue, the vulnerability, misconfiguration or identity gap that enabled the attack, still needs to be addressed. In a traditional MDR model, that work typically falls back to the customer's internal team.
This creates a handoff problem. The MDR provider closes the incident from a monitoring perspective. The customer is left to manage the remediation work, often without the same level of context the MDR team has built up during the response.
A more complete model extends MDR into remediation: taking the findings from detection and response, identifying the root cause, applying and verifying the fix and confirming that the finding is genuinely closed before moving on.
This is what we mean by closed-loop MDR: a process where detection, response and remediation operate as a single continuous cycle, rather than three separate handoffs. The measure of success is not alert volume or response time alone. It is the closure rate, the percentage of findings that are genuinely removed from the estate, and the direction of travel on attack surface over time.
When the number of open findings reduces month on month, the security programme is working. When it stays flat despite active monitoring, something in the loop is broken.
Whether you are building IR capability internally, evaluating an MDR provider or reviewing your current programme, these questions cut through the surface-level answers:
The organisations that handle incidents best are not always the ones with the most tooling. They are the ones with the clearest process and the most honest measurement.
If you cannot answer these questions with confidence, that is a useful starting point for improving your IR programme, regardless of what technology you have in place.
CybaVerse is built around the principle that detection and response are not the end of the job. They are the start of it.
Our FAFO operating cycle, Find, Analyse, Fix, Operate, is designed to run continuously: identifying what is wrong, prioritising what matters, applying and verifying fixes, and confirming that findings are genuinely closed before the next cycle begins. Each cycle should leave the organisation with a smaller attack surface than the one before.
CybaEdge includes unlimited incident response, human-led MDR and deeper identity coverage. CybaOne adds SIEM capability, penetration testing and broader managed security visibility. CybaRemediate extends any package with managed remediation, verified closure and a full audit trail of what was fixed and when.
If your current IR programme stops at containment, speak to CybaVerse about what closing the loop actually looks like in practice.