For a CTO at an EU financial firm, DORA changes architecture in four places: how dependent you are on a single ICT provider, whether you can leave one, how you test resilience, and whether you can produce incident facts fast. These are design decisions, not paperwork.
Why is DORA an architecture issue?
The regulation applies since 17 January 2025 and covers ICT risk management, third-party risk, resilience testing and incident reporting. The recitals explain the worry: financial services depend heavily on technology companies, and a failure at one provider can spread across firms and borders. A policy cannot fix a design where one vendor is a single point of failure.
Where is your concentration?
Draw the dependency map for each critical function: payments, trading, customer login, claims. Mark the provider, the region, the identity system and the build pipeline it relies on. Constructed example: payments run on provider A, but the identity service they authenticate against sits at provider B, and both deploy through the same hosted CI service. That is three providers and one shared pipeline, and the pipeline is the part nobody listed.
The regulation expects the firm to assess this risk before signing and during the contract. Your job is to give the risk team a map that is true, not a map that is tidy.
Can you actually exit?
DORA's third-party rules cover key contractual provisions and exit strategies for ICT services that support important functions. An exit plan on paper is cheap. A tested one is expensive.
Decide a level per function.
- Stressed exit: you can move within a defined time with data exported in a documented format.
- Partial substitution: a second provider can carry core traffic.
- Accept and document: you cannot exit in a reasonable time, and the board has signed off the residual risk.
The third option is legitimate when it is explicit. It is a problem when it is accidental.
How much testing is enough?
EIOPA describes testing under DORA as basic and advanced. Basic testing is for every in scope firm and covers things like vulnerability assessments, scenario tests and source code reviews. Advanced testing applies only to some entities, so confirm with your supervisor whether you are one of them. Plan test environments that look like production, because a test that cannot fail the real thing proves little.
Can you answer incident questions in hours?
Incident reporting under DORA is detailed, and the technical standards define content and deadlines. Whatever the current numbers are, the architecture question is the same: can you answer what broke, which customers were affected, how long, and whether data was lost, from logs and inventories you already have? If answering needs three teams and two weeks of archaeology, add telemetry and an asset inventory before the next incident.
Your application layer counts here too. Knowing which services run which open source packages lets you say within minutes whether a newly published flaw touches you. Safeguard provides SBOM and dependency scanning with reachability analysis to help with that specific question.
What to do
- Map every critical function to its providers, regions, identity and build dependencies.
- Pick an exit level per function and write it down with an owner.
- Test one exit path or failover for the most critical function this year.
- Verify that logs and inventories can answer the four incident questions.
- Confirm with your supervisor which testing tier applies to you.
- Report residual concentration risk to the management body in plain terms.
Quick check
Does DORA ban using one cloud provider?
No. It requires you to assess and manage concentration and have exit strategies, not to avoid a provider.
Who is accountable for DORA compliance inside the firm?
The regulation places responsibility for the ICT risk framework on the management body. The CTO usually owns delivery, but accountability sits above.
Sources
Last reviewed: 18 October 2026.
