Binnen veel verzekeraars wordt DORA nog steeds gezien als één van drie dingen: een vinkje, een stapel papierwerk of een vervelende nieuwe verplichting die vooral extra tijd kost. En eerlijk is eerlijk: die reactie is logisch. Teams staan al onder druk, de backlog puilt uit, en niemand zit te wachten op nóg een regelset. Maar juist daar gaat het in de praktijk mis: DORA is geen compliance-klusje. DORA is een architectuurvraagstuk.
Neem een recente situatie die ik tegenkwam. We ontwikkelden een nieuwe koppeling. Het was allang duidelijk dat die via onze API-managementlaag moest lopen — zodat we aantoonbaar in control zijn en niet afhankelijk worden van ongedocumenteerde directe verbindingen. Toch werd er “even” rechtstreeks gebouwd, om tijd te besparen en de business niet te laten wachten. Je voelt hem al: tijdens de testen vlak voor go-live werkte de koppeling niet. Wat volgde was rework, vertraging en precies het gedoe dat we hadden willen voorkomen.
En dit is geen uitzondering. Teams kiezen vaak voor de directe route omdat ze denken tijd te winnen. “Het ging al jaren zo, waarom nu anders?” Maar onderaan de streep is de kern simpel: je kunt niet aantonen dat je in control bent, en rework kost altijd meer dan het volgen van de juiste route. De rekensom is kort: je bespaart nu misschien een half uur, maar betaalt straks een halve sprint.
Bovendien spelen menselijke factoren een enorme rol. Binnen teams merk ik vooral twee dingen: weerstand tegen verandering (“weer een nieuwe regel…”) en pure tijdsdruk (“we hebben al zoveel te doen, dit kan er niet bij”). En die combinatie is dodelijk voor elke transitie. Als je al nauwelijks tijd hebt om features te bouwen, voelt elk nieuw kader als sabotage. Tot het moment dat je vlak voor livegang ontdekt dat dat kader je juist had gered.
De technische realiteit achter DORA: governance is geen luxe, maar noodzaak
Veel discussies over DORA blijven hangen op het niveau van processen en papieren. Maar de kern zit in de techniek: je moet je IT-landschap zó ontwerpen dat controleerbaarheid vanzelf ontstaat. Niet als extra stap, maar als gevolg van je ontwerpkeuzes.
Dat betekent concreet:
1. API-governance is geen ‘nice to have’, maar een harde randvoorwaarde
Als elke nieuwe koppeling via zijn eigen pad gaat, creëer je onzichtbare risico’s. Als elke koppeling via een governance-laag gaat, creëer je zicht en controle.
Een volwassen API-governancemodel bestaat uit:
- Verplichte registratie van elke API (inclusief eigenaar en gebruiksdoel)
- Standaarden voor versiebeheer, authenticatie en documentatie
- Een enforced proces: je kunt niet live zonder de juiste checks
- Monitoring en auditing op dezelfde plek, niet verspreid over teams
Dit klinkt streng, maar is precies waardoor audits soepel verlopen. Geen jacht op Excelletjes. Geen ‘wie heeft dit gebouwd?’ Geen stress.
2. Controls automatiseren waar kan — en elimineren waar het moet
De grootste fout die verzekeraars maken, is alles willen aantonen via handwerk. Checklistjes, screenshots, mailtjes… dat werkt niet op schaal.
DORA vraagt om aantoonbare beheersing, en dat betekent onder andere:
- gebruik CI/CD-pijplijnen die automatisch policies afdwingen;
- zorg dat deployment-logs volledig en onveranderbaar zijn;
- monitor integraties centraal, niet team-voor-team;
- automatiseer kwetsbaarheidsscans en dependency-checks.
Hoe meer je automatiseert, hoe minder het voelt als bureaucratie.
3. Audit-readiness is een ontwerpkeuze, geen eindstap
Je kunt een landschap bouwen dat bij elke audit weer bloed, zweet en tranen kost, of je bouwt een landschap dat zichzelf uitlegt.
Dat laatste betekent:
- alles heeft een eigenaar;
- alles is traceerbaar;
- alles wat risicovol is, logt automatisch;
- alles wat kritisch is, is gestandaardiseerd.
Audit-readiness is het bijproduct van volwassen architectuur.
Wat je morgen al kunt verbeteren (zonder een project van 6 maanden te starten)
DORA voelt soms groot, maar de eerste stappen zijn verrassend snel te zetten. Dit is wat ik morgen zou regelen als ik in een willekeurige verzekeraar zou binnenstappen:
1. Standaardiseer de intake van nieuwe changes
Maak één simpele vraag verplicht in elke refinement:
“Raakt dit change DORA-relevante kaders (API’s, logging, risico’s, failover, IAM, leveranciers)?”
Teams die deze vraag bewust beantwoorden, maken direct betere keuzes.
2. Zet API-management weer op de kaart als default route
En niet als advies, maar als technisch enforced pad. Direct bouwen mag niet meer. Punt.
3. Maak zichtbaarheid belangrijker dan snelheid
Je kunt snel zijn én rommel maken, of je kunt snel zijn én controle houden. Maar snel en ongecontroleerd? Dat is geen volwassen IT-strategie.
4. Plan een ‘landschapsscan light’
Niet een groot onderzoek, maar een compact overzicht van:
- welke koppelingen bestaan er?
- welke lopen buiten API-management om?
- welke missen logging of monitoring?
- welke hebben geen eigenaar?
80% van de risico’s komt uit 20% van deze lijst.
5. Beperk uitzonderingen — de sluipmoordenaar van compliance
Elke uitzondering die vandaag wordt toegestaan, keert morgen als incident terug. En niemand weet meer waarom hij ooit is toegestaan.
De organisatorische impact: architectuur en delivery moeten elkaar weer vinden
Verzekeraars kampen vaak met een kloof tussen “de architectuurwereld” en “de deliverywereld”. DORA legt die kloof genadeloos bloot.
Wat delivery-teams nodig hebben
- kaders die te begrijpen zijn;
- tooling die helpt in plaats van hindert;
- een proces dat niet voelt als strafwerk.
Wat architectuur nodig heeft
- teams die bereid zijn om standaarden te volgen;
- ruimte om kaders te vernieuwen;
- governance die technisch afdwingbaar is.
Waar het misgaat
- architectuur wordt te abstract;
- teams worden te pragmatisch;
- compliance probeert het op te lossen met processen;
- en de audit komt altijd op het slechtst mogelijke moment.
DORA dwingt deze groepen opnieuw samen te werken. Niet via extra overleg, maar via gedeelde verantwoordelijkheid.
DORA is geen molensteen, maar een ballon die je landschap optilt
De boodschap die ik verzekeraars wil meegeven, is eenvoudig:
“Zie wetgeving zoals DORA niet als molensteen, maar als ballon die je IT-landschap naar een hoger niveau tilt.”
DORA maakt je landschap beter als je het integreert in je manier van werken. Het is geen rem. Het is een reality-check. En het zorgt dat je landschap toekomstbestendig is — niet alleen auditbestendig.
Wat ik wil dat lezers na vandaag anders doen
Drie dingen. Bewust, herhaalbaar en vast onderdeel van de WoW:
- Eerder afstemmen — en niet pas als het fout gaat.
- API-governance standaard meenemen — nergens meer “even snel rechtstreeks”.
- Compliance zien als ontwerpelement — niet als eindcontrole.
Als dat lukt, verdwijnen quick fixes vanzelf. Dan werk je gecontroleerd, robuust en zonder verrassingen vlak voor go-live.