DevOps onder DORA: engineeringdiscipline voor gereguleerde financiële delivery

Iedere engineering leider in de financiële sector beheert nu dezelfde tegenstelling. De business wil de deployment-cadans van een fintech-challenger. De toezichthouder wil gedocumenteerde, reproduceerbare en verdedigbare controle over elke wijziging die een betaling, een grootboek of klantgegevens raakt. Het grootste deel van het afgelopen decennium werden die twee drukken behandeld als een afweging die u per kwartaal onderhandelde. Sinds DORA verplicht is geworden in de hele EU, is die onderhandeling voorbij: er wordt van u verwacht dat u zowel snelheid als continue operationele weerbaarheid aantoont, en dat u dit op verzoek met bewijs onderbouwt. De teams die hier goed mee omgaan, zijn niet degenen die een kant hebben gekozen. Het zijn degenen die hun controls in de pipeline hebben ondergebracht.

Dit stuk gaat over de vier drukken die de SDLC op dit moment daadwerkelijk beperken in een gereguleerde financiële omgeving op grote schaal, wat de data over elk daarvan zegt, en wat gedisciplineerde teams anders doen. Niets ervan is theoretisch. Het komt allemaal terug in de change-failure rate, de auditbevindingen en de verloopcijfers.

AI levert u throughput op en verkoopt u instabiliteit

De kernboodschap uit het 2025 DORA / Accelerate State of DevOps-rapport is werkelijk goed nieuws, en het is een valstrik als u daar stopt met lezen. De relatie van AI met de throughput van softwaredelivery keerde van negatief in 2024 om naar positief in 2025, waarbij 90% van de respondenten nu AI in hun werk gebruikt, met een mediaan van twee uur per dag. Teams leveren meer op. Maar instabiliteit is de enige grote delivery-metriek die AI nog steeds verslechtert: AI-adoptie correleert met meer change failures, meer rework en een langere hersteltijd na mislukte deployments. Het kader van DORA is het deel om u eigen te maken: AI is een versterker van de bestaande sterke en zwakke punten van een organisatie, geen oplossing daarvoor.

Voor een generiek SaaS-team is een hogere change-failure rate een kostenpost. Voor een bank die opereert onder de functiescheidingseisen van SOX en de weerbaarheidsverplichtingen van DORA is sneller opleveren terwijl change failures en rework toenemen precies het faalpatroon dat auditors en toezichthouders bestraffen. Het 2026 State of Code-onderzoek verklaart het mechanisme: het werk is verschoven van het schrijven van code naar verificatie en debugging, en 96% van de developers vertrouwt de functionele juistheid van AI-gegenereerde code niet volledig, waarbij slechts 4% het volledig eens is met de stelling dat deze functioneel correct is. In een sector waar verificatie verplicht is in plaats van optioneel, verlicht een ongemitigeerde AI-uitrol geen toil, maar verplaatst die naar de duurste, meest gereguleerde fase van uw pipeline.

Compliance is een continue, bewijsintensieve heffing op delivery geworden

DORA heeft de eenheid van compliance verschoven van de jaarlijkse audit naar het draaiende systeem. Sinds het op 17 januari 2025 verplicht werd, moeten financiële entiteiten in de EU operationele weerbaarheid continu aantonen: gestructureerde classificatie van ICT-incidenten met gestandaardiseerde rapportage aan toezichthouders, threat-led penetratietesten en scenario-oefeningen met gedocumenteerde remediatie, continue monitoring van ICT-risico's bij derden met exit-strategieën, en onafhankelijk auditbewijs. Dit stapelt bovenop PCI-DSS, SOX en GDPR in plaats van ze te vervangen, en PCI-DSS, SOX en GDPR leggen elk hun eigen beperkingen op aan de SDLC, van versleuteling en continue auditing van betaalgegevens tot gedocumenteerde goedkeuringen en functiescheiding voor elke codewijziging.

De boetes maken dit tot een getal op bestuursniveau, niet tot een engineering-voetnoot. Niet-naleving van DORA gaat gepaard met boetes tot 2% van de jaarlijkse wereldwijde omzet of EUR 1 miljoen voor instellingen, en tot EUR 5 miljoen voor kritieke ICT-aanbieders. Hogan Lovells, die na een half jaar het landschap evalueerde, constateerde dat het compliance-traject verre van voltooid is, met entiteiten die hun governance-, incident-response- en bedrijfscontinuïteitsregelingen nog steeds aan het herzien zijn. Het voorspelbare gevolg is dat governance de dominante beperking op snelheid wordt. Een bankbestuurder vertelde Deloitte dat het verhoogde compliance-toezicht "absoluut impact had op de algehele snelheid van ons team." Daarom stappen volwassen teams over op governance as code: geautomatiseerde policy gates en audit-ready bewijs dat door de pipeline wordt gegenereerd, in plaats van spreadsheets en goedkeuringstickets die onder tijdsdruk worden gereconstrueerd.

Legacy plus bureaucratie rond change control is waar uw capaciteit naartoe gaat

De reden dat dit moeilijk is, is structureel, niet cultureel. Mainframes verwerken nog steeds ongeveer 68% van de wereldwijde IT-productieworkloads, en het grootste deel van de IT-budgetten van banken gaat naar onderhoud van legacy in plaats van naar innovatie, terwijl fintech-concurrenten wekelijks releasen. U kunt de core niet zomaar eruit trekken, dus de beperking is permanent en moet eromheen worden geëngineerd.

Daaronder is technical debt een continue aderlating op precies de engineers die u het liefst nieuwe functionaliteit laat bouwen. De cijfers van Deloitte zijn ronduit: 33% van de tijd van developers gaat op aan onderhoud van technical debt, en 78% van de engineers zegt dat legacy-systemen het moreel negatief beïnvloeden, wat een aanjager van verloop is, niet slechts een sentimentmetriek. Leg daar handmatige overdrachten via tickets en goedkeuringsboards bovenop, en een groot deel van uw capaciteit is verbruikt voordat iemand een feature schrijft. De consensusoplossing is platform engineering: paved roads, interne developer portals, ingebedde compliance en geautomatiseerde quality gates die kleinere, auditeerbare wijzigingen opleveren die eenvoudiger te testen, terug te draaien en aan een auditor te bewijzen zijn. De richting is duidelijk genoeg dat Gartner voorspelt dat 80% van de grote software-engineeringorganisaties tegen 2026 platform-engineeringteams zal hebben, tegenover 45% in 2022. De opbrengst is concreet: Software Mind noemt Capital One dat de bouwtijd van ontwikkelomgevingen terugbracht van drie maanden naar minuten.

De software supply chain is nu een auditverplichting, geen scan

Open-sourcecomponenten vormen 80-90% van moderne applicaties en liggen onder vrijwel elk financieel systeem, en de dreiging daartegen escaleert in hoog tempo. Het 2026-rapport van Sonatype registreerde meer dan 1,2 miljoen geblokkeerde kwaadaardige packages. Triage is lastiger dan het op een dashboard lijkt: 65% van de nieuwe kwetsbaarheden heeft geen severity score, dus u kunt niet simpelweg op CVSS gaten zetten. En AI introduceert een nieuwe vector rechtstreeks in de dependency graph: ongeveer 27% van de AI-suggesties voor dependencies is ongeldig of bestaat uit risicovolle hallucinaties.

Regelgeving is hierop aangesloten. SBOMs, secure-by-design-attestatie onder de EU Cyber Resilience Act en de Amerikaanse NIST SSDF/CISA-richtlijnen, en aantoonbaar toezicht op het risico van software van derden verschijnen nu rechtstreeks in inkoopcycli en auditpraktijk, versterkt door de ICT-mandaten van DORA voor derden. CRA-boetes lopen op tot 2% van de wereldwijde omzet, en regelgeving rond software assurance convergeert wereldwijd in plaats van regiospecifiek te blijven. Voor een finance engineering director is de implicatie specifiek: SBOM-generatie, herkomst van dependencies en continue vulnerability gating moeten vaste, audit-ready onderdelen van de pipeline zijn, geen periodieke scan die iemand uitvoert vlak voor een release.

Hoe goed eruitziet

De teams die alle vier de drukken opvangen zonder tot stilstand te komen, delen een herkenbare vorm:

Controls leven in CI/CD, niet in tickets. Functiescheiding, change approval en policy checks worden door de pipeline afgedwongen en gelogd, zodat het auditartefact een bijproduct is van het opleveren in plaats van een aparte reconstructie-inspanning.
AI-output wordt gegated door verificatie, niet door vertrouwen. Gegeven dat 96% van de developers AI-gegenereerde code niet volledig vertrouwt, worden de change-failure rate en de rework-metrieken rechtstreeks bewaakt, en wordt AI uitgerold in teams die al sterk testen, omdat het versterkt wat er al is.
Wijzigingen zijn klein, omkeerbaar en bewijsbaar. Kleinere auditeerbare deployments met echte rollback zijn zowel het weerbaarheidsverhaal dat DORA wil als het snelheidsverhaal dat de business wil.
Supply chain-bewijs is continu. SBOMs en herkomst worden bij elke build gegenereerd, en de gating houdt rekening met de 65% van de kwetsbaarheden zonder severity score en met het risico van gehallucineerde dependencies.

De discipline is de strategie

Geen van deze vier drukken is op te lossen met de aanschaf van een tool of een eenmalig programma. Het zijn eigenschappen van het draaien van gereguleerde software op grote schaal, en ze versterken elkaar: AI-instabiliteit slaat het hardst toe in legacy-zware landschappen, de compliance-last is het zwaarst waar change control het meest handmatig is, en supply chain-risico is het grootst waar de herkomst het zwakst is. De rode draad in elk team dat ermee omgaat, is dezelfde: een gedisciplineerde SDLC waarin weerbaarheid en auditeerbaarheid in het delivery-platform zijn ingebouwd in plaats van bij de review erop vastgeschroefd. Dat is weinig glamoureus, en het is het werk. De instellingen die platform engineering en governance as code behandelen als kerninfrastructuur voor delivery, zijn degenen die DORA veranderen van een heffing in een basislijn waaraan zij al voldoen.