Introduction

Every year, thousands of organisations complete their business continuity reviews. Plans are updated, sign-offs are collected, and audit checklists are ticked. The BCM manager files the report. The board notes it. Everyone moves on.

Then disruption strikes. And the response, despite all that preparation, is chaos.

This is one of the most common and least discussed failures in business continuity management-the gap between a plan that passes scrutiny on paper and a programme that actually works under pressure.

The emergence of cloud-based generative AI platforms is poised to relieve these pain points. In this thought leadership piece, we explore how cutting-edge AI solutions are revolutionizing regulatory compliance management – from instant clause extraction and policy drafting to automated change tracking and beyond.

What Business Continuity Planning Is Actually For:

Business continuity planning (BCP) is the process of identifying how an organisation will maintain critical functions during and after a disruption. It covers
everything from who does what, to how long systems can be offline, to what
constitutes a successful recovery.

At its core, a BCP should answer three questions when things go wrong:

1. Who is in charge?
2. What do we do first?
3. How do we know when we’re back to normal?

The Audit Illusion

Here is the uncomfortable truth: passing a business continuity audit and being genuinely prepared are two very different things.

An audit checks whether a plan exists, whether it has been reviewed recently, whether key roles are assigned, and whether certain processes have been documented. These are necessary things. But they are not sufficient.

What an audit does not check is whether anyone has actually read the plan. Whether the Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) were calculated with real data or estimated in a workshop. Whether the contact list has been tested. Whether the person named as the incident lead still works at the company.

What Happens When a Real Incident Hits

CrowdStrike, July 2024

On 19 July 2024, a single faulty software update from CrowdStrike crashed approximately 8.5 million Windows devices worldwide. Banks, hospitals, airports, emergency services, and hundreds of thousands of businesses were affected simultaneously. Total losses were estimated at over $5 billion.

The organisations that recovered quickly had one thing in common: they had tested their fallback procedures before the day arrived. They knew which systems were critical, who was responsible for each recovery action, and what ‘recovered’ actually looked like.

While all Indian carriers were forced into chaotic, pen-and-paper manual operations, the sheer scale of IndiGo’s market dominance magnified their cancellations, proving that when primary systems fail, the speed of executing manual fallback procedures is the only thing standing between delay and total collapse.

Delta Air Lines the same incident, a worse outcome

While most airlines recovered within hours, Delta cancelled over 7,000 flights over the following five days, affecting 1.3 million passengers and costing the airline an estimated $550 million in lost revenue and added expenses. Their crew scheduling systems a dependency nobody had stress-tested against this type of failure could not recover at the same pace as their flight operations systems.

A gap in their dependency mapping turned a one-day incident into a week-long operational crisis

Post the incident, all the focus was on:

• The faulty software update
• Microsoft Windows crashes
• CrowdStrike’s quality controls
• Recovery timelines
• Financial impact

The Root Causes Nobody Talks About

•  BCPs Scattered Across Drives and Inboxes

When an incident occurs at 2am, the incident lead does not have time to search SharePoint, check their inbox for the latest forwarded version, or call a colleague to ask which file is current.

In most organisations, BCPs exist in multiple versions across shared drives, personal laptops, email attachments, and occasionally USB sticks with unknown owners. Nobody knows which is current. Nobody has reviewed the most recent version. The plan that gets activated is often the one that comes up first in a search not the right one.

This is not a technology problem. It is a governance problem. And it is entirely solvable.

• BIAs Built on Gut Feel, Not Standardised Data

A Business Impact Analysis (BIA) is supposed to answer: what does this function need to survive, and how long can we manage without it?

In practice, most BIAs are filled out in workshops where Finance says ‘we could survive a week,’ IT says ‘our RTO is four hours,’ and Operations says ‘maybe two days.’ Nobody is using the same scale. Nobody has defined what ‘survive’ actually means in measurable terms. This is not a technology problem. It is a governance problem. And it is entirely solvable.

A typical BIA form with Gut feel

The result is a BIA that looks complete but contains no comparable, auditable data. When an incident occurs, the RTOs in the document do not reflect what the business actually needs, they reflect what people guessed in a meeting two years ago.

Every field answered in hours, not vague words, every financial impact in real figures, every owner a named person, not a job title. This is the difference between a BIA that satisfies a checkbox and one that could actually guide a recovery.

• No Testing Record, No Improvement Loop

Most organisations conduct tabletop exercises and theoretical walkthroughs of what would happen in a given scenario. These are useful. But they rarely produce a documented record of findings, and those findings rarely get linked back to concrete improvement actions.

The result is that the same gaps surface every year. The exercise report sits in a folder. Nobody acts on it. The next audit finds the same issues. The plan is updated superficially. The cycle continues.

• Incomplete Dependency Mapping

Organisations often don’t realise how many critical services, systems, and processes are connected until one of them fails. When a single endpoint platform goes down and takes five other functions with it, the BCP that was written without a dependency map is immediately useless. Mapping what depends on what – across IT, operations, and suppliers – is the foundation of any recovery plan that works in practice.

• Recovery Knowledge Locked in People, Not Systems

In too many organisations, the person who knows how to activate the workaround, who to call first, or where the backup access credentials are, is a single individual. When that person is unavailable during the actual incident, recovery stalls. Institutionalising recovery knowledge means documenting it, testing it with others, and ensuring it lives in the system.

• No Single Source of Truth

Processes, systems, risks, vendor contacts, and recovery procedures are maintained in separate repositories, which means no one has the full picture at the moment they need it most. When the incident lead has to stitch together information from four different tools and three different inboxes during a live crisis, every minute of that search is a minute not spent recovering.

• Manual Workarounds That Have Never Been Tested

Most organisations document manual workarounds as a fallback but have never actually executed them under real conditions. A workaround that looks logical in a document can fall apart completely in practice: the system access isn’t there, the staff aren’t trained, the volumes can’t be handled manually. An untested workaround is not a workaround. It is a false sense of security.

The Difference Between a Plan and a Practice

A plan is a document. A practice is a capability.

Organisations with genuine business continuity capability share certain characteristics:

• Their BCPs live in a single governed repository, one version, always current, always accessible
• Their BIAs use standardised data fields, so RTOs from Finance and IT are calculated on the same basis and can be compared
• Their test results are recorded and linked directly to improvement actions
• Their staff know the plan exists, know where to find it, and have used it at least once in a structured exercise
• Their incident occurred on the day of a disruption, which is not discovering the plan for the first time

The Questions Your BCP Should Be Able to Answer Today

Before your next audit, ask these questions honestly:

• If your primary document management system went down right now, where is your BCP, and who can access it?
• Are your RTOs based on real financial impact data, or estimates from a workshop?
• Do Finance, IT, and Operations use the same scale when defining recovery priorities?
• When did you last run a structured test? Are the findings documented? Were improvement actions completed?
• Can you name, right now, the person accountable for each critical business function recovery?

If any of these are difficult to answer, the plan may pass the next audit. But the next incident will expose the gap.

From a Filing Exercise to a Living Programme

Business continuity management is not a document. It is not an annual checkbox. It is an ongoing capability that requires structured data, governed processes, tested procedures, and clear ownership.

The difference between organisations that recover quickly and organisations that don’t isn’t the quality of their plans at the point of writing. It is the maturity of their practice at the moment disruption arrives.

Gieom’s Risk Central turns business continuity from a filing exercise into a living programme.

Structured BIAs. Single-governed BCP repository. Test and improve with every finding linked to action.

One version. Always current. Always ready.

Ready to move from spreadsheets to resilience?

Explore Solution

Expert Review

This article incorporates domain insights from Bhavana Mallesh, Chief Technology Officer at GIEOM, whose expertise in business continuity and operational resilience helped shape and validate the ideas presented. Her inputs ensure the discussion is grounded in practical resilience challenges faced by organizations.

Figures and incident details referenced in this article are drawn from the following primary and verified sources:

1. U.S. Department of Transportation – investigation findings into Delta Air Lines’ handling of the July 2024 CrowdStrike-related disruption. https://www.transportation.gov
2. Delta News Hub – official statement from Delta CEO Ed Bastian on the CrowdStrike outage recovery (July 24, 2024). https://news.delta.com/update-delta-customers-ceo-ed-bastian-july-24
3. Travel Weekly – coverage of the DOT’s closure of its investigation into Delta’s outage response, including comparative airline recovery times. https://www.travelweekly.com/Travel-News/Airline-News/DOT-ends-inquiry-of-CrowdStrike-crash-that-plagued-Delta
4. Wikipedia – “2024 Delta Air Lines disruption,” an aggregated, citation-backed summary of the incident timeline, flight cancellation figures, and financial impact. https://en.wikipedia.org/wiki/2024_Delta_Air_Lines_disruption