DORA: wat als technisch bewijs telt
DORA is van toepassing sinds 17 januari 2025. Het grootste deel gaat over governance, tests en contracten. Een smal stuk — cryptografie, certificaten, het activaregister en de gegevens die uw financiële klanten nu schriftelijk opvragen — laat sporen na die iedereen van buitenaf kan waarnemen. Deze gids loopt dat stuk artikel voor artikel door en is expliciet over waar het ophoudt.
Geschreven door het SkyQon-engineeringteam · Laatst gecontroleerd op 6 augustus 2026
Wat DORA werkelijk vereist
De Digital Operational Resilience Act — Verordening (EU) 2022/2554 — is een verordening en geen richtlijn. Er is geen omzettingsstap en geen nationale variant om na te gaan: dezelfde tekst geldt in elke lidstaat, en wel sinds 17 januari 2025.
De tekst bestaat uit vijf blokken. ICT-risicobeheer staat in de artikelen 5 tot en met 16. Incidentbeheer en -melding lopen van artikel 17 tot en met artikel 23. Tests van digitale operationele weerbaarheid beslaan de artikelen 24 tot en met 27. Het ICT-risico van derde partijen — waar de meeste leveranciers DORA voor het eerst tegenkomen — loopt van artikel 28 via het toezichtkader tot artikel 44. Informatiedeling sluit de reeks af in artikel 45.
Twee bepalingen zetten de toon. Artikel 5, lid 2, verplicht het leidinggevend orgaan het ICT-risicobeheerkader vast te stellen, goed te keuren en erop toe te zien, en maakt het verantwoordelijk voor de uitvoering — dezelfde persoonlijke verantwoordelijkheid die NIS2 in artikel 20 bij de leiding legt. En artikel 9, lid 1, verplicht financiële entiteiten de beveiliging en werking van hun ICT-systemen doorlopend te bewaken en te beheersen. Dat woord doet werk: een controle die doorlopend heet, bewijst u niet met een document dat eens per jaar wordt gemaakt.
Officiële tekst: Regulation (EU) 2022/2554
Twee doelgroepen, en de tweede is meestal verrast
DORA bindt financiële entiteiten rechtstreeks — banken, verzekeraars en herverzekeraars, beleggingsondernemingen, betaal- en elektronischgeldinstellingen, handelsplatformen, aanbieders van cryptoactivadiensten en de rest van de lijst in artikel 2. Die ondernemingen weten dat ze onder DORA vallen.
Voor ICT-dienstverleners van derden ligt het anders. Tenzij de Europese toezichthoudende autoriteiten u op grond van artikel 31 als kritiek aanmerken, reguleert DORA u niet rechtstreeks. Het bereikt u via uw klanten, en stevig. Artikel 28, lid 4, verplicht de financiële entiteit tot due diligence vóór ondertekening. Artikel 28, lid 5, staat alleen contracten toe met aanbieders die passende normen voor informatiebeveiliging naleven en verlangt, voor diensten die kritieke of belangrijke functies ondersteunen, dat de entiteit terdege rekening houdt met het gebruik van de meest actuele en hoogwaardigste informatiebeveiligingsnormen door de aanbieder. Artikel 30 legt vervolgens vast wat het contract moet bevatten.
Voor de meeste leveranciers komt DORA dus niet als een brief van een toezichthouder. Het komt als een due-diligencevragenlijst met vijftig punten van de inkoopafdeling van een klant, gevolgd door contractteksten die u niet hebt opgesteld, gevolgd door dezelfde vragenlijst van de volgende klant drie weken later.
De praktische consequentie mag helder gezegd worden: voor een leverancier is DORA-gereedheid eerst een verkoopvraagstuk en pas daarna een compliancevraagstuk. Bedrijven die snel, consistent en met iets verifieerbaars erbij antwoorden, sluiten sneller af dan bedrijven die telkens opnieuw het spreadsheet openen.
Welke artikelen van buitenaf waarneembare sporen achterlaten
Het grootste deel van DORA is van buiten uw perimeter onzichtbaar, net als het grootste deel van NIS2. Een handvol bepalingen vormt de uitzondering, omdat zij precies regelen wat een client, een browser of een mailserver zelf kan zien.
| Bepaling | Wat zij vereist | Van buitenaf waarneembaar |
|---|---|---|
| Art. 8 | ICT-activa en hun afhankelijkheden identificeren, classificeren en documenteren; inventarissen bijhouden en actueel houden. | Het van buitenaf bereikbare deel van het landschap, en de cryptografische identiteiten die het bedienen. |
| Art. 9 | Doorlopende bewaking en beheersing; integriteit en vertrouwelijkheid van data in rust, in gebruik en onderweg; beveiliging van de middelen voor gegevensoverdracht; bescherming van cryptografische sleutels en versleuteling. | Elke TLS-handshake die uw publieke diensten voltooien, en de certificaten daarachter. |
| Art. 24–25 | Een programma voor weerbaarheidstests; artikel 25, lid 1, noemt onder de passende tests uitdrukkelijk kwetsbaarheidsbeoordelingen en -scans, opensourceanalyses en beoordelingen van netwerkbeveiliging. | Doorlopende externe beoordeling — een bouwsteen van het programma, nooit het programma zelf. |
| Art. 26–27 | Dreigingsgestuurde penetratietests voor entiteiten die daartoe verplicht zijn, met eisen aan de testers. | Niets. TLPT is een afgebakende oefening met een afspraak erachter. |
| Art. 28–30 | Een informatieregister van alle contractuele ICT-afspraken; due diligence vóór contractsluiting; verplichte contractinhoud. | De externe houding van de leverancier zelf, en de meeste technische gegevens die een registerregel nodig heeft. |
| RTS Art. 6 | Een gedocumenteerd beleid voor versleuteling en cryptografische controles, inclusief hoe cryptografische technologie wordt bijgewerkt naarmate de cryptanalyse vordert. | De algoritmen, sleutellengtes en protocolversies die uw landschap daadwerkelijk onderhandelt. |
| RTS Art. 7 | Een register van alle certificaten en certificaatopslagapparaten voor activa die kritieke of belangrijke functies ondersteunen, en tijdige vernieuwing vóór het verlopen. | Of het register met de werkelijkheid overeenkomt, en of vernieuwingen daadwerkelijk op tijd zijn gebeurd. |
Al het overige — incidentclassificatie, bedrijfscontinuïteit, exitplannen, toezicht door het bestuur, contractuele auditrechten — is intern of contractueel en geen enkel extern instrument kan het zien. Een product dat beweert DORA in zijn geheel te bewijzen, beschrijft iets dat het niet kan waarnemen.
De RTS zijn concreter dan de verordening
Artikel 15 van DORA droeg de Europese toezichthoudende autoriteiten op technische normen te ontwikkelen die de instrumenten, methoden, processen en beleidslijnen voor ICT-risicobeheer harmoniseren. Het resultaat is Gedelegeerde Verordening (EU) 2024/1774 van de Commissie van 13 maart 2024, en daar houden de cryptografie-eisen op abstract te zijn.
Artikel 6 vereist een gedocumenteerd beleid voor versleuteling en cryptografische controles, gebaseerd op een goedgekeurde dataclassificatie en ICT-risicobeoordeling. Artikel 6, lid 2, bepaalt wat het moet dekken: versleuteling van data in rust en onderweg, van data in gebruik waar nodig, van interne netwerkverbindingen en van verkeer met externe partijen. Artikel 6, lid 3, vereist criteria voor het kiezen van cryptografische technieken die rekening houden met toonaangevende praktijken en normen, en verplicht een entiteit die daaraan niet kan voldoen tot mitigerende en bewakende maatregelen.
Dan volgt de bepaling die het meest de moeite waard is. Artikel 6, lid 4, vereist dat het beleid voorziet in het zo nodig bijwerken of wijzigen van de cryptografische technologie op basis van ontwikkelingen in de cryptanalyse. Dat is crypto-agility, vastgelegd in Europees financieel recht, jaren voordat iemand het eens wordt over een datum voor post-quantummigratie. Artikel 6, lid 5, maakt het af: elke mitigerende maatregel op grond van lid 3 of 4 moet worden vastgelegd, met een onderbouwde toelichting — een bewijsplicht die in de tekst staat en er niet uit hoeft te worden afgeleid.
Artikel 7 gaat over sleutelbeheer, en twee van zijn leden zijn ongewoon concreet. Artikel 7, lid 4, vereist een actueel gehouden register van alle certificaten en certificaatopslagapparaten, dat ten minste ICT-activa omvat die kritieke of belangrijke functies ondersteunen. Artikel 7, lid 5, vereist tijdige vernieuwing van certificaten vóór het verlopen. Beide zijn meetbaar, beide toetsbaar aan de werkelijkheid, en beide precies het soort gegeven dat een spreadsheet al een kwartaal na het opstellen niet meer weergeeft.
Officiële tekst: Delegated Regulation (EU) 2024/1774
Waarom het beleid niet het bewijs is
Beleid is een ontwerpmaatregel: het zegt wat er zou moeten gebeuren. Toezicht en klant-due-diligence vragen naar wat er werkelijk is gebeurd, over de hele periode en over het hele landschap. Dat is werking in de praktijk, en dat is een ander document.
DORA is hierover ongewoon expliciet, wat het doel makkelijker haalbaar maakt dan bij een tekst die alleen beleid eist. Artikel 6, lid 5, van de RTS vraagt mitigerende maatregelen vast te leggen en toe te lichten. Artikel 28, lid 3, verplicht het informatieregister op verzoek aan de bevoegde autoriteit te overleggen. Artikel 24, lid 5, vereist procedures om elk door tests aan het licht gebracht probleem te prioriteren, te classificeren en te verhelpen — een herstelregistratie, geen bevindingenlijst.
Toegepast op het cryptografische landschap wordt het verschil concreet. Beleid dat sterke transportbeveiliging voorschrijft, is ontwerp. Een registratie die laat zien wat elk publiek eindpunt elf maanden lang wekelijks onderhandelde, dat er vier uitzonderingen op gedateerde momenten opdoken en dat elk daarvan binnen een vastgestelde termijn werd gesloten, is werking in de praktijk. Alleen het tweede beantwoordt de vraag om het te laten zien.
Het informatieregister, en waarom de vragenlijsten strenger werden
Artikel 28, lid 3, verplicht elke financiële entiteit een informatieregister bij te houden en te actualiseren van alle contractuele afspraken over ICT-diensten, op entiteitsniveau en op subgeconsolideerd en geconsolideerd niveau, met onderscheid tussen afspraken die kritieke of belangrijke functies ondersteunen en de overige. Entiteiten rapporteren ten minste jaarlijks aan hun bevoegde autoriteit over nieuwe afspraken, categorieën aanbieders en de betrokken diensten, en moeten het volledige register op verzoek overleggen.
Een register is niet beter dan de gegevens in zijn regels, en de meeste daarvan zijn van de leverancier: rechtspersoon en identificatiecode, soort ICT-dienst, waar de dienst wordt verricht en waar data worden verwerkt en opgeslagen, onderaannemingsafspraken, en de voorwaarden voor audit, exit en teruggave van data. Artikel 30, lid 2, maakt verschillende daarvan tot uitdrukkelijke contractuele eisen — waaronder de plicht de betrokken regio's of landen te noemen en de klant vooraf te informeren over wijzigingen.
Daarom krijgen leveranciers aan de Europese financiële sector nu van elke klant dezelfde gestructureerde vragenset, meerdere keren per jaar, in net iets andere sjablonen. De informatie verandert zelden. De kosten zitten volledig in het opnieuw beantwoorden.
Eén grens verdient eerlijkheid: het register is een verplichting van de financiële entiteit en kan niet worden uitbesteed. Een leverancier kan er niet aan voldoen. Wat een leverancier wél kan, is het invullen goedkoop maken — de antwoorden één keer publiceren, actueel houden en bewijs meeleveren dat een beoordelaar zonder telefoontje kan verifiëren.
De vierde partij achter uw derde partij
Artikel 29 draagt de titel "Voorlopige beoordeling van het ICT-concentratierisico op entiteitsniveau", en de twee leden stellen verschillende vragen. Artikel 29, lid 1, gaat over concentratie bij de directe aanbieder: leidt de afspraak ertoe dat een moeilijk vervangbare aanbieder wordt gecontracteerd, of dat meerdere kritieke afspraken bij dezelfde of nauw verbonden aanbieders worden gestapeld? Artikel 29, lid 2, gaat over wat achter die aanbieder zit: als een contract uitbesteding van een kritieke of belangrijke functie toestaat, moet de entiteit voordelen en risico's afwegen, onderaannemers in derde landen meewegen en beoordelen of lange of complexe uitbestedingsketens haar vermogen om de functie nog te kunnen bewaken aantasten.
In de vertrouwenslaag krijgt die abstracte vraag een heel concrete vorm. Welke certificaatautoriteit de certificaten in het hele landschap ondertekent. Naar wiens nameservers de zones delegeren. Op wiens mailinfrastructuur de domeinen steunen. Dit zijn gedeelde bovenliggende afhankelijkheden die niemand bewust heeft gecontracteerd, en ze concentreren zich in stilte: een vertrouwensintrekking bij één certificaatautoriteit of een storing bij één DNS-aanbieder haalt alles wat ervan afhing tegelijk onderuit.
Het nuttige eraan is dat juist deze concentratie van buitenaf meetbaar is, voor uw landschap en dat van uw leveranciers, zonder medewerking van wie dan ook. Of een bepaalde concentratie aanvaardbaar is, blijft uw risicobeslissing — maar u kunt die niet nemen over een afhankelijkheid die u nooit hebt geteld.
Wat SkyQon bewijst, precies gezegd
Het DORA-bewijs van SkyQon omvat acht categorieën. Elke categorie noemt de bepaling waaraan zij bijdraagt en een dekkingsniveau dat op het document zelf staat; de formulering komt uit een geversioneerde mapping die woordelijk in het ondertekende rapport wordt overgenomen — wat u hier leest, leest een beoordelaar daar dus ook.
| Bewijscategorie | Bepaling | Dekking |
|---|---|---|
| Cryptografie en crypto-agility — post-quantumgereedheid van het certificatenlandschap en het vermogen te migreren naarmate de cryptanalyse vordert | Art. 9 / RTS Art. 6 | Direct |
| Transport- en certificaathygiëne — protocolversies, geldigheid en verloop, sleutel- en handtekeningsterkte, eIDAS-kwalificatie | Art. 9 | Direct |
| E-mailauthenticatie — SPF-, DKIM-, DMARC- en TLS-RPT-status over de bewaakte domeinen | Art. 9 | Direct |
| DNS-beveiliging — DNSSEC, CAA en DNS-hygiëne over de bewaakte domeinen | Art. 9 | Direct |
| Doorlopend bewijs van het aanvalsoppervlak — schaduw-, verkeerd geconfigureerde en dode activa, als input voor het kwetsbaarheidsdeel van de tests | Art. 24–25 | Ondersteunend |
| Continuïteit van de bewaking — aangetoonde continuïteit van externe bewaking over de periode | Art. 24–25 | Ondersteunend |
| Register van cryptografische identiteiten — een ontdubbeld register van elk certificaat en elke identiteit over gescande, automatisch vernieuwde, ontdekte en niet-TLS-activa | Art. 8 | Ondersteunend |
| Vierde partij en concentratie — gedeelde bovenliggende afhankelijkheden voor certificaatautoriteit, DNS en e-mail, en hoe geconcentreerd die zijn | Art. 28–30 | Ondersteunend |
Vier direct, vier ondersteunend, geen ervan omschreven als compliance. Direct betekent dat onze telemetrie het primaire bewijs voor die bepaling is. Ondersteunend betekent dat het één van meerdere bouwstenen is die u nog steeds zelf moet samenbrengen.
Aan de leverancierskant voedt dezelfde telemetrie een deelbare trustpagina die uw financiële klanten zonder account kunnen lezen, een set velden voor het informatieregister die u één keer invult, een gegenereerd addendum bij artikel 30, en een ondertekend bewijsrapport met een inhoudshash die iedereen kan narekenen bij onze publieke verifier. Leveranciers die u zelf registreert, worden beoordeeld op dezelfde publieke signalen, zodat de concentratievraag een laag verder naar buiten kan worden gesteld.
Wat het niet bewijst
Incidentmelding op grond van de artikelen 17 tot en met 23 valt buiten het product. Wij detecteren en voorzien van tijdstempels; wij dienen niets in bij een nationale bevoegde autoriteit. Die indieningen volgen de volgorde van artikel 19 — eerste melding, tussentijds rapport en eindrapport — op sjablonen en binnen termijnen die op grond van artikel 20 zijn vastgesteld.
Dreigingsgestuurde penetratietests op grond van de artikelen 26 en 27 vallen volledig buiten het bereik. Dat geldt ook voor de koperskant van het register: SkyQon levert bewijs aan de leverancierskant en is geen governanceplatform dat het informatieregister van een financiële entiteit voor haar beheert.
Twee grenzen binnen wat we wél dekken. De concentratieanalyse meet afhankelijkheden van certificaatautoriteit, DNS en e-mail; concentratie bij hosting, op netwerkniveau en bij contentdistributie zit er niet in, omdat we daarvoor geen betrouwbare bron hebben en een slechte gevolgtrekking erger zou zijn dan een verklaarde leemte. En de leveranciersbeoordeling meet een extern vertrouwensoppervlak — geen securityrating op basis van breach- of botnettelemetrie; dat is een andere productcategorie met andere data erachter.
Ten slotte de framing. Alles wordt beschreven als afgestemd op DORA, nooit als DORA-compliance of -certificering. Artikel 5, lid 2, legt goedkeuring en toezicht bij uw leidinggevend orgaan, en geen enkel document van welke leverancier dan ook verplaatst dat.
Een praktische volgorde
- Bepaal aan welke kant van het contract u staat. De verplichtingen rusten op financiële entiteiten. Leveranciers erven ze via de artikelen 28 tot en met 30. Veel bedrijven zijn allebei, en de twee rollen vragen uit dezelfde gegevens verschillende documenten.
- Bouw het certificatenregister voordat iemand erom vraagt. RTS-artikel 7, lid 4, verlangt er een dat ten minste kritieke of belangrijke functies dekt en actueel wordt gehouden. Elke serieuze due-diligencevragenlijst vraagt u het te beschrijven. Het in kaart brengen van het landschap is het deel dat weken kost.
- Maak vernieuwingsbewijs een bijproduct. Artikel 7, lid 5, wil tijdige vernieuwing vóór het verlopen. Het bewijs is een gedateerde registratie van vernieuwingen die op tijd plaatsvonden — automatisch vast te leggen, want achteraf is die niet te reconstrueren.
- Beantwoord de clausule over crypto-agility met een plan, niet met een bewering. Artikel 6, lid 4, verwacht bepalingen om cryptografische technologie te wijzigen naarmate de cryptanalyse vordert. Kunt u dat nog niet, dan verwacht artikel 6, lid 5, dat de mitigatie en de redenering worden vastgelegd. Een inventaris van wat u vandaag draait, is de eerste helft van beide antwoorden.
- Schrijf uw registerantwoorden één keer. Rechtspersoon, dienstsoort, locaties, subverwerkers, beveiligingscontact, meldtermijnen, hersteldoelstellingen, exitvoorwaarden. Publiceer ze waar een klant zichzelf kan bedienen, en de vijfde vragenlijst kost wat de eerste kostte — niets.
- Tel uw bovenliggende concentratie voordat een klant dat voor u doet. Eén certificaatautoriteit, één DNS-aanbieder en één mailplatform achter een heel landschap is een verdedigbare keuze en een onverdedigbare verrassing. Het verschil is of u het getal mee naar de vergadering nam.
Veelgestelde vragen
Bestaat er zoiets als DORA-certificering?
Nee. DORA legt verplichtingen op aan financiële entiteiten en creëert een toezichtregime voor aanbieders die op grond van artikel 31 als kritiek zijn aangemerkt. Niets erin certificeert iemand als compliant, en geen leverancier kan zo'n status verlenen. Beschouw de claim als een signaal over de leverancier.
Geldt DORA voor mij als ik alleen software aan een bank verkoop?
Niet rechtstreeks, tenzij u bent aangemerkt als kritieke ICT-dienstverlener van derden. Het bereikt u via de verplichtingen van uw klant onder de artikelen 28 tot en met 30: due diligence vóór ondertekening, specifieke contractclausules en een registerregel die actueel moet blijven.
Welk artikel gaat over cryptografie?
Artikel 9 op niveau 1 — met name lid 2 over data in rust, in gebruik en onderweg, lid 3, punt a), over de beveiliging van de middelen voor gegevensoverdracht, en lid 4, punt d), over sleutelbescherming en versleuteling. Het detail dat in de praktijk telt, staat in de RTS: artikel 6 voor versleuteling en cryptografische controles, artikel 7 voor sleutel- en certificaatbeheer.
Waar past post-quantum in?
In RTS-artikel 6, lid 4, dat bepalingen vereist om cryptografische technologie bij te werken naarmate de cryptanalyse vordert. Post-quantumcryptografie wordt niet met naam genoemd — dat hoefde ook niet. Een migratieplan is het natuurlijke antwoord, en een inventaris van wat u nu draait, is de voorwaarde daarvoor.
Is een externe scan genoeg voor de artikelen 24 en 25?
Nee. Artikel 25, lid 1, noemt kwetsbaarheidsbeoordelingen en -scans tussen vele testsoorten, binnen een programma dat artikel 24 u verplicht te ontwerpen, met onafhankelijke testers uit te voeren en ten minste jaarlijks toe te passen op systemen die kritieke of belangrijke functies ondersteunen. Doorlopende externe beoordeling voedt het; ze vervangt het niet.
Waarin verschilt dit van NIS2?
Ander toepassingsgebied, andere toezichthouders, maar eronder grotendeels hetzelfde technische bewijs. DORA is een verordening die sinds januari 2025 rechtstreeks geldt; NIS2 is een richtlijn die u via nationaal recht bindt. Produceert u al bewijs voor het één, dan is het meeste ervan opnieuw bruikbaar voor het ander.
Lees de bijbehorende gids: NIS2 artikel 21(2) — wat als bewijs telt
Produceer dit bewijs voor uw eigen landschap
De add-on DORA Trust Center maakt van doorlopende bewaking een deelbare pagina over leveranciersgereedheid, ondersteuning voor het informatieregister, een gegenereerd addendum bij artikel 30 en een ondertekend, met een hash verifieerbaar bewijsrapport — met dekkingsniveaus die eerlijk op het document zelf staan. Hij is beschikbaar als add-on op elk betaald abonnement. Begin met een gratis controle om te zien hoe het uwe er nu voor staat.