In mijn eerdere blogs over wetgeving op het gebied van informatiebveiliging had ik het over de Telecommunicatiewet en de Algemene Verordening Gegevensbescherming (AVG) . Vandaag zoom ik in op DORA — de Digital Operational Resilience Act. Klinkt als een EU-ding voor grote banken en verzekeraars (en dat ís het ook), maar onderschat niet hoe dit ook bij jou als MKB’er op de stoep kan staan, zeker als je in of rond de financiële keten opereert.
**Waarom bestaat DORA?**Heel simpel: financiële dienstverlening mág niet omvallen door digitale haperingen. Niet door hacks, niet door uitval bij een cloudleverancier, niet door een vergeten update. DORA trekt één Europese lat voor digitale weerbaarheid: je moet verstoringen kunnen voorkomen, opvangen, en snel herstellen — en je moet aantonen dat je dat kunt.
**Wat regelt DORA in gewone-mensentaal?**Het komt op het volgende neer:
- ICT-risicomanagement op orde: weten welke systemen kritisch zijn, wie waarvoor verantwoordelijk is, patchen, back-ups, segmentatie, monitoring — maar aantoonbaar en herhaalbaar.
- Incidenten snel en gestandaardiseerd melden: niet “we komen er op terug”, maar tijdig rapporteren aan De Nederlanse Bank (DNB) of Autoriteit Financiele markten (AFM), inclusief impact en herstel.
- Testen dat je écht veerkrachtig bent: van kwetsbaarheidsscans tot tabletop-oefeningen tot (voor grotere partijen) dreigingsgestuurde pentests.
- Grip op leveranciers: je mag veel uitbesteden, maar niet je verantwoordelijkheid. Contracten, exit-plannen, en toezicht op je kritieke ICT-dienstverleners horen er gewoon bij.
- Informatie delen over dreigingen: samenwerken in de sector om sneller te leren en reageren.
**Ik hoor je zeggen: “Tim, heel leuk dit. Maar dat is toch vooral een zorg voor de grote jongens. Wat heb ík er mee te maken?”**Meer dan je denkt. Twee routes waarop DORA je kan raken als MKB’er:
- Je bent zelf een financiële partij (of aanpalend) — denk aan een kleinere betaaldienstverlener, fintech, beleggingsdienst of assurantiekantoor met IT-dependenties. DORA geldt proportioneel, maar hij geldt wél: je moet laten zien dat jouw digitale fundament staat.
- Je levert aan financiële klanten — software, hosting, security, outsourcing, zelfs niche-tools. Dan gaat de lat via contracten omhoog: eisen aan beschikbaarheid, beveiliging, rapportage, audits, exit, en soms meedoen in ketentests. Niet omdat je nu “onder DORA valt”, maar omdat jouw klant dat moet kunnen aantonen.
Twee korte voorbeelden uit de praktijk
- De SaaS-leverancier met “99,9% uptime” en een lege map proceduresJe levert een planningstool aan een vermogensbeheerder. Er is een storing bij je cloudprovider, alles ligt een middag plat. Voorheen was dat vooral vervelend; nu wil je klant herstel-rapportages, root-cause, verbeteracties en bewijs dat je monitoring en failover werken. Dat is DORA die via de voordeur binnenkomt.
- Het IT-beheerbedrijf met snelle handen en weinig papierJe beheert werkplekken bij een verzekeraar. Jullie lossen incidenten vaak “even tussendoor” op bij de klant die ‘het hardste schreeuwt’. Dat werkt niet binnen de DORA. Onder DORA wil de klant dat je binnen uren formeel meldt, logt wat je gedaan hebt, en periodiek aantoont dat je patchbeleid en back-ups werken — bewijs, niet onderbuikgevoel.
**“Wordt dit dan weer zo’n papieren tijger?”**Alleen als je het zo aanvliegt. DORA is in de kern gewoon goed huisvaderschap voor IT, maar dan expliciet en herhaalbaar. Het voorkomt vooral dat één vergeten schakel in de keten iedereen lam legt. En ja, het is werk — net als je boekhouding — maar het verdient zich terug bij de eerste echte storing.
Wat doe je maandag anders? (zonder meteen een leger consultants)
- Maak je kritieke keten zichtbaar: welke systemen en leveranciers mógen niet plat? Schrijf het op, en wijs een eigenaar toe die verantwoordelijk is om hier op toe te zien. Bedenkt ook hoe snel je terug online wilt zijn, en hoeveel verlies van data acceptabel is ( RTO/RPO ).
- Regel een basis niveau beveiliging in en maak het aantoonbaar: patchkalender, back-up-tests (en ook het terugzetten testen!), monitoring-alerts van kritieke systemen en houd een incidentlog bij.
- Schoon je contracten op: voeg eisen toe aan contracten naar jouw leveranciers over: incidentmeldingen, beschikbaarheid eisen, welke beveiligingsstandaarden gehanteerd moeten worden, audit-rechten en een realistisch exit-plan.
- Oefen klein, maar leer groot: doe elk kwartaal een uurtje een oefening in incidenten bestrijding (een zogenaamde tabletop). “Wat als onze belangrijkste database corrupt is?”, “SaaS leverancier X kampt twee weken lang met een ransomware aanval”. Schrijf op waar je tegen aanliep en welke verbeteringen je doorvoert.
- Communiceer volwassen: bij een incident: wie belt wie, binnen hoeveel uur, met welke minimale info. Geen paniek-whatsapp, wel een kort format.
Niet te weinig, niet te veelTe weinig doen betekent dat je bij het eerste audit-vinkje van je klant door de mand valt. Te véél (over-engineering) maakt je traag en duur. Zoek de gepaste set maatregelen die past bij jouw risico’s en rol in de keten. Dat is dezelfde denklijn als bij je risk appetite: je tekent bewust waar je grens ligt — en je kunt het uitleggen.
Als je het zo inzet, wordt DORA geen blok aan je been maar een kwaliteitsfilter: robuustere dienstverlening, minder uitval, betere klantrelaties — en ja, compliance als bijproduct. Niet omdat Brussel het zegt, maar omdat je bedrijf er sterker van wordt.