DORA evidence without evidence theatre.
Why the packs are bloated
DORA went live in January 2025. The first wave of evidence packs we reviewed in the second half of that year had two consistent features. They were enormous, and almost none of the volume was for the auditor.
The pattern is familiar from earlier regimes (ISO, SOC 2, NIS2). A consultant arrives with a checklist. The team translates the checklist into PDFs. The PDFs reference Confluence pages. The Confluence pages reference Jira tickets that no one updates. By the time the auditor opens the pack, every artefact is downstream of three other artefacts and none of them are alive.
The auditor is not impressed by volume. The auditor is looking for four things.
What the auditor actually wants
One: a list of your critical or important functions, and the ICT services that support them. Two: evidence that you can recover those services within the recovery objectives you wrote down. Three: evidence that you exercised those recoveries against scenarios. Four: a register of your ICT third-party providers, with their criticality and your dependency on them.
Each of these can be produced from the platform itself, on a schedule, without a human transcribing anything. That is the whole game.
Evidence as code, not evidence as PDF
The pattern we run now is the same regardless of cloud or sector. The list of critical functions lives in the service catalogue (Backstage or equivalent). The recovery objectives are SLOs in the same place. The evidence that recoveries happen comes from the same telemetry that runs the platform: CloudTrail or Azure Activity for control-plane actions, OpenTelemetry traces for the recovery itself, ChatOps logs for who pressed the button.
The exercise log is a stored output of game days. We run game days as code. The scenario, the steps, the success criteria and the outcome live in the same repo as the runbook the alert links to.
The third-party register is a YAML file under version control. Every supplier carries a criticality tag, a contract reference, an exit plan reference, and a renewal date. The auditor reads the YAML directly. We have yet to meet an auditor who objected.
"The auditor is not impressed by volume. The auditor is looking for four things."
Maikel Vlasman / Cloud Architect
What changes for the platform team
Three things change in the operating model. One: SLOs become real. If the recovery objective in the DORA pack does not match the SLO the on-call holds itself to, the auditor will see the gap. We surface both in the same dashboard.
Two: every change to the third-party register goes through a PR. Procurement still owns the relationship; the platform team owns the artefact. This eliminates the annual scramble to reconcile what supply-chain people thought we used.
Three: game days are scheduled, not heroic. One game day per critical service per quarter, scenario chosen from a written catalogue, outcome logged. The auditor sees twelve months of evidence on the day they arrive.
What does not change
The threat-led penetration testing (TLPT) requirement stays manual. The exit plans for critical providers stay narrative documents. The board reporting cycle stays where it was. We are not trying to automate everything in DORA; we are trying to automate the boring 70 percent so the team has time for the 30 percent that needs judgement.
The principle is the same one we apply to everything: if it can be generated from the platform, it should be. If a human is transcribing it once a year, it is debt.