Regulation defines what you must prove. Not what you must have — what you must demonstrate. That single distinction is the whole of this page, and almost every technology estate I am called into was built as though it doesn’t exist.
Most organisations still read regulation as a documentation requirement: write the policy, file it, produce it if asked. That reading was defensible a decade ago. It is not defensible now, because supervisors across nearly every regime that matters have made the same structural move in the same few years — from checking that a policy exists to demanding evidence that the control it describes actually ran, recently, and can be shown on request.
The shift, sector by sector
Look at the pattern across the regulations I write about most. DORA does not ask a financial entity whether it has an operational-resilience framework; it asks the entity to produce the register, the test results, the incident chain, on a timeline measured in hours. APRA’s CPS 230 is, in its own regulator’s language, a standard built around resilience rather than documentation — I have written about it at length as a proof standard wearing a policy standard’s clothes. The Cyber Resilience Act’s Article 14 does not care whether you have a vulnerability policy; it gives you 24 hours to report an exploited flaw, whether or not you were ready. NIS2 makes the point personally: essential entities face proactive, unannounced audits, and a management body that cannot show its measures work can be individually sanctioned.
None of these regimes are unusually strict by historical standards. What has changed is the object of scrutiny. It used to be the policy. It is now the evidence that the policy is real.
Why this reorders the whole decision
If proof is the actual requirement, then the first question in any technology decision cannot be which platform. It has to be what must we be able to demonstrate, to whom, and on what notice — because that question determines what the system underneath has to be capable of producing. Get the order backwards, and you buy a platform first, discover months later what it cannot tell a regulator, and spend the weeks before an audit assembling the answer by hand from spreadsheets and institutional memory. That fire drill is not evidence. It is a symptom that the model was never built to carry the obligation in the first place.
Regulation-driven, in the way I mean it, is not a compliance posture. It is a sequencing rule: let the obligation define the shape of the evidence before a single tool gets chosen. Everything downstream — the data model, the system architecture, eventually the vendor — inherits from that starting point rather than being retrofitted to serve it.
What this looks like in practice
It means the first working session on any engagement is not a platform shortlist. It is a plain accounting of what an external party — a regulator, an auditor, an acquirer, an insurer — is entitled to ask, and whether the current estate could answer without a scramble. Most organisations have never done this exercise in the open, because it is uncomfortable: it tends to surface that several expensive systems cannot answer the one question they were quietly assumed to cover.
It also means being specific about which regulation is doing the defining, because the obligation differs by regime even where the language sounds similar. “Prove resilience” means something different under DORA than under CPS 230 than under NIS2, and a model built to satisfy one loosely will not automatically satisfy the others precisely — though, built deliberately, a single well-designed control can often answer more than one. That convergence is the subject of the evidence and assurance model that sits underneath this page.
Once the obligation is named precisely, the next question is what the data has to carry to answer it — which is the second link in the chain, and the subject of the data-first page. The tool comes last, once the model is right, which is the third link, covered on the platform-agnostic page.
A concrete case
Take a CASP registered under MiCA. The regulation-first question is not “what custody platform should we run” — it’s “what must we be able to show a regulator about a client’s assets, on request, and how current does that answer need to be.” MiCA’s own answer is specific: safeguarding of client funds and instruments, conflict-of-interest records, and transaction records that a supervisor can request and expect promptly. Only once that answer is pinned down does the custody or ledger question become answerable, because now there’s a test to select against, rather than a feature list to be impressed by. Firms that reverse the order end up custody-platform-rich and evidence-poor: perfectly capable systems that were never asked the regulator’s actual question, and therefore can’t quite answer it without a manual reconciliation exercise that should never have been necessary.
See how the full chain fits together on How I Work, or go straight to the regulations that are likely defining your obligations right now.