DORA-evidence zonder evidence-theater.
Waarom de packs zijn opgeblazen
DORA ging live in januari 2025. De eerste golf evidence-packs die we in de tweede helft van dat jaar reviewden had twee constanten. Ze waren enorm, en bijna niets van het volume was voor de auditor.
Het patroon kennen we van eerdere regimes (ISO, SOC 2, NIS2). Een consultant komt met een checklist. Het team vertaalt de checklist naar PDF's. De PDF's verwijzen naar Confluence-pagina's. De Confluence-pagina's verwijzen naar Jira-tickets die niemand bijwerkt. Tegen de tijd dat de auditor het pack opent, is elk artefact downstream van drie andere artefacten en is geen ervan levend.
De auditor is niet onder de indruk van volume. De auditor zoekt vier dingen.
Wat de auditor werkelijk wil
Eén: een lijst van je kritieke of belangrijke functies, en de ICT-diensten die ze ondersteunen. Twee: bewijs dat je die diensten kunt herstellen binnen de recovery objectives die je hebt opgeschreven. Drie: bewijs dat je die herstellen hebt geoefend tegen scenario's. Vier: een register van je ICT-derde-partij-providers, met hun kritikaliteit en jouw afhankelijkheid.
Elk hiervan kun je vanuit het platform genereren, op een schema, zonder dat een mens iets overtypt. Dat is het hele spel.
Evidence as code, geen evidence as PDF
Het patroon dat we nu draaien is hetzelfde, ongeacht cloud of sector. De lijst van kritieke functies leeft in de service-catalogus (Backstage of vergelijkbaar). De recovery objectives zijn SLO's op dezelfde plek. Het bewijs dat herstellen gebeuren komt uit dezelfde telemetrie die het platform draait: CloudTrail of Azure Activity voor control-plane-acties, OpenTelemetry-traces voor het herstel zelf, ChatOps-logs voor wie de knop drukte.
Het oefenlog is een opgeslagen output van game days. We draaien game days als code. Het scenario, de stappen, de succescriteria en de uitkomst leven in dezelfde repo als de runbook waar de alert naar verwijst.
Het derde-partij-register is een YAML-bestand onder versiebeheer. Elke leverancier draagt een kritikaliteit-tag, een contract-referentie, een exit-plan-referentie, en een verlengingsdatum. De auditor leest de YAML direct. We hebben nog geen auditor ontmoet die bezwaar maakte.
"De auditor is niet onder de indruk van volume. De auditor zoekt vier dingen."
Maikel Vlasman / Cloud Architect
Wat verandert voor het platformteam
Drie dingen veranderen in het operating model. Eén: SLO's worden echt. Als de recovery objective in het DORA-pack niet overeenkomt met de SLO die de on-call zichzelf oplegt, ziet de auditor het gat. Wij surfacen beide in hetzelfde dashboard.
Twee: elke wijziging aan het derde-partij-register gaat via een PR. Procurement bezit de relatie; het platformteam bezit het artefact. Dit elimineert het jaarlijkse gehannes om te reconciliëren wat supply-chain dacht dat we gebruikten.
Drie: game days zijn gepland, geen heldhaftigheid. Eén game day per kritieke service per kwartaal, scenario gekozen uit een geschreven catalogus, uitkomst gelogd. De auditor ziet twaalf maanden evidence op de dag dat ze aankomen.
Wat niet verandert
De threat-led penetration testing (TLPT) blijft handwerk. De exit-plannen voor kritieke providers blijven narratieve documenten. De board-rapportage-cyclus blijft waar hij was. We proberen niet alles in DORA te automatiseren; we proberen de saaie 70 procent te automatiseren zodat het team tijd heeft voor de 30 procent die oordeel vereist.
Het principe is hetzelfde dat we overal toepassen: als het vanuit het platform gegenereerd kan worden, moet het. Als een mens het eens per jaar overschrijft, is het schuld.