Financial Services

For workloads run by or for banks, insurers and other supervised financial entities in Germany, and the operators who build for them. The mountain is the same as for everyone; this page maps what the supervised route demands of it, and adds nothing.

The regulatory map

What binds here, and what each regime asks of an architecture.

DORA. The EU regulation on digital operational resilience for the financial sector, applied since January 2025 and supervised in Germany by BaFin . It is a resilience regime, not a residency regime: it asks whether critical functions survive ICT disruption, whether resilience is tested rather than assumed, and whether dependencies on ICT third parties are inventoried, contracted and exitable. That maps onto REL, SEC 11, OPS 9 and the exit half of SOV rather than onto placement.

The supervisory risk management frame. BaFin’s risk management supervision carries the German administrative practice, MaRisk and BAIT among it, including the outsourcing rules under which a cloud workload is a material outsourcing with notification, audit and exit obligations. The current circulars come from the compliance function.

The ICT third-party register. DORA requires a maintained register of information on all ICT third-party arrangements. For an architecture that means the processing chain must be known, current and reportable, which is SOV 6 asked by a supervisor instead of a customer.

Exit is a supervised property. Concentration risk and exit strategies for critical ICT providers are explicit supervisory topics. An exit plan that exists on paper only fails SOV 11, and here a supervisor asks the same question.

The tier default

Tier 2, sovereignty-preferred. No general statute forces a German bank’s workloads onto sovereign infrastructure, and DORA regulates resilience, not residency. What the criteria describe is elevated protection need and severe reputational and supervisory damage on compromise, which is Tier 2.

The tier is set per data set, SOV 1.3, and rises where the data does: data under banking secrecy in its strict reading, or data whose compelled disclosure to a foreign authority would itself be a reportable event, is a Tier 1 conversation. Deviations in either direction are recorded reasoning, SOV 1.2.

The pillar weighting

Three pillars shift; each shift traces to the map.

Reliability leads, and it is supervised. DORA’s subject is whether critical functions survive disruption within stated tolerances. That makes REL 1 and REL 2 regulatory artefacts (impact tolerances per critical function are targets per flow with an accountable owner), and it makes the testing questions, REL 9 and REL 10, duties rather than good practice.

Operational Excellence is elevated for incidents. Major ICT incidents are classified and reported on deadlines. OPS 9’s severity model, roles and timelines stop being internal conventions, and the telemetry in OPS 7 is what reconstructs an incident for a report.

Sovereignty & Compliance is elevated on its exit half. The register, the jurisdictional chain, portability and the tested exit plan (SOV 6, SOV 10, SOV 11) carry the concentration-risk and exit expectations. The residency half binds as Tier 2, per data set.

Security is elevated in the ordinary supervised way: the baseline is externally framed (SEC 1.1 reads DORA, MaRisk and BAIT), and detection with a rehearsed response (SEC 11) feeds the reporting duties. Performance Efficiency, Cost Optimization and Sustainability do not shift.

The statement core

What an assessment of a supervised financial workload accounts for regardless of where the conversation went: each of these ends evidenced or in the risk register.

Reliability

Swipe sideways to see the whole table

Statement	What makes it mandatory here
REL 1.1	Impact tolerances need the cost of disruption quantified, not estimated
REL 1.2	Tolerances are set per critical function, which is per flow, not per workload
REL 1.4	A supervised tolerance needs an accountable name against it
REL 2.1	The critical functions must be enumerated before anything can be tolerable
REL 2.2	Ranking by consequence of failure is the supervisory expectation stated as method
REL 3.2	A failure mode without a decided response is an untested tolerance
REL 9.2	The recovery sequence with a named invoker is what a resilience test exercises
REL 9.3	Rehearsed and timed against the tolerance, or the tolerance is fiction
REL 10.3	Testing digital resilience means injecting faults, not reviewing documents
REL 10.4	A failover that never ran does not count as tested anywhere, least of all here

Sovereignty & Compliance

Swipe sideways to see the whole table

Statement	What makes it mandatory here
SOV 6.1	The ICT third-party register demands a current inventory of the processing chain
SOV 6.3	Marketplace and sub-provider services are in the register or the register is wrong
SOV 8.1	DORA, MaRisk and BAIT apply differently per entity; which ones bind is step one
SOV 8.3	The responsibility split per control is what an outsourcing audit walks through
SOV 10.2	Portable data formats are the technical half of any credible exit
SOV 10.4	Concentration risk is priced per dependency and accepted explicitly, not discovered
SOV 11.1	The exit plan must be steps somebody could follow, because somebody may have to
SOV 11.2	Rehearsing the rehearsable parts is what separates a plan from a chapter
SOV 11.3	The exit timeline is what a supervisor compares against the contract’s notice period

Security and incidents

Swipe sideways to see the whole table

Statement	What makes it mandatory here
SEC 1.1	The baseline is externally framed: DORA, MaRisk, BAIT, and what the entity adds
SEC 11.1	Incident reconstruction needs records the incident cannot have altered
SEC 11.2	Detection tuned to compromise patterns is what makes deadlines meetable at all
SEC 11.3	The response, including who reports what to whom, is defined before the alert
SEC 11.4	The non-technical parts of response, reporting included, are rehearsed
OPS 7.1	Joinable telemetry is what turns an incident into a reportable account
OPS 9.1	Severity, roles and escalation mirror the regulatory classification and deadlines
OPS 9.4	Review actions tracked to completion are what a follow-up inspection asks for

Outside this page

Payments-specific regimes. Card payment workloads carry PCI DSS beside everything here; that is a contractual scheme regime with its own assessors and is not mapped here.

The compliance function’s territory. Which circulars apply to which entity class, notification thresholds and supervisory correspondence are legal questions. This page maps what the architecture must be able to evidence; it does not interpret the law.

Related

• Reliability: the pillar the supervision reads first
• Sovereignty & Compliance: the register and the exit