DORA Compliance Software Architecture: Contracts to Design Decisions
DORA compliance software architecture covering article 30 contract minimums, exit strategy design, audit access, resilience testing and requirements traceability borrowed from aerospace engineering.
13 min read
43 views
Key takeaways: DORA compliance software architecture 5
The article 30 contract split, exit strategy design, audit readiness, resilience testing and requirements traceability translated into architecture decisions.
- Article 30 splits into two tiers Article 30(2) sets minimum terms for every ICT contract. Article 30(3) adds audit rights, precise SLAs, exit strategies and testing participation, but only for services supporting a critical or important function, a separate classification from the provider-level criticality decision under article 31.
- An exit strategy is a capability, not a document A real exit strategy needs vendor abstraction, portable data formats and rehearsed export and restore drills, so time-to-replace is a measured number, scoped to critical or important functions rather than every vendor.
- Audit readiness replaces the spreadsheet register Immutable logs, environment segregation and a dependency inventory generated from build metadata turn the article 28(3) register and article 30(3) audit rights into a design property instead of a manual task.
- Resilience testing is a design constraint Fault-injection points, rehearsed backup restoration and a production-equivalent test environment need to exist before a scenario-based or threat-led penetration test can use them.
- Traceability turns obligations into evidence Borrowing aerospace requirements-traceability discipline maps each DORA obligation to an architecture decision, an automated check and an evidence artifact an auditor can inspect.
Most DORA compliance software architecture work stops with contract commentary and a vendor register, not a line of architecture. But large parts of the regulation, the third-party contract requirements, the exit-strategy obligation, the testing chapter and the register itself, are not paperwork exercises. They are requirements a system has to be built to satisfy, and someone has to translate the clause into a design decision. This article sets out DORA compliance software architecture for the architects and engineering leads who do that translation, not for readers who still need DORA explained from the ground up.
In short: DORA compliance is usually treated as a legal and GRC exercise, but its third-party and resilience articles read like architecture requirements once you translate the clause. A practical way to work through them is to treat each obligation the way aerospace engineering treats a requirement, traced to a specific design decision, enforced by an automated check where one is possible and backed by an evidence artifact an auditor can inspect. None of this replaces legal review, it is the engineering half of a compliance program that otherwise stops at a document.
Why DORA is an architecture problem, not just a legal one
If your team already knows what DORA is, who it applies to and what the five pillars cover, skip ahead. We cover that ground already in DORA for crypto firms, including scope and penalties. This article does not repeat any of it.
What it covers instead is the part that tends to fall between two professions. A lawyer reading DORA writes clause-by-clause commentary: what article 30(3) says, what "unrestricted access rights" probably means in a dispute. A GRC vendor reading the same regulation sells a register tool, a place to log every ICT contract and mark which ones support a critical or important function. Both are useful and neither one produces a system. Somewhere between the clause and the register sits a decision an architect has to make: where does this data live, how do we prove we can leave this vendor, what does our test environment need to look like for a threat-led penetration test. That gap is where this article sits, scoped to the parts of DORA that map most directly onto design decisions: articles 28 and 30 on third-party contracts, articles 24 to 26 on testing, article 12 on backups and articles 17 to 19 on incident management.
DORA article 30 requirements as design inputs
Article 30 sets two tiers of contract terms. Article 30(2) applies to every ICT service contract regardless of importance. Article 30(3) adds a further set of terms, but only where the service supports a function the entity has itself classified as critical or important. That classification is the entity's own call, and it is a separate exercise from article 31, where the European Supervisory Authorities designate certain ICT third-party providers as critical at the provider level across the whole financial sector. A vendor can be critical under article 31 without a specific contract triggering article 30(3), and a contract can trigger 30(3) with a vendor nobody would call critical under article 31.
Read as prose, article 30 is a checklist for a contract. Read as architecture, most of its clauses are a design input a legal team cannot satisfy on its own; something in the system has to be true for the clause to hold.
| Contract clause | Tier | What it means in architecture |
|---|---|---|
| Data processing and storage locations | 30(2), all contracts | Region pinning and residency tagging generated from infrastructure as code, not tracked by hand in a spreadsheet |
| Availability and service level descriptions | 30(2), all contracts | Availability described in the contract instrumented and measured against real telemetry, not just asserted in the text |
| Data access and return on termination or insolvency | 30(2), all contracts | A tested, repeatable data export pipeline, not a one-off migration built under pressure after the fact |
| Cooperation with competent authorities | 30(2), all contracts | Evidence-grade logging and audit trails that can be handed over without a manual reconstruction effort |
| Full SLA with precise performance targets | 30(3), critical or important functions | Precise performance targets watched by automated alerting on defined breach thresholds, with breach evidence retained for the regulator conversation |
| Unrestricted access, inspection and audit rights | 30(3), critical or important functions | Environment segregation and access controls that let an auditor in without exposing unrelated systems or secrets |
| Exit strategy with adequate transition period | 30(3), critical or important functions | Vendor abstraction at integration boundaries and a rehearsed, time-bound migration path, not a document |
| Participation in threat-led penetration testing | 30(3), critical or important functions | Interfaces and environments built so the provider can realistically take part in threat-led penetration testing |
None of this is exotic engineering. Region pinning, measured SLOs and tested export pipelines are practices most mature backend development teams already reach for on data-heavy systems. DORA just makes them a contractual obligation for anything touching a critical or important function.
Exit strategy is an architecture, not a document
Article 28(8) requires an exit strategy for ICT services supporting a critical or important function, and article 30(3) requires the contract to give that strategy an adequate transition period to work with. Most exit strategies that exist today are documents: a page describing which vendor would replace the current one and roughly how long that would take. A document like that answers an auditor's question, not the operational one, which is whether the migration it describes has ever actually happened.
A real exit capability tends to share a handful of properties. Vendor-specific logic sits behind an abstraction at the integration boundary, so swapping a provider is a configuration change rather than a rewrite. Data is stored and exported in portable formats rather than a provider's proprietary export. Export and restore are rehearsed on a schedule, not left untested until the day they are needed, and the replacement environment is reproducible from infrastructure as code rather than rebuilt by hand. Put those together and "time to replace this vendor" becomes a number measured on a drill, not a number estimated in a document.
This is not free: full portability across every ICT service would slow delivery on services that do not need it. The honest scope is the same one article 30(3) already draws: build real exit capability for the services that support a critical or important function, and accept a lighter, document-based exit note for everything else. Rehearsing an exit from a niche SaaS vendor and rehearsing one from a hyperscaler are different problems; for cloud-platform concentration, the honest posture is documented concentration-risk acceptance paired with portability for the most critical workloads, not a pretend full-exit plan for the whole estate.
Audit access and the register without spreadsheets
Article 30(3) gives the entity, and the relevant competent authorities, unrestricted rights to access, inspect and audit an ICT provider supporting a critical or important function. Article 28(3) separately requires a register of information covering every ICT third-party contractual arrangement, not just the critical ones. Many organizations still try to satisfy both with a spreadsheet someone updates when they remember to. Neither scales well, and neither produces the kind of evidence a supervisor is actually asking for. A common trap is signing 30(3) unrestricted audit-access terms that a provider's multi-tenant architecture cannot technically grant, a gap that tends to surface later as a renegotiation under supervisory pressure rather than at contract signing.
Audit readiness is a design property before it is a process. Immutable logs and retained decision records mean an auditor's question has an existing answer instead of a reconstruction project. Environment segregation means letting an auditor into the systems relevant to one provider does not also expose secrets or data belonging to something unrelated. A dependency inventory generated from build metadata, similar in spirit to an SBOM, can feed the article 28(3) register directly from what actually shipped, rather than from what a spreadsheet owner remembers to add. Access boundaries and audit logging of this kind sit squarely inside cybersecurity services work, and the article 28(3) register is best treated as a downstream export of that work rather than a separate manual task. That register and the exit plan behind it are only as good as visibility into the provider's own subcontractors; a sub-outsourcing chain means an SBOM-style inventory of your own estate does not reach fourth-party dependencies, so contract terms should oblige the provider to disclose material subcontractors directly.
Due diligence under article 28(4), the pre-contract check before onboarding a new provider, benefits from the same treatment: a repeatable technical checklist covering data location, access model, sub-processors and exit feasibility.
Resilience testing shapes the design
Article 24 requires a digital operational resilience testing programme and article 25 covers testing of ICT tools and systems including vulnerability assessments and scenario-based testing. Article 26 requires threat-led penetration testing at least every three years for entities in scope. Read together, they treat testability as something a system either has or does not, and a system that was not built with testing in mind is expensive to make testable after the fact.
In practice that means a few concrete design habits. Fault-injection points, ways to deliberately fail a dependency or a network path in a controlled environment, need to exist before a scenario-based test can use them. Backup restoration under article 12 deserves particular attention: a backup nobody has ever restored is a hope, not a control, and restoration drills belong on the same schedule as the backups themselves. A threat-led penetration test needs a production-equivalent environment the test team can reach without risking the live system, an infrastructure decision made well before the test is scheduled. Incident classification and reporting under articles 17 to 19 add a data requirement on top: meeting tight initial-notification windows set by the regulation and its technical standards depends on clock-accurate event data and evidence retained long enough to reconstruct what happened, a logging and retention design decision, not a policy document.
Data lineage and version-controlled data contracts
DORA does not name BCBS 239, the Basel risk-data aggregation principles, but the expectation behind both is similar: a regulated entity should answer "where does this number come from" with something more solid than institutional memory, and that is well served by practices already common in mature data engineering.
A schema registry or a set of data contracts held in version control gives every consumer of a dataset a versioned definition to check against, instead of a shared understanding that quietly drifts. Contract tests running in CI catch a breaking schema change before it reaches production rather than after an audit finds inconsistent numbers downstream. Lineage metadata generated as a build artifact, which pipeline produced this table, from which source, at which commit, turns a lineage question into something you can query instead of something you have to ask three teams about. That same versioned foundation pays off directly under DORA: reconstructing an incident under articles 17 to 19 depends on trustworthy, versioned data definitions of what actually happened, and the article 28(3) register is only as reliable as the data quality behind the entries feeding it.
The aerospace borrow: requirements traceability
Aerospace engineering has spent decades on a version of this exact problem: how do you prove, to a regulator who was not in the room, that a system satisfies every requirement it was supposed to satisfy. ECSS-style requirement-writing discipline insists on a controlled vocabulary and a rule that every requirement has to be independently verifiable, not just aspirational. NASA-style requirements verification practice pairs each requirement with a verification method, test, analysis, inspection or demonstration, and a matrix that traces one to the other. Neither is a regulatory obligation for a financial entity. Both are a well-tested way of working worth borrowing.
Applied to DORA, the same structure maps an obligation to a decision, a decision to an automated check, often a fitness function guarding that decision in CI, and a check to an artifact an auditor can look at. We cover the decision-record side of this, how to write and govern the ADR itself, separately in our guide to architecture decision records governance. What follows is a sample of how a traceability matrix built on that foundation might read for a handful of DORA obligations.
| DORA obligation | Architecture decision (ADR) | Automated verification | Evidence artifact |
|---|---|---|---|
| Article 30(3) exit strategy | Adopt a storage abstraction layer portable across cloud providers | Quarterly export-and-restore drill run in CI | Drill logs and a measured restore-time report |
| Article 26 threat-led penetration testing | Maintain a production-equivalent staging environment reachable by the test team | Automated parity check against production configuration | Parity report and TLPT scope document |
| Article 12 backup and restoration | Automate backup restoration as a scheduled job rather than a manual runbook | Scheduled restore-and-checksum job | Restore job logs retained for the audit window |
| Article 28(3) register of information | Generate the third-party register from build and deployment metadata | CI step that fails the build if a dependency lacks register metadata | Timestamped generated register export |
The matrix needs an owner and a refresh trigger of its own: review it when a contract changes, when an ADR is superseded and on the resilience testing programme's cadence, so it stays a live artifact rather than a one-time snapshot.
DORA architecture decision guide
Every entity's DORA architecture work starts from a different baseline. The situations below cover common starting points.
| Situation | Default posture |
|---|---|
| FinTech startup on a single cloud provider | Start the register and article 30(2) contract review now; defer full exit-strategy tooling until a function is classified as critical or important |
| One vendor supporting a critical or important function | Prioritize that contract for article 30(3) terms, audit access design and a real, rehearsed exit strategy before any other vendor |
| Multi-vendor estate across several critical functions | Standardize the traceability matrix and the register generation pipeline first, so each new vendor onboards into an existing pattern |
| Entity in TLPT scope | Invest early in a production-equivalent, safely isolated test environment; it is the long-lead item, not the test itself |
| Legacy estate with undocumented dependencies | Start with an SBOM-style dependency inventory before attempting the register or an exit strategy; you cannot classify or exit what you have not mapped |
None of these are rules. Use the table as a starting conversation with your architecture and compliance teams, not as a substitute for it.
How Pharos Production builds DORA-ready architecture
We build the engineering half of a DORA compliance program: region-pinned and residency-tagged infrastructure, measured SLOs, tested exit and data-export pipelines, audit-ready logging, environment segregation and resilience testing environments that hold up under a real or threat-led scenario. If your team needs a custom software development engagement to bring an existing estate into shape for article 30, that is the work we do.
Sources: Regulation (EU) 2022/2554 (DORA), guidance materials published by the European Supervisory Authorities (EBA, ESMA, EIOPA), the BCBS 239 risk-data aggregation principles and published aerospace engineering standards practice, including ECSS requirement-writing conventions and NASA systems-engineering requirements verification guidance. Presented as engineering guidance, not legal advice; confirm current obligations and classifications with qualified legal counsel.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 5
No matches
Try a different keyword, change the topic or clear filters
-
DORA treats third-party ICT contracts and operational resilience as more than paperwork. Article 30 sets minimum contract terms that only hold up if the architecture behind them is real, region pinning that matches the data-location clause, measured service levels instead of asserted ones, a tested data-export pipeline for termination and evidence-grade logging for cooperation with authorities.
Articles 24 to 26 add a testing program, including threat-led penetration testing, that requires the system to be built for testability in the first place.
-
Article 30(2) sets minimum contract terms for every ICT service: a description of the functions and services provided, the locations where data is processed and stored, availability and service level descriptions, data access and return on termination, notice periods, cooperation with competent authorities and termination rights. Article 30(3) adds further terms, but only for services that support a function the entity has classified as critical or important: full SLAs with precise performance targets, unrestricted audit and access rights, an exit strategy with an adequate transition period and participation in the entity's resilience testing.
-
Under article 28(8), an exit strategy is required for ICT services supporting a critical or important function, and article 30(3) requires the contract to give it an adequate transition period. A document describing a hypothetical replacement vendor satisfies the letter of that requirement but not the operational reality of it.
A working exit strategy is closer to a capability: vendor logic kept behind an abstraction layer, data stored in portable formats and export and restore rehearsed on a schedule, so the time it would take to actually leave a vendor is a measured number, not an estimate.
-
Articles 24 to 26 require a digital operational resilience testing programme: scenario-based testing, vulnerability testing and threat-led penetration testing at least every three years for entities in scope. That means testability has to be designed in rather than added later: fault-injection points for controlled failure testing and a production-equivalent environment the test team can safely reach, plus backup restoration under article 12 rehearsed on a schedule rather than assumed to work when it is finally needed.
-
For the fuller picture of scope, the five pillars and penalties, see our guide to DORA for crypto firms; in short, yes, crypto-asset service providers are in scope. What this article adds once that applies to you is the architecture side, translating article 30 contract terms, the exit-strategy obligation and the testing chapter into design decisions a CASP engineering team actually has to build, rather than restating the scope question.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
