DORA isn't a compliance checklist. It's an architecture mandate.

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:

1. ICT risk management framework — board-level, not buried under a CISO.
2. Incident classification + reporting — major incidents reported to the competent authority within strict windows.
3. Digital operational resilience testing — threat-led penetration tests, recoverability tests, not just tabletop exercises.
4. ICT third-party risk — a maintained register of ALL ICT third parties, plus subcontracting chains, plus exit strategies.
5. 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 good news: the architecture rewrite is smaller than it looks. It’s a register-of-record, an incident workflow with a timer, and a recoverability test that actually runs. The bad news: each of those three needs to exist by the time your next supervisory dialogue lands.