The Digital Operational Resilience Act took full effect on 17 January 2025. A year in, the firms that got their first round of audit findings are sorting into two piles.
Pile A: firms that built a DORA spreadsheet. Pile B: firms that rewrote how ICT decisions get made. The first pile is losing.
What DORA actually requires (without the legal hedge)
DORA is five things stapled together:
- ICT risk management framework. Board-level, not buried under a CISO.
- Incident classification + reporting. Major incidents reported to the competent authority within strict windows.
- Digital operational resilience testing. Threat-led penetration tests, recoverability tests, not just tabletop exercises.
- ICT third-party risk. A maintained register of ALL ICT third parties, plus subcontracting chains, plus exit strategies.
- Information and intelligence sharing. Voluntary in spec, expected in practice.
The legal text is 64 articles. The architectural change is shorter: every ICT decision that touches a critical or important function now generates an audit-grade evidence trail.
Where firms in pile A are going wrong
The pattern is almost identical across the firms I’ve audited.
Mistake one: register-as-spreadsheet. The ICT third-party register lives in Excel, maintained by procurement, reconciled quarterly. By the time the auditor asks for the list of subprocessors under a specific SaaS vendor, the spreadsheet is six weeks stale and nobody can attest it’s complete.
Mistake two: incident reporting as paperwork. Major incident windows are tight. A firm that classifies, reports, and roots-causes through a ticket-then-email-then-PDF flow misses the timeline.
Mistake three: testing as theatre. Threat-led penetration testing means an actual external red team simulating realistic threat actors against production-like systems. Not a vendor demo with the firewall in audit mode.
What pile B actually built
The firms whose first audit came back clean built three architectural patterns:
One: register-as-data-pipeline. Every contract, vendor, and subprocessor relationship is a row in a system of record. Procurement updates it. Procurement signing a renewal triggers a workflow that asks “is this critical or important?” If yes, the contract template auto-enforces the exit strategy clauses. The audit trail is the database log.
Two: incident workflow with hard timers. Sev-1 classified incidents start a clock visible on a status page the regulator can subscribe to. The escalation tree, the comms templates, the regulator-facing report draft, all auto-populated. The CISO approves; the bot files.
Three: resilience testing as a continuous integration test. Recoverability checks run against production-like environments on a schedule. Threat-led tests are scoped quarterly, scoped to actual customer-impacting flows, scoped against an ATT&CK threat profile that reflects your sector.
The shape of an architecture mandate
You can tell which pile a firm is in by asking one question: “Show me how a change to a critical-function dependency propagates through your register, your impact assessment, and your exit strategy.”
Pile A says “we’d run the change advisory board, then update the register at month-end.”
Pile B says “here’s the pull request that triggered the impact assessment; here’s the auto-generated regulator notification draft; here’s the link to the updated exit strategy in the runbook.”
DORA isn’t asking who signed the policy. It’s asking whether the policy is executable.
What this looks like in practice
The migration from pile A to pile B isn’t a tooling exercise. It’s a redesign of how ICT decisions get logged.
The questions to ask your team this quarter:
- Where does the ICT third-party register live? Is it queryable by your auditor’s API team?
- When was the last time a contract renewal triggered an exit-strategy review automatically?
- Can you produce a major-incident report draft within the reporting window without manual escalation?
- Does your resilience testing run on a cadence, or only when the auditor’s date is on the calendar?
If three of those answers are “no”, you’re in pile A.
The data shape that survives audit
The single most useful artifact a financial entity can build before the next supervisory dialogue is a relational schema for the ICT third-party register. The table reads like this:
| Field | Source | Refreshed |
|---|---|---|
| Contract ID | Procurement system of record | On contract create / amend |
| Counterparty legal name | Procurement | On signature |
| Function supported | Business architecture | On onboarding |
| Critical or important? | Business impact assessment workflow | On reclassification |
| Subprocessors disclosed | Vendor questionnaire response | At least annual |
| Exit strategy clauses | Contract template + signed addenda | On signature, on amendment |
| Last operational test | Resilience test scheduler | On test run |
| Last incident | Incident workflow | On incident closure |
Every cell in the table is a query. Every change to a cell is a log entry. When an auditor asks “show me your view of subprocessing relationships for critical functions as of last quarter end,” the answer is a SQL query, not a meeting.
The reporting windows that matter
Article 19 reporting cadence is where most pile A firms fall over. The deadlines are tight and they’re measured from the moment of classification, not the moment of detection. The competent authority expects an initial notification within hours, an intermediate report within days, and a final report once the incident is resolved.
The architectural implication: classification and notification are the same workflow. A sev-1 ticket that’s marked “major incident, DORA Article 19” should auto-generate the regulator notification draft as part of the ticket transition, not as a downstream paperwork step. Treat the regulator as a stakeholder subscribed to your incident channel, and the windows take care of themselves.
What architects build that compliance teams don’t
A compliance team can write the policy. An architect’s job is to make the policy executable in the systems the firm already runs.
The handful of patterns that come up in every DORA review:
- Service registry → critical-function map. The list of microservices, with the business function each one supports, with the criticality classification. Without this, no DORA decision is computable.
- Identity-aware audit trail. Every administrative action against ICT systems carries an authenticated identity and a reason. Without this, the regulator’s “who changed this?” question gets the wrong answer.
- Vendor-API-shaped onboarding. New SaaS gets onboarded through an API call that captures contract data, subprocessor disclosure, criticality classification, and registers the relationship in the register-of-record. Without this, the register lags procurement by weeks.
- Resilience test schedule that touches production-like paths. Recoverability tests that don’t exercise the actual prod-like flows pass for the wrong reason.
None of those four patterns are new. They’re patterns most firms have started but not finished. DORA is the deadline that’s forcing the finishing work.
The good news: the architecture rewrite is smaller than it looks. It’s a register-of-record, an incident workflow with a timer, a recoverability test that actually runs, and an identity-aware audit trail. The bad news: each of those needs to exist by the time your next supervisory dialogue lands.
About the author
Bimal Jeet Kaur
Strategic Advisor, GRC & Cyber Security · ex-KPMG, Deloitte, PwC
Senior architect at BluOryn. Writes about real engagements, not vendor slides. See the team.