Every modern regulation asks the same question in a different accent. Not “do you have a policy,” but “can you prove it” — on demand, traced to source, signed by someone who is accountable. This is the model that answers that question, and the reason most control environments cannot.
DORA, NIS2, the Cyber Resilience Act, CPS 230 in Australia, the EU AI Act — read them side by side and the surface detail differs but the demand underneath is identical. Each has moved the standard from the existence of a control to the effectiveness of a control, evidenced continuously. Supervisors no longer accept that a policy describes what happens. They want to see the thing itself, and they want to see it fast.
Most organisations fail that demand not because their controls are weak, but because nothing connects the control to the obligation it satisfies or the record that proves it ran. The evidence exists somewhere; it just cannot be produced in the shape and time a regulator asks for. That is an architecture problem, and it has a structure.
The chain, link by link
A defensible evidence model is a chain that runs in one direction, from the law to the artefact you can hand over.
Reference. The specific provision — an article, a standard, a clause — not “DORA” in the abstract but Article 28(3), not “CPS 230” but the tolerance-level requirement. Vague references produce vague evidence.
Obligation. What that provision actually requires you to do, stated as a testable duty rather than a paraphrase. “Maintain a register of ICT third-party arrangements, complete and current, submittable on request” is an obligation. “Manage third-party risk” is a mood.
Interpretation. How the obligation applies to your business — which systems, which providers, which thresholds. This is the link most firms skip, and skipping it is why generic control libraries do not survive a real review.
Supervisory expectation. What “good” looks like to the authority that will actually examine you, drawn from their guidance, their findings, their prior enforcement. The same clause is examined differently by different regulators; the expectation is where that lives.
Evidence. The record that the control operated — a log, an approval, a test result, a timestamped decision. Evidence is not the policy that says the control should operate. It is proof that it did.
Test. The check that the evidence is real and current — the tabletop that proves the four-hour recovery objective is achievable, the reconciliation that proves the register matches the contract inventory. Untested evidence is an assertion.
Attestation. A named person, with the authority to be wrong, signing that the chain holds. Accountability that cannot be delegated into a committee is what turns a pile of records into assurance.
Where the chain breaks
It almost always breaks in the same place: between interpretation and evidence. A firm has controls and it has policies, but nothing maps a specific control to a specific obligation and forward to a specific record. So when a supervisor names one operation, the answer requires a fire drill — people, spreadsheets, and best recollection — instead of a query. The fire drill is the finding.
Fixing it is not a documentation exercise. It is a data model: obligations, controls, evidence, and owners held as related records rather than as prose scattered across a policy library. Once that model exists, proof becomes retrieval. That is the whole point of the way I approach technology leadership — data first, because everything a regulator asks for is a question about your data.
A worked example
Take one obligation and run the chain. The reference is DORA Article 28(3). The obligation is to maintain a register of ICT third-party arrangements that is complete, current, and submittable to your competent authority on request. The interpretation names your actual providers, tags which of them support critical or important functions, and sets the criticality thresholds you will defend. The supervisory expectation, learned from the first reporting cycle, is that the register reconciles to your contract inventory and to what the provider itself reports — inconsistencies are flagged automatically. The evidence is the register export itself, plus the change log showing it is maintained continuously rather than assembled the night before. The test is a reconciliation against procurement’s contract list and a spot-check of legal entity identifiers. The attestation is the named owner who signs that the register is true as at a date.
Skip any one link and the chain fails in a predictable way. Skip interpretation and your register is generic and wrong at the edges. Skip the test and you submit data that a supervisor’s automated cross-check breaks. Skip attestation and no one is accountable when it does. The model is only as strong as its weakest link, which is exactly why it has to be built as a structure rather than assembled per-audit.
One control, many regimes
The prize at the end of the chain is convergence. Because the underlying demands overlap heavily — incident detection, third-party oversight, continuity, access control appear in nearly every regime — a control mapped properly to obligations can satisfy several regulators from one implementation and one body of evidence. That is the ambition, and it is worth being honest about it: the mapping has to be built deliberately before a single control can be shown to answer, say, both DORA and NIS2. Done well, it turns duplicated compliance programmes into one. Done carelessly, it produces evidence that satisfies no one.
This model sits underneath the specific regulatory readings on this site — CPS 230, the Cyber Resilience Act, and the rest of the regulations library — and underneath the wider technology control framework. Each of those is a particular case of the same chain.
If your controls are sound but you could not produce the proof on a supervisor’s timeline, the gap is the model, not the controls. That is the conversation to have.