Cloud adoption in financial services has passed the point of being a strategic question. It is now an operational reality: the major hyperscalers — Microsoft Azure, Amazon Web Services and Google Cloud — have become, in practice, critical infrastructure for the European banking system. BaFin acknowledged this formally when it identified specific cloud providers as potential Critical Third-Party Providers under DORA. The question for regulated banks is no longer whether to adopt cloud, but how to do so in a way that satisfies the layered regulatory requirements of the German and European supervisory environment — and that actually works in the long term.
This article draws on the experience of developing and executing cloud migration strategy for a BaFin-regulated commercial real estate finance bank, where the work involved establishing over 130 architecture principles and guidelines, documenting more than 200 enterprise interfaces, building a data mesh architecture, and aligning the entire cloud programme with the concurrent obligations of DORA and the EU AI Act. The lessons below are practical, sometimes uncomfortable, and reflect what actually happens when the theory of cloud migration meets the reality of a regulated German banking environment.
The Regulatory Stack You Are Operating Within
Before a single workload moves to the cloud, technology and architecture leaders in BaFin-supervised institutions need a clear understanding of the regulatory framework that governs the move. It is more layered than most organisations appreciate at the outset, and the layers interact in ways that create obligations beyond what any single regulation implies in isolation.
The practical implication of this stack is that cloud migration in a German bank is not primarily a technology programme. It is a governance, risk and compliance programme that happens to involve significant technology change. Teams that treat it as the former and discover the latter mid-flight pay a significant cost in rework, delays and regulatory exposure.
Lesson One: Architecture Principles Before Migration Begins
The single most important decision made in any cloud programme is also frequently the one most tempted to be deferred: establishing the architecture principles that will govern the entire migration before any workloads move. The pressure to demonstrate early progress — to show cloud usage, to hit migration targets, to realise cost savings — creates a powerful incentive to start moving workloads before the architecture framework is in place. Resisting that pressure is, in my experience, the difference between a cloud programme that builds capability and one that accumulates technical and regulatory debt.
Architecture principles for a regulated cloud migration need to cover, at minimum: cloud service model boundaries (what goes to IaaS, PaaS, SaaS, and what stays on-premise); data classification and cloud eligibility by data tier; network architecture and connectivity standards; identity and access management; encryption requirements in transit and at rest; resilience and recovery standards by workload criticality; and the interface standards that govern how cloud-hosted workloads interact with on-premise systems. Each of these areas has regulatory dimensions — BaFin's expectations on data classification, DORA's requirements on resilience, GDPR's constraints on data processing — that must be reflected in the principles themselves, not treated as an afterthought to be applied later.
"A cloud migration without established architecture principles is not a programme — it is a series of individual decisions that will need to be revisited, repeatedly, as their cumulative consequences become clear."
Lesson Two: Data Classification Is Non-Negotiable and Harder Than Expected
Not all data can go to the cloud, and the process of determining what can and cannot — and under what conditions — is invariably more complex and contentious than anticipated. In a regulated bank, data classification for cloud eligibility needs to address at least four dimensions: regulatory constraints (data subject to banking secrecy, customer data under GDPR, supervisory data); data sensitivity (confidential, internal, public); residency requirements (where the data must be processed and stored); and criticality (what happens to the business if this data is unavailable or compromised).
The process of classifying a mature bank's data estate typically surfaces two uncomfortable discoveries. First, that a substantial proportion of data has never been formally classified — it exists in systems, spreadsheets and file shares whose contents are partially unknown. Second, that systems long assumed to contain only non-sensitive operational data frequently contain customer-identifiable information that was accumulated over years without deliberate intent. Both discoveries require time and organisational effort to resolve, and neither can be shortcut by moving the classification exercise to run in parallel with migration.
Lesson Three: The Hyperscaler Relationship Is Not a Normal Vendor Relationship
The three major hyperscalers — Microsoft, Amazon and Google — operate on a fundamentally different commercial model from traditional IT vendors. Their standard contracts are not negotiable in the way that conventional enterprise software agreements are. Their service terms change periodically and unilaterally. Their pricing models are complex and can produce unexpected costs at scale. And their market position is such that the standard risk management approach of "if we can't get acceptable terms, we go to market" is, for most institutions, more theoretical than real.
BaFin has explicitly acknowledged this dynamic in its cloud guidance. The regulator does not expect banks to have negotiated bespoke terms with hyperscalers — it expects them to have assessed the residual risks of the standard terms and documented their risk acceptance. This is a meaningful distinction from the EBA's outsourcing guidelines, which imply that audit rights should be contractually secured. In practice, hyperscalers offer audit rights through third-party certification schemes (ISO 27001, SOC 2, C5) rather than direct institutional access — and BaFin has accepted this as a workable model, provided institutions understand what the certifications do and do not cover.
The most consistently underestimated aspect of hyperscaler relationships is sub-contracting transparency. DORA Article 28 requires that ICT third-party contracts allow institutions to identify and assess the risks from the sub-contracting chain. Hyperscalers operate on global infrastructure using numerous sub-contractors for physical facilities, network connectivity and specialist services. The sub-contracting lists maintained by the major providers run to dozens of entities across multiple jurisdictions. Mapping this against DORA's requirement for sub-contracting visibility — and then doing the same for each significant cloud service — is a material piece of work that most institutions have not yet completed to the standard that a supervisory review would require.
Lesson Four: Exit Strategy Is a Regulatory Requirement, Not a Planning Nicety
Both the EBA Outsourcing Guidelines and DORA require that institutions maintain a documented, tested exit strategy for each critical ICT outsourcing arrangement — including cloud. This means being able to demonstrate, credibly, how the institution would migrate workloads away from its cloud provider in a scenario where the provider became unavailable, commercially unacceptable, or subject to regulatory direction to exit.
For most institutions, an honest assessment of their exit strategy reveals a significant gap between what the documentation says and what would actually be possible. Exit from a hyperscaler for an institution that has spent three years migrating workloads to that platform, building on proprietary services and integrations, is a multi-year programme that would cost more than the original migration. That is not, in itself, a regulatory problem — regulators understand that exit is difficult and expensive. The problem arises when institutions have not assessed this honestly, have not tested whether exit is feasible within the timescales their continuity plans imply, and cannot demonstrate that the residual risk has been formally accepted at an appropriate governance level.
A practical approach is to design cloud architectures that minimise proprietary lock-in where doing so does not compromise functionality or economics — using containerised workloads, open standards for data formats and APIs, and avoiding deep integration with provider-specific services where equivalent functionality is available from portable alternatives. This is not always possible or desirable, but the extent to which an architecture is built on portable foundations should be a deliberate and documented architectural decision, not an accidental consequence of implementation choices.
Lesson Five: The Hybrid Interface Is Where Most Problems Live
The dominant model for cloud adoption in regulated banking is hybrid: some workloads in the cloud, others on-premise, with the two environments needing to communicate reliably, securely and with appropriate performance characteristics. In theory this is well-understood territory. In practice, the interface between cloud and on-premise environments — the network connectivity, the identity federation, the API gateway layer, the monitoring and observability stack that spans both — is where the majority of operational problems, security incidents and compliance gaps occur.
Private connectivity between the institution's on-premise environment and the cloud — Azure ExpressRoute, AWS Direct Connect or equivalent — is not optional in a regulated banking context. Public internet connectivity for production banking workloads is incompatible with both the security standards expected under BAIT and the resilience requirements of DORA. But private connectivity is itself a critical dependency that must be resilient: a single ExpressRoute circuit connecting the bank to its cloud environment is a single point of failure that must be addressed in the business continuity architecture.
The interface documentation challenge compounds this. A mature bank's IT estate will typically have hundreds of interfaces between systems — data feeds, API calls, batch file transfers, message queue integrations — many of which are inadequately documented, particularly for older systems. When workloads move to the cloud, every interface to the migrated workload must be reviewed, updated if necessary, and documented to the standard required by both BAIT and DORA's ICT asset management requirements. This is painstaking work. At the institution where I led cloud architecture development, documenting over 200 enterprise interfaces to the standard required for regulatory compliance was a programme of work in its own right.
Lesson Six: Governance Must Be Built for the Cloud Operating Model
Cloud introduces a fundamentally different technology operating model from on-premise. Infrastructure is provisioned on demand, through code, in seconds. Configuration changes can be made by developers without infrastructure team involvement. New services can be enabled at the click of a button by anyone with sufficient permissions. The governance models built for traditional on-premise environments — change advisory boards, formal infrastructure requests, quarterly capacity planning — are not adequate for cloud, and attempting to apply them unchanged will either slow cloud adoption to the point of irrelevance or create shadow IT as teams work around the controls.
Effective cloud governance in a regulated environment typically requires: a cloud governance framework that establishes guardrails (what cannot be done) rather than just processes (how to request things); policy-as-code that enforces regulatory requirements automatically rather than relying on manual review; clear ownership of cloud cost, security and compliance at team level; and a cloud centre of excellence that supports teams in using cloud effectively within the regulatory constraints. The key shift is from governance as a gate — a control point that approves or rejects — to governance as a set of constraints within which teams can move at cloud speed.
Seven Questions for Cloud Programme Leaders
- Have we established and formally approved the architecture principles that will govern the entire cloud migration before significant workloads are moved?
- Is our data classification framework complete, current and applied to all data that will be processed in the cloud — including data in SaaS platforms?
- Have we documented our cloud arrangements in the outsourcing register required under BAIT/MaRisk, and have we completed the risk assessments required under the EBA Outsourcing Guidelines and DORA?
- Have we reviewed our hyperscaler contracts against DORA Article 28 requirements and documented our risk acceptance for provisions that cannot be negotiated?
- Does our exit strategy for each cloud arrangement reflect a realistic assessment of what exit would actually require — in time, cost and resource — and has that assessment been formally accepted at board level?
- Is our private connectivity to the cloud environment resilient by design, and is it included in our DORA-compliant business continuity and disaster recovery plans?
- Have we mapped and documented all interfaces between cloud-hosted and on-premise systems to the standard required for regulatory compliance?
The Broader Point: Cloud Is Infrastructure, Not Transformation
There is a tendency in the industry to treat cloud migration as synonymous with digital transformation — as if moving workloads to the cloud is itself a strategic objective that delivers business value. It is not. Cloud is infrastructure. Moving a poorly-designed, poorly-governed application from an on-premise server to a cloud virtual machine produces a poorly-designed, poorly-governed application that now runs in the cloud. The costs are likely to be higher, the operational characteristics will be broadly similar, and the regulatory obligations will have increased.
The institutions that derive genuine value from cloud adoption — improved agility, faster time to market, better resilience, reduced infrastructure cost at scale — are those that use the cloud migration as an opportunity to redesign their application and data architectures, establish modern engineering practices, and build a technology operating model suited to the pace at which their business needs to move. That is a more ambitious undertaking than a migration programme. It requires sustained leadership commitment, genuine architectural vision, and the willingness to do the hard governance work before, rather than instead of, the visible migration activity.
In a regulated banking environment, it also requires that the technology function and the compliance function work together from the outset rather than sequentially. The compliance review at the end of a cloud programme that was designed without regulatory input is a source of expensive rework and delay. The compliance conversation at the beginning of architectural design is a source of requirements that shape what gets built. The difference between those two modes of engagement is, ultimately, the difference between a cloud programme that succeeds and one that stalls.