The Problem With Your Business Continuity Plan Is Your Org Chart

Introduction

A cross-border payments outage hits a shared processing platform used by banking entities in four countries. The Group business continuity function activates its plan within the hour, exactly as designed. What the plan doesn’t say is who decides whether the German entity keeps settling domestic payments locally while the shared platform in Ireland is still down. Three country COOs are on the call. Each one is right that it isn’t clearly their call to make alone, and each one is also right that someone has to make it now.

That gap, not the plan itself, is where continuity programs actually fail. The escalation path exists in every country’s individual playbook. What’s missing is the one name attached to who owns the decision when the incident crosses the line between them.

Most GRC professionals running continuity programs across EMEA financial services already recognize this scene, even without having had a reason to name it precisely before. This guide names it, explains why it shows up more often in financial services groups operating across EMEA than almost anywhere else, and lays out what a program looks like and what leadership has to put in place once someone actually owns the handoff.

The Real Failure Point Isn’t the Plan, It’s the Handoffs

Ask most BCM managers at a financial services firm whether their organization has a business continuity plan, and the answer is almost always yes. Ask them whether they could point to the single person accountable for a decision that spans two countries mid-incident, and the confidence drops fast.

That’s because most continuity programs are built and measured at the level of the document: is the plan current, has it been tested, is the binder up to date. None of that answers the question that actually matters during a live incident, which is who has the authority to make a cross-boundary call when the people who wrote the plan aren’t the people living the disruption.

A handoff isn’t a procedure. It’s a decision made by a specific person at a specific moment, under conditions a document can only approximate. A plan can say escalate to the country crisis lead. It can’t say what happens when two country crisis leads are both technically right and neither has the authority to overrule the other.

This is not a testing problem. An organization can run a disciplined tabletop exercise every quarter and still have this gap, because most exercises test whether a single team executes its own plan well, not whether two or three teams correctly hand a decision to each other under pressure. The handoff is invisible in a single-team exercise. It is the entire story in a real, cross-border incident.

Why This Fragments Faster in EMEA Financial Services Than Anywhere Else

A US-based bank or insurer, operating under a single primary regulator and one holding company structure, can build a continuity plan with a relatively short chain of command. Replicate that same institution across six EMEA countries, and the chain of command was never actually short. It just looked that way on the org chart.

Separately licensed entities are the first reason, and financial services feels this more than most industries.

Banking, e-money, and insurance licenses are typically granted at the national level across the EU and UK, which means a financial services group operating in six EMEA countries is often legally required to run six separately licensed, separately capitalized entities, not simply organized that way by internal preference. A Group BCM function can set the standard. It frequently cannot compel a nationally licensed entity’s local management to follow it during a live incident.

Works councils and local employee representation add a second layer most US-built programs never have to plan around. In several EMEA jurisdictions, decisions that affect employees during a crisis (relocation, remote work mandates, safety-related shutdowns) may require consultation with a works council before they can be executed, which means the fastest technically correct decision is not always the fastest legally executable one.

Language and localization compound both of the above. A single incident narrative translated into four languages doesn’t stay a single incident narrative. Details get lost or reinterpreted at each translation point, and by the time a decision reaches the fourth country, it may not be the same decision the first country made.

The disruption itself doesn’t have to be a cyber incident to expose this. Transit strikes and infrastructure disruptions across the region cross the same fractured lines between entities and countries, and test the same missing ownership, whether the incident starts in a data center or outside a regional trading floor.

None of this means EMEA financial services groups are worse at continuity planning. It means the operational surface area of a single incident is genuinely larger, and a continuity program built around one accountable owner per plan, rather than one accountable owner per handoff, was never going to hold up against that surface area.

Then Two Regulators Started Asking Who’s Actually in Charge

Regulation didn’t create this fragmentation. It’s now the thing making it visible, because DORA and the UK’s operational resilience regime, the two frameworks written specifically for financial services, are both, in different language, asking the same underlying question: who is accountable for the whole chain, not just their piece of it. NIS2 reinforces the same point from a different angle, for the market infrastructure and critical ICT providers many financial institutions depend on but don’t directly control.

The EU’s Digital Operational Resilience Act, in force since January 2025 and now under active supervisory review, requires financial entities to demonstrate ICT resilience at the level of the service, not the system. A cross-border payments or securities settlement service that depends on infrastructure across three entities and two ICT providers has to be able to show recovery objectives for the service as a whole, which means someone has to own that service end to end, not just the piece of it inside their own entity’s walls.

NIS2 reinforces the same expectation for the market infrastructure providers and critical ICT vendors a bank or insurer relies on but doesn’t own. Where it applies, a vendor incident stops being purely the vendor’s problem to escalate upward and becomes something the receiving institution has to be able to answer for directly.

The UK Took a Structurally Different Approach

Since the transition period for the FCA and PRA’s operational resilience rules ended in March 2025, UK banks, insurers, and payment firms have been required to identify their important business services and set impact tolerances defining the maximum disruption each one can absorb before causing intolerable harm.

The important business service concept is the sharpest version of the handoff argument in either of these regimes, because a single important business service routinely spans multiple legal entities, functions, and countries inside the same group. Impact tolerance can only be met if someone owns the service across every one of those boundaries, not just within one of them.

The FCA has already confirmed this gap exists in practice. Its March 2026 review of firms one year past the deadline found that common weaknesses included incomplete mapping of the third parties supporting important business services, scenario testing that wasn’t severe enough to reveal a real handoff failure, and self-assessments that hadn’t been meaningfully updated since firms first passed the deadline. The plans exist. The ownership behind them, in the FCA’s own findings, often doesn’t.

And the People Who Answer for It

None of this stays confined to the BCM function’s side of the org chart. Under DORA’s governance requirements, the management body, meaning the board and senior executives directly responsible for the institution, bears what the regulation calls ultimate responsibility for ICT risk, including approving the digital operational resilience strategy and actively overseeing how it’s carried out, not simply signing off on it once a year. The UK’s operational resilience rules place a parallel expectation on the Board and senior leadership, who remain accountable for the firm meeting its impact tolerances even when the underlying service depends on entities and providers the Board doesn’t directly run.

For a COO or CRO, that turns the handoff gap from an operational inconvenience into a personal one. If a cross-border incident exposes that no one owned the decision, a supervisory review afterward doesn’t stop at what happened. It goes on to ask who on the management body can show they knew the risk and had a framework in place to govern it. Naming that owner in advance isn’t just good practice at that point. It’s what the accountability the regulation assigns to leadership actually requires.

Read together, DORA, the UK regime, and NIS2 where it applies point in the same direction for a financial services group: proving the plan exists is no longer enough. Regulators, and increasingly boards, now expect proof of who owns it across every boundary it crosses.

What Ownership Actually Looks Like When It Works

Three things close the handoff gap for a financial services group operating across EMEA, and none of them require a bigger program or a new platform, just naming what most continuity programs currently leave implicit.

A Group BCM Lead with an explicit cross-entity mandate. This is different from a Group BCM function that writes standards and hopes each licensed entity adopts them. The mandate has to include named decision rights for cross-boundary calls specifically, not general oversight of the plan. If a decision spans two entities, the Group BCM Lead, or someone explicitly delegated by that role for the specific incident, is the name attached to making it, not a committee assembled after the fact.

A RACI that travels with the incident, not one that lives in a country playbook. Most organizations have a RACI, but it’s usually filed inside each country’s individual plan, which means during a real incident, three different RACIs have to be reconciled in real time, exactly when there’s no time to do it. A traveling RACI is built once, at the group level, and defines accountability at each handoff point specifically: who owns the decision the moment an incident crosses from one country’s remit into another’s, before the incident happens, not during it.

Handoff protocols mapped to named entity boundaries, not general escalation paths. A general escalation path says who to call. A handoff protocol says what authority transfers, what information has to travel with it, and how long the receiving party has to accept or contest the transfer before it defaults to them. This is the piece most programs skip entirely, because it requires naming the exact boundaries a real incident will cross, which takes more upfront work than a generic escalation chart, but is the only version that actually functions under pressure.

None of this is a new discipline invented for this guide. ISO 22301’s requirements for interested-party and interdependency mapping already point toward it, and the Business Continuity Institute’s Good Practice Guidelines treat structured handoff and activation authority as a core discipline in their own right, not an afterthought to planning. The standard already exists. What’s usually missing is a program that actually builds against it at the point where handoffs happen.

A Mandate Only Leadership Can Grant

The three practices above only work with one more ingredient no BCM manager can supply alone: a mandate from above. A BCM manager can design a traveling RACI and draft handoff protocols in detail, but naming a Group BCM Lead with real cross-entity decision rights is a mandate only a COO, a CRO, or the management body itself can grant. Where that mandate doesn’t come from above, the RACI becomes another document nobody follows under pressure, no different from the plan it was meant to fix.

Four Questions Worth Asking, Whichever Seat You Sit In

The gap this guide has been describing usually isn’t visible until someone asks about it directly. These four questions surface it in one sitting, whether you’re the one building the RACI or the one who has to answer for it if it fails.

1. Is there a named individual, not a committee, accountable for decisions that cross entity or country boundaries?
2. Does that person’s authority come from an explicit mandate, or from an assumption that the Group BCM function will simply be listened to?
3. Is the RACI built once at the group level, or does it have to be reconciled across separate country plans during a live incident?
4. Could the answer to any of the above be shown to a regulator or a board, or does it live only as an informal understanding?

If the honest answer to the last question is no, the accountability DORA and the UK’s operational resilience rules assign to leadership isn’t yet backed by anything the organization could actually produce.

A useful way to track progress rather than intent: the share of critical or important business services that have a single named, cross-entity owner recorded in the RACI. Most programs can state this number once they look for it. Few can state it today.

Back to the Payments Outage

Return to the incident this guide opened with. The difference between that outage and one that resolves cleanly in an hour isn’t a better plan sitting in a drawer in Frankfurt or Dublin. It’s a name attached to the decision the three country COOs were arguing over. If the Group BCM Lead already owns that specific handoff, backed by a mandate from above and a traveling RACI that says so in advance, the call isn’t a debate. It’s already been made.

Name the Owner Before the Next Incident Does

The scene this guide opened with, three country COOs on a call, each correct that the decision isn’t clearly theirs alone, isn’t a failure of effort or planning discipline. It’s what happens when a program is built to own a document instead of a chain of decisions that crosses borders it was never mapped against.

DORA, NIS2, and the UK’s operational resilience rules didn’t create that gap for EMEA financial services groups. They’re simply the first outside parties with enough reach to notice it consistently, across enough institutions, and now to expect specific people to close it. For a BCM manager, that means building the traveling RACI and the handoff protocols. For a COO or CRO, it means granting the mandate that makes them real, and being able to show a regulator or a board that both already exist before the next incident forces the question.

Where Mitratech Fits

Naming an owner, building a traveling RACI, and mapping handoff protocols is organizational work no software replaces. What a connected platform can do, for a financial services group managing separately licensed entities across EMEA, is make that ownership structure enforceable and visible: a single plan record that reflects entity and country boundaries, escalation workflows that follow the handoff protocol automatically, and an incident record that stays whole across every licensed entity it touches. It also gives leadership something to point to when a regulator or a board asks for evidence of ownership, a live, time-stamped record of who holds it, evidence a policy document alone can’t provide.

That connected approach is also independently recognized. In August 2026, QKS Group named Mitratech Preparis a Leader in the SPARK Matrix™: Business Continuity & Operational Resilience Management, 2026, citing its ability to support enterprise-wide resilience programs across complex regulatory environments.