Recorded, Tested, Approved, Verified: DORA Compliance Grounded in Truth
Miguel Martinez
Since January 2025, every financial entity operating in the EU has been subject to the Digital Operational Resilience Act (DORA). The grace period is over: supervisors have moved from reviewing paperwork to demanding proof.
Most DORA programs start with the visible workstreams: incident reporting, resilience testing, the third-party register. All of them matter. But they share a dependency that gets far less attention: the integrity of the software delivery lifecycle itself.
This post is about the first pillar, ICT risk management, and the question underneath it: how do you know that what you have in production is what you intended to have?
The risk, in DORA’s own words
RTS (EU) 2024/1774, Article 16(1)(c) requires measures to mitigate “the risk of unintentional alteration or intentional manipulation of the ICT systems during the development, maintenance, and deployment… in the production environment.”
DORA (EU) 2022/2554, Article 9(4)(e) requires that all changes are “recorded, tested, assessed, approved, implemented and verified in a controlled manner.”
That is a chain of custody, written in regulatory language. It is the same foundation SLSA, NIST SSDF, and the Cyber Resilience Act rest on: prove how your software was built, checked, and approved. DORA is not exempt from it.
Why this is foundational
If code can change outside that control, through tampering or by skipping process under pressure, every other DORA control inherits the blind spot. Incident response assumes you know what code is running. Recovery assumes the restore target is trustworthy. Change approval assumes the deployed system is the one that was reviewed. Vulnerability management assumes the inventory matches production. Uncontrolled change doesn’t add one more risk to the list; it invalidates the premise the rest are built on.
The Trivy and LiteLLM attacks showed how this plays out: production running code nobody intended, and nothing in the delivery process noticing.
The chain of custody
Each stage below is a point where “what’s running” can drift from “what was intended”. Evidence at each stage is what proves the drift didn’t happen, or surfaces it when it did.
| Chain-of-custody stage | DORA/RTS anchor | Evidence | How Chainloop covers it |
|---|---|---|---|
| Intent is defined and approved (the baseline) | RTS 16(1)(b) | Requirements doc, threat model, asset owner sign-off | Evidence attached manually to the attestation |
| Development matches intent | RTS 16(1)(a), 16(3) | Source review, SAST/SCA findings, PR approval | PR approval checks plus SAST/SCA policy evaluation |
| Build faithfully reflects reviewed source | RTS 16(1)(c) | Provenance, artifact-to-commit binding | Signed attestation binding artifact to source (SLSA, in-toto) |
| Artifact verified before promotion | RTS 16(2)-(4) | Test results, coverage, criticality-scaled release gate | Automated policy gate over attested test and coverage evidence |
| Known deficiencies don’t silently ship | RTS Art. 10, DORA 9(4)(f) | SBOM, vulnerability scan, VEX, remediation evidence | SBOM, vulnerability, and VEX evidence with policy checks |
| Every deviation from baseline is authorized | RTS Art. 17, DORA 9(4)(e) | Change record, approver identity, rollback plan | Adapts to your approval model (see below) |
| Third-party and OSS code also matches intent | RTS 16(8) | Component provenance, SCA, signature verification | SCA, component provenance, and signature verification policies |
| What’s deployed matches what was verified | RTS 16(1)(c) | Deployment record, digest match prod-to-attestation | Deployment record matching artifact digest to attestation |
Where Chainloop fits
Chainloop is an SDLC governance platform: it collects tamper-proof evidence from the tools you already use, evaluates policies against it, and gates releases on the result. SLSA and NIST SSDF are expressed on top of that foundation; DORA maps onto it the same way.
- Agreed upfront. Contracts declare, per project, what evidence a release requires, as code, independent of your CI/CD system.
- Signed and locked. Every piece of evidence is cryptographically bound to the artifact it came from (in-toto, Sigstore, SLSA). The auditor’s answer is a verifiable attestation, not a screenshot collection.
- Evaluated automatically. Policy verdicts are computed at attestation time and stored in the same signed record.
- Enforced at release. A failed policy blocks promotion to production. Approval becomes an enforced step, not a report read after the fact.
Approval models differ: some organizations pre-approve plans, some review every candidate, some auto-approve low-risk changes by policy. Chainloop doesn’t impose one; the evidence and gates wrap around the workflow you already run.
As one senior executive vice president of platform engineering at a large Asian bank put it: “Audits that once took weeks or months are now completed in just hours.”
Closing
DORA describes something most organizations have never built: a continuous, verifiable chain of custody from intent to production. A policy document can say changes are controlled. Evidence shows that each specific change was. Producing it takes the same SDLC governance foundation that serves every other framework. DORA is not a special case.
If you’re mapping DORA’s Article 9 and RTS Article 16 requirements to your delivery pipeline, reach out.
