By Sean Tilley
Most organizations now recognise that a serious cyber incident is likely, but the real question is whether they can keep running when it happens. A major incident can disrupt services, damage revenue, expose governance weaknesses, and test customer trust as events unfold. The greatest risk often sits in the gap between recognising that reality and having a recovery plan that works under pressure. That is where financial loss, operational disruption, and regulatory scrutiny can quickly escalate.
Cyber resilience has moved into the boardroom
High-profile incidents, greater reliance on digital services, and increasing regulatory pressure have made cyber resilience a boardroom priority, forcing organizations to look beyond breach prevention and focus on how the business keeps running during disruption.
In the UK, operational resilience regulations require firms in sectors such as financial services to identify important business services, set impact tolerances, and show they can remain within those tolerances during severe but plausible disruption. Similar expectations are also growing across healthcare, utilities, and telecommunications, where disruption can quickly affect essential services. This needs to be tested, not simply written into a policy.
Cyber resilience now demands clear ownership, recovery plans that have been tested, and the ability to show regulators, auditors, and stakeholders how services will be restored. It is no longer enough to assume recovery will work; organizations need to know that it will.
Prevention alone is not enough
Investment in prevention remains essential, but it does not address the full operational risk, particularly as cyber attacks continue to increase in volume and complexity despite advances in security tooling.
Prevention reduces the likelihood and spread of incidents, while resilience determines whether the organization can maintain operations and restore services safely when incidents occur. They are symbiotic; one does not replace the other.
A resilient organization brings identification, protection, detection, response, and recovery together, and lifecycle approaches such as the NIST Cybersecurity Framework reflect this shift by treating recovery as part of resilience rather than an afterthought. For business leaders, security capability should be judged by whether critical services can be restored, not only by how strong the defensive controls appear.
Downtime is a measurable business risk
Downtime links directly to cyber risk because it affects revenue, service delivery, customer confidence, and, in regulated sectors, the ability to remain within agreed impact tolerances.
For many organizations, even a short outage can quickly become a material financial risk, and that’s before longer-term impacts such as customer attrition, reputational damage, and regulatory scrutiny are considered.
It puts cyber risk into commercial terms, forcing organizations to assess how long they can tolerate disruption and whether their current recovery approach can deliver within those limits.
Recovery capabilities must be tested
Many organizations are more confident in their recovery plans than their testing justifies, believing that they can recover effectively without proving that assumption under realistic conditions.
Testing is often treated as an annual exercise aligned to compliance requirements, but that approach is no longer sufficient when applications, data, and dependencies constantly change and recovery plans can quickly become outdated.
Regular testing is essential to identify gaps and confirm recovery times and organizations should test both traditional disaster recovery scenarios and cyber recovery scenarios because they place very different demands on the business.
Traditional disaster recovery assumes a known failure and a clean restore point, while cyber recovery is more complex because the organization may not immediately know when the compromise began, whether backup data has been affected, or whether restoring systems could reintroduce the threat.
A backup-only mindset is no longer enough
Backups remain a critical component of recovery, but they are not a complete solution, especially as threat actors increasingly target backup systems before launching attacks to remove recovery options.
A modern recovery strategy must include off-site copies, immutability, and strong access controls, while backup environments should be segmented from production systems and protected against tampering.
Organizations also need isolated recovery environments where data can be checked before being restored into production, reducing the risk of reinfection or incomplete recovery.
Recovery must also account for application dependencies, service prioritisation, and operational coordination, which makes it a business process rather than a standalone technical task.
People and process are as important as technology
Technology alone does not deliver resilience. Skills shortages, competing priorities, and increasing complexity mean that many organizations struggle to build and maintain the required capabilities internally.
Training is often overlooked and annual awareness programmes are not sufficient when people need continuous, role-based preparation that reflects real-world scenarios.
Employees need to understand their responsibilities during an incident, particularly in the first hour of an incident, while IT teams need to rehearse recovery procedures and test systems under realistic conditions.
During a live incident, recovery is rarely slowed by one technical issue alone and is often delayed by unclear ownership, slow decisions, or poor communication. Scenario-based exercises help organizations test decision-making, governance, communications, and the handover between technical, legal, communications, and executive teams, not just technical recovery.
The role of a resilience partner
Many organizations do not have the resources to manage prevention, response, and recovery entirely in-house, and external expertise can provide access to specialist skills, tested processes, and greater confidence in recovery readiness.
External support should be judged by the outcomes it can help deliver, not by the length of its product list. The key question is whether it can help the organization identify critical services, design recovery around those services, and prove performance against business tolerances.
That includes designing recovery into the operating environment, testing recovery paths, and creating the documentation needed to support assurance, audit, and regulatory requirements.
Where to start
Recovery planning should begin with what the business needs to keep running, then work back to the technology required to support it.
The starting point is to identify the business services that must be maintained or restored quickly, then map the dependencies that support those services, including applications, data, infrastructure, and third parties.
From there, organizations should define acceptable levels of disruption and assess whether current recovery readiness can meet those targets.
Gaps in backup, isolation, and recovery processes should be addressed as a priority, and at least one end-to-end cyber recovery exercise should be scheduled within the next year.
Organizations cannot prevent every disruption, but they can reduce their impact by making sure they know how to recover, restore critical services, and keep operating under pressure.
That is what cyber resilience should deliver, with stronger defences matched by tested recovery that can hold up under real pressure.
The author
Sean Tilley is Senior Director of Sales, EMEA, and Sam Woodcock, Senior Director of Solutions Architecture, EMEA, 11:11 Systems
