When backups are not enough: business continuity, cyber resilience and business survival

Events such as large-scale power outages, the fallout from cyber incidents or cyberattacks are not abstractions. They come in the form of servers going offline, operations grinding to a halt, or decisions that have to be made in real time with incomplete information. For most organisations, that moment is the first real test of whether the business continuity work carried out in calmer times was robust or merely cosmetic.

______

The expression used to describe the total collapse of a system, 'going to zero', is an existential term. It describes the moment when an organisation loses its ability to operate, serve customers or even communicate. Backups and cloud snapshots do not prevent an organisation from going to zero.

A backup answers the question of which data can be recovered, but it does not answer the question of how the organisation continues operating during the time it takes to complete that recovery.

How long could your organisation continue operating at a meaningful level if its core IT systems were unavailable for four hours? Twenty-four hours? A week?

This is not a hypothetical scenario designed for boardroom presentations. It is the scenario that business continuity management (BCM) is designed to address. And yet, for many organisations, the honest answer remains: they simply do not know.

To understand why organisational resilience so often falls short in practice, it is helpful to map the four disciplines intended to prevent failure and understand exactly where each one begins and ends.

Business impact analysis: the foundation no one overlooks, but many fail to invest in sufficiently

The business impact analysis (BIA) is the starting point of any serious BCM programme. It does not ask what could go wrong. Instead, it asks: if a specific business function became unavailable for thirty minutes, four hours or five days, what would be the precise financial, legal and reputational impact?

Two of the most important metrics in business continuity planning emerge from the BIA:

• The Recovery Time Objective (RTO), which defines the maximum acceptable period of downtime for a system or process.
• The Recovery Point Objective (RPO), which defines the maximum acceptable amount of data loss measured in time.

These are not IT metrics. They are business commitments. An RTO of four hours for a transaction processing system means that the business has accepted up to four hours of downtime. That decision carries financial, contractual and reputational consequences.

RTO and RPO are not technical parameters. They are the organisation's formal statement of how much disruption it is prepared to tolerate, and how much it is not.

The BIA also highlights what is perhaps the most underestimated risk in business continuity planning: dependence on key individuals. Organisations often design sophisticated IT recovery architectures while overlooking a fundamental question: who activates them, who decides when to escalate an incident, and what happens if that person is unavailable? Critical systems may be restored within minutes by an experienced engineer, yet take days if that engineer is the only person who knows the procedure.

Does your organisation's BIA reflect the decisions real people make under real pressure, or an idealised version of how the organisation is supposed to operate?

Business continuity management (BCM) is the overarching programme that governs everything. It is the governance layer that sits above the BCP. While the BCP is a document, comprising procedures and responsibilities, BCM is a management system: a continuous cycle of risk assessment, planning, training, testing and improvement. The distinction is operationally significant.

Many organisations still confuse BCM with BCP documentation. They assume that once the plan has been written, the work is complete. That assumption is precisely the problem. A BCP that has never been tested is not a plan; it is a hypothesis. A BCM programme without regular exercises, post-incident reviews and structured improvement cycles is not business continuity management; it is business continuity theatre.

■ Both ISO 22301 and NIST convey the same message: business continuity is a process, not an outcome. The six functions of the NIST CSF 2.0 (Govern, Identify, Protect, Detect, Respond and Recover) are not a checklist to complete once. They represent a continuous operational posture.

This is where cyber resilience goes a step further. NIST SP 800-160 sets out a cyber resilience engineering framework with profound implications for the way organisations approach their long-term survival. Its central premise is straightforward: it is no longer enough to design systems that can withstand attacks. Systems must be designed to anticipate adverse conditions, withstand them, recover from them and adapt as a result.

These four properties Anticipate, Withstand, Recover and Adapt are not sequential stages. They are complementary capabilities that a resilient system maintains throughout its operational lifecycle:

• An organisation that can recover but cannot anticipate will constantly be caught off guard.
• One that can withstand disruption but cannot adapt will continue fighting yesterday's battles.

The four pillars of cyber resilience (NIST SP 800-160v2r1)

• Anticipate: maintain awareness of the threat landscape and potential failure modes before they materialise.
• Withstand: absorb disruption and continue delivering essential services, even in a degraded operating state.
• Recover: restore full operational capability within the agreed RTO and RPO commitments.
• Adapt: learn from incidents and exercises, embedding those lessons into updated designs, procedures and capabilities.

The practical implications of this framework are significant. Cyber resilience is not a cybersecurity project. It is an organisational design challenge encompassing governance, people, technology infrastructure, relationships with suppliers and the communications strategy.

—A ransomware attack that encrypts core systems is a cybersecurity incident. An organisation's ability to maintain essential operations, communicate with customers and execute its recovery procedures under those conditions is a measure of resilience, and depends far more on governance and preparedness than on any individual technical control.

Has your organisation's Disaster Recovery as a Service (DRaaS) solution been tested not only for technical recovery, but across the entire operational scenario, including teams activating the plan, communications functioning through alternative channels and users successfully accessing restored services?

This question matters because one of the most common shortcomings identified in DRaaS implementations is not the recovery of servers, but connectivity between those servers and the users who rely on them. A system may be fully restored in a secondary data centre yet remain inaccessible because network connectivity requirements were not properly considered when the recovery architecture was designed. Technology alone does not deliver resilience.

■ At Telefónica Tech, we provide our customers with advanced services and specialist expertise to help them maintain business operations and service availability in critical scenarios. Find out more →

Cloud

Trends reshaping Cloud communications for businesses

June 15, 2026