Every regime worth naming made the same move: from paperwork to proof.
There is a way to read the last decade of technology regulation as a dozen separate burdens, each with its own acronym, deadline and consultancy. Most firms read it that way, which is why most firms have a dozen separate programmes, a dozen separate spreadsheets, and one recurring panic.
There’s a better reading, and it’s also the true one.
Every regime that matters — DORA, the EU AI Act, NIS2, MiCA, the Cyber Resilience Act, APRA’s CPS 230, GDPR before them all — has made the same move in the same direction. Supervisors stopped accepting the policy document as evidence that you comply. They started asking you to demonstrate it: with current, dated, attributable proof, produced by your systems, available whenever they choose to look. The paperwork era is over. The proof era is here, and it does not care how good your intentions are.
Once you see that, the dozen burdens collapse into one problem stated a dozen ways. Can you prove it? Not do you have a policy. Can you produce the evidence, now, without assembling it by hand in the fortnight before an inspection.
Why this changes what you build, not just what you file
If regulation only asked you to have things, compliance would be a documentation exercise and you could outsource it to whoever writes the neatest policy. But it asks you to prove things, and proof lives in your systems, not your filing cabinet. That moves the regulatory question out of the legal function and into the architecture — because you cannot attest to something your data model cannot express.
This is the thread that runs under every page below. A regime is a specification for what your evidence layer has to produce. Read it that way and it stops being a cost centre and starts being a design brief. Read it the other way — as a form to fill in — and you will pass the audit on adrenaline every single time, until the year you don’t.
The regimes
Each of these deserves its own treatment, because the specifics matter and the deadlines are real. But notice, as you read across them, how much they rhyme.
DORA — operational resilience for EU financial entities. Critical functions, impact tolerances, ICT third-party risk, incident reporting on a clock. The template every other operational-resilience regime is now cut from.
The EU AI Act — risk-tiered obligations for AI systems. It doesn’t ask whether your model is fair; it asks for the record that shows how you’d know. The high-risk obligations are the ones that turn into engineering work.
NIS2 — cyber resilience for essential and important entities, with director accountability that has teeth in several member states. Entity obligations, as opposed to the CRA’s product obligations.
MiCA — the technology and custody obligations underneath crypto-asset service provision. Where digital-asset ambition meets a supervisor who wants evidence.
The Cyber Resilience Act — product obligations for anything with digital elements. Security-by-design as a legal requirement, an SBOM you can produce, and a reporting clock that starts 11 September 2026.
APRA CPS 230 — Australia’s operational-risk standard, live since July 2025. DORA-shaped, native English, and almost nobody credible is covering it properly. If you carry APRA obligations, start here.
The move that saves you a fortune
Here is the payoff of reading regulation as one shift rather than twelve. One control, evidenced many times.
Because the regimes rhyme, the control you build to satisfy DORA’s impact tolerances is substantially the control CPS 230 wants, attested against a different reference. The incident process that satisfies NIS2 overlaps heavily with the one DORA demands. The evidence layer you build once — if you build it deep enough to carry an obligation rather than shallow enough to pass a single audit — can produce the attestation for several regimes from the same source.
What you cannot do is run a separate programme per acronym. That way you pay for each one, reconcile them forever, and still can’t answer a cross-regime question. The firms that get regulation right build the model once, map each obligation to it, and generate the proof on demand. The firms that get it wrong buy a platform per regime and wonder why the spreadsheets keep multiplying.
That’s the whole argument, and it’s the reason the way I work leads with regulation and ends with the tool, rather than the other way around.
- You have a specific deadline. Pick the regime above.
- You want the underlying method. → How I work
- You want to know how ready you actually are. → Assessments