DORA Explained: From Paperwork to Proof 

DORA — the Digital Operational Resilience Act — has been fully in force since 17 January 2025, which makes it the rare regulation on this list that isn’t a “coming soon.” 2026 is the year enforcement gets real. Regulators are shifting from checking whether you filed the right paperwork to demanding live proof: automated reporting, demonstrable control over ICT risk, evidence that your systems can actually withstand disruption rather than a policy document that says they should. With reportedly only around half of in-scope firms fully compliant, this is the year supervisory letters start landing. 

One concrete deadline worth flagging: the Register of Information covering ICT third-party arrangements as of 31 December 2025 has staggered national deadlines — the Dutch AFM set 31 March 2026, Luxembourg’s CSSF portal opened 11 February 2026, and the consolidated European Supervisory Authority deadline is 30 April 2026. Incomplete or inconsistent registers have already been the single biggest trigger for supervisory follow-up in the first enforcement cycle. Separately, the European Commission owes a report by 17 January 2026 assessing whether DORA’s scope should expand — auditors and audit firms are explicitly on the table. 

What DORA actually requires

Strip away the acronym and DORA asks for five things: an ICT risk management framework that’s actually operational, not shelved; incident classification and reporting within tight timeframes; regular resilience testing, including threat-led penetration testing for larger entities; a comprehensive, accurate register of every critical ICT third party you depend on; and — for the providers deemed critical — direct oversight from EU supervisors. 

Where this becomes a build problem

The Register of Information sounds like a spreadsheet exercise until you try to populate it accurately across a real technology estate with cloud providers, sub-processors, SaaS tools, and inherited legacy dependencies nobody fully mapped. Getting it right requires the same discipline as good architecture documentation: a living, queryable inventory of dependencies, not a one-time export. Incident reporting deadlines mean your monitoring and alerting stack needs to produce a classifiable, timestamped incident record automatically — not something someone reconstructs by hand at 2am. And resilience testing means your CI/CD and infrastructure need to support controlled failure injection without taking down production. 

This is squarely where our DevOps and quality-assurance work overlaps with compliance. We’ve built CI/CD pipelines, monitoring, and access-control systems for clients operating under strict regulatory scrutiny for close to two decades, shipping continuously without treating security as an afterthought — DORA formalises a lot of what disciplined engineering teams were already doing, and penalises the ones that weren’t. Our senior teams work embedded, directly with yours, so nothing gets lost in a hand-off to a distant vendor when a supervisor asks a hard question. If your Register of Information is still a manually maintained document and your incident response still relies on institutional memory, that’s an architecture conversation worth having before your national supervisor’s next data call, not after. 

If DORA compliance at your organisation is still more paperwork than proof, that’s exactly the conversation we have every day. Get in touch with the Maxcode team and let’s scope out what it actually takes to build for it.