De DORA-verordening — de Digital Operational Resilience Act — is de EU-wet over cyberweerbaarheid voor de financiële sector. Zij bepaalt hoe financiële instellingen met cyberbeveiliging en IT-risico moeten omgaan. Simpel gezegd: elke bank, betaalonderneming, beleggingsonderneming, verzekeraar en cryptobeurs in de EU moet kunnen blijven functioneren tijdens een hack, cloudstoring of mislukte software-update en toezicht houden op de IT-leveranciers waarvan zij afhankelijk is.
Deze gids is geschreven voor mensen zonder juridische of IT-achtergrond. Hij behandelt op wie DORA van toepassing is, wat de verordening vereist, hoe snel een incident moet worden gemeld, hoe DORA verschilt van NIS2 en GDPR, welke sancties gelden en wat de DORA-vereisten betekenen voor fintech- en cryptobedrijven. Hij eindigt met een korte DORA-compliancechecklist.
Wat is DORA in eenvoudige woorden?
DORA — soms geschreven als EU DORA of de DORA Act — is Verordening (EU) 2022/2554 inzake digitale operationele weerbaarheid voor de financiële sector. „Digitale operationele weerbaarheid” klinkt ingewikkeld, maar betekent één ding: kan uw onderneming haar klanten blijven bedienen wanneer haar IT faalt? Een hacker dringt binnen, een update mislukt, een leverancier gaat offline — worden betalingen nog verwerkt, kunnen klanten nog inloggen, zijn hun gegevens nog veilig? DORA maakt van die vraag een wettelijke plicht in plaats van een goede praktijk.
Vóór DORA had elk EU-land en elk deel van de financiële sector eigen IT-beveiligingsregels en eigen incidentformulieren. DORA vervangt die lappendeken door één regelboek voor de hele financiële sector van de EU. Omdat het een verordening en geen richtlijn is, geldt zij woordelijk in elke lidstaat — er is geen nationale wet nodig om haar van kracht te laten worden.
De DORA-compliancedeadline is al verstreken. De voorbereidingsperiode van twee jaar na vaststelling is voorbij, alle DORA-verplichtingen zijn van kracht en nationale financiële toezichthouders controleren erop. Het DORA-kader rust op vijf pijlers; de rest van deze gids behandelt ze stuk voor stuk:
- ICT-risicobeheer — een schriftelijk plan voor IT-risico, onder verantwoordelijkheid van het bestuursorgaan (de raad van bestuur);
- beheer en melding van ICT-gerelateerde incidenten — IT-incidenten signaleren, registreren en aan de toezichthouder melden;
- testen van digitale operationele weerbaarheid — van routinematige kwetsbaarheidsscans tot volledige „red team”-aanvalssimulaties;
- ICT-risicobeheer voor derden — toezicht op de IT-leveranciers waarvan de onderneming afhankelijk is, met een register van alle leveranciers;
- informatiedeling — vrijwillige uitwisseling van dreigingsinformatie tussen financiële entiteiten.
Resultaten, geen technologieën
DORA schrijft niet voor welke software of leverancier u moet gebruiken. De verordening stelt resultaten vast: wees weerbaar, detecteer problemen, herstel snel en beheers uw leveranciers. De raad van bestuur is verantwoordelijk voor het aantonen dat die resultaten worden bereikt en bestuurders moeten hun kennis van IT-risico actueel houden (de verordening noemt uitdrukkelijk opleiding). Alles aan de IT-afdeling overlaten en het vervolgens vergeten, is precies wat DORA verbiedt.
Belangrijke DORA-termen uitgelegd
Een aantal gedefinieerde termen komt terug in elk artikel van de DORA-verordening, elk toezichtsformulier en elk leverancierscontract. Zodra u ze kent, leest de rest veel gemakkelijker.
| Financiële entiteit | De term van de verordening voor een financiële onderneming met vergunning — elk van de twintig typen in artikel 2. Hebt u een van die vergunningen, dan is DORA op u van toepassing. |
|---|---|
| ICT-dienstverlener die derde is | Elke onderneming die IT levert aan een financiële entiteit: cloudhosting, software, datastreams, beheerde beveiliging of betalingsverwerking. |
| Kritieke ICT-dienstverlener die derde is (CTPP) | Een zeer grote leverancier — denk aan grote cloudplatforms — die door EU-autoriteiten voor rechtstreeks toezicht door een Lead Overseer is aangewezen omdat zo veel ondernemingen ervan afhankelijk zijn. |
| Kritieke of belangrijke functie | Een bedrijfsfunctie waarvan stilstand de financiën van de onderneming ernstig zou schaden, haar wettelijke plichten zou schenden of haar vergunde diensten zou onderbreken. Betalingen en klantrekeningen zijn typische voorbeelden. |
| Groot ICT-gerelateerd incident | Een IT-incident dat — gelet op getroffen klanten, duur, verloren gegevens of financiële gevolgen — groot genoeg is om verplichte melding aan de toezichthouder te veroorzaken. |
| Threat-led penetration testing (TLPT) | Een geavanceerde test waarbij ethische hackers live systemen aanvallen zoals een echte aanvaller dat zou doen. Minstens elke drie jaar verplicht voor ondernemingen die de toezichthouder daarvoor heeft aangewezen; de toezichthouder kan dit vaker verlangen. |
| Informatieregister | Een gestructureerde lijst van elk IT-contract van de onderneming, die actueel wordt gehouden en minstens eenmaal per jaar aan de toezichthouder wordt verstrekt. |
| Technische reguleringsnormen (RTS) | De gedetailleerde uitvoeringsregels — sjablonen, drempels en methoden — die EU-autoriteiten uitvaardigen om de verordening in te vullen. |
Op wie is DORA van toepassing?
Het toepassingsgebied van DORA is vastgelegd in artikel 2, dat twintig categorieën financiële entiteiten noemt. Als een financiële instelling ergens in de EU een van deze vergunningen heeft, valt zij eronder — ongeacht haar omvang — tenzij een specifieke vrijstelling geldt. De belangrijkste groepen staan hieronder.
| Sector | Wie valt binnen het toepassingsgebied | Goed om te weten |
|---|---|---|
| Bankieren en betalingen | Banken, betalingsinstellingen, instellingen voor elektronisch geld, aanbieders van rekeninginformatiediensten | Uitgevers van e-moneytokens onder MiCA vallen eronder omdat zij banken of instellingen voor elektronisch geld moeten zijn |
| Beleggingen en fondsen | Beleggingsondernemingen, fondsbeheerders (AIFMs en UCITS), handelsplatformen, centrale tegenpartijen, centrale effectenbewaarinstellingen | Kleine en niet-verweven beleggingsondernemingen volgen een lichter kader |
| Cryptoactiva | Aanbieders van cryptoactivadiensten en uitgevers van activagerelateerde tokens | Beide vergund onder MiCA; gedekt vanaf de dag dat de vergunning wordt verleend |
| Verzekeringen en pensioenen | Verzekeraars, herverzekeraars, verzekeringstussenpersonen, bedrijfspensioenfondsen | Micro-, kleine en middelgrote tussenpersonen zijn vrijgesteld |
| Marktgegevens en infrastructuur | Kredietbeoordelingsbureaus, aanbieders van datarapportagediensten, transactieregisters en securitisatieregisters, beheerders van kritieke benchmarks | Verschillende hiervan staan rechtstreeks onder toezicht op EU-niveau |
| Overig | Crowdfundingplatformen, ICT-dienstverleners die derde zijn | Zie hieronder hoe IT-leveranciers worden gedekt |
Hoe zit het met de IT-ondernemingen zelf? Cloudplatforms, datacenters, softwareleveranciers en aanbieders van beheerde beveiliging zijn geen financiële entiteiten, maar DORA bereikt hen op twee manieren. Ten eerste moet elke financiële entiteit DORA-achtige voorwaarden in haar contracten met hen opnemen; een leverancier die weigert, riskeert dus de klant te verliezen. Ten tweede worden de grootste leveranciers — grote aanbieders van cloud-, datacenter-, telecom- en financiële software — aangemerkt als kritieke ICT-dienstverleners die derde zijn en rechtstreeks op EU-niveau onder toezicht staan; de lijst wordt jaarlijks bijgewerkt.
Is DORA van toepassing op niet-EU-ondernemingen? Rechtstreeks alleen op ondernemingen met een EU-vergunning — waaronder EU-dochterondernemingen en filialen van Britse, Amerikaanse of Aziatische groepen. Indirect bereikt zij elke buitenlandse leverancier die een financiële EU-onderneming bedient, omdat de verplichte contractbepalingen gelden ongeacht de vestigingsplaats. Een niet-EU-leverancier die als kritiek wordt aangewezen, moet binnen twaalf maanden een EU-dochteronderneming oprichten.
Ten slotte is DORA evenredig: de verplichtingen nemen toe met de omvang en complexiteit van de financiële instelling. Micro-ondernemingen — minder dan tien medewerkers en minder dan twee miljoen euro omzet of balanstotaal — hoeven aan diverse vereisten niet te voldoen, waaronder threat-led penetration testing en bepaalde governance- en rapportageplichten. Een afgebakende groep kleinere ondernemingen, zoals kleine en niet-verweven beleggingsondernemingen en bepaalde vrijgestelde betalings- en e-moneyinstellingen, volgt op grond van artikel 16 een vereenvoudigd kader voor ICT-risicobeheer. Klein zijn haalt een vergunde onderneming niet buiten DORA; het verlicht alleen de last.
DORA-vereisten: de vijf pijlers uitgelegd
De DORA-compliancevereisten vallen in vijf groepen. Samen vormen zij één cyclus — voorkomen, detecteren, reageren, herstellen, leren — en de toezichthouder verwacht bewijs voor elke stap.
Kader voor ICT-risicobeheer (artikelen 5–16)
In gewone woorden: weet welke IT u hebt, weet wat ermee mis kan gaan en beschik over een schriftelijk plan om die te beschermen en te herstellen. Het kader moet IT-activa en afhankelijkheden opsommen en uiteenzetten hoe de onderneming problemen voorkomt en detecteert, erop reageert en herstelt, en van incidenten leert. Het wordt minstens jaarlijks en na elk groot incident herzien. Het bestuursorgaan keurt het goed, bepaalt welk risico aanvaardbaar is en stelt het budget beschikbaar. Kritieke functies moeten in kaart worden gebracht, back-ups moeten daadwerkelijk worden getest en er moet een IT-continuïteitsplan zijn naast het algemene continuïteitsplan van de onderneming.
Incidentmelding: de termijnen van 4 uur, 72 uur en één maand
Elk ICT-gerelateerd incident moet worden geregistreerd en ingedeeld volgens dezelfde maatstaven in de hele EU: hoeveel klanten zijn getroffen, hoe ernstig de reputatie van de onderneming is geschaad, hoe lang het duurde, hoe ver het zich verspreidde, welke gegevens verloren gingen, hoe kritiek de dienst was en hoeveel geld op het spel stond. Een incident dat de drempels overschrijdt, is „groot” en moet in drie stappen aan de toezichthouder worden gemeld: een eerste melding binnen vier uur nadat het als groot is aangemerkt (en nooit later dan 24 uur nadat de onderneming ervan kennis kreeg), een tussentijds verslag binnen 72 uur na die eerste melding en een eindverslag binnen een maand na het tussentijdse verslag. Klanten wier geld of gegevens zijn geraakt, moeten onverwijld worden geïnformeerd. Ernstige cyberdreigingen die nog geen incident zijn geworden, kunnen vrijwillig worden gemeld.
Weerbaarheidstests en Threat-Led Penetration Testing (TLPT)
Het testen van digitale operationele weerbaarheid is een jaarlijks programma: elk systeem dat een kritieke of belangrijke functie ondersteunt, moet kwetsbaarheidsscans, gap-analyses, broncodebeoordelingen, scenariotests, prestatietests en penetratietests doorlopen. Ondernemingen die de toezichthouder significant acht — wegens hun omvang of de gevolgen van hun uitval — moeten daarnaast minstens elke drie jaar threat-led penetration testing uitvoeren. Dit is een gecontroleerde aanval op live systemen door gekwalificeerde ethische hackers, volgens een erkend kader. Micro-ondernemingen en ondernemingen onder het vereenvoudigde kader zijn vrijgesteld van TLPT en testen volgens een lichter, risicogebaseerd schema.
Derdenrisico, uitbesteding en het informatieregister
IT uitbesteden — aan een cloudserviceprovider of iemand anders — besteedt de verantwoordelijkheid niet uit. ICT-risicobeheer voor derden begint met een schriftelijke strategie voor leveranciersrisico; een onderneming moet leveranciers controleren vóór ondertekening, vermijden te sterk van één leverancier afhankelijk te zijn en een informatieregister bijhouden — een gestructureerde lijst van elk IT-contract — dat minstens jaarlijks naar de toezichthouder gaat. De contracten zelf moeten een vaste reeks bepalingen bevatten: wat de dienst is en welk niveau wordt toegezegd, waar gegevens worden opgeslagen, het recht op inspectie en audit, de plicht om bij incidenten te helpen, hoe het contract kan worden beëindigd en hoe de onderneming zo nodig naar een andere leverancier zou overstappen. De onderneming blijft volledig verantwoordelijk, ook wanneer de leverancier een kritieke aanbieder is die op EU-niveau onder toezicht staat.
Informatiedeling over cyberdreigingen
Financiële entiteiten mogen binnen vertrouwde groepen dreigingsinformatie uitwisselen — aanvalspatronen en indicators of compromise. Niemand hoeft deel te nemen, maar een onderneming die dat doet, moet haar toezichthouder informeren en de uitwisseling moet de regels inzake vertrouwelijkheid en gegevensbescherming naleven.
DORA versus NIS2 versus GDPR: hoe de regels samenhangen
Drie EU-wetten overlappen op het gebied van cyberweerbaarheid en incidentmelding, en veel financiële instellingen vallen onder meer dan één daarvan. De tabel toont wie elk instrument dekt en hoe de meldingstermijnen verschillen.
| Aspect | DORA | NIS2-richtlijn | GDPR |
|---|---|---|---|
| Wie het dekt | Financiële ondernemingen en hun IT-leveranciers | Essentiële en belangrijke entiteiten in achttien kritieke sectoren, waaronder bankieren | Iedereen die persoonsgegevens verwerkt |
| Wat het beschermt | Continuïteit van financiële diensten en hun IT | Netwerk- en informatiebeveiliging van kritieke sectoren | Persoonsgegevens van individuen |
| Eerste melding verschuldigd | Binnen 4 uur na classificatie, max. 24 uur na kennisname | Vroege waarschuwing binnen 24 uur | Binnen 72 uur aan de gegevensbeschermingsautoriteit |
| Vervolgmeldingen | Tussentijds na 72 uur; definitief binnen één maand | Melding na 72 uur; definitief binnen één maand | Gefaseerd, naarmate feiten bekend worden |
| Rechtsvorm | Verordening — rechtstreeks van toepassing | Richtlijn — elk land schrijft eigen wetgeving | Verordening — rechtstreeks van toepassing |
| Onderlinge verhouding | De gespecialiseerde wet: gaat voor op NIS2 voor financiële ondernemingen | Geldt voor financiële ondernemingen alleen waar DORA zwijgt | Loopt parallel; één incident kan beide activeren |
In de praktijk meldt een financiële onderneming IT-incidenten aan haar financiële toezichthouder, niet aan de nationale cyberbeveiligingsinstantie. GDPR loopt parallel: als een cyberaanval klantgegevens lekt, meldt de onderneming dit tweemaal — onder DORA aan de financiële toezichthouder en onder GDPR aan de gegevensbeschermingsautoriteit — volgens twee afzonderlijke termijnen.
DORA en crypto: wat dit betekent voor CASPs en tokenuitgevers
Voor cryptobedrijven vormen de DORA-verordening en het MiCA-kader een paar. MiCA bepaalt wie cryptodiensten mag verlenen of tokens mag uitgeven in de EU; DORA bepaalt hoe de technologie achter die diensten moet worden beheerd. Een onder MiCA toegelaten aanbieder van cryptoactivadiensten is vanaf het moment dat zijn vergunning wordt verleend een financiële entiteit onder DORA, evenals elke uitgever van activagerelateerde tokens. MiCA verwijst zelf naar DORA voor IT- en beveiligingsvereisten, dus elke toezichthouder leest beide samen.
In de praktijk wordt de weerbaarheid al tijdens het vergunningsproces gecontroleerd, niet alleen achteraf. Wanneer een toezichthouder een CASP-aanvraag beoordeelt, maken het IT-risicokader, het bedrijfscontinuïteitsplan, incidentprocedures en uitbestedingsregelingen deel uit van het dossier, en DORA is de maatstaf waartegen zij worden getoetst. Een cryptobeurs of bewaarder kan geen vergunning krijgen — of behouden — met een weerbaarheidsplan dat alleen op papier bestaat.
Cryptobedrijven hebben ook IT-afhankelijkheden die een bank niet heeft: bewaring van privésleutels, aanbieders van blockchainnodes, walletinfrastructuur van derden, smart-contractcomponenten en markten die de klok rond handelen zonder onderhoudsvenster. Onder DORA is elk daarvan een IT-activum of leveranciersrelatie die moet worden opgenomen, ingedeeld, gecontracteerd en getest. Zo gaan ook niet-vergunde leveranciers van hosting, sleutelbeheer of blockchaininfrastructuur aan DORA voldoen: via de contracten van hun klanten.
DORA-sancties, boetes en gevolgen van niet-naleving
Er bestaat geen enkele EU-brede tabel met DORA-sancties. Artikel 50 draagt elke lidstaat op sancties vast te stellen die „doeltreffend, evenredig en afschrikkend” zijn en geeft toezichthouders de bevoegdheid documenten op te vragen, inspecties uit te voeren, herstelmaatregelen te bevelen en waarschuwingen te publiceren. De nationale bevoegde autoriteit van elke lidstaat past deze toe op grond van de eigen vergunningswetgeving van de sector. Een bank, betaalonderneming en cryptobeurs krijgen dus elk te maken met de sanctieladder van hun eigen sector.
Mogelijk hebt u een „DORA-boete” van één procent van de gemiddelde dagelijkse wereldwijde omzet gezien. Dat cijfer bestaat, maar is voor iemand anders bedoeld: het is de dagelijkse sanctie die de Europese toezichthoudende autoriteiten maximaal zes maanden kunnen opleggen aan een kritieke ICT-dienstverlener die derde is en een toezichtbesluit negeert. Het is geen boete voor banken of cryptobedrijven. De „2% van de jaaromzet” die soms daarnaast wordt genoemd, staat evenmin in DORA: dit komt uit NIS2, waar het de minimale bovengrens is die landen voor essentiële entiteiten moeten vaststellen. Voor een financiële onderneming zijn de realistische gevolgen:
- toezichtmaatregelen — bevelen om zaken te herstellen, beperkingen van activiteiten en, in ernstige gevallen, schorsing of verlies van de vergunning;
- administratieve boetes volgens de nationale wetgeving van de sector;
- persoonlijke aansprakelijkheid van bestuursleden, omdat DORA de raad van bestuur verantwoordelijk maakt voor het IT-kader;
- strafrechtelijke aansprakelijkheid in landen die ervoor hebben gekozen deze toe te voegen, wat artikel 52 toestaat;
- reputatie- en commerciële schade — verloren klanten, bankpartners en investeerders.
Vergunningsrisico voor MiCA-vergunde ondernemingen
Voor een aanbieder van cryptoactivadiensten is de vergunning zelf het grootste risico. Degelijk IT-governance is een voorwaarde voor het verkrijgen van een MiCA-vergunning, dus herhaaldelijke DORA-tekortkomingen kunnen worden aangemerkt als het niet langer voldoen aan de vergunningsvoorwaarden — niet slechts als een eenmalige compliance-inbreuk.
Wie houdt toezicht op DORA? Toezichthouders op nationaal en EU-niveau
Het dagelijkse DORA-toezicht blijft bij de toezichthouder die de onderneming al een vergunning verleent — de centrale bank of financiële toezichthoudende autoriteit van haar lidstaat van herkomst. Die bevoegde autoriteit ontvangt incidentmeldingen en informatieregisters, bepaalt wie TLPT moet uitvoeren en controleert het IT-risicokader als onderdeel van het gewone toezicht. De meeste publiceren DORA-richtsnoeren, sjablonen en termijnen op hun websites.
Op EU-niveau delen drie instanties het werk: de European Securities and Markets Authority, de European Banking Authority en EIOPA, de autoriteit voor verzekeringen en pensioenen. Zij schrijven de technische normen die de details invullen en wijzen gezamenlijk de kritieke ICT-dienstverleners die derde zijn aan, die vervolgens elk onder toezicht staan van een van de drie als Lead Overseer.
DORA-compliancechecklist: hoe u compliant wordt
Of een onderneming nu een vergunning aanvraagt of al onder toezicht staat, tijdens een audit bewijst dezelfde set documenten de DORA-compliance. Een praktisch startpunt voor een DORA-implementatieplan of gap-analyse:
- Bevestig uw toepassingsgebied: onder welke categorie van artikel 2 u valt en of het vereenvoudigde kader of een micro-ondernemingsvrijstelling geldt.
- Breng elk IT-activum, systeem en elke gegevensstroom in kaart die een kritieke of belangrijke functie ondersteunt.
- Stel een door de raad van bestuur goedgekeurd beleid voor ICT-risicobeheer vast, met benoemde verantwoordelijken en jaarlijkse herziening.
- Richt incidentindeling, een incidentlogboek en meldingssjablonen in die aansluiten bij de wettelijke termijnen.
- Maak een jaarlijkse testkalender en controleer of de toezichthouder u op de TLPT-lijst heeft geplaatst.
- Stel het informatieregister van alle IT-leveranciers samen en actualiseer hun contracten met de verplichte bepalingen.
- Controleer concentratierisico en schrijf exitplannen voor leveranciers die kritieke functies ondersteunen.
- Test back-ups, herstel en het IT-continuïteitsplan minstens eenmaal per jaar.
- Leid de raad van bestuur op en bewaar bewijs dat de opleiding heeft plaatsgevonden.
Eesti Firma adviseert fintech- en cryptobedrijven over de juridische kant van DORA: vaststellen welke verplichtingen gelden, het IT-kader afstemmen op MiCA-vergunningsvereisten, leverancierscontracten beoordelen en de documenten voorbereiden die een toezichthouder verwacht te zien. Neem contact met ons op om te bespreken hoe de verordening op uw onderneming van toepassing is.
Veelgestelde vragen over DORA
DORA staat voor de Digital Operational Resilience Act, een EU-verordening met uniforme regels voor ICT-risicobeheer, incidentmelding, weerbaarheidstests en derdenrisico in de financiële sector. Zij is rechtstreeks van toepassing in alle lidstaten en volledig van kracht.
Op twintig categorieën financiële instellingen met een EU-vergunning — banken, betalings- en e-moneyinstellingen, beleggingsondernemingen, fondsbeheerders, verzekeraars, aanbieders van cryptoactivadiensten en marktinfrastructuren — en, via contracten en EU-toezicht, op de IT-leveranciers die hen bedienen.
Ja. De voorbereidingsperiode na vaststelling is geëindigd en elke verplichting geldt volledig. Toezichthouders behandelen DORA nu als onderdeel van gewone vergunningverlening en inspecties, niet als toekomstig project.
Alleen voor hun dochterondernemingen en filialen met EU-vergunning. Niet-EU-leveranciers die financiële EU-ondernemingen bedienen, zijn indirect gebonden via verplichte contractvoorwaarden, en een als kritiek aangewezen niet-EU-leverancier moet binnen twaalf maanden een EU-dochteronderneming oprichten.
NIS2 is een algemene cyberbeveiligingsrichtlijn voor kritieke sectoren; DORA is de gespecialiseerde verordening voor financiën. Waar beide kunnen gelden, heeft DORA voorrang voor ICT-risicobeheer en incidentmelding, en financiële ondernemingen melden aan hun financiële toezichthouder in plaats van aan de nationale cyberbeveiligingsinstantie.
Ja. Aanbieders van cryptoactivadiensten en uitgevers van activagerelateerde tokens met een vergunning onder MiCA zijn financiële entiteiten onder DORA. Uitgevers van e-moneytokens vallen eronder als banken of instellingen voor elektronisch geld. Niet-vergunde leveranciers aan deze ondernemingen voldoen indirect aan DORA via contractvoorwaarden.
In drie stappen: een eerste melding binnen vier uur na classificatie als groot en uiterlijk 24 uur na kennisname, een tussentijds verslag binnen 72 uur na het eerste en een eindverslag binnen een maand na het tussentijdse verslag.
Sancties voor financiële ondernemingen worden op grond van artikel 50 door nationale wetgeving vastgesteld en door de nationale toezichthouder gehandhaafd. Zij lopen van herstelbevelen via boetes tot verlies van de vergunning. De één procent van de dagelijkse wereldwijde omzet is een sanctie voor kritieke ICT-dienstverleners die derde zijn onder EU-toezicht, niet voor financiële ondernemingen.
Ja, maar evenredig. Micro-ondernemingen hoeven geen threat-led penetration testing uit te voeren, zijn vrijgesteld van de vaste jaarlijkse testplicht en enkele governanceplichten, en een afgebakende groep kleinere ondernemingen volgt een vereenvoudigd kader voor ICT-risicobeheer. Klein zijn haalt een vergunde onderneming niet buiten het toepassingsgebied.
