Let Digiqt design and test multi-region failover for the workloads that genuinely require zero data loss.

Zero Data Loss You Can Prove

# Getting to Zero Data Loss Without Pretending Physics Does Not Apply

Boards ask for zero data loss and zero downtime, and technology teams write both into a resilience document because arguing feels like admitting weakness. Then a region degrades, the failover runs, and the institution discovers that a synchronous target three thousand kilometres away had been quietly demoted to asynchronous months earlier because write latency was hurting the payment path.

Zero data loss is achievable and it has a price denominated in latency, distance, and complexity. Designing banking multi region failover RPO targets that hold under real conditions means paying that price deliberately for the workloads that need it, and being honest about the ones that do not.

## What does zero data loss actually require?

That no transaction is acknowledged to a client until it is durably recorded in more than one location.

That single sentence contains the whole trade-off. Acknowledgement cannot precede durability in a second location, so every commit pays the round trip to that location. There is no configuration that removes this, only choices about how far apart the locations are and which workloads accept the cost.

### What is the physics constraint?

Signal propagation adds roughly a millisecond per hundred kilometres each way, before any equipment overhead.

Light in fibre travels at around two thirds of its vacuum speed, and real paths are not straight lines. A synchronous replica three hundred kilometres away adds several milliseconds of unavoidable round-trip latency to every write, and one at fifteen hundred kilometres adds tens of milliseconds. That is fine for many workloads and fatal for a payment authorisation path with a hard external timer, which is precisely the tension described in this guide to [FedNow and RTP participation](https://digiqt.com/blog/fednow-rtp-integration/), where the scheme response budget leaves little room for a distant synchronous commit.

### Which workloads genuinely need an RPO of zero?

Ledger postings, payment instructions, and anything irreversible once acknowledged.

| Workload | Realistic RPO | Reasoning |
|---|---|---|
| Ledger postings and balances | Zero | A lost posting is an unrecoverable financial discrepancy |
| Accepted payment instructions | Zero | Client was told the payment was accepted |
| Authorisation decisions with scheme obligations | Zero to seconds | Irreversible and externally visible |
| Customer profile and entitlement changes | Seconds | Recoverable from source or reissued |
| Fraud model features and scores | Seconds to minutes | Recomputable |
| Analytics, reporting, data warehouse | Minutes to hours | Derived data, rebuildable |
| Logs and telemetry | Minutes | Volume makes synchronous replication uneconomic |

Classifying honestly is the first cost saving available, because institutions that apply zero RPO uniformly spend heavily and slow the paths that matter most.

> **Is your payment path paying synchronous latency to protect data that could be rebuilt?**
>
> [Talk to Digiqt about RPO classification and replication design](https://digiqt.com/contact-us/)

## Which replication models are available?

Six, trading data loss against latency, distance, and complexity.

| Model | Data loss | Write latency cost | Suits |
|---|---|---|---|
| Asynchronous | Seconds to minutes of loss | None | Derived data, analytics, far geographies |
| Semi-synchronous | Usually zero, not guaranteed | Partial round trip | Middle ground, often misunderstood as zero |
| Synchronous two sites | Zero between the pair | Full round trip | Metro or near-region pairs |
| Synchronous with witness or arbiter | Zero, with safe tie-breaking | Full round trip | Banking standard for critical stores |
| Consensus or quorum databases | Zero once quorum acknowledges | Round trip to quorum majority | Modern distributed stores across nearby regions |
| Application-level dual write | Inconsistent under failure | Two writes | Almost never appropriate |

### Where does synchronous replication break down?

At distance, and under partial failure where the replica is slow rather than absent.

The failure everyone plans for is a replica that disappears, and the failure that actually causes incidents is a replica that responds slowly. A degraded synchronous target drags every commit with it, so the primary appears to fail while remaining technically available. Decide in advance whether the system prioritises availability by dropping to asynchronous or prioritises durability by refusing writes, make that behaviour explicit and alarmed, and never let it be an emergency judgment call. Silent demotion to asynchronous is the single most common reason a bank believes it has zero RPO and does not.

### Why is application-level dual write usually wrong?

Because it has no atomicity, so a failure between the two writes leaves inconsistent state with no arbiter.

Writing to two regions from application code looks straightforward and produces divergence that nobody can reconcile afterwards, since there is no transaction spanning both and no authority on which one is correct. Where a genuine cross-store guarantee is needed, use replication provided by the data platform, or use an event log as the source of truth with derived stores rebuilt from it. The one legitimate variant is writing to a durable log synchronously and projecting asynchronously, which keeps a single authoritative order.

## Why is RTO usually harder than RPO?

Because replication is a product feature and failover is an organisational decision.

Zero RPO can be bought. Low RTO has to be engineered across detection, decision, promotion, fencing, downstream reconnection, and capacity, and it fails on whichever of those is weakest. Most institutions have solid replication and a failover process that takes hours because three of those steps require a person who has to be found.

### How should the failover decision be made?

Automatic detection and fencing, with a time-limited human decision on final promotion for ledger stores.

Automate detection, quorum evaluation, and fencing of the failed primary, since those need to happen in seconds and are deterministic. For promoting a new primary on a ledger, many banks keep a human in the loop, because an incorrect automatic promotion during a network partition is worse than a short delay. If you do that, bound it: a named on-call role, a defined maximum decision time, pre-authorised criteria, and an automatic path if nobody responds. Unbounded human decisions are how a thirty-second technical failover becomes a two-hour outage.

### How do you prevent split brain?

With quorum across three locations and hard fencing of the old primary.

Two sites cannot distinguish a partition from a peer failure, which is why a third location holding a witness or arbiter is required even when you only intend to run in two regions. The third site needs no data capacity, only independence, and it must not share the failure domain that could partition the pair. Then fence properly: the demoted primary must be prevented from accepting writes, by network isolation, credential revocation, or storage-level fencing, before the new primary is promoted. A ledger that accepted writes in two places for ninety seconds creates a reconciliation problem that outlasts the incident by months.

> **Do you have an independent third location capable of breaking a tie?**
>
> [Talk to Digiqt about quorum and fencing design](https://digiqt.com/contact-us/)

## What breaks during failover that nobody tests?

In-flight work, identifier generation, session state, downstream reconnection, and capacity.

| Failure mode | What happens | Mitigation |
|---|---|---|
| In-flight transactions | Accepted but incomplete work in unknown state | Idempotency keys, durable intent log, reconciliation on recovery |
| Sequence and identifier generation | Duplicate or reused identifiers across regions | Region-partitioned or globally coordinated generation |
| Session and authentication state | Customers logged out or stuck mid-journey | Replicated or reconstructible session state |
| Downstream reconnection | Consumers hold stale endpoints or connection pools | Health-aware clients, short DNS TTLs, tested reconnection |
| Capacity in the surviving region | Insufficient headroom for full load | Reserved capacity, load shedding plan, tested at full volume |
| Batch and scheduled jobs | Jobs run twice or not at all | Region-aware scheduling with leader election |
| Third-party callbacks | Provider still calls the failed region | Registered endpoints that follow failover, provider testing |

### How do you handle in-flight payments?

With a durable intent record, idempotency, and a reconciliation pass that runs automatically after recovery.

A payment accepted but not confirmed at the moment of failure is the most consequential item in the list, because both duplicating and dropping it are unacceptable. Record intent durably before any external call, key every external interaction idempotently, and treat unknown outcomes as a first-class state to be resolved after failover rather than as an error to be retried blindly. Then run reconciliation against the rail and the ledger as part of the recovery runbook, not as a follow-up task. Institutions that skip this find the problem days later in a break report.

## How do you test failover honestly?

Frequently, unannounced, at full load, and including the messy parts.

| Test | What it proves | Cadence |
|---|---|---|
| Planned failover with notice | The mechanism works | Quarterly minimum |
| Unannounced failover in business hours | Detection, decision, and people | Twice yearly for critical services |
| Failover at peak load | Capacity in the surviving region | Annually |
| Degraded replica scenario | Behaviour when the replica is slow, not absent | Annually |
| Partition scenario | Quorum, fencing, split-brain prevention | Annually |
| Failback | Returning without a second outage | Every exercise, since this is often untested |

Failback deserves specific attention. Many institutions can fail over and have never returned cleanly, which means every real event leaves them running in a secondary configuration for weeks. Test the return path as part of every exercise. Regular, boring failover is the goal, since a mechanism exercised quarterly is one the team trusts at 3 a.m., and the broader recovery discipline is covered in this guide to [disaster recovery for mission-critical platforms](https://digiqt.com/blog/ransomware-resilience-banking/) and in [disaster recovery for core systems](https://digiqt.com/blog/ransomware-resilience-banking/).

## What does this actually cost?

Roughly double infrastructure for active-passive, more for active-active, plus latency and engineering complexity.

Synchronous replication requires capacity that is idle most of the time or an active-active design that costs more to build and reason about. Add cross-region bandwidth, the third site, and the engineering effort to make failover routine. Present the cost against the tolerance it protects rather than as an infrastructure line item, because the decision belongs to whoever owns the service and its tolerance. That framing is exactly what [mapping critical business services and setting impact tolerances](https://digiqt.com/blog/operational-resilience-impact-tolerance/) provides, and the tolerance-based case is far more likely to be funded than an architectural preference.

## How does this connect to regulatory expectations?

Supervisors care whether critical services stay available and recoverable, not which replication mode you chose.

The Basel Committee's Principles for operational resilience, published in March 2021, take a principles-based approach to withstanding operational disruption, and CPMI-IOSCO's guidance on cyber resilience for financial market infrastructures, published in June 2016, frames the expectation as anticipating threats, responding rapidly, and achieving faster and safer target recovery objectives. For payment participants there is also a hard operational reality: instant rails run continuously, with the FedNow Service operating a 24-hour business day every day of the week including weekends and holidays, so a maintenance window that once absorbed failover work no longer exists. Note too that failover protects against infrastructure failure and not against corruption, since synchronous replication faithfully copies corrupted data to both regions, which is why immutable isolated copies remain necessary as covered in [ransomware resilience and immutable backup design](https://digiqt.com/blog/ransomware-resilience-banking/).

## Which metrics prove the capability?

Tested failover time, replication lag and mode, unannounced test results, failback success, and capacity headroom.

Report tested failover time per critical service rather than designed RTO, since the difference is your real exposure. Monitor replication lag continuously and alarm on any silent transition from synchronous to asynchronous, because that transition is the most dangerous undetected state in this whole design. Track results from unannounced exercises separately from planned ones, as the gap measures your operational readiness rather than your technology. Record failback success rate. And measure surviving-region capacity headroom at peak, since a failover into insufficient capacity converts a regional outage into a total one. The underlying RTO and RPO discipline, including how to derive targets rather than assert them, is set out in this guide to [disaster recovery planning with RTO and RPO](https://digiqt.com/blog/ransomware-resilience-banking/).

Zero data loss is an engineering commitment with a latency invoice attached, and the institutions that hold it are the ones that scoped it narrowly, put a witness in a third location, fenced their old primaries properly, and failed over often enough that nobody hesitates.

## Frequently Asked Questions

### Is zero data loss across regions actually achievable?

Yes, with synchronous replication, and it costs write latency proportional to distance. The physics is fixed, so the design question is which workloads justify paying that latency.

### How much latency does distance add?

Signal propagation alone adds roughly one millisecond per hundred kilometres each way, before switching and protocol overhead, and every synchronous commit pays the round trip.

### Which workloads genuinely need an RPO of zero?

Ledger postings, payment instructions, and anything irreversible once acknowledged. Analytics, reporting, and derived data almost never justify synchronous replication.

### Why is RTO usually harder than RPO?

Because replication is a product feature while failover is an organisational decision involving detection, quorum, fencing, downstream reconnection, and capacity in the surviving region.

### Why do you need a third site for two-region failover?

To break ties. With two sites, neither can safely distinguish a network partition from the other's failure, so a witness or arbiter elsewhere is what prevents split brain.

### What is the most commonly untested part of failover?

In-flight work. Messages accepted but not completed, sequence generators, session state, and downstream reconnection behaviour cause most of the damage during real failovers.

### Should failover be automatic?

For detection and fencing, yes. For the final promotion decision on a ledger, many banks keep a human in the loop with a strict time limit, because an incorrect automatic promotion is worse than a delay.

### How often should failover be tested?

Frequently enough to be routine, which for critical services means at least quarterly, including unannounced exercises rather than only scheduled ones with everyone watching.

## Sources

- [CPMI-IOSCO, Guidance on cyber resilience for financial market infrastructures](https://www.bis.org/cpmi/publ/d146.htm)
- [BCBS, Principles for operational resilience](https://www.bis.org/bcbs/publ/d516.htm)
- [Federal Reserve, FedNow Service additional questions and answers](https://www.federalreserve.gov/paymentsystems/fednow-additional-questions-and-answers.htm)

Banking Multi-Region Failover With Zero Data Loss Requirements

Let Digiqt build and test a cloud exit plan your supervisor will accept and your engineers could execute.

An Exit Plan You Could Actually Run

# Writing an Exit Plan You Could Actually Execute Under Pressure

Most cloud exit plans are written to satisfy a document request, and it shows. They name no specific destination, assume the provider will help, quote a timeline nobody derived from anything, and have never been tested in any part. They pass on submission and would not survive the first hour of a real exit.

That gap matters more than it used to. Supervisors have read many of these documents and have learned which questions expose them: where exactly would this workload run, who extracted the data and how long did it take, and what would you do if the provider stopped cooperating tomorrow. A cloud exit plan financial services regulators accept is one where those three answers are specific and at least partly evidenced.

## What is an exit plan actually for?

Demonstrating the bank could keep delivering critical services without a provider it currently depends on.

That framing matters because it rules out two common shortcuts. It is not a procurement document showing alternatives exist, and it is not a migration plan assuming an orderly project. It is a continuity capability, which means the relevant question is always what you hold and can run independently of the provider you are leaving.

### Which scenarios must the plan cover?

Six, and they need different assumptions rather than one document with a variable date.

| Scenario | Notice available | Provider cooperation | Practical implication |
|---|---|---|---|
| Contract expiry or renegotiation | Months | Full | Standard migration project |
| Commercial decision to move | Months | Usually good | Migration with negotiated assistance |
| Persistent performance failure | Weeks | Degraded | Compressed timeline, disputed relationship |
| Provider or region failure | None | None or partial | Run from what you already hold |
| Regulatory instruction to exit | Defined by authority | Variable | Timeline set externally, not by you |
| Security compromise of the provider | None | Unsafe to rely on | Assume the environment is untrusted |

### Why is stressed exit a genuinely different plan?

Because it cannot assume notice, cooperation, or a usable source environment.

An orderly exit lets you copy data at leisure, run in parallel, and ask the provider for help. A stressed exit gives you none of that, so it depends entirely on assets held outside the provider: independent copies of data, infrastructure definitions in your own repositories, credentials and keys under your control, and a target environment that either exists or can be created without the provider's tooling. Write the stressed variant first, because it exposes dependencies the orderly version hides, and everything it requires makes the orderly path easier too.

> **Could you stand up your most critical cloud workload if the provider stopped cooperating tomorrow?**
>
> [Talk to Digiqt about stressed exit planning](https://digiqt.com/contact-us/)

## What makes an exit plan credible?

Named destination, dependency-ordered sequence, tested data extraction, real cost and time, and defined decision triggers.

| Element | Weak version | Credible version |
|---|---|---|
| Destination | Another provider or on-premises | A named target with capacity assumptions and a service mapping |
| Sequence | High-level phases | Dependency-ordered steps including identity, keys, and network |
| Data | Data can be exported | Tested extraction at production volume with completeness verification |
| Timeline | An estimate | Derived from tested components and stated assumptions |
| Cost | Not stated | Modelled including egress, dual running, and staff |
| Degraded operation | Not addressed | What the bank does during transition and what customers experience |
| Triggers | Board decision | Defined conditions that start the plan and who declares them |
| Evidence | The document | Test records, extraction proofs, exercise notes |

### Why is naming the destination the hardest part?

Because provider-specific managed services often have no equivalent to move to.

A workload built on a proprietary managed database, a provider-specific event service, and platform-native identity has no destination in any meaningful sense, which is why so many plans stay vague at exactly this point. Resolving it means either designing the target explicitly, including what you would build or buy to replace each managed service, or accepting the coupling and documenting it as a limitation with compensating controls. Both are defensible. Silence is not.

## How do you assess portability honestly?

By classifying every critical service against how tightly it couples to provider-specific capabilities.

| Coupling level | Characteristics | Exit implication |
|---|---|---|
| Portable | Containers, open-source data stores, standard protocols | Weeks, mostly operational work |
| Moderately coupled | Managed versions of open-source services, provider networking | Months, migration with known equivalents |
| Tightly coupled | Proprietary databases, serverless platform primitives, native identity | Rebuild, not migration |
| Structurally dependent | Provider-specific analytics and machine learning services holding business logic | No realistic exit without redesign |

Run the assessment per critical service rather than per application, and publish the result. Engineering teams usually know which category they are in and have never been asked to state it, and stating it changes design conversations immediately because tight coupling becomes a visible choice with a documented consequence.

### How much portability should you actually buy?

Enough for critical services to move within your stated tolerance, and no more.

Portability costs real money and real capability: avoiding managed services means operating more yourself, and abstraction layers add complexity that slows delivery. Buy it deliberately for the services whose loss would breach an impact tolerance, accept coupling elsewhere, and record the decision. A bank that insists on full portability everywhere either spends heavily or quietly ignores the policy, and the second outcome is the one supervisors find. The abstraction patterns that make this manageable are the same ones described in this guide to [API gateway strategies for integration complexity](https://digiqt.com/blog/swift-gpi-api-connectivity/).

## What does data extraction really involve?

Getting complete, usable, decryptable data at production scale, within a time you have measured.

Extraction is where paper plans fail fastest. The questions are whether the export format is usable by the target rather than only by the source, whether the volume can move within your window given real throughput and egress limits, whether the extract is complete and verifiable rather than plausible, whether encrypted data can be decrypted independently of the provider's key service, and whether the data model travels with the data. Test it: pull a production-scale extract, restore it into a target, and reconcile record counts and checksums. The due-diligence discipline for this is well described in run-off data readiness, where the question is likewise whether historical data can be handed over in a state someone else can actually use, and the migration mechanics follow the patterns in this guide to [data migration to cloud-native platforms](https://digiqt.com/blog/cloud-migration-regulatory-approval-banking/).

> **When did you last extract a production-scale dataset and reconcile it in a target environment?**
>
> [Talk to Digiqt about exit data extraction testing](https://digiqt.com/contact-us/)

## How does a stressed exit actually run?

Partially, service by service, in degraded mode, under a declared trigger.

Nobody exits an entire estate at once under stress, and plans that assume it are unrealistic. Model a partial exit: which services move first, which run degraded, which are suspended, and what customers can still do throughout. Then define the triggers precisely enough that someone can declare them, including sustained unavailability beyond a threshold, confirmed compromise, regulatory instruction, or provider insolvency indicators, and name who declares each. Escalation without a named declarer is how organisations spend two days deciding whether the plan has started. The wider governance point, that late exit decisions are the expensive ones, is made well in this account of reducing exit decisions made too late.

### What must exist outside the provider before you need it?

Independent data copies, infrastructure as code, keys, credentials, and documentation.

Keep at least one copy of critical data outside the provider's control plane, hold infrastructure definitions and deployment pipelines in a repository you control, keep key material and secrets under custody that survives losing the provider, and store the exit runbook somewhere retrievable when your primary environment is unavailable. Each of those is cheap in advance and impossible to arrange during an incident, which is exactly the pattern behind the isolation requirements in [ransomware resilience and immutable backup design](https://digiqt.com/blog/ransomware-resilience-banking/).

## Which contract terms make exit possible?

Export rights in usable formats, transition assistance, survivable notice, subcontractor transparency, and no post-termination dependence.

Negotiate data export rights that specify format and completeness rather than merely permitting export, transition assistance obligations with defined duration and scope, notice periods long enough to execute your own plan, access to information about material subcontractors, and continuity of service through a termination dispute so a commercial disagreement cannot become an outage. Supervisory expectations reinforce this: the EBA's guidelines on outsourcing arrangements set out the definition of outsourcing and the criteria for assessing whether a function is critical or important, and the FSB's December 2023 toolkit provides tools for managing risk across the lifecycle of third-party relationships, which includes the end of them. Secure these terms before signature, because renegotiating an exit clause with an incumbent provider is a poor negotiating position.

## How do you test without performing the migration?

Through component tests, tabletop exercises, and one real workload move per cycle.

| Test type | What it proves | Cadence |
|---|---|---|
| Data extraction at scale | Volume, format, completeness, time | Annually per critical dataset |
| Restore into alternative target | The extract is usable elsewhere | Annually |
| Representative workload on alternative | Portability claim is real | Annually, rotating service |
| Key and credential independence | You can decrypt without the provider | Annually |
| Stressed scenario tabletop | Decision-making, triggers, roles | Twice yearly |
| Actual migration of one non-critical service | End-to-end capability | Per cycle where feasible |

The last row is the most convincing evidence available and the least commonly done. Moving one genuine service, even a small one, produces findings no tabletop generates and gives you a defensible answer to the question of whether you have ever actually left anything.

## Who owns the plan and how is it kept current?

The accountable executive for the service, with the platform team maintaining technical content on a fixed cycle.

Exit plans decay quickly because architecture changes faster than documents. Tie review to change rather than to the calendar alone: adopting a new managed service, adding a region, or onboarding a subcontractor should each trigger a plan update. Keep the plan short enough that updating it is realistic, hold the detail in the platform inventory it references, and review it formally at least annually alongside your outsourcing register. Concentration analysis belongs in the same cycle, since exit feasibility and concentration are two views of the same dependency, as covered in [third-party and concentration risk in cloud dependencies](https://digiqt.com/blog/third-party-concentration-risk-cloud/), and the approval context is in [cloud migration regulatory approval](https://digiqt.com/blog/cloud-migration-regulatory-approval-banking/).

## Which metrics prove exit readiness?

Tested extraction recency, portability classification coverage, independent copy coverage, tabletop currency, and services actually moved.

Report when each critical dataset's extraction was last tested and how long it took, since that is the number a supervisor will probe. Track the share of critical services with a documented portability classification and a named destination. Measure independent copy coverage, meaning critical data held outside the provider's control plane. Record tabletop and exercise recency per scenario. And count services genuinely migrated in the last cycle, because one real move is worth more than a hundred pages of intent and it is the only metric that cannot be produced by writing.

Exit planning is unrewarding work that becomes suddenly valuable on the day it is needed, and the difference between institutions is almost entirely whether they tested anything. A short plan with three tested components beats a comprehensive one with none, and only one of them will survive the conversation.

## Frequently Asked Questions

### What is a cloud exit plan actually for?

Demonstrating that the bank could continue delivering critical services if it had to leave a provider, whether in an orderly transition or after sudden failure, without depending on that provider's goodwill.

### How is a stressed exit different from an orderly exit?

An orderly exit assumes cooperation, notice, and a working environment. A stressed exit assumes none of those, so it relies on copies you already hold and destinations already prepared.

### Why do generic exit plans get rejected?

Because they name no destination, no sequence, no cost, and no tested step. A statement that alternatives exist is an intention rather than a plan a supervisor can assess.

### What makes the destination hard to specify?

Provider-specific managed services. A workload built on a proprietary database or messaging service has no equivalent target, so the destination has to be designed, not just named.

### How do you test exit without doing the migration?

Test the components: extract production-scale data and verify completeness, run a representative workload on the alternative, and walk the stressed scenario with the people who would run it.

### How much portability is worth paying for?

Enough for critical services to move within your stated tolerance. Full portability across the estate is usually poor value, so buy it deliberately where it matters.

### What contract terms make exit feasible?

Data export rights in usable formats, defined transition assistance, notice periods you can survive, subcontractor transparency, and no dependence on provider cooperation after termination.

### Who should own the exit plan?

The accountable executive for the outsourced service, with the platform team maintaining the technical content and a fixed review cycle tied to architectural change.

## Sources

- [EBA, Guidelines on outsourcing arrangements](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/internal-governance/guidelines-outsourcing-arrangements)
- [FSB, Enhancing Third-party Risk Management and Oversight: A Toolkit](https://www.fsb.org/2023/12/final-report-on-enhancing-third-party-risk-management-and-oversight-a-toolkit-for-financial-institutions-and-financial-authorities/)

Cloud Exit Plan for Financial Services That Regulators Accept

Let Digiqt prepare the criticality assessment, register, and exit plan your supervisor will expect before your migration starts.

Get Cloud Approved Without Rewriting It Twice

# Getting a Supervisor Comfortable With Your Public Cloud Plan

Cloud migration programmes in banking rarely fail on technology. They fail on the conversation with the regulator, and they usually fail late, after architecture is committed and delivery dates are public. The engineering team presents a well-designed landing zone and gets asked how the bank would exit the provider in a stressed scenario, who at the provider can access customer data, and what happens if the region hosting the workload becomes unavailable during a resolution event.

Those questions are answerable, and the answers are largely governance artefacts rather than technical ones. Securing cloud migration regulatory approval banking supervisors accept is mostly a matter of preparing the right evidence early and designing the migration so the evidence is true.

## What does a supervisor actually want to see?

Evidence that the bank remains in control and accountable, whoever runs the infrastructure.

The underlying principle across regimes is that outsourcing does not transfer accountability. Supervisors therefore examine how you decided the arrangement was appropriate, how you monitor it, and what you would do if it failed. The European Banking Authority's revised Guidelines on outsourcing arrangements, published in March 2019 and applicable from September 2019, set out a clear definition of outsourcing and criteria for assessing whether an activity, service, process, or function is critical or important, which is the assessment that drives everything else.

### Which questions come up every time?

Criticality, register, exit, concentration, data location, oversight rights, incident reporting, and resilience testing.

| Question | What satisfies it |
|---|---|
| Is this a critical or important function? | Documented assessment against defined criteria, with the conclusion and reasoning |
| Where is it recorded? | A maintained outsourcing register with the required fields |
| How would you exit? | A specific, sequenced, costed plan with tested components |
| What is your concentration exposure? | Analysis at provider, region, and service level with mitigations |
| Where is the data, and who can reach it? | Data location mapping including support access and key custody |
| What oversight and audit rights do you hold? | Contract terms plus the assurance mechanism you will actually use |
| How are incidents reported? | Defined thresholds, timelines, and the provider's notification obligations |
| How do you test resilience? | Scenario testing evidence, including provider failure |

### Why is approval about governance rather than technology?

Because supervisors are assessing whether the bank can still fulfil its obligations, not whether your architecture is modern.

An excellent technical design with no tested exit plan will struggle, and a conventional design with rigorous governance will pass. That asymmetry frustrates engineering teams and it is entirely rational from a supervisory perspective: the concern is continuity of critical services and the institution's ability to remain accountable. Frame your submission in those terms rather than in terms of technical merit, and the conversation gets substantially easier.

> **Could you produce a costed, sequenced exit plan for your most critical cloud workload this week?**
>
> [Talk to Digiqt about cloud approval readiness](https://digiqt.com/contact-us/)

## How should workloads be classified?

By criticality, with expectations scaling accordingly rather than uniformly.

| Tier | Examples | Supervisory expectation |
|---|---|---|
| Critical or important | Core ledger, payment processing, customer authentication | Full assessment, register entry, tested exit, resilience testing, notification where required |
| Significant but not critical | Analytics on customer data, internal reporting | Register entry, assessment, proportionate exit planning |
| Supporting | Development tooling, collaboration, non-customer workloads | Lightweight assessment, standard vendor management |

Do the classification honestly and early. Institutions that classify aggressively downward to reduce paperwork create a worse problem later, when a supervisor disagrees with a classification after the workload is live and the remediation is retrospective. Where the assessment is genuinely borderline, document the reasoning and the compensating controls.

## What does the outsourcing register need to contain?

Enough that someone outside the team can understand each arrangement, its criticality, and its dependencies.

Record the provider and any material subcontractors, the function outsourced, the criticality conclusion, the countries where data is stored and processed, the contract dates and notice periods, the exit plan reference, the last review date, the accountable executive, and the assurance mechanism in use. Then keep it current, because a stale register is worse than an incomplete one: it demonstrates that the governance is nominal. Automate the parts that can be derived from your cloud estate rather than maintaining them by hand, since manual registers drift within a quarter.

## How do you write an exit plan a supervisor believes?

Name the alternative, sequence the steps, cost it, time it, and test the parts you can.

### Why is intending to move not a plan?

Because a plan you have never exercised is an assumption, and supervisors have seen many of them.

A credible plan names the specific alternative for each critical workload, whether another provider, a return to on-premises, or a degraded internal service. It sequences the steps in dependency order, states the elapsed time and cost, identifies what would be lost, and describes how the bank would operate during the transition. It also distinguishes an orderly exit at contract end from a stressed exit following provider failure or a regulatory instruction, because those are different plans with different assumptions.

### What should actually be tested?

Data extraction, workload portability on a sample, and the stressed scenario as a documented exercise.

Nobody expects a full rehearsed migration. What is expected is evidence: proof that you can extract data in a usable form and at realistic volume, that a representative workload can run on the alternative, and that the stressed scenario has been walked through with the people who would run it. Test data extraction in particular, since egress volume, format, and time are where paper plans meet reality. This is also where the architectural choices made during migration matter, because a workload built on deeply provider-specific managed services is not portable no matter what the plan says, which is the trade-off examined in this guide to [cloud migration for core systems](https://digiqt.com/blog/core-banking-data-migration/).

## How should concentration risk be addressed?

At institution level for your own dependencies, and with awareness that authorities are watching sector-level concentration.

The FSB's toolkit on enhancing third-party risk management and oversight, published in December 2023, provides tools for identifying critical third-party services and for identifying, monitoring, and managing systemic third-party dependencies and potential systemic risks. Your own analysis should cover reliance on a single provider across multiple critical functions, reliance on a single region, reliance on a single service such as a managed database that many workloads share, and concentration through subcontractors you do not contract with directly. Region-level exposure is frequently underestimated, as set out in [cloud region exposure and why multi-cloud is not diversification](https://digiqt.com/blog/banking-multi-region-failover-rpo/), and shared-provider outages produce correlated failures across the sector in the way described in [common cloud outages](https://digiqt.com/blog/banking-multi-region-failover-rpo/).

### Which mitigations are actually credible?

Architectural independence for the most critical path, degraded-mode operation, and honest documentation of what you accept.

Full multi-provider redundancy for every workload is expensive and usually unnecessary. What is credible is designing the most critical path so it can run in a second region or provider, defining a degraded mode that keeps essential service available, and documenting clearly where you accept concentration and why. Supervisors respond better to a well-reasoned accepted risk than to an implausible mitigation, and the accepted risk survives scrutiny while the implausible mitigation collapses under a single question.

> **Do several of your critical workloads depend on one provider service nobody listed as a dependency?**
>
> [Talk to Digiqt about cloud concentration analysis](https://digiqt.com/contact-us/)

## How do audit and oversight rights work in practice?

Through pooled audits, assurance reports, and contractual access rights rather than bespoke on-site inspection.

Hyperscale providers do not accommodate individual bank audits of their data centres, and supervisors know this. The workable position combines contractual audit and access rights, third-party assurance reports and certifications, participation in pooled audits, and your own monitoring of the controls that remain yours. Confirm with your supervisor in advance that the mechanism is acceptable rather than assuming, and be precise about which controls are the provider's and which are yours, because shared responsibility confusion is a recurring finding. Also secure rights that extend to material subcontractors, since that chain is where visibility is usually lost.

## How should data location and sovereignty be handled?

By mapping obligations per country and data category, and by treating support access and key custody as location questions too.

Storage location is the obvious dimension and rarely the binding one. What also matters is where processing occurs, where support engineers are located and what they can reach, where backups and disaster recovery copies sit, and where encryption keys are held and who controls them. A workload stored in-country but supportable from anywhere may not satisfy the obligation you are trying to meet. The full architecture for multi-country institutions is the subject of [data residency and sovereignty architecture](https://digiqt.com/blog/data-residency-architecture-banking/), and key custody decisions belong in the design described in [HSM and key management architecture](https://digiqt.com/blog/hsm-key-management-financial/).

## What does the engagement timeline look like?

Six to eighteen months for a first critical workload, driven by artefact quality rather than by the supervisor's speed.

| Stage | Duration | What determines it |
|---|---|---|
| Internal assessment and classification | 1 to 2 months | Clarity of your service and dependency mapping |
| Artefact preparation | 2 to 3 months | Register, exit plan, concentration analysis, control mapping |
| Contract negotiation for required rights | 2 to 4 months | Audit, subcontracting, data location, termination terms |
| Initial supervisory engagement | 1 to 3 months | Quality of what you bring to the first meeting |
| Iteration and clarification | 1 to 4 months | How many gaps the first submission left |
| Notification or approval and go-live | 1 to 2 months | Jurisdictional process |
| Ongoing supervision | Continuous | Register currency, testing evidence, incident handling |

The fastest approvals are the ones where the first meeting presents complete artefacts. Arriving with an architecture and a promise to write the exit plan later converts a three-month process into a year, and it damages credibility that later submissions have to rebuild.

## Which metrics keep approval intact after go-live?

Register currency, exit plan test recency, concentration trend, resilience test coverage, and incident reporting timeliness.

Approval is not a one-time event, and supervisors return to the same questions. Track register currency as a percentage of arrangements reviewed within their defined period. Record when each critical exit plan component was last tested. Report concentration trend, since drift toward a single provider happens quietly as teams adopt convenient managed services. Measure resilience testing coverage including provider failure scenarios, which connects directly to [ransomware resilience and recovery design](https://digiqt.com/blog/ransomware-resilience-banking/). And monitor incident notification timeliness against your obligations, because a missed notification undermines confidence faster than an outage does.

Cloud in banking is now a well-trodden path, and the institutions that move quickly are not the ones with the cleverest architecture. They are the ones that decided early which workloads are critical, wrote an exit plan they had actually tested, and could answer the concentration question with a number rather than a reassurance.

## Frequently Asked Questions

### What do supervisors actually want to see for a cloud migration?

Evidence of governance rather than architecture diagrams: criticality assessment, a maintained register, a tested exit plan, concentration analysis, audit rights, incident reporting, and resilience testing.

### What makes a function critical or important?

Whether its failure would materially impair regulatory compliance, financial performance, or the soundness and continuity of services. Supervisory guidelines set the criteria and expect a documented assessment.

### Why is a generic exit plan rejected?

Because saying you could move to another provider is an intention, not a plan. Supervisors want named alternatives, sequenced steps, data extraction proof, cost, timeline, and evidence something was tested.

### Do you have to test the exit plan?

You have to demonstrate credibility, which in practice means testing components such as data extraction and running a workload on an alternative, rather than rehearsing a full migration.

### How is concentration risk assessed?

At institution level across your own reliance on one provider or region, and at sector level where authorities monitor systemic dependencies. Both need documented analysis and mitigations.

### How do audit rights work with a hyperscale provider?

Mostly through pooled audits, third-party assurance reports, and contractual access rights rather than bespoke on-site audits. Confirm the mechanism is acceptable to your supervisor in advance.

### Does data have to stay in country?

It depends entirely on jurisdiction and data type. Map obligations per country and per data category, and remember that key location and support access matter as much as storage location.

### What is the most common cause of delay?

Starting the conversation late. Approval timelines are driven by the quality of artefacts you bring, so building the register, assessment, and exit plan before the first meeting shortens everything.

## Sources

- [EBA, Guidelines on outsourcing arrangements](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/internal-governance/guidelines-outsourcing-arrangements)
- [FSB, Enhancing Third-party Risk Management and Oversight: A Toolkit](https://www.fsb.org/2023/12/final-report-on-enhancing-third-party-risk-management-and-oversight-a-toolkit-for-financial-institutions-and-financial-authorities/)

Cloud Migration Regulatory Approval for Banking Workloads

Let Digiqt design data residency architecture that satisfies each country without forking your platform into unmaintainable variants.

One Platform, Many Jurisdictions

# Building One Platform That Obeys Many Countries' Rules

Multi-country banking groups almost always start from the same place: a platform designed for one country, deployed globally because that was cheaper, and a growing list of jurisdictions whose rules it does not quite satisfy. The initial response is usually a database in each country and a declaration that residency is handled.

Then someone asks where the monitoring data goes, who can access production from the group's engineering hub, where the backups replicate to, and where the encryption keys live. Each of those answers travels across a border, and each is a residency question. Getting data residency architecture banking groups can genuinely operate means treating residency as a property of the whole system rather than of the primary datastore.

## What does data residency actually require?

Control over every place data is stored, processed, copied, or reachable from, not just the primary database.

| Dimension | Question | Frequently missed |
|---|---|---|
| Storage | Where do primary records live | No, this is always covered |
| Processing | Where is data computed on | Sometimes, for batch and analytics |
| Backups and disaster recovery | Where do copies replicate to | Often |
| Support and administrative access | Who can reach production, from where | Very often, and it is the biggest gap |
| Encryption keys | Who holds them and where | Often |
| Logs and telemetry | Where do application and platform logs land | Very often |
| Metadata and queues | Do identifiers travel in message payloads | Almost always missed |
| Third-party subprocessors | Where do vendor services process data | Often, especially at second tier |

### Why is metadata the part that catches people?

Because telemetry and message payloads leave by default while the database stays put.

A platform can hold every customer record in-country and still stream logs containing account identifiers to a global observability service, publish events to a regional message bus that replicates elsewhere, and send error traces with payload fragments to a vendor. None of that appears in a data flow diagram drawn around the database, which is why residency reviews should start from network egress and vendor lists rather than from the schema. The reinsurance analogue is documented in this account of data residency when files cannot travel, where the constraint applies to documents rather than telemetry but the failure mode is identical.

### Why does support access decide compliance?

Because an engineer who can query production has effectively moved the data to wherever they are sitting.

If your group operations team in one country can access customer records held in another, the data is reachable from that jurisdiction regardless of storage location. That is the finding most likely to surface in a supervisory review, and fixing it after the fact means rebuilding your support model. Design it up front: local support teams where required, break-glass access with in-country approval and full recording, and tooling that returns aggregated or masked data by default so routine work never requires raw access.

> **Do you know every place your platform's logs and telemetry land?**
>
> [Talk to Digiqt about a residency and egress assessment](https://digiqt.com/contact-us/)

## Which deployment patterns are available?

Four, and most multi-country groups end up with regional instances of one codebase.

| Pattern | How it works | Fits when | Cost |
|---|---|---|---|
| Single global instance | One deployment serving all countries | Few countries, permissive rules | Lowest until it is non-compliant |
| Regional instances | Same codebase deployed per country or region, data stays local | Most multi-country groups | Moderate, multiplied operations |
| Hub and spoke | Global control plane, local data planes | Strong central platform capability | Moderate, control plane scrutiny |
| Local-only with global aggregates | Full local autonomy, only aggregates leave | Strict jurisdictions, joint ventures | Highest, weakest consistency |

### When is the regional instance model right?

Almost always, once more than two jurisdictions with meaningful rules are involved.

It keeps data local by construction rather than by configuration, which is much easier to evidence, and it isolates a country's outage and change risk. The cost is operational multiplication: more deployments to patch, more environments to monitor, more release coordination. Absorb that with automation rather than with headcount, and resist the temptation to reduce it by centralising a shared service back into one region, which is how residency erodes quietly.

### How do you avoid forking into many divergent platforms?

One codebase, per-country configuration, and a rule that country differences never live in code.

Country-specific behaviour belongs in configuration, policy, and data: field requirements, retention periods, permitted flows, product rules, reporting formats. The moment a country gets its own branch, you have committed to maintaining separate platforms forever and every future change costs several times more. Enforce that boundary in code review, and treat a request for a country-specific fork as an architectural escalation rather than a delivery decision. The pressures that produce fragmentation are exactly those described in data localization rules and fragmented architecture.

## How do you serve legitimate cross-border needs?

With aggregates, pseudonymised extracts, or federated queries rather than by centralising raw records.

Group risk aggregation, financial crime monitoring, consolidated supervision, and management reporting all have genuine needs for a cross-border view, and a residency architecture that ignores them will be worked around. Design the flows deliberately: send aggregates where aggregates suffice, pseudonymised extracts where individual granularity is needed without identity, and query federation where the answer can be computed locally and only the result travels. Document the lawful basis and the minimum data for each flow, and keep an inventory of them, because the flows are what a supervisor will examine. Where the requirement is genuinely to compute across borders on sensitive data, the privacy-preserving techniques described in [federated fraud intelligence sharing](https://digiqt.com/blog/federated-fraud-data-sharing/) apply to intra-group analysis just as they do between institutions.

### What happens when a transfer mechanism changes?

You need to be able to switch a flow off without breaking the business function.

Lawful transfer mechanisms change, and a flow that is permitted today may require a different basis in two years. Build each cross-border flow so it can be suspended, narrowed, or re-routed through a local computation without a re-architecture: keep the flow explicit rather than embedded, retain a local fallback for the function it serves, and record the basis alongside the flow definition. Institutions that hard-wired central processing into critical paths have had to rebuild under time pressure, which is expensive and avoidable.

## Where should keys and access controls live?

Under custody consistent with the residency obligation, because key location can undermine compliant storage.

If data is stored in-country and the keys are held elsewhere under another jurisdiction's control, the protection you are relying on may not satisfy the obligation. Map key custody per data category alongside storage, decide whether in-country key management is required, and be explicit about who can technically compel or perform decryption. NIST's key management recommendation frames the protection each key type requires and the processes for administering it, which is the right basis for deciding what in-country custody actually needs to mean in your design. The platform mechanics of that sit in [HSM and key management architecture](https://digiqt.com/blog/hsm-key-management-financial/).

## How do sovereign cloud offerings and local providers fit?

As one option among several, evaluated on the same governance criteria as any other arrangement.

Sovereign or in-country cloud offerings can resolve residency and support-access questions cleanly, and they typically offer a narrower service catalogue, higher cost, and slower feature availability. Local providers may satisfy residency and introduce concentration and resilience questions of their own. Evaluate both against the criteria a supervisor will use, which include criticality assessment, exit planning, and concentration, as set out in the EBA's outsourcing guidelines and the FSB's third-party risk toolkit. That evaluation is the same one described in [cloud migration regulatory approval](https://digiqt.com/blog/cloud-migration-regulatory-approval-banking/), and the answer frequently differs per country, which is another reason the platform must tolerate different infrastructure underneath the same codebase.

> **Would a change of lawful transfer mechanism break a critical group function tomorrow?**
>
> [Talk to Digiqt about cross-border flow design](https://digiqt.com/contact-us/)

## How should data be classified and enforced?

With a small classification scheme, tagged at the data layer, enforced by policy as code.

| Classification | Example | Handling rule |
|---|---|---|
| Locally restricted | Customer records in a strict jurisdiction | Never leaves the country in any form including logs |
| Locally stored, aggregable | Customer transactions | Local storage, aggregates may leave |
| Pseudonymisable | Behavioural and risk features | May leave once identifiers are removed under a defined process |
| Group internal | Configuration, reference data, code | Moves freely |
| Public | Rates, published disclosures | No constraint |

Keep the scheme small enough that engineers apply it correctly. Four or five classes with clear rules beat a fifteen-class taxonomy nobody remembers.

### How do you enforce rather than document?

Through platform controls that make a violation fail rather than appear in a later audit.

Constrain deployment regions in infrastructure code, deny cross-region replication by policy rather than by convention, block egress to unapproved destinations at the network layer, require classification tags on datasets before they can be provisioned, and generate evidence automatically from the platform rather than assembling it manually for each review. Documentation describes intent, and policy as code produces the compliance. This is also what makes the audit conversation short, since you can demonstrate the constraint rather than asserting the practice, which is the wider point made in this guide to data sovereignty for regulated platforms.

## What operating model does this need?

Clear per-country accountability, a central platform team, and change control that catches residency impact before release.

Name an accountable owner per country for data handling, keep the platform itself centrally owned so the codebase does not fragment, and add a residency impact assessment to change control so a new vendor, a new log destination, or a new shared service is evaluated before it ships. The failure pattern is a well-designed architecture eroded by a hundred small decisions, each locally sensible: a monitoring tool adopted globally, an analytics pipeline centralised for efficiency, a support rota extended across regions for coverage. Catching those at change time is far cheaper than finding them in a review.

## How should delivery be phased?

Map reality first, then close the invisible flows, then restructure deployment, then automate enforcement.

| Phase | Duration | Deliverable |
|---|---|---|
| Discovery and flow mapping | 2 to 3 months | Every store, process, copy, log destination, vendor, and access path documented |
| Obligation mapping per country | 1 to 2 months | Requirements by country and data category, with legal sign-off |
| Close the invisible flows | 2 to 4 months | Logs, telemetry, queues, backups, and support access brought into compliance |
| Classification and tagging | 2 months | Scheme applied at the data layer |
| Deployment restructuring | 4 to 8 months | Regional instances of one codebase, shared services reconsidered |
| Cross-border flow design | 2 to 3 months | Aggregates, pseudonymisation, federated queries with documented basis |
| Policy as code and evidence | 2 to 3 months | Automated constraints and automated evidence generation |

Discovery is the phase people want to skip and the one that changes the plan. Almost every group that maps honestly finds several flows nobody knew about, and finding them yourself is considerably better than having them found for you.

## Which metrics prove compliance holds over time?

Flow inventory completeness, unapproved egress events, support access from outside jurisdiction, tagged coverage, and evidence automation.

Report the share of data flows documented with a classification and lawful basis, and treat undocumented flows as defects. Count unapproved egress attempts blocked by policy, since a healthy number proves the control is live. Track raw production access from outside the data's jurisdiction and drive it toward zero with local tooling and masked defaults. Measure tagged coverage of datasets. And report what share of compliance evidence is generated automatically rather than assembled by hand, because that ratio determines whether the next review costs a week or a quarter.

Residency architecture is one of the few areas where the cheap answer and the correct answer diverge sharply, and where the cost of the cheap answer arrives years later as a rebuild under supervisory pressure. The groups that handle it well decided early that data location is a platform property enforced in code, not a policy statement maintained in a document.

## Frequently Asked Questions

### Is data residency just about where data is stored?

No. Processing location, backup and disaster recovery copies, support access, encryption key custody, logs, and metadata all count, and support access is the dimension most often missed.

### Why does metadata cause problems?

Because platform telemetry, logs, queue payloads, and monitoring data frequently leave the country by default even when the primary database stays put, and they often contain customer identifiers.

### Which deployment pattern works best?

Regional instances of one codebase for most multi-country groups. A single global instance is simplest until one country's rules make it non-compliant everywhere.

### How do you avoid maintaining many divergent codebases?

One codebase, per-country configuration, and a hard rule that country-specific behaviour lives in configuration and policy rather than in forked code.

### Can group risk and financial crime functions still get a consolidated view?

Usually yes, through aggregates, pseudonymised extracts, or federated queries rather than by centralising raw records, with the lawful basis documented per flow.

### Where should encryption keys live?

Under custody consistent with the residency obligation, which often means in-country or under a key regime the local authority accepts, since key location can undermine otherwise compliant storage.

### How do you enforce residency rather than document it?

Policy as code in the platform: region-constrained deployment, denied cross-region replication, tagged data classification, and automated evidence that the constraints held.

### What breaks first when a group scales into a new country?

Shared services. Fraud scoring, analytics, identity, and reporting were built globally, and the new country's rules force each to be reconsidered individually.

## Sources

- [EBA, Guidelines on outsourcing arrangements](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/internal-governance/guidelines-outsourcing-arrangements)
- [FSB, Enhancing Third-party Risk Management and Oversight: A Toolkit](https://www.fsb.org/2023/12/final-report-on-enhancing-third-party-risk-management-and-oversight-a-toolkit-for-financial-institutions-and-financial-authorities/)
- [NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final)

Data Residency Architecture for Multi-Country Banking Platforms

Let Digiqt design a sovereign landing zone your engineers will adopt and your supervisor will accept.

Foundations That Pass Review And Ship Fast

# Laying Foundations a Regulator and an Engineer Can Both Live With

Landing zones fail in two opposite directions. The permissive kind lets teams deploy anything anywhere, and the first supervisory review finds customer data in an unexpected region with logs streaming to a global service. The restrictive kind blocks so much that delivery teams request exceptions on every project, and within a year the exception process is the real architecture.

A sovereign cloud landing zone banking teams actually use has to satisfy both audiences: preventive controls a supervisor can see working, and a paved road fast enough that nobody wants to route around it. Those goals are compatible, and getting there is mostly about deciding which controls are absolute and which are defaults.

## What is a landing zone, and what makes it sovereign?

The pre-built foundation every workload deploys into, and sovereignty is the set of constraints that foundation enforces.

| Landing zone component | What it provides | Sovereignty relevance |
|---|---|---|
| Account and subscription structure | Isolation boundaries and blast radius control | Per-jurisdiction separation |
| Network design | Connectivity, segmentation, egress control | Prevents data leaving by default |
| Identity and access | Authentication and authorisation | Who can reach in-country data, from where |
| Logging and monitoring | Operational and audit telemetry | Log residency and immutability |
| Policy guardrails | Preventive and detective controls | Region and service restriction |
| Key management | Cryptographic custody | Key location and export policy |
| Pipelines and paved road | How workloads get deployed | Makes the compliant path the fast path |
| Cost and tagging | Attribution and accountability | Ownership evidence for critical services |

### Which sovereignty dimensions does the landing zone actually control?

Data location, personnel access, key custody, operational autonomy, and provider dependency.

Location is the obvious one and the easiest to enforce. Personnel access is harder and more consequential, because an engineer authenticating from another country to support an in-country workload has effectively extended the data's reach. Key custody determines whether encryption satisfies the obligation. Operational autonomy asks whether the environment can be run without personnel outside the jurisdiction. And provider dependency asks what remains if the provider is unavailable to you. Design each explicitly, since a landing zone that only enforces region selection covers one dimension of five, which is the wider point made in this guide to [data sovereignty for regulated platforms](https://digiqt.com/blog/data-residency-architecture-banking/).

## Which sovereign deployment options exist?

Five, trading capability and cost against control.

| Option | Control gained | What you give up |
|---|---|---|
| Public region with strong controls | Location, policy enforcement, key custody | Provider personnel access remains a contractual matter |
| Provider sovereign region or partition | Personnel and operational constraints | Higher cost, narrower service catalogue |
| Provider-operated sovereign cloud | Local operation and personnel controls | Feature lag, sometimes significant |
| Local partner-operated provider stack | Local entity and staff, local jurisdiction | Scale, maturity, and service breadth |
| In-country private infrastructure | Full control | Elasticity, cost, and pace of capability |

Start by asking which specific obligation the public region cannot satisfy. Frequently the answer is none, and the sovereign option is being chosen for comfort rather than requirement, which is an expensive way to buy reassurance. Where a genuine constraint exists, name it in the decision record so the trade-off is explicit and revisitable.

> **Which specific obligation rules out a public region with strong controls?**
>
> [Talk to Digiqt about sovereign deployment options](https://digiqt.com/contact-us/)

## How should the account and environment structure be designed?

Per jurisdiction first, then per environment, then per workload domain.

Structure determines both blast radius and evidence quality. Separating by jurisdiction at the top means residency controls apply to a whole boundary rather than to individual resources, which is far easier to enforce and to demonstrate. Below that, separate production from non-production strictly, since non-production is where real data most often leaks. Then separate workload domains so a compromise or misconfiguration is contained. Keep the structure shallow enough to navigate, because a deeply nested hierarchy nobody understands produces misplacement, which is its own compliance failure.

## Where should identity live?

As close to the jurisdiction as the obligation requires, with cross-border access controlled and recorded.

Identity is the most commonly overlooked sovereignty dimension. A global identity provider that can grant access to in-country production data means the effective control point sits outside the jurisdiction, and that is exactly the finding a reviewer will raise. Decide deliberately whether authentication and authorisation for in-country production must be locally controlled, implement break-glass access with in-country approval and full session recording, and default operational tooling to masked or aggregated views so routine work never needs raw access. Where local support teams are required, staff them before go-live rather than promising them in a remediation plan.

## How should guardrails work?

Preventive for anything that cannot be allowed even briefly, detective for everything else.

| Control | Type | Reasoning |
|---|---|---|
| Region restriction | Preventive | A resource created in the wrong region has already breached the obligation |
| Prohibited services | Preventive | Some services cannot meet residency or logging requirements |
| Public exposure of data stores | Preventive | The window between creation and detection is the incident |
| Key export and cross-region replication | Preventive | Undoing these does not undo the exposure |
| Encryption configuration | Preventive with narrow exceptions | Retrofitting encryption is expensive and often incomplete |
| Tagging and ownership | Detective with enforcement at deployment | Missing metadata is a quality issue, not an exposure |
| Cost anomalies | Detective | Financial rather than compliance risk |
| Configuration drift | Detective with automated remediation | Continuous correction beats blocking |

Implement all of it as policy as code in the same pipeline that provisions infrastructure, so the control and the environment are versioned together. That also produces the evidence automatically, which is what turns a review from an assembly exercise into a query, and it is the same discipline applied to containerised workloads in this guide to [containerisation and Kubernetes in regulated environments](https://digiqt.com/blog/developer-velocity-regulated-banking/).

### Why do restrictive landing zones get bypassed?

Because they block delivery without providing an approved alternative.

If the compliant path takes six weeks and an exception takes two days, every team learns to request exceptions. Fix that by investing in the paved road: pre-approved patterns for common workload shapes, self-service provisioning inside guardrails, and a fast path for anything that fits an approved pattern. Then make the exception process deliberately slower and more visible than the paved road, so the incentive points the right way. A landing zone that engineers prefer is a control that works.

> **Is your compliant deployment path faster or slower than requesting an exception?**
>
> [Talk to Digiqt about paved road design for regulated cloud](https://digiqt.com/contact-us/)

## How should logging and evidence be handled?

In-country, immutable, and generating compliance evidence automatically.

Logs are data, and they frequently contain identifiers, so their destination is a residency decision rather than an operational convenience. Keep audit logs in the jurisdiction, write them to storage the account's own administrators cannot alter, and separate operational telemetry from audit records so sanitised operational data can travel while audit records stay put. Then derive evidence from the platform: region compliance, blocked guardrail violations, key custody, log residency, and any access from outside the jurisdiction. That evidence is what a supervisor examining the arrangements described in [cloud migration regulatory approval](https://digiqt.com/blog/cloud-migration-regulatory-approval-banking/) will want, and generating it continuously is far cheaper than assembling it per review.

## Where do keys and secrets belong?

Under custody consistent with the jurisdiction's expectation, with export prevented by policy.

Decide per data category whether keys must be held in-country, whether the provider may ever hold key material, and who can technically perform or compel decryption. Then enforce it: prevent key export, prevent cross-region key replication, and log every administrative key operation. Where the obligation is strict, in-country key management or customer-controlled key infrastructure may be required, and where the concern is specifically provider visibility during processing rather than storage, that is a different control addressed by [confidential computing for sensitive workloads](https://digiqt.com/blog/confidential-computing-financial-workloads/). The broader custody design sits in [HSM and key management architecture](https://digiqt.com/blog/hsm-key-management-financial/).

## How do you support many countries without forking the platform?

One landing zone definition with per-country parameters, deployed independently per jurisdiction.

Treat the landing zone as a product with a versioned definition and country-specific parameters covering permitted regions, prohibited services, key custody model, log destinations, identity configuration, and access rules. Deploy an instance per jurisdiction from that single definition. Country differences then live in configuration, upgrades roll out consistently, and evidence has the same shape everywhere, which matters when a group-level report has to cover fifteen markets. Forking per country is the failure mode that makes every subsequent change cost several times more, and the wider platform argument is set out in [data residency and sovereignty architecture](https://digiqt.com/blog/data-residency-architecture-banking/).

## How should delivery be phased?

Obligations first, then structure and guardrails, then paved road, then evidence automation.

| Phase | Duration | Deliverable |
|---|---|---|
| Obligation mapping per country | 1 to 2 months | Requirements by jurisdiction and data category, legally reviewed |
| Structure and network foundation | 2 to 3 months | Account hierarchy, segmentation, egress control |
| Identity and access design | 1 to 2 months | Identity placement, break-glass, masked defaults, local support model |
| Preventive guardrails | 2 months | Policy as code for region, services, exposure, keys, replication |
| Paved road and self-service | 2 to 3 months | Approved patterns, fast provisioning, exception process |
| Evidence automation | 1 to 2 months | Continuous compliance reporting from the platform |
| Multi-country rollout | Ongoing | Per-jurisdiction instances from one definition |

Do the obligation mapping before the technical design, because the answers determine whether you need a sovereign region at all, and that decision is expensive to reverse once workloads exist. Bring cost discipline in early too, since sovereign and dedicated options carry a premium that grows quietly, which is the trap examined in this guide to [cloud cost optimisation at scale](https://digiqt.com/blog/cloud-migration-regulatory-approval-banking/). Supervisory expectations on the surrounding arrangements come from the EBA's outsourcing guidelines and the FSB's third-party risk toolkit, both of which focus on criticality, oversight, and exit rather than on which region you chose.

## Which metrics show the landing zone is working?

Paved road adoption, exception volume, blocked violations, evidence automation, and out-of-jurisdiction access.

Report the share of workloads deployed through the paved road rather than bespoke, since that is the single best indicator of whether the control is real. Track exception requests and their ageing, because rising exceptions mean the road is too narrow. Count guardrail violations blocked, as a healthy number proves prevention is active rather than theoretical. Measure the share of compliance evidence produced automatically. And monitor access to in-country production from outside the jurisdiction, driving it toward zero with local tooling and masked defaults, since that is the finding most likely to appear in a review.

A landing zone is the cheapest place in a bank to enforce a rule, because enforcing it once in the foundation costs nothing per workload afterwards. That is also why it deserves genuine product investment rather than being treated as a one-off project: the version teams adopt willingly is the version that keeps the institution compliant three years later.

## Frequently Asked Questions

### What is a landing zone?

The pre-built foundation every workload deploys into: account structure, network, identity, logging, policy guardrails, key management, and pipelines, provided as a paved road rather than assembled per project.

### What makes a landing zone sovereign?

Control over where data and workloads run, who can operate them, where keys and logs live, and how much the arrangement depends on personnel or infrastructure outside the jurisdiction.

### Which sovereign deployment option should we choose?

Usually a public region with strong controls unless a specific obligation rules it out, since dedicated sovereign offerings cost more and lag on service availability.

### Where should the identity plane live?

As close to the jurisdiction as the obligation requires. A global identity provider that can authenticate access to in-country data is frequently the weak point in an otherwise compliant design.

### Which guardrails must be preventive rather than detective?

Region restriction, prohibited services, public exposure of data stores, key export, and cross-region replication. Detection after the fact does not satisfy a residency obligation.

### Why do landing zones get bypassed?

Because they block delivery without offering an approved alternative. If the compliant path is slower than the workaround, teams route around it and the controls stop meaning anything.

### How do you support multiple countries without forking?

One landing zone definition with per-country parameters, deployed separately per jurisdiction, so differences live in configuration rather than in divergent implementations.

### What evidence should the landing zone produce automatically?

Region compliance, guardrail violations blocked, key custody, log residency, and access from outside the jurisdiction, generated continuously rather than assembled for each review.

## Sources

- [EBA, Guidelines on outsourcing arrangements](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/internal-governance/guidelines-outsourcing-arrangements)
- [FSB, Enhancing Third-party Risk Management and Oversight: A Toolkit](https://www.fsb.org/2023/12/final-report-on-enhancing-third-party-risk-management-and-oversight-a-toolkit-for-financial-institutions-and-financial-authorities/)

Sovereign Cloud Landing Zone Design for Financial Institutions

Let Digiqt build a dependency and concentration picture derived from your live estate rather than from a procurement register.

Map What You Actually Depend On

# Knowing What You Depend On, Including the Things You Never Contracted For

Ask a bank for its list of critical third parties and you will get a procurement register. Ask what would break if a specific managed queue service degraded in one region for six hours, and the answer usually requires a week of investigation across several teams. The gap between those two things is where concentration risk lives.

It exists because dependencies do not arrive through procurement. They arrive when an engineering team picks the convenient managed option, when a vendor changes its own subcontractor, and when three unrelated services quietly standardise on the same component. Managing third party concentration risk cloud estates create therefore starts with discovery from the live environment rather than with a better spreadsheet.

## What are you actually trying to manage?

The possibility that one failure outside your control takes down several critical services at once.

Concentration is a correlation problem rather than a vendor management problem. A single provider dependency is tolerable if it affects one non-critical service and serious if it sits under six critical ones, and the register that lists both identically tells you nothing about which is which.

### Which types of concentration exist?

Six, and institutions typically track only the first.

| Type | Example | Usually tracked |
|---|---|---|
| Provider | Most critical workloads on one cloud provider | Yes |
| Service | Many services depending on one managed database or queue | Rarely |
| Region | Critical workloads and their recovery in the same region | Sometimes |
| Subcontractor or nth party | Several vendors relying on the same underlying provider | Almost never |
| Skills and knowledge | One team or a few individuals who can operate a critical platform | No |
| Sector level | Many institutions depending on the same provider at once | Monitored by authorities, rarely by firms |

Service-level and nth-party concentration cause the incidents that surprise people, because they are invisible in a contract-based view. Region-level exposure is similarly underestimated, which is the argument made in [cloud region exposure and why multi-cloud is not diversification](https://digiqt.com/blog/banking-multi-region-failover-rpo/).

### Why does nth-party dependency defeat most registers?

Because you have no contract, often no visibility, and the failure presents as someone else's outage.

Your payments vendor runs on a cloud provider, which runs on a content delivery network, which depends on a DNS provider. When the bottom layer fails, you see your vendor unavailable with no explanation and no ability to act. The FSB's toolkit on enhancing third-party risk management and oversight, published in December 2023, specifically addresses identifying critical third-party services and monitoring systemic third-party dependencies, which is the frame to borrow: ask each critical provider which of their own dependencies would take your service down, and make the answer a contractual reporting obligation rather than a goodwill enquiry.

> **Do you know which single managed service sits under the largest number of your critical workloads?**
>
> [Talk to Digiqt about a dependency and concentration assessment](https://digiqt.com/contact-us/)

## How do you build a dependency inventory that stays true?

By deriving it from the running estate and reconciling it against contracts, not the other way round.

Surveys and registers go stale immediately because they capture intent at a point in time. Your estate, by contrast, tells the truth continuously if you read it.

### Where do undeclared dependencies show up?

In billing, egress, DNS, package manifests, and infrastructure code.

Cloud billing reveals every managed service actually in use, including the ones nobody documented. Network egress destinations reveal external calls from production. DNS query logs reveal integrations that appear nowhere in architecture diagrams. Package manifests and container images reveal software supply chain dependencies. Infrastructure code reveals regions, services, and account structure. Pull all five continuously, map them to business services, and reconcile against the outsourcing register so the discrepancies become work items rather than surprises. The move from documented process maps to live dependency data is precisely the shift described in [going from critical-process maps to live dependencies](https://digiqt.com/blog/operational-resilience-impact-tolerance/).

### How do you connect a dependency to a business service?

Through service ownership metadata applied at deployment, so the mapping is a byproduct rather than a project.

Require every deployed component to declare the business service it supports and its criticality, enforce that at deployment time, and derive the dependency map from telemetry rather than from documentation. That turns the question of what breaks if a specific service degrades into a query rather than an investigation, which is the difference between answering a supervisor in an afternoon and in a month.

## How do you assess criticality and substitutability?

Criticality from business impact, substitutability from whether an alternative is named, tested, and owned.

| Rating | Criticality meaning | Substitutability meaning |
|---|---|---|
| High | Failure breaches an impact tolerance quickly | Alternative named, tested, owner assigned |
| Medium | Failure degrades service or delays obligations | Alternative identified, not tested |
| Low | Failure is inconvenient and absorbable | Alternative obvious and commodity |
| None | Not applicable | No realistic alternative exists |

The cell that matters is high criticality combined with no substitutability, and every institution has some. The correct response is not to pretend otherwise but to document the acceptance, add compensating controls such as degraded-mode operation, and report it to the board as a knowingly accepted risk. Supervisors respond considerably better to that than to an implausible mitigation, and the Basel Committee's Principles for operational resilience, published in March 2021, frame exactly this expectation of understanding and managing dependencies rather than eliminating them.

### What makes a substitute real rather than theoretical?

A named target, a tested path, an owner, and a known switch time.

An alternative provider that exists in the market is not a substitute. A named alternative with a tested migration path, an accountable owner, and a measured switch time is. Test one substitution per cycle even at small scale, since the exercise reveals the dependencies that make substitution harder than the paper suggests, and it feeds directly into the exit work described in [cloud exit and stressed exit planning](https://digiqt.com/blog/cloud-exit-plan-financial-services/).

## How should ongoing monitoring work?

On a small set of signals per critical provider, reviewed on a cadence, with escalation defined in advance.

Watch performance and availability against contractual commitments using your own telemetry rather than the provider's status page, since the two frequently disagree during incidents. Track incident history and the quality of post-incident information, because a provider that explains failures poorly is harder to manage than one that fails slightly more often. Monitor security posture through assurance reports and vulnerability disclosure behaviour. Watch financial and corporate signals, including ownership changes, since acquisition frequently changes service and pricing. And require notification of material subcontractor changes, which is the only practical route to nth-party visibility. Where the industry publishes shared outage analysis, use it, because correlated sector-wide events are the ones your own telemetry cannot anticipate, as discussed in [common cloud outages and non-malicious accumulation](https://digiqt.com/blog/banking-multi-region-failover-rpo/).

> **Do you measure provider availability from your own telemetry or from their status page?**
>
> [Talk to Digiqt about provider monitoring design](https://digiqt.com/contact-us/)

## What about emerging concentration in newer services?

Treat compute-intensive and model-serving dependencies as concentration risks now, before they become critical.

Specialised infrastructure creates concentration faster than general compute, because the supply of suitable capacity is narrower and the alternatives are fewer. Institutions adopting model-serving platforms, specialised accelerators, and vendor-hosted inference are accumulating dependencies with very limited substitutability, often through individual team decisions rather than architectural review. Bring those into the inventory early and assess substitutability honestly, because the window in which the choice is reversible is short. The exposure cluster this creates is examined in AI compute concentration as a new exposure.

## How should scenario testing be done?

By testing the failure of the dependency rather than the failure of the application.

Run scenarios that name the third party: this region becomes unavailable, this managed service degrades to fifty percent, this vendor is compromised, this subcontractor fails and your provider cannot say why. Then measure whether the affected business services stay inside their tolerances and whether your response worked. Include partial degradation rather than only total failure, since partial is more common and harder to detect. Tolerance setting and service mapping are the prerequisite for judging the results, which is the subject of [mapping critical business services and setting impact tolerances](https://digiqt.com/blog/operational-resilience-impact-tolerance/).

## What belongs in board reporting?

Critical services with single points of failure, concentration trend, substitutability gaps, and accepted risks.

| Report element | Why the board needs it |
|---|---|
| Critical services and their single points of failure | The concentration picture in business terms |
| Concentration trend by provider, service, and region | Drift happens quietly through engineering choices |
| Substitutability status for high-criticality dependencies | Distinguishes managed risk from hope |
| Provider incidents and response quality | Early signal of a deteriorating relationship |
| Nth-party visibility coverage | How much of the chain remains unknown |
| Knowingly accepted concentrations | Explicit acceptance rather than implicit exposure |

Keep it short and keep the trend, because a board can act on a direction of travel and cannot act on a hundred-row register.

## How should delivery be phased?

Discovery first, then service mapping, then substitutability assessment, then monitoring and testing.

Start with automated discovery from billing, egress, DNS, manifests, and infrastructure code, since that is where the unknown dependencies are. Then build the mapping from dependency to business service through deployment metadata. Then assess criticality and substitutability for the high-impact set, and accept explicitly where no substitute exists. Then stand up ongoing monitoring with defined signals and escalation, and add dependency-named scenario testing. Then tie the whole thing into your outsourcing register so the register becomes a view of reality rather than a parallel document, which is what supervisors examining the arrangements described in [cloud migration regulatory approval](https://digiqt.com/blog/cloud-migration-regulatory-approval-banking/) will expect.

## Which metrics show the risk is being managed?

Inventory coverage and freshness, single points of failure under critical services, substitutability coverage, nth-party visibility, and scenario coverage.

Report the share of production dependencies discovered automatically rather than declared, and how recently the inventory refreshed. Count single points of failure under critical services and track the number down deliberately. Measure substitutability coverage for high-criticality dependencies, with tested status distinguished from identified. Report nth-party visibility as the share of critical providers who have disclosed their own critical dependencies. And track scenario coverage, meaning how many of your top dependencies have been tested by failure rather than discussed.

Concentration risk is the one exposure that grows without anyone deciding to take it on, one convenient managed service at a time. The institutions that control it are the ones that read their own estate continuously, mapped dependencies to business services, and told the board plainly which single points of failure they have chosen to live with.

## Frequently Asked Questions

### What kinds of concentration actually matter?

Provider, individual service, region, subcontractor, scarce internal skills, and sector-level concentration where many institutions depend on the same provider simultaneously.

### Why do registers miss the real dependencies?

Because they record contracts, and dependencies arrive through engineering choices. A managed service adopted by three teams becomes critical without any procurement event.

### How do you find undeclared dependencies?

From the estate rather than from surveys: billing data, network egress destinations, DNS queries, package manifests, and infrastructure code all reveal what production actually calls.

### What is nth-party risk?

Dependence on your provider's providers. You have no contract with them, often no visibility, and their failure can present as your provider's outage with no explanation available.

### What makes a service genuinely substitutable?

A named alternative, a tested migration path, and an owner. Anything short of that is a substitute in principle, which does not help during an incident.

### How do you monitor a provider you cannot audit?

Through assurance reports, contractual reporting obligations, your own telemetry on their service, incident history, financial and security posture signals, and pooled industry oversight.

### Is multi-cloud the answer to concentration?

Rarely as a whole-estate strategy. Targeted independence for the most critical services usually delivers more resilience per unit of cost and complexity than broad duplication.

### What should the board actually see?

Critical services and their single points of failure, concentration trend, substitutability status, unresolved provider incidents, and which risks the bank is knowingly accepting.

## Sources

- [FSB, Enhancing Third-party Risk Management and Oversight: A Toolkit](https://www.fsb.org/2023/12/final-report-on-enhancing-third-party-risk-management-and-oversight-a-toolkit-for-financial-institutions-and-financial-authorities/)
- [BCBS, Principles for operational resilience](https://www.bis.org/bcbs/publ/d516.htm)
- [EBA, Guidelines on outsourcing arrangements](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/internal-governance/guidelines-outsourcing-arrangements)

Posts tagged with#Cloud

Banking Multi-Region Failover With Zero Data Loss Requirements

Cloud Exit Plan for Financial Services That Regulators Accept

Cloud Migration Regulatory Approval for Banking Workloads

Data Residency Architecture for Multi-Country Banking Platforms

Sovereign Cloud Landing Zone Design for Financial Institutions

Third-Party and Concentration Risk in Financial Cloud Estates

Our Offices