DORA 2026-roadmap voor ICT-risico, leveranciers en TLPT

De DORA 2026-zoekpaniek gaat niet echt over regelgeving, maar over bewijsmateriaal

Het is 08:15 uur op een maandag en de CISO van een middelgrote betaalinstelling heeft drie browsertabbladen openstaan: “DORA RTS/ITS-checklist”, “DORA-template voor ICT-derdenregister” en “DORA TLPT-vereisten voor financiële entiteiten”.

De compliancemanager heeft al gevraagd of het bestuursdossier de nieuwste workflow voor incidentclassificatie moet bevatten. Inkoop wil een nieuw cloudanalyseplatform onboarden. De COO wil zekerheid dat de SaaS-aanbieder voor core banking geen verborgen blootstelling heeft aan onderaannemers buiten de EU. Interne Audit vraagt om een testkalender. Juridische Zaken vraagt of de GDPR-meldtermijnen voor inbreuken zijn afgestemd op DORA-incidentmelding.

Niemand stelt een theoretische vraag. De vraag is: “Kunnen we dit vrijdag aantonen?”

Dat is het echte DORA 2026-probleem. De meeste financiële entiteiten begrijpen de hoofdverplichtingen: ICT-risicobeheer, melding van ICT-gerelateerde incidenten, testen van digitale operationele weerbaarheid, ICT-risicobeheer voor derde partijen en versterkt toezicht op kritieke ICT-aanbieders. Het moeilijke deel is het omzetten van technische reguleringsnormen (RTS), technische uitvoeringsnormen (ITS) en verplichtingen op artikelniveau in beheerste, herhaalbare en auditeerbare praktijk.

De Digital Operational Resilience Act verplicht financiële entiteiten tot robuuste capaciteiten voor ICT-risicobeheer, beleid voor het beheren en melden van ICT-gerelateerde incidenten, het testen van ICT-systemen, beheersmaatregelen en processen, en gestructureerd toezicht op ICT-dienstverleners van derde partijen. DORA verwacht ook proportionaliteit. Een kleinere beleggingsonderneming en een grote bankengroep hebben geen identieke modellen voor bewijsmateriaal nodig, maar beide moeten kunnen aantonen dat hun aanpak passend is voor hun omvang, risicoprofiel, complexiteit en kritieke functies.

DORA-projecten mislukken meestal om een van drie redenen. Ten eerste behandelt de organisatie DORA als een juridische mappingoefening in plaats van als een operationeel model. Ten tweede wordt leveranciersrisico vastgelegd als een leverancierslijst in plaats van als afhankelijkheid, vervangbaarheid en concentratierisico. Ten derde wordt testen gezien als een jaarlijkse penetratietest in plaats van als een weerbaarheidsprogramma met kwetsbaarheidsscans, scenariotests, incidentoefeningen en, waar van toepassing, threat-led penetratietesten, vaak gezocht als TLPT.

Een betere aanpak is één systeem voor bewijsmateriaal op te bouwen dat beleid, registers, eigenaren, risico’s, incidenten, leveranciers, testen, herstel en directiebeoordeling met elkaar verbindt. Daar helpen Clarysec’s Zenith Blueprint, gebruiksklare beleidsdocumenten en Zenith Controls financiële entiteiten om DORA om te zetten van een deadline in een operationeel ritme.

Begin met het DORA-operationele model, niet met de RTS/ITS-spreadsheet

Veel teams beginnen met een spreadsheet met DORA-artikelen en RTS/ITS-vereisten. Dat is nuttig, maar niet voldoende. Een spreadsheet kan aangeven wat moet bestaan. Hij wijst geen eigenaren toe, definieert geen beoordelingsfrequentie, bewaart geen bewijsmateriaal en toont niet aan dat een beheersmaatregel daadwerkelijk werkt.

In de Zenith Blueprint: een 30-stappenroadmap voor auditors behandelt Clarysec dit in de fase Risicobeheer, stap 14, beleid voor risicobehandeling en regelgevende kruisverwijzingen:

“DORA: Voor ondernemingen in de financiële sector vereist DORA een ICT-risicobeheerkader dat sterk aansluit op wat we hebben gedaan: risico’s identificeren, beheersmaatregelen (en beleid) invoeren en deze testen. DORA legt ook nadruk op incidentrespons en rapportage, en op toezicht op ICT-dienstverleners van derde partijen.”

De praktische boodschap is eenvoudig: bouw “DORA-naleving” niet als parallelle bureaucratie. Bouw een risicogebaseerde ICT-governancelaag die DORA-vereisten koppelt aan beleid, registers, eigenaren van beheersmaatregelen, testregistraties, leveranciersbewijsmateriaal en directiebeoordeling.

Een praktisch DORA-operationeel model moet vijf pijlers voor bewijsmateriaal hebben:

Voor gereguleerde financiële entiteiten zet deze structuur RTS/ITS-implementatie om in een systeem voor bewijsmateriaal dat gereed is voor audits. Voor entiteiten die onder vereenvoudigd ICT-risicobeheer vallen, kan hetzelfde model worden afgeschaald naar minder documenten en eenvoudigere registers. De kerndisciplines blijven gelijk: identificeren, beschermen, detecteren, reageren, herstellen, testen en leveranciers aansturen.

ICT-risicobeheer: het register is de regiekamer

De verwachtingen van DORA voor ICT-risicobeheer vereisen dat financiële entiteiten ICT-risico’s identificeren, classificeren en beheren over systemen, gegevens, processen, kritieke of belangrijke functies en afhankelijkheden van derde partijen heen.

De meest voorkomende tekortkoming is niet het ontbreken van een risicoregister. Het probleem is dat het register losstaat van leveranciers, activa, incidenten en tests. DORA beloont geen fraaie spreadsheet als die niet kan verklaren waarom een leverancier met hoog risico geen exitplan heeft, of waarom een kritiek platform voor klantbetalingen niet is getest.

Clarysec’s SME Beleid inzake risicobeheer geeft kleinere financiële entiteiten een beknopte baseline voor bewijsmateriaal:

“Elke risicovermelding moet het volgende bevatten: beschrijving, waarschijnlijkheid, impact, score, eigenaar en behandelplan.”
Uit sectie “Governancevereisten”, beleidsclausule 5.1.2.

Voor grotere financiële entiteiten vereist Clarysec’s Enterprise Beleid inzake risicobeheer een formeler proces:

“Een formeel risicobeheerproces moet worden onderhouden in overeenstemming met ISO/IEC 27005 en ISO 31000, en moet risico-identificatie, analyse, evaluatie, behandeling, monitoring en communicatie omvatten.”
Uit sectie “Governancevereisten”, beleidsclausule 5.1.

Dit onderscheid is belangrijk. DORA is proportioneel, maar proportionaliteit betekent niet informeel. Een kleine betaalinstelling kan een gestroomlijnd register gebruiken, terwijl een bankengroep geïntegreerde GRC-tooling kan inzetten. In beide gevallen zal de auditor nog steeds vragen: Wat zijn uw ICT-risico’s? Wie is eigenaar? Wat is het behandelplan? Welk bewijsmateriaal toont voortgang aan? Hoe beïnvloeden leveranciers en kritieke functies de score?

Een sterk DORA ICT-risicoregister moet deze velden bevatten:

Een praktische oefening is om één kritieke ICT-dienst te nemen, bijvoorbeeld een in de cloud gehost platform voor transactiemonitoring, en binnen 20 minuten een risicovermelding aan te maken. Beschrijf het storings- of compromitteringsscenario, scoor waarschijnlijkheid en impact, wijs een eigenaar toe, identificeer gerelateerde leveranciers, definieer een behandelplan en koppel de vermelding aan bewijsmateriaal zoals leveranciers-due diligence, SLA, incidentclausules, BIA, DR-testresultaten, monitoringdashboards en toegangsrechtenbeoordelingen.

Die ene vermelding wordt de rode draad die DORA ICT-risicobeheer, toezicht op derde partijen, incidentdetectie, continuïteit en testen met elkaar verbindt. Zo wordt een risicoregister een regiekamer, geen archiefkast.

RTS/ITS-gereedheid: koppel verplichtingen aan beleid, niet aan beloftes

De praktische zoekterm “DORA RTS/ITS-checklist” betekent meestal: “Welke documenten verwachten toezichthouders?” Financiële entiteiten moeten vermijden dat zij naleving toezeggen via generieke verklaringen. Zij hebben een mapping nodig die elke verplichting verbindt met een beleid, beheersmaatregel, eigenaar en bewijsmateriaal.

Clarysec’s SME Beleid inzake juridische en regelgevende naleving legt een eenvoudig governanceanker vast:

“De algemeen directeur moet een eenvoudig, gestructureerd nalevingsregister onderhouden waarin het volgende is opgenomen:”
Uit sectie “Governancevereisten”, beleidsclausule 5.1.1.

Voor DORA 2026 moet uw nalevingsregister het volgende bevatten:

• DORA-verplichting of RTS/ITS-vereistengebied.
• Toepasbaarheid, inclusief proportionaliteitsonderbouwing.
• Verwijzing naar beleid of procedure.
• Eigenaar van de beheersmaatregel.
• Locatie van bewijsmateriaal.
• Beoordelingsfrequentie.
• Openstaande hiaten en deadline voor herstelmaatregelen.
• Status van rapportage aan bestuur of management.

Dit sluit aan op de aanpak van Zenith Blueprint stap 14: koppel regelgevende vereisten aan ISMS-beheersmaatregelen en beleid, zodat niets tussen wal en schip valt. In plaats van te vragen “Voldoen we aan DORA?”, kan het leiderschap vragen: “Welke DORA-bewijsitems zijn achterstallig, welke kritieke leveranciers missen exitplannen en welke testactiviteiten hebben nog geen bewijsmateriaal voor herstelmaatregelen opgeleverd?”

ICT-risico van derde partijen: concentratie, vervangbaarheid en onderaannemers

DORA heeft het leveranciersgesprek in de financiële sector veranderd. Het is niet langer voldoende om te vragen of een aanbieder een beveiligingscertificering, verzekering of verwerkersovereenkomst heeft. Financiële entiteiten moeten beoordelen of een aanbieder concentratierisico creëert, of de aanbieder realistisch kan worden vervangen, of meerdere kritieke diensten afhankelijk zijn van één leverancier of gelieerde leveranciers, en of uitbesteding aan onderaannemers aanvullende juridische of weerbaarheidsblootstelling introduceert.

Dit is het vraagstuk dat veel CISO’s wakker houdt. Een onderneming kan voor transactieverwerking, data-analyse, klantportalen en interne samenwerking afhankelijk zijn van één grote Cloud Service Provider (CSP). Als die aanbieder langdurige uitval, een geschil met een toezichthouder of een falen van een onderaannemer ondervindt, is de vraag niet alleen: “Hebben we een contract?” De vraag is: “Kunnen we kritieke diensten voortzetten, met klanten communiceren en aantonen dat we de afhankelijkheid begrepen voordat deze faalde?”

Clarysec’s SME Beleid inzake beveiliging van derde partijen en leveranciers legt de basis:

“Een leveranciersregister moet worden onderhouden en bijgewerkt door de administratieve of inkoopcontactpersoon. Het moet het volgende bevatten:”
Uit sectie “Governancevereisten”, beleidsclausule 5.4.

Voor enterpriseprogramma’s gaat Clarysec’s Beleid inzake beheer van leveranciersafhankelijkheidsrisico’s dieper in op DORA-specifieke afhankelijkheid en vervangbaarheid:

“Register van leveranciersafhankelijkheden: de VMO moet een actueel register bijhouden van alle kritieke leveranciers, met gegevens zoals geleverde diensten/producten; of de leverancier sole-source is; beschikbare alternatieve leveranciers of vervangbaarheid; actuele contractvoorwaarden; en een beoordeling van de impact als de leverancier zou falen of gecompromitteerd zou raken. Het register moet leveranciers met een hoge afhankelijkheid duidelijk identificeren (bijvoorbeeld leveranciers waarvoor geen snel alternatief beschikbaar is).”
Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.1.

Dit is het leveranciersbewijsmateriaal dat DORA-projecten vaak missen. Een leveranciersregister zegt wie de leverancier is. Een afhankelijkheidsregister zegt wat er gebeurt wanneer de leverancier faalt.

De fase Controls in Action van de Zenith Blueprint, stap 23, organisatorische beheersmaatregelen, biedt een praktische workflow voor leverancierstoezicht. Deze beveelt aan een volledige leverancierslijst samen te stellen, leveranciers te classificeren op basis van toegang tot systemen, gegevens of operationele controle, te verifiëren dat beveiligingsverwachtingen in contracten zijn opgenomen, risico’s van onderaannemers en downstreamrisico’s te beheren, wijzigings- en monitoringprocedures te definiëren en een proces voor beoordeling van clouddiensten op te zetten.

In Zenith Controls: de cross-compliancegids wordt ISO/IEC 27002:2022-beheersmaatregel 5.21, Beheer van informatiebeveiliging in de ICT-toeleveringsketen, gemapt als een preventieve beheersmaatregel ter ondersteuning van vertrouwelijkheid, integriteit en beschikbaarheid. Deze is gekoppeld aan beveiliging van leveranciersrelaties en het cybersecurityconcept Identify. De beheersmaatregel verbindt veilige engineering, veilige programmeerpraktijken, toegangscontrole, beveiligingstesten, bewijsverzameling, veilige ontwikkelingslevenscyclus en uitbestede ontwikkeling.

Dat is precies de realiteit van DORA-toezicht op derde partijen. Leveranciersrisico is niet alleen inkoop. Het raakt architectuur, ontwikkeling, incidentrespons, toegangscontrole, bedrijfscontinuïteit en Juridische Zaken.

Vanuit cross-complianceperspectief koppelt Zenith Controls beveiliging van de ICT-toeleveringsketen aan GDPR Articles 28 en 32, omdat verwerkers en subverwerkers moeten worden geselecteerd en onder toezicht moeten staan met passende technische en organisatorische maatregelen. Het ondersteunt NIS2-verwachtingen voor beveiliging van de toeleveringsketen, waaronder Article 21-maatregelen voor cyberbeveiligingsrisicobeheer en Article 22 gecoördineerde risicobeoordelingen van de toeleveringsketen. Het sluit sterk aan op DORA Articles 28, 29 en 30, waar ICT-risico’s van derde partijen, concentratierisico, sub-outsourcing en contractuele bepalingen centraal staan.

Ondersteunende normen versterken het bewijsmateriaal. ISO/IEC 27036-3:2021 ondersteunt beveiliging bij ICT-inkoop en leveranciersselectie. ISO/IEC 20243:2018 ondersteunt integriteit van vertrouwde technologische producten en beveiliging van de toeleveringsketen. ISO/IEC 27001:2022 verbindt dit met risicobehandeling en leveranciersbeheersmaatregelen in Annex A.

Incidentmelding: bouw de escalatieketen vóór het incident

DORA-incidentmelding gaat niet alleen over het indienen van een melding. Het gaat om detecteren, classificeren, escaleren, communiceren en leren van ICT-gerelateerde incidenten. Financiële entiteiten moeten processen onderhouden voor ICT-incidentbeheer en -rapportage, met gedefinieerde rollen, classificatiecriteria, meldroutes en post-incidentanalyse.

Clarysec’s SME Incidentresponsbeleid verbindt responstermijnen voor incidentrespons met wettelijke vereisten:

“Responstermijnen, inclusief verplichtingen voor gegevensherstel en melding, moeten worden gedocumenteerd en afgestemd op wettelijke vereisten, zoals de GDPR 72-uurs meldplicht voor inbreuken in verband met persoonsgegevens.”
Uit sectie “Governancevereisten”, beleidsclausule 5.3.2.

Voor enterpriseomgevingen voegt Clarysec’s Incidentresponsbeleid het perspectief van escalatie rond gereguleerde gegevens toe:

“Als een incident leidt tot bevestigde of waarschijnlijke blootstelling van persoonsgegevens of andere gereguleerde gegevens, moeten Juridische Zaken en de FG beoordelen of het volgende van toepassing is:”
Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.4.1.

Het citaat eindigt bij het triggermoment, en precies daar falen veel incidentprocessen. Als de trigger onduidelijk is, discussiëren teams over meldplichten terwijl de klok al loopt.

De fase Controls in Action van de Zenith Blueprint, stap 16, People Controls II, benadrukt door personeel gedreven incidentmelding. Werknemers, contractanten en stakeholders moeten weten hoe zij potentiële beveiligingsincidenten herkennen en melden via eenvoudige kanalen zoals een specifieke mailbox, portaal of hotline. De Blueprint koppelt dit aan GDPR Article 33, NIS2 Article 23 en DORA Article 17, omdat rapportage aan toezichthouders begint met interne bewustwording en escalatie.

In Zenith Controls wordt ISO/IEC 27002:2022-beheersmaatregel 5.24, planning en voorbereiding van informatiebeveiligingsincidentbeheer, gemapt als een corrigerende beheersmaatregel ter ondersteuning van vertrouwelijkheid, integriteit en beschikbaarheid, afgestemd op Respond en Recover. De beheersmaatregel houdt rechtstreeks verband met gebeurtenisbeoordeling, leren van incidenten, logging en monitoring, beveiliging tijdens verstoringen, continuïteit van informatiebeveiliging en contact met autoriteiten. De gids koppelt dit aan DORA Articles 17 tot en met 23 voor beheer, classificatie en rapportage van ICT-gerelateerde incidenten en vrijwillige melding van cyberdreigingen, GDPR Articles 33 en 34 voor melding van inbreuken, en NIS2 Article 23 voor incidentmelding.

Een DORA-gereed incidentproces moet het volgende omvatten:

• Duidelijke kanalen voor incidentintake.
• Criteria voor gebeurtenistriage en classificatie.
• Escalatieworkflow voor majeure ICT-gerelateerde incidenten.
• Beslispunten voor Juridische Zaken, FG en melding aan toezichthouders.
• Triggers voor incidentmelding door leveranciers.
• Vereisten voor behoud van bewijsmateriaal.
• Regels voor communicatie met topmanagement en bestuur.
• Post-incident evaluatie en geleerde lessen.
• Koppeling met updates van het risicoregister en remediatie van beheersmaatregelen.

Ondersteunende normen brengen structuur. ISO/IEC 27035-1:2023 biedt principes voor planning en voorbereiding op incidentbeheer. ISO/IEC 27035-2:2023 beschrijft stappen voor incidentenafhandeling. ISO/IEC 22320:2018 ondersteunt commandovoering, controle en gestructureerde crisiscommunicatie. Dit is belangrijk wanneer een ICT-uitval uitgroeit tot een klantimpactcrisis en de entiteit moet aantonen dat besluiten tijdig, gecoördineerd en op bewijsmateriaal gebaseerd waren.

Testen van digitale operationele weerbaarheid en TLPT: laat de test niet het incident worden

Testen is een van de meest gezochte DORA 2026-onderwerpen, omdat het zowel technisch als governance-intensief is. Financiële entiteiten moeten ICT-systemen, beheersmaatregelen en processen testen. Voor aangewezen entiteiten wordt geavanceerd testen zoals TLPT een centrale vereiste op grond van DORA Article 26.

De auditvraag is niet alleen: “Hebt u getest?” De vraag is: “Was de test risicogebaseerd, geautoriseerd, veilig, onafhankelijk waar vereist, geremedieerd en gekoppeld aan weerbaarheidsdoelstellingen?”

Clarysec’s Enterprise Beleid inzake beveiligingstesten en red teaming definieert het minimale testprogramma duidelijk:

“Soorten tests: Het beveiligingstestprogramma moet minimaal omvatten: (a) kwetsbaarheidsscans, bestaande uit geautomatiseerde wekelijkse of maandelijkse scans van netwerken en toepassingen om bekende kwetsbaarheden te identificeren; (b) penetratietesten, bestaande uit handmatige diepgaande tests van specifieke systemen of toepassingen door bekwame testers om complexe zwaktes te identificeren; en (c) red-teamoefeningen, bestaande uit scenariogebaseerde simulaties van echte aanvallen, inclusief social engineering en andere tactieken, om de detectie- en responsmogelijkheden van de organisatie als geheel te testen.”
Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.1.

Dit is de brug tussen routinematig testen en TLPT-volwassenheid. Kwetsbaarheidsscans vinden bekende zwaktes. Penetratietesten valideren exploitbaarheid. Red teaming test detectie en respons als systeem. TLPT moet, waar van toepassing, onderdeel zijn van een bestuurd testprogramma met scopebeheersing, veiligheidsregels, risicobeheer voor productie, vastlegging van bewijsmateriaal en opvolging van herstelmaatregelen.

De fase Controls in Action van de Zenith Blueprint, stap 21, behandelt de bescherming van informatiesystemen tijdens audit en testen. De Blueprint waarschuwt dat audits, penetratietesten, forensische beoordelingen en operationele evaluaties risico’s kunnen introduceren omdat zij verhoogde toegang, intrusieve tools of tijdelijke wijzigingen in systeemgedrag kunnen omvatten. De Blueprint koppelt dit aan GDPR Article 32, DORA-verwachtingen voor testen van digitale operationele weerbaarheid, NIS2-continuïteitszorgen en COBIT 2019-praktijken voor veilige uitvoering van audits en beoordelingen.

In Zenith Controls wordt ISO/IEC 27002:2022-beheersmaatregel 5.35, onafhankelijke beoordeling van informatiebeveiliging, gemapt als preventief en corrigerend, ter ondersteuning van vertrouwelijkheid, integriteit en beschikbaarheid. De beheersmaatregel houdt verband met naleving van beleid, managementverantwoordelijkheden, leren van incidenten, bescherming van registraties, verwijdering van informatie, logging en monitoring. Voor DORA liggen de relevante testverplichtingen primair in Articles 24 tot en met 27, inclusief Article 26 voor TLPT. Dit ondersteunt ook GDPR Article 32(1)(d), dat regelmatige tests en evaluaties van technische en organisatorische maatregelen vereist, en NIS2 Article 21, dat maatregelen voor cyberbeveiligingsrisicobeheer vereist.

Een DORA TLPT-gereedheidspakket moet het volgende bevatten:

De belangrijkste DORA-les is dat testbewijsmateriaal niet mag stoppen bij het rapport. Auditors zullen vragen of bevindingen op risico zijn geclassificeerd, toegewezen, geremedieerd en opnieuw getest. Zij kunnen ook controleren of testen kritieke of belangrijke functies omvatte, en niet alleen vanaf internet bereikbare bedrijfsmiddelen.

Bedrijfscontinuïteit en herstel na verstoringen: weerbaarheid moet operationeel zijn

DORA is regelgeving voor digitale operationele weerbaarheid. Herstel is net zo belangrijk als preventie. Een gedocumenteerd ICT-risicokader helpt niet als een uitval van een betaalplatform blootlegt dat hersteltijddoelstellingen nooit zijn getest, contactbomen voor leveranciers verouderd zijn en het crisisteam het niet eens wordt over wie met klanten communiceert.

Clarysec’s SME Beleid voor bedrijfscontinuïteit en herstel na verstoringen legt een duidelijke baseline vast:

“De organisatie moet zowel haar BCP- als DR-capaciteiten ten minste jaarlijks testen. Tests moeten het volgende omvatten:”
Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.4.1.

Het Enterprise Beleid voor bedrijfscontinuïteit en herstel na verstoringen begint met de business impact:

“Business Impact Analysis (BIA) moet ten minste jaarlijks worden uitgevoerd voor alle kritieke bedrijfseenheden en worden beoordeeld bij significante wijzigingen in systemen, processen of afhankelijkheden. BIA-output moet het volgende definiëren:”
Uit sectie “Governancevereisten”, beleidsclausule 5.2.

Voor DORA moet de BIA worden gekoppeld aan ICT-activa, leveranciers, incidentrespons en testen. Als de BIA “klantbetalingen” als kritieke functie identificeert, moet het register van leveranciersafhankelijkheden de processors, cloudservices en netwerkproviders identificeren die deze functie ondersteunen. Het risicoregister moet faalscenario’s bevatten. Het testplan moet validatie van weerbaarheid omvatten. Het incidentresponsplan moet escalatie en communicatie bevatten. De DR-test moet bewijsmateriaal opleveren, niet slechts een vergadernotitie.

Deze traceerbaarheid zet DORA-naleving om in een operationeel weerbaarheidssysteem.

Cross-compliance: één set bewijsmateriaal, veel auditvragen

Financiële entiteiten hebben zelden alleen met DORA te maken. Zij hebben vaak GDPR-verplichtingen, NIS2-blootstelling, contractuele beveiligingsverplichtingen, ISO/IEC 27001:2022-doelstellingen, interne-auditvereisten, klant-due diligence, SOC-verwachtingen en risicorapportage aan het bestuur. Het antwoord is niet om afzonderlijke bewijssilo’s te creëren. Het antwoord is een cross-compliancemodel voor bewijsmateriaal bouwen.

Zenith Controls is Clarysec’s kompas voor cross-compliance. Het verzint geen nieuwe verplichtingen. Het mapt officiële normen en raamwerken zodat organisaties kunnen begrijpen hoe één beheersgebied meerdere nalevingsuitkomsten ondersteunt.

Dit is belangrijk voor budget en governance. Een CISO kan aan het bestuur uitleggen dat verbetering van incidentclassificatie DORA-rapportage, GDPR-melding van inbreuken, NIS2-incidentenafhandeling en interne weerbaarheid ondersteunt. Een inkoopverantwoordelijke kan mapping van leveranciersafhankelijkheden rechtvaardigen omdat dit DORA-concentratierisico, GDPR-due diligence voor verwerkers en NIS2-beveiliging van de toeleveringsketen ondersteunt. Een testverantwoordelijke kan laten zien dat red-teamoefeningen en onafhankelijke beoordelingen DORA-testen, GDPR-evaluatie van beheersmaatregelen en bredere assurance ondersteunen.

Auditperspectief: hoe beoordelaars uw DORA-bewijsmateriaal zullen testen

DORA-gereedheid wordt concreet wanneer iemand om bewijsmateriaal vraagt. Verschillende auditors en beoordelaars benaderen hetzelfde onderwerp vanuit verschillende invalshoeken.

Een auditor met een ISO/IEC 27001:2022-perspectief begint met ISMS-logica: toepassingsgebied, risicobeoordeling, risicobehandeling, toepasselijkheid van Annex A-beheersmaatregelen, interne audit, directiebeoordeling en bewijsmateriaal dat beheersmaatregelen zijn geïmplementeerd. Voor beveiliging van de ICT-toeleveringsketen kijkt de auditor naar beleid, leveranciersclassificatie, contractuele clausules, due diligence en doorlopende monitoring. Voor incidentbeheer inspecteert de auditor het plan, rollen, escalatieroutes, tools en registraties. Voor testen verwacht de auditor geplande intervallen, onafhankelijkheid waar passend, remediatie en input voor de directiebeoordeling.

Een auditperspectief op basis van ISO/IEC 19011:2018 richt zich op de uitvoering van audits. In Zenith Controls vermeldt de auditmethodologie voor beveiliging van de ICT-toeleveringsketen dat auditors inkoopbeleid, RFP-sjablonen en leveranciersmanagementprocessen onderzoeken om te verifiëren dat ICT-specifieke beveiligingsvereisten zijn ingebed van aanschaf tot afvoer. Voor incidentbeheer onderzoeken auditors het incidentresponsplan op volledigheid en afstemming op beste praktijken. Voor onafhankelijke beoordeling zoeken auditors naar bewijsmateriaal dat onafhankelijke audits of beoordelingen zijn uitgevoerd.

Een ISO/IEC 27007:2020-perspectief is specifieker voor ISMS-audits. Zenith Controls merkt op dat auditors inkoopfunctionarissen, IT-beveiligingsmedewerkers en leveranciersmanagers kunnen interviewen om begrip en uitvoering van ICT-toeleveringsketenbeheersmaatregelen te beoordelen. Voor incidentvoorbereiding bevestigen zij dat een Incident Response Team bestaat en operationeel is. Voor onafhankelijke beoordeling verifiëren zij dat het interne-auditprogramma het volledige ISMS-toepassingsgebied dekt en over voldoende middelen beschikt.

Een testbeoordelaar die zich baseert op NIST SP 800-115 richt zich op de methodologie voor kwetsbaarheidsbeoordeling en penetratietesten. Deze kan onderzoeken of testscope, rules of engagement, bevindingen, ernstclassificaties, remediatie en hertesten zijn gedocumenteerd. Voor DORA TLPT betekent dit dat de beoordelaar geen genoegen neemt met een red-team-slidedeck. Er is bewijs nodig van governance, veiligheid, technische diepgang en afsluiting.

Een COBIT 2019- of ISACA-achtige auditor vraagt of governancedoelstellingen worden gehaald: wie is eigenaar van het proces, hoe worden prestaties gemeten, hoe worden uitzonderingen goedgekeurd en hoe ontvangt het management assurance.

De praktische DORA 2026-gereedheidschecklist

Gebruik deze checklist als werkbaseline om DORA-zoekvragen om te zetten in acties.

Governance en RTS/ITS-mapping

• Onderhoud een DORA-nalevingsregister met verplichtingsgebied, toepasselijkheid, eigenaar, bewijsmateriaal, beoordelingsfrequentie en status van hiaten.
• Koppel DORA-vereisten aan beleid, registers, beheersmaatregelen en managementrapportage.
• Definieer de proportionaliteitsonderbouwing voor vereenvoudigd of opgeschaald ICT-risicobeheer waar van toepassing.
• Wijs eindverantwoordelijkheid op directieniveau toe voor ICT-risico, incidentmelding, toezicht op derde partijen en testen.
• Neem DORA-status op in directiebeoordeling en risicorapportage aan het bestuur.

ICT-risicobeheer

• Onderhoud een ICT-risicoregister met beschrijving, waarschijnlijkheid, impact, score, eigenaar en behandelplan.
• Koppel risico’s aan kritieke of belangrijke functies.
• Koppel risico’s aan ICT-activa, leveranciers en processen.
• Beoordeel risico’s na majeure incidenten, leverancierswijzigingen, technologische wijzigingen of testbevindingen.
• Volg behandelacties tot afsluiting of formele risicoacceptatie.

Toezicht op ICT van derde partijen

• Onderhoud een leveranciersregister en een register van leveranciersafhankelijkheden.
• Identificeer leveranciers die kritieke of belangrijke functies ondersteunen.
• Beoordeel sole-source-leveranciers en vervangbaarheid.
• Beoordeel onderaannemers en sub-outsourcingafspraken.
• Neem beveiligings-, toegangs-, incidentmeldings-, audit- en exitclausules op in contracten.
• Monitor kritieke leveranciers ten minste jaarlijks of na materiële wijzigingen.
• Onderhoud exit- en noodplannen voor aanbieders met hoge afhankelijkheid.

Incidentbeheer en melding

• Onderhoud incidentresponsprocedures met duidelijke rollen en escalatieroutes.
• Definieer classificatiecriteria voor ICT-incidenten.
• Stem DORA-rapportagetriggers af op GDPR, NIS2 en contractuele meldplichten.
• Train werknemers en contractanten in kanalen voor incidentmelding.
• Onderhoud incidentlogboeken, besluitvormingsregistraties en bewijsmateriaal.
• Voer post-incident evaluaties uit en werk risico’s en beheersmaatregelen bij.

Testen, red teaming en TLPT

• Onderhoud een risicogebaseerde testkalender.
• Voer kwetsbaarheidsscans en penetratietesten uit met gedefinieerde intervallen.
• Gebruik scenariogebaseerde red-teamoefeningen om detectie en respons te testen.
• Definieer voor TLPT-gereedheid scope, rules of engagement, veiligheidsmaatregelen en leverancierscoördinatie.
• Bescherm productiesystemen tijdens testen.
• Volg bevindingen, remediatie, hertesten en geleerde lessen.
• Rapporteer testresultaten aan het management.

Continuïteit en herstel

• Voer jaarlijks een BIA uit voor kritieke bedrijfseenheden en werk deze bij na significante wijzigingen.
• Definieer hersteldoelstellingen voor kritieke functies en ondersteunende ICT-diensten.
• Test BCP- en DR-capaciteiten ten minste jaarlijks.
• Neem scenario’s voor leveranciersuitval en cyberincidenten op.
• Bewaar testbewijsmateriaal, hiaten, herstelmaatregelen en hertestresultaten.
• Stem continuïteitsplannen af op incidentrespons en crisiscommunicatie.

Hoe Clarysec financiële entiteiten helpt van zoekresultaten naar auditgereed bewijsmateriaal

DORA 2026-gereedheid wordt niet bereikt door een checklist te downloaden en te hopen dat de organisatie de hiaten later kan opvullen. Het vereist een gestructureerd operationeel model dat risico, leveranciers, incidenten, testen, continuïteit en auditbewijsmateriaal met elkaar verbindt.

De aanpak van Clarysec combineert drie lagen.

Ten eerste biedt de Zenith Blueprint de implementatieroadmap. Stap 14 helpt organisaties regelgevende vereisten te koppelen aan risicobehandeling en beleid. Stap 16 versterkt door personeel gedreven incidentmelding. Stap 21 zorgt ervoor dat audits en tests productiesystemen niet in gevaar brengen. Stap 23 zet leverancierstoezicht om in een praktische workflow voor classificatie, contracten, onderaannemers, monitoring en cloudbeoordeling.

Ten tweede bieden Clarysec-beleidsdocumenten governance die direct operationeel kan worden gemaakt. Het Beleid inzake risicobeheer, Beleid inzake juridische en regelgevende naleving, Beleid inzake beveiliging van derde partijen en leveranciers, Beleid inzake beheer van leveranciersafhankelijkheidsrisico’s, Incidentresponsbeleid, Beleid inzake beveiligingstesten en red teaming en Beleid voor bedrijfscontinuïteit en herstel na verstoringen geven teams concrete clausules, eigenaarschapsmodellen en verwachtingen voor bewijsmateriaal.

Ten derde biedt Zenith Controls de cross-compliancemapping. Het laat zien hoe beveiliging van de ICT-toeleveringsketen, planning van incidentbeheer en onafhankelijke beoordeling aansluiten op DORA, GDPR, NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022, ISO/IEC 27035, ISO/IEC 27036, ISO/IEC 22320, ISO/IEC 20243, COBIT 2019 en NIST-testpraktijken.

Het resultaat is een DORA-nalevingsprogramma dat verdedigbaar is in een audit en bruikbaar is tijdens een echt incident, leveranciersfalen of weerbaarheidstest.

Volgende stap: bouw uw DORA-bewijspakket vóór het volgende auditverzoek

Als uw team nog steeds zoekt naar “DORA RTS/ITS-checklist”, “DORA ICT risk management template”, “DORA third-party oversight” of “DORA TLPT requirements”, is de volgende stap om die zoekvragen om te zetten in beheerst bewijsmateriaal.

Begin deze week met vier acties:

1. Maak of actualiseer uw DORA-nalevingsregister met het Clarysec-beleidsmodel.
2. Selecteer één kritieke functie en traceer deze via het risicoregister, het register van leveranciersafhankelijkheden, de incidentworkflow, BIA en het testplan.
3. Beoordeel uw vijf belangrijkste ICT-leveranciers op vervangbaarheid, onderaannemers, incidentclausules en exitopties.
4. Bouw een testbewijspakket met scope, autorisatie, resultaten, remediatie en hertesten.

Clarysec kan u helpen dit te implementeren met de Zenith Blueprint, beleidssjablonen en Zenith Controls, zodat uw DORA 2026-programma praktisch, proportioneel en auditgereed is.