DORA ·

By Arya Soni

BaFin cloud outsourcing expectations and DORA on AWS, Azure and GCP

For financial entities supervised in Germany, cloud outsourcing sits at the intersection of long-standing BaFin guidance on IT outsourcing (including the cloud-specific expectations in BAIT and the outsourcing circulars) and the EU Digital Operational Resilience Act - Regulation (EU) 2022/2554 - which has applied since 17 January 2025. DORA's third-party pillar (Articles 28-30) is where cloud teams feel the weight: a register of information, concentration-risk assessment and mandatory contract content for arrangements supporting critical or important functions. Legal counsel and compliance own regulatory interpretation and contractual sign-off; engineering owns whether the estate, the register and the operational evidence match what was declared.

Share

LinkedIn

BaFin's lens: outsourcing, not just 'using AWS'

BaFin has treated material IT and cloud outsourcing as a supervisory topic for years: advance notification or approval for material arrangements, documented risk analysis, exit planning and audit access are recurring themes in BaFin communications and in the Banking Supervisory Requirements for IT (BAIT), which apply to institutions under BaFin supervision.

Using a hyperscaler is not exempt because the provider is large. What matters is whether the arrangement is outsourcing of a function or resource that is material to orderly operations - and whether governance, documentation and controls match that materiality. A production landing zone on AWS, Azure or GCP with customer-facing payment flows will almost always be material; the question is how you demonstrate oversight, not whether you file a form.

DORA Article 28: register of information

Article 28(3) requires financial entities to maintain a register of information on all contractual arrangements with ICT third-party service providers. The register must cover the provider, the functions supported, data processed, locations, subcontracting chains where relevant, and the classification of whether the function is critical or important - with content specified further in the regulatory technical standards (Commission Delegated Regulation (EU) 2024/1773).

For cloud teams the register is only as good as the inventory behind it: every production account, subscription or project tied to a regulated service line, linked to the enterprise agreement or order form, with an owner who can answer update requests. A spreadsheet that lists 'AWS' once is not a register; neither is a CSPM asset export with no contract mapping.

Articles 29-30: concentration risk and contract clauses

Article 29 requires assessment of concentration risk where reliance on a single ICT third-party provider or a small number of them could impair resilience. Single-cloud is a valid strategy; undocumented dependency on one region, one organisation root and one support plan without an exit narrative is what supervisors challenge.

Article 30 lists minimum contractual provisions for arrangements supporting critical or important functions: full descriptions of services and SLAs, locations of data and processing, assistance with incidents and audits, participation in resilience testing, termination and exit rights, and subprocessors subject to flow-down obligations. Hyperscalers publish financial-services addenda (for example AWS's ESA framework components, Microsoft FS Addendum, Google Cloud financial services terms) that address many clauses - but they must be executed, archived and referenced in the register, not assumed from a standard online agreement.

What cloud engineering must be able to show

Supervisory and internal audit reviews increasingly ask for artefacts that live in engineering systems, not only in legal folders:

  • Architecture and data-flow diagrams that match production: regions, encryption, identity federation, logging destinations.
  • Evidence that audit and access rights in Article 30 are operationalised - who can pull CloudTrail, activity logs or Azure Monitor exports for a review window.
  • Incident and resilience testing records linked to critical functions hosted on the cloud.
  • Exit strategy mechanics at the technical level: backups, IaC portability, RTO/RPO assumptions - even if full multi-cloud exit is not the business plan.

Roles: legal sign-off vs engineered evidence

Contract negotiation, regulatory notifications to BaFin where required, and formal classification of functions as critical or important under DORA belong with legal, compliance and the management body - not with a platform team acting alone.

Stratoworks sits on the engineering side of that boundary: landing zones, guardrails, logging, backup/restore testing, register-ready inventory exports and the technical annexes that legal teams need to attach to outsourcing files. We do not provide legal advice or sign filings; we make it harder for the technical story to contradict the regulatory one.

A sensible 90-day engineering track (parallel to legal)

While counsel progresses addenda and notifications, cloud teams can advance evidence that supports both BaFin outsourcing files and DORA reviews:

  • Weeks 1-3: complete ICT provider inventory (IaaS, PaaS, SaaS touching production), map to business services, draft register rows.
  • Weeks 4-6: gap-check executed contracts against Article 30 themes; flag missing FS addenda or undefined subprocessors to legal.
  • Weeks 7-9: centralise logging and backup/restore test evidence for critical workloads; document regions and encryption defaults.
  • Weeks 10-12: run one tabletop linking a cloud outage scenario to incident reporting duties (Articles 17-23) and update the register with any changes.

DORA readiness for financial entities

FAQ

Does DORA replace BaFin outsourcing rules for German banks?

DORA is EU law with direct effect; national outsourcing requirements remain relevant where they do not conflict. In practice you align the register, contracts and governance to DORA while keeping BaFin notification and documentation expectations in view. Specific obligations depend on entity type and materiality - legal counsel should confirm.

Is a standard hyperscaler click-through agreement enough for Article 30?

Usually not for critical or important functions. Regulators expect the financial-services contract packages and documented SLAs, incident cooperation and audit/access terms. The addendum must be in force for the accounts that support regulated services.

Who should own the DORA register day to day?

Accountability often sits with ICT risk or third-party risk management, but maintenance requires input from cloud platform owners, application teams and procurement. Engineering should not own legal classifications - but must supply accurate technical data or the register will drift within one release cycle.