What 'Full Recovery' Really Means After a Breach

Recovery from a breach can continue well after containment ends. IBM's own methodology holds every recovered organisation to a four-part bar: operations back to normal in the affected areas, compliance obligations met (including any fines), trust restored, and controls in place to prevent a repeat.

Only the first criterion is primarily a technical task. The other three depend on evidence: that obligations were actually met, that trust-rebuilding work actually happened, and that new controls are genuinely operating day to day.

The recovery rate is improving, but slowly

Three consecutive years of improvement have moved that figure from 12% in 2024, to 35% in 2025, to 42% now. Even so, 58% of breached organisations remain short of IBM's own bar, a majority despite the run of progress.

The gains are concentrated at the slow end of the distribution. The share of organisations needing more than 150 days to fully recover dropped to 19% from 26% last year, the biggest single shift in this year's data. The fast end barely moved. Fewer than one in 20 organisations recovered in under 50 days, and most still land somewhere in the 100-to-150-day range.

IBM's report attributes the majority of breach cost, 63%, to two categories: detection and escalation, and lost business. The second covers crisis management, disrupted operations and customer churn, the exact ground IBM's own "trust restored" recovery criterion sits on. Rebuilding trust is slower and harder to measure than patching a vulnerability. That gap is why the fast end of the recovery curve hasn't moved.

This tracks with how NIST's own incident response guidance (SP 800-61 Revision 3) frames the recovery phase: verifying the integrity of restored assets, remediating root-cause vulnerabilities, confirming restoration with system owners, and producing an after-action report for stakeholders. Recovery, on NIST's own account, is coordinated, deliberate work that continues well past the moment systems come back online.

The UK's Information Commissioner's Office breach response and monitoring guidance spells out what "compliance obligations met" looks like in practice: a breach log documenting the cause, what happened, the personal data affected, and the remedial action taken. A governance body has to review it, with evidence the steps actually prevented a recurrence. That's a separate body of evidence, one an organisation has to build and hold onto quite apart from fixing the technical issue.

SureCloud's own analysis of incident management makes a related point. Regulators grade organisations on whether their evidence trail is complete, independent of how quickly a ticket closed. Meeting IBM's compliance and trust criteria means an organisation can produce that evidence on demand, months after the incident itself is old news internally.

SureCloud's incident management capability tracks incidents and the communications tied to them, connecting to external systems so the record of actions, progress and responses builds automatically. Nothing needs reconstructing after the fact. Gracie AI Agents with Personas and Skills reasons across that incident record alongside compliance and control data, surfacing which of IBM's four recovery criteria still have open evidence gaps.

The compliance criterion carries a cost of its own. The FCA fined UK firms £15.7 million in the first quarter of 2026 alone, and every one of those cases still had to demonstrate remediation on top of paying the penalty. Recovery counts once it's evidenced, whatever the incident timeline says.