Cloud Migration Regulatory Approval for Banking Workloads
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?
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.
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, and shared-provider outages produce correlated failures across the sector in the way described in common cloud outages.
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?
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, and key custody decisions belong in the design described in HSM and key management architecture.
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. 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.
