Introduction

In the first post of this series, I introduced the principle of Assume Breach and highlighted three areas that are often underdeveloped in practice: Business Continuity Planning, Data Loss Prevention and Cryptography. This post takes a closer look at the first of these topics: Business Continuity Planning, or BCP.

In my experience when reviewing organisations through internal laudits, maturity assessments or ISO 27001 implementations, Business Continuity Planning is often present on paper. There may be a policy, a business impact analysis, a list of critical systems and perhaps even a recovery plan. However, the real question is not whether a BCP document exists. The real question is whether the organisation can continue to operate when disruption actually occurs.

That is where the Assume Breach principle becomes highly relevant.

From “if” disruption happens to “when” disruption happens

Traditional continuity planning often focuses on scenarios such as office unavailability, power outages, natural disasters or supplier failure. These scenarios are still valid, but they are no longer sufficient. Modern organisations also need to prepare for cyber-related disruptions such as ransomware, loss of cloud services, data corruption, compromised administrator accounts, unavailable identity providers, destructive malware or a major data breach.

An Assume Breach approach accepts that some level of compromise may already have occurred. This changes the way continuity planning should be designed. It is not enough to restore systems quickly. Organisations must be able to restore them securely, with confidence that the same compromise is not being reintroduced.

This requires a shift from availability-only thinking to resilience-based thinking.

BCP is not only about recovery time

Many continuity plans focus heavily on Recovery Time Objectives and Recovery Point Objectives. These are important. They help define how quickly a process or system must be restored and how much data loss is acceptable. However, in a cyber incident, recovery is rarely a simple technical exercise.

For example, if a ransomware incident affects critical systems, the organisation must first understand which systems are impacted, whether backups are intact, whether credentials are still trusted, whether data has been altered and whether the recovery environment is clean. Restoring too quickly without proper validation may bring the attacker back into the environment.

A mature BCP therefore needs to answer more than “How fast can we recover?” It must also answer:

  • What are our truly critical business processes?
  • Which systems, data, suppliers and people support these processes?
  • What minimum operating capability is required during a crisis?
  • How do we communicate if normal communication channels are unavailable?
  • Who is authorised to make decisions under pressure?
  • How do we validate that recovery is secure?
  • What dependencies could delay or block recovery?

These questions turn Business Continuity Planning from a static document into an operational capability.

The ISO 27001 perspective

ISO 27001 supports this approach by requiring organisations to consider information security during disruption. This is especially visible in Annex A controls related to continuity and resilience, such as A.5.29 Information security during disruption and A.5.30 ICT readiness for business continuity.

These controls make clear that continuity planning is not separate from information security. During a disruption, confidentiality, integrity and availability still matter. In fact, they may matter even more. A crisis is exactly the moment when shortcuts, unclear ownership and weak procedures can create additional risk.

For this reason, BCP should be part of the Information Security Management System and not treated as a standalone compliance exercise. It should be linked to risk assessment, incident response, supplier management, access control, backup strategy, crisis communication and management review.

Common weaknesses in BCP implementations

In practice, several weaknesses appear frequently.

The first is that continuity plans are too generic. They describe broad actions but do not provide enough practical guidance for real incidents. During a crisis, people need clarity. Vague procedures create delay.

The second weakness is that plans are not sufficiently tested. A tabletop exercise once every few years is not enough for critical processes. Testing should include realistic cyber scenarios, unavailable systems, loss of key personnel and recovery from isolated backups.

The third weakness is poor dependency mapping. Organisations often know which applications are important, but not which identity services, network components, suppliers, certificates, data flows or privileged accounts are required to make those applications work.

The fourth weakness is overconfidence in backups. Backups are essential, but they are only useful if they are protected, recoverable and tested. In an Assume Breach model, backups should be segregated, monitored, encrypted and protected against deletion or manipulation.

The fifth weakness is unclear decision-making. In a major incident, technical teams, business owners, legal, communications, management and external parties must work together. If roles and authority are unclear, the organisation loses valuable time.

Building BCP around Assume Breach

A stronger approach starts with accepting that not all systems can be trusted during a serious incident. This means continuity planning should include secure fallback processes, alternative communication channels, emergency access procedures, out-of-band decision-making and recovery environments that are isolated from the impacted infrastructure.

It also means that continuity planning and incident response must be closely connected. Incident response focuses on detecting, containing and eradicating the incident. BCP focuses on maintaining or restoring critical business operations. These two capabilities must work together. If they operate separately, the organisation may either recover too slowly or recover unsafely.

An effective BCP should also include clear prioritisation. Not every system is equally important. Not every process needs immediate recovery. Organisations should define which services are mission-critical, which can operate manually for a limited period and which can be temporarily suspended. This prioritisation reduces confusion and supports better decision-making during an incident.

The business value of mature BCP

A mature Business Continuity Plan does more than satisfy an audit requirement. It directly reduces business impact. It helps limit downtime, reduce financial loss, protect customer trust and support regulatory obligations. It also helps management understand where resilience investments are needed most.

This is especially important because incidents are not only technical events. They quickly become business events. A cyber incident can affect customer service, operations, legal exposure, contractual obligations, reputation and cash flow. BCP provides the structure to manage this wider impact.

Conclusion

Business Continuity Planning is often underestimated because it is seen as documentation rather than capability. Under the Assume Breach principle, this is no longer sufficient. Organisations must be able to continue operating when systems are compromised, data is unavailable, suppliers are disrupted or normal communication channels cannot be trusted.

Aligned with ISO 27001, BCP should be risk-based, tested, integrated and continuously improved. It should focus not only on restoring operations, but on restoring them securely.

In the end, the strength of a Business Continuity Plan is not proven during an audit. It is proven during disruption. The organisations that prepare for that moment will recover faster, make better decisions and reduce the overall cost and impact of incidents.