DORA-testprogramma: koppel tests aan ISO 27001

Het is februari 2026. De CISO van een middelgrote betaalinstelling heeft over twee dagen een vergadering met de raad van bestuur, over zes weken een controleaudit voor ISO/IEC 27001:2022 en een DORA-verzoek van de toezichthouder in de compliance-inbox.

De toezichthouder vraagt niet om een gelikte cyberstrategie. Het verzoek is praktisch:

• Verstrek uw testprogramma voor digitale operationele weerbaarheid voor 2026.
• Laat zien welke tests kritieke of belangrijke functies afdekken.
• Toon aan hoe bevindingen worden verholpen en opnieuw getest.
• Lever bewijsmateriaal van toezicht door het leidinggevend orgaan.
• Leg uit hoe externe ICT-dienstverleners worden betrokken.
• Verstrek registraties voor kwetsbaarheidsbeoordelingen, scenariogebaseerde tests, prestatie- en capaciteitstests en penetratietests.

De CISO opent vier mappen. Kwetsbaarheidsscans staan in het ticketingsysteem van het SOC. Notities van tabletop-oefeningen staan op een gedeelde schijf. Resultaten van loadtests zijn in beheer bij engineering. Penetratietestrapporten staan in de afgeschermde repository van Legal. De opvolging van remediatiemaatregelen is verdeeld over Jira, e-mail en een spreadsheet die voor de ISO-audit van vorig jaar is gemaakt.

Niets daarvan is nep. Veel ervan is goed werk. Maar het is nog geen bestuurd DORA-testprogramma voor digitale operationele weerbaarheid. Het is een verzameling tests.

Dat verschil doet er in 2026 toe. DORA is van toepassing sinds 17 januari 2025 en stelt een uniform EU-kader vast voor digitale operationele weerbaarheid op het gebied van ICT-risicobeheer, incidentmelding, weerbaarheidstests, het delen van informatie over cyberdreigingen en kwetsbaarheden, ICT-risicobeheer van derden, contractuele eisen en toezicht op kritieke externe ICT-dienstverleners. DORA bestrijkt een brede groep financiële entiteiten, waaronder kredietinstellingen, betaalinstellingen, beleggingsondernemingen, aanbieders van cryptoactivadiensten, verzekeringsondernemingen en andere gereguleerde entiteiten. DORA fungeert ook als sectorspecifieke rechtshandeling van de Unie voor financiële entiteiten die anders onder gelijkwaardige NIS2-verplichtingen voor cyberbeveiliging zouden vallen.

De praktische vraag voor raden van bestuur, CISO’s, compliancemanagers en ICT-dienstverleners is niet langer of er wordt getest. De vraag is of testen gepland, risicogebaseerd, met bewijsmateriaal onderbouwd, geremedieerd, beoordeeld en herbruikbaar is voor zowel DORA als ISO/IEC 27001:2022.

Het operationele model van Clarysec is precies voor dit probleem ontworpen. Met de Zenith Blueprint: de 30-stappenroadmap voor auditors, de ISO-georiënteerde beleidssuite van Clarysec en Zenith Controls: de cross-compliancegids kunnen organisaties verspreide weerbaarheidsactiviteiten omzetten in een beheerde jaarlijkse testcatalogus die voldoet aan de verwachtingen van toezichthouders, auditors, klanten en raden van bestuur.

Waarom DORA testen tot een governancevraagstuk maakt

DORA is expliciet over bestuurlijke verantwoordelijkheid. Article 5 legt de verantwoordelijkheid voor ICT-risicobeheer bij het leidinggevend orgaan. Article 6 vereist een degelijk, alomvattend en goed gedocumenteerd ICT-risicobeheerkader dat is geïntegreerd in het algemene risicobeheersysteem van de organisatie. Article 4 voegt proportionaliteit toe: vereisten moeten worden toegepast op basis van omvang, algemeen risicoprofiel en de aard, schaal en complexiteit van diensten, activiteiten en operaties.

Daardoor is testen van digitale operationele weerbaarheid meer dan een technische taak. Het wordt bewijsmateriaal dat het leidinggevend orgaan risico begrijpt, een strategie heeft goedgekeurd, betekenisvolle rapportage ontvangt en remediatiemaatregelen aanstuurt.

ISO/IEC 27001:2022 gebruikt een vergelijkbare managementsysteemlogica. Clauses 4.1 to 4.4 vereisen dat de organisatie context, belanghebbenden, wettelijke en contractuele verplichtingen, scope, interfaces en afhankelijkheden begrijpt. Clauses 5.1 to 5.3 vereisen leiderschap, beleidsafstemming, middelen, communicatie, toegewezen verantwoordelijkheden en rapportage aan het topmanagement. Clause 6.1 vereist informatiebeveiligingsrisicobeoordeling en risicobehandeling.

Een DORA-testprogramma moet daarom de volgende elementen verbinden:

• Bedrijfsdiensten en kritieke of belangrijke functies
• ICT-activa, gegevens en afhankelijkheden van derden
• Risicobeoordeling, risico-eigenaren en behandelplannen
• Testtypen, frequentie en triggers
• Autorisatie, onafhankelijkheid en uitvoeringsregels
• Bevindingen, remediatietermijnen en hertests
• Bewaring van bewijsmateriaal en toegangsbeveiliging
• Managementrapportage en continue verbetering

Voor kleinere financiële entiteiten of entiteiten met een lager risico voorziet Article 16 in een vereenvoudigd ICT-risicobeheerkader, maar vereenvoudigd betekent niet informeel. Ook afgeschaalde programma’s vereisen gedocumenteerd ICT-risicobeheer, monitoring, weerbare systemen, identificatie van ICT-risicobronnen en afwijkingen, belangrijke ICT-afhankelijkheden van derden, continuïteits- en herstelmaatregelen, regelmatige tests en geleerde lessen.

Met andere woorden: DORA beloont geen testvolume. DORA beloont bestuurd, risicogebaseerd testen dat weerbaarheid aantoont voor de diensten die er het meest toe doen.

Wat hoort thuis in een DORA-testprogramma voor 2026?

Een volwassen DORA-testprogramma moet werken als een jaarlijkse testcatalogus. Het mag niet beperkt blijven tot één jaarlijkse penetratietest of een stapel exports van kwetsbaarheidsscans. Het moet basale en geavanceerde tests omvatten, gepland op basis van risico, kritikaliteit van diensten, wettelijke verplichtingen, leveranciersafhankelijkheden, majeure wijzigingen en eerdere bevindingen.

DORA Article 24 stelt het testprogramma voor digitale operationele weerbaarheid vast. Article 25 beschrijft een reeks tests, waaronder kwetsbaarheidsbeoordelingen en scans, open-sourceanalyses, netwerkbeveiligingsbeoordelingen, gap-analyses, fysieke beveiligingsbeoordelingen, vragenlijsten, scanning software-oplossingen, broncodebeoordelingen waar haalbaar, scenariogebaseerde tests, compatibiliteitstests, prestatietests, end-to-endtests en penetratietests. Article 26 voegt dreigingsgestuurde penetratietests (TLPT) toe voor financiële entiteiten die door bevoegde autoriteiten zijn aangewezen.

Voor de meeste organisaties wordt de praktische catalogus opgebouwd rond vier testfamilies.

Clarysec’s Beleid inzake beveiligingstests en red teaming biedt een sterke beleidsbasis voor deze catalogus:

“Testtypen: het beveiligingstestprogramma moet minimaal het volgende omvatten: (a) kwetsbaarheidsscans, bestaande uit geautomatiseerde wekelijkse of maandelijkse scans van netwerken en applicaties om bekende kwetsbaarheden te identificeren; (b) penetratietests, bestaande uit handmatige diepgaande tests van specifieke systemen of applicaties door ervaren testers om complexe zwaktes te identificeren; en (c) red-teamoefeningen, bestaande uit scenariogebaseerde simulaties van echte aanvallen, waaronder social engineering en andere tactieken, om de detectie- en responsmogelijkheden van de organisatie als geheel te testen.”

Hetzelfde beleid vereist regelmatige planning:

“Testschema: de organisatie moet beveiligingstests uitvoeren volgens een regelmatig schema. Belangrijke systemen die vanaf internet bereikbaar zijn en kritieke interne applicaties moeten ten minste jaarlijks penetratietests ondergaan. Wijzigingen met een hoog risico, zoals de uitrol van een nieuw kritiek systeem of majeure upgrades, vereisen ad-hoctests vóór en/of kort na de livegang in productie.”

Dit is cruciaal voor DORA. Een statisch jaarplan is niet voldoende als de entiteit een nieuwe betalingsgateway uitrolt, een kernsysteem naar de cloud migreert, van managed service provider wisselt of een nieuwe flow voor klantauthenticatie uitbrengt. Een wijziging met een hoog risico moet aanvullende tests triggeren.

Bouw de jaarlijkse testcatalogus als single source of truth

De meest efficiënte manier om aan DORA en ISO/IEC 27001:2022 te voldoen, is één beheerde jaarlijkse testcatalogus opstellen. Die kan in een GRC-platform, een ticketingworkflow of een beheerde spreadsheet staan. Het formaat is minder belangrijk dan de traceerbaarheid.

Elke test moet vijf auditvragen beantwoorden:

1. Welke dienst, asset, leverancier, applicatie of proces is getest?
2. Welk risico, welke verplichting of welke beheersmaatregelvereiste heeft de test getriggerd?
3. Wie heeft de test geautoriseerd en uitgevoerd?
4. Welke bevindingen zijn geïdentificeerd, geaccepteerd, geremedieerd of uitgesteld?
5. Welk bewijsmateriaal toont aan dat de test heeft plaatsgevonden en dat de uitkomst is beoordeeld?

Een praktische catalogus in Clarysec-stijl bevat deze velden.

Clarysec’s Beleid voor audit en compliancemonitoring - mkb geeft een beknopte governanceregel die op deze structuur aansluit:

“Elke audit moet een gedefinieerde scope, doelstellingen, verantwoordelijke medewerkers en vereist bewijsmateriaal bevatten.”

Hoewel deze regel voor audits is geschreven, moet dezelfde regel gelden voor weerbaarheidstests. Als een kwetsbaarheidsscan, tabletop-oefening, failoversimulatie of penetratietest geen gedefinieerde scope, doelstelling, eigenaar en vereist bewijsmateriaal heeft, is deze zwak onder zowel DORA- als ISO-audittoetsing.

Hetzelfde beleid stelt:

“Bewijsmateriaal moet ten minste twee jaar worden bewaard, of langer wanneer certificering of klantovereenkomsten dat vereisen.”

Voor DORA-gereguleerde financiële entiteiten en ICT-dienstverleners moet twee jaar als ondergrens worden beschouwd. Contractuele verplichtingen, verwachtingen van toezichthouders, certificeringscycli en incidentonderzoeken kunnen langere bewaartermijnen vereisen.

Koppel DORA-testtypen aan ISO 27001-bewijsmateriaal

De kracht van een geïntegreerd programma is dat één test meerdere verplichtingen kan ondersteunen. De sleutel is bewijsmateriaal correct te taggen en aan het ISMS te koppelen.

De Zenith Blueprint legt dit uit in de fase Audit, beoordeling en verbetering, Step 24:

“Uw SoA moet consistent zijn met uw risicoregister en risicobehandelingsplan. Controleer nogmaals of elke beheersmaatregel die u als risicobehandeling hebt gekozen, in de SoA als ‘Van toepassing’ is gemarkeerd.”

Voor een DORA-testprogramma wordt de testcatalogus de brug tussen risicobehandeling en operationeel bewijsmateriaal. De Verklaring van Toepasselijkheid mag niet aangeven dat een beheersmaatregel van toepassing is terwijl het testbewijsmateriaal elders staat, zonder mapping en zonder beheer.

Deze tabel helpt een CISO de veelgestelde vraag van de CEO te beantwoorden: “Zijn onze ISO-penetratietests en kwetsbaarheidsscans voldoende voor DORA?”

Het antwoord is: ze kunnen onderdeel zijn van DORA-compliance, maar alleen als ze risicogebaseerd zijn, gekoppeld zijn aan kritieke of belangrijke functies, door beleid worden bestuurd, via remediatie worden opgevolgd en aan het management worden gerapporteerd.

Kwetsbaarheidsbeoordelingen: continu bewijsmateriaal, niet alleen scanoutput

Kwetsbaarheidsbeoordeling is vaak de eenvoudigste testactiviteit om uit te voeren en de eenvoudigste om verkeerd te beheren. Veel organisaties kunnen scanrapporten produceren. Minder organisaties kunnen aantonen dat scans de juiste activa afdekken, kritieke diensten prioriteren, tijdige remediatie genereren en input leveren voor besluiten over risicobehandeling.

Clarysec’s Beleid inzake kwetsbaarheden- en patchbeheer - mkb begint met de juiste doelstelling:

“Bekende kwetsbaarheden in alle IT-activa tijdig en consistent identificeren en beoordelen”

Voor DORA ondersteunt dit de identificatie van ICT-risicobronnen, weerbare en bijgewerkte systemen, monitoring, anomaliedetectie en continue verbetering. Voor ISO/IEC 27001:2022 mapped dit rechtstreeks naar 8.8 Beheer van technische kwetsbaarheden, en steunt het ook op 5.9 Inventaris van informatie en andere bijbehorende bedrijfsmiddelen, 8.16 Monitoringactiviteiten en 8.32 Wijzigingsbeheer.

Een sterke registratie van een kwetsbaarheidsbeoordeling moet het volgende bevatten:

• Momentopname van de inventaris van bedrijfsmiddelen die voor scoping is gebruikt
• Scandatum, tool en geauthenticeerde of niet-geauthenticeerde methode
• Uitsluitingen en zakelijke rechtvaardiging
• Bevindingen naar ernst, exploitbaarheid en bedrijfsdienst
• Mapping naar kritieke of belangrijke functies en gegevenstypen
• Ticketreferenties en risico-eigenaar
• Remediatie-SLA en vervaldatum
• Resultaat van hertest
• Uitzonderingen met goedkeuring van restrisico

Zenith Controls positioneert 8.8 Beheer van technische kwetsbaarheden als een kerngebied voor bewijsmateriaal rond identificatie, beoordeling, prioritering en opvolging van remediatie. Het laat ook zien waarom auditors aangrenzende processen zullen testen. Als de inventaris van bedrijfsmiddelen onvolledig is, is de kwetsbaarheidsdekking onvolledig. Als wijzigingsbeheer wordt omzeild, kan patchuitrol nieuw operationeel risico creëren. Als monitoring zwak is, worden exploitpogingen mogelijk niet gedetecteerd.

Scenariotests: bewijs besluitvorming vóór het echte incident

Scenariotests maken operationele weerbaarheid zichtbaar voor leidinggevenden. Een ransomware-tabletop, simulatie van uitval van een cloudregio, oefening rond compromittering van geprivilegieerde toegang of scenario voor falen van een kritieke ICT-dienstverlener legt zwaktes bloot die een scan niet kan vinden.

DORA Articles 17 to 20 vereisen een formele levenscyclus voor ICT-gerelateerde incidenten: detecteren, beheren, melden, registreren, monitoren, afhandelen, opvolgen, de oorzaakanalyse documenteren, remediëren, ernst classificeren, rollen toewijzen, majeure incidenten escaleren en via de vereiste fasen rapporteren. Waar financiële belangen van klanten worden geraakt, moeten klanten zonder onnodige vertraging worden geïnformeerd.

NIS2 kent een vergelijkbare urgentie voor entiteiten binnen de scope, waaronder vroegtijdige waarschuwing, melding, tussentijdse rapportage en eindrapportage. Voor financiële entiteiten binnen de scope is DORA de sectorspecifieke rechtshandeling voor gelijkwaardige verplichtingen op het gebied van cyberbeveiligingsrisicobeheer en rapportage. ICT-dienstverleners, SaaS-platformen, MSP’s en MSSP’s moeten nog steeds controleren of zij rechtstreeks onder NIS2 vallen of contractueel in DORA-assurance door gereguleerde klanten worden betrokken.

De Zenith Blueprint, fase Controls in Action, Step 23, geeft het praktische bewijsmodel:

“Selecteer een recent event of voer een tabletop-oefening uit om uw plan te valideren. Leg alle besluiten, rollen en communicatie vast en log deze (5.26), en werk het plan bij met geleerde lessen (5.27).”

Een DORA-scenariotest moet auditeerbare registraties opleveren, niet alleen vergadernotities:

• Scenariobriefing en doelstellingen
• Deelnemers en rollen, waaronder Legal, Comms, IT, SOC, bedrijfseigenaar en leverancierscontacten
• Tijdlijn van injects en besluiten
• Classificatiebesluit en analyse van rapportagedrempels
• Concepten voor interne en externe communicatie
• Maatregelen voor behoud van bewijsmateriaal
• Geleerde lessen
• Actie-eigenaren en vervaldatums
• Bijgewerkte incident-, continuïteits- of communicatieprocedures

Clarysec’s Beleid voor bedrijfscontinuïteit en herstel na verstoringen - mkb versterkt de verwachting van jaarlijkse tests:

“De organisatie moet zowel haar BCP als haar herstelcapaciteiten ten minste jaarlijks testen. Tests moeten omvatten:”

De testcatalogus moet die verplichting vertalen naar specifieke oefeningen, zoals een crisismanagement-tabletop, back-uphersteltest, cloudfailovertest, contactboomtest en simulatie van leveranciersverstoring.

Prestatie-, capaciteits- en hersteltests: het vaak verwaarloosde weerbaarheidsbewijs

Prestatietests worden vaak gezien als een engineeringaangelegenheid. Onder DORA worden zij bewijsmateriaal voor weerbaarheid.

Een handelsplatform, betaaldienst, claimsysteem, identiteitsplatform of klantportaal heeft geen cyberaanval nodig om klanten te laten falen. Capaciteitsuitputting, verzadiging van wachtrijen, databaseknelpunten, verkeerd geconfigureerde autoscaling of defecte failover kunnen dezelfde operationele verstoring veroorzaken als een beveiligingsincident.

ISO/IEC 27001:2022 bijlage A 8.6 Capaciteitsbeheer is het primaire anker. Het bewijsmateriaal kan loadtesting, stresstesting, tests van degradatie van dienstverlening, validatie van infrastructuurdrempels, back-uphersteltests en failoversimulaties omvatten.

Een goede registratie van prestatie- en capaciteitstests moet vastleggen:

• Baselineaannames voor normale belasting en piekbelasting
• Geteste kritieke transactieketens
• Geteste infrastructuur- en cloudlimieten
• Monitoringdashboards en waarschuwingsdrempels
• Faalmodi, zoals verzadiging van wachtrijen of databaseknelpunten
• Relevantie van RTO en RPO wanneer failover of herstel wordt getest
• Bedrijfsimpact als drempels worden overschreden
• Herstelmaatregelen, schaalbesluiten of architectuurwijzigingen
• Managementacceptatie van restrisico rond capaciteit

De Zenith Blueprint, Step 23, koppelt herstelverwachtingen aan bewijsmateriaal:

“Verifieer dat Recovery Time Objectives (RTO) en Recovery Point Objectives (RPO) voor kritieke systemen aansluiten op de verwachtingen voor bedrijfscontinuïteit (5.30). Voer ten minste één technische hersteltest of failoversimulatie uit en documenteer de resultaten.”

Dat is het verschil tussen zeggen “we hebben back-ups” en bewijzen dat een kritieke dienst binnen de afgesproken tolerantie is hersteld, met gedocumenteerde resultaten en zichtbaarheid voor het management.

Penetratietests en red teaming: sterk bewijsmateriaal vereist sterke beheersing

Penetratietests leveren zeer waardevol bewijsmateriaal op, maar brengen ook operationeel risico mee. Slecht bestuurde tests kunnen productiesystemen beïnvloeden, gevoelige gegevens blootstellen, ongecontroleerde alarmen triggeren, juridische kwesties veroorzaken of klanten verstoren.

Het Beleid inzake vereisten voor applicatiebeveiliging - mkb stelt een duidelijke release gate:

“Vóór uitrol moeten alle applicaties beveiligingstests ondergaan om de hierboven genoemde baselinefuncties te verifiëren.”

Voor kritieke applicaties moet dit de DORA-catalogus voeden als pre-productiebeveiligingstests, post-go-livevalidatie voor wijzigingen met hoog risico en periodieke penetratietests op basis van blootstelling en kritikaliteit.

Het Beleid inzake beveiligingstests en red teaming versterkt de remediatieketen:

“Remediatie van bevindingen: alle geïdentificeerde kwetsbaarheden of zwaktes moeten worden gedocumenteerd in een bevindingenrapport met ernstclassificaties. Na ontvangst van het rapport zijn systeemeigenaren verantwoordelijk voor het opstellen van een remediatieplan met vervaldatums; kritieke bevindingen moeten bijvoorbeeld binnen 30 dagen worden geremedieerd en bevindingen met hoge ernst binnen 60 dagen, in overeenstemming met het Beleid inzake kwetsbaarheden- en patchbeheer van de organisatie. De STC moet de voortgang van remediatie volgen. Hertests moeten worden uitgevoerd om te bevestigen dat kritieke kwesties zijn opgelost of adequaat zijn gemitigeerd.”

Hetzelfde beleid definieert rapportageverwachtingen:

“Rapportage: na afronding van elke test moet een formeel rapport worden uitgebracht. Voor penetratietests moet het rapport een managementsamenvatting, methodologie en gedetailleerde bevindingen met onderbouwend bewijsmateriaal en aanbevelingen bevatten.”

De Zenith Blueprint, Step 21, benadrukt ook bescherming tijdens audits en tests:

“Geen enkele test of audit mag doorgaan zonder gedocumenteerde goedkeuring van systeemeigenaren of relevante stakeholders.”

Uitvoeringsregels, testvensters, noodcontacten, tijdelijke toegang, gegevensverwerking, logging, rollbackprocedures en juridische goedkeuringen zijn geen bureaucratie. Het zijn waarborgen voor weerbaarheid.

Betrek externe ICT-dienstverleners voordat de test faalt

DORA maakt ICT-risico’s van derden tot een centraal weerbaarheidsvraagstuk. Article 28 vereist dat financiële entiteiten ICT-risico’s van derden beheren binnen het ICT-risicobeheerkader, verantwoordelijk blijven bij het gebruik van ICT-diensten, een informatieregister bijhouden, bepaalde regelingen melden, precontractuele beoordelingen uitvoeren en dienstverleners gebruiken die voldoen aan passende informatiebeveiligingsstandaarden. Articles 29 and 30 behandelen concentratierisico, uitbesteding aan onderaannemers, gegevensherstel, contractuele bescherming, serviceniveaus, incidentondersteuning, auditrechten, continuïteitstests bij dienstverleners, deelname aan tests waar relevant en exitregelingen.

ISO/IEC 27001:2022 bijlage A biedt ondersteunende leveranciersbeheersmaatregelen, waaronder 5.19 Informatiebeveiliging in leveranciersrelaties, 5.20 Informatiebeveiliging opnemen in leveranciersovereenkomsten, 5.21 Beheer van informatiebeveiliging in de ICT-toeleveringsketen, 5.22 Monitoring, beoordeling en wijzigingsbeheer van leveranciersdiensten en 5.23 Informatiebeveiliging voor het gebruik van clouddiensten.

Een DORA-testcatalogus moet identificeren welke tests leveranciersdeelname of leveranciersbewijsmateriaal vereisen. Voorbeelden zijn:

• Failoveraannames van cloudproviders
• Escalatie en behoud van bewijsmateriaal door een managed SOC
• Incidentcommunicatie van een core banking-platform
• Scenario voor uitval van een payment processor
• Hersteltest van een identiteitsprovider
• Attesten van penetratietests door SaaS-leveranciers
• Impactbeoordeling van de keten van kritieke onderaannemers

Een programma dat kritieke ICT-dienstverleners uitsluit, faalt de realiteitstoets. De klantgerichte dienst kan van u zijn, maar de weerbaarheidsafhankelijkheid kan in een cloudregio, uitbesteed SOC, identiteitsprovider, softwareleverancier, payment processor of datacenter liggen.

Cross-compliancemapping: één set bewijsmateriaal, veel verplichtingen

Een goed ontworpen DORA-testprogramma vermindert auditmoeheid. Hetzelfde bewijsmateriaal kan DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 en COBIT 2019-governancebeoordelingen ondersteunen als het correct wordt getagd, bewaard en gerapporteerd.

GDPR mag niet worden vergeten. Als weerbaarheidstests persoonsgegevens, logboeken, klantregistraties, identiteitsgegevens, HR-registraties, biometrie of bijzondere categorieën persoonsgegevens omvatten, moet de organisatie de GDPR-beginselen respecteren, waaronder rechtmatigheid, behoorlijkheid, transparantie, gegevensminimalisatie, opslagbeperking, integriteit, vertrouwelijkheid en verantwoordingsplicht. Kopieën van testgegevens, geëxporteerde logboeken en bewijsmateriaal uit penetratietests kunnen gereguleerde gegevensopslagplaatsen worden. Het testprogramma moet definiëren wie er toegang toe mag hebben, hoe lang ze worden bewaard en hoe ze veilig worden vernietigd.

Hoe auditors hetzelfde programma zullen toetsen

Een DORA-toezichthouder, ISO-auditor, NIST-gebaseerde beoordelaar, COBIT-reviewer en klantauditor kunnen hetzelfde bewijsmateriaal vanuit verschillende invalshoeken inspecteren.

Zenith Controls is hier nuttig als cross-compliancekompas. Voor DORA-tests benadrukt Clarysec 5.35 Onafhankelijke beoordeling van informatiebeveiliging, 8.8 Beheer van technische kwetsbaarheden en 8.6 Capaciteitsbeheer als bijzonder belangrijke ankers in ISO/IEC 27001:2022 bijlage A. Zij helpen eigenaren van beheersmaatregelen testen te verbinden met onafhankelijke assurance, afhandeling van kwetsbaarheden en operationele capaciteit.

Clarysec’s Informatiebeveiligingsbeleid ondersteunt ook de audittrail:

“Eigenaren van beheersmaatregelen moeten testresultaten, logboeken en beoordelingsregistraties bijhouden ter ondersteuning van periodieke audits.”

Die zin moet een operationele regel worden. Elke testeigenaar moet weten wat moet worden bewaard, waar het moet worden bewaard, hoe het moet worden beschermd en hoe het verband houdt met risico- en beheersmaatregelbewijsmateriaal.

Bouw in één week een DORA-naar-ISO-bewijspakket

Een financiële entiteit of ICT-dienstverlener kan in vijf werkdagen aanzienlijke voortgang boeken.

Dag 1: Definieer scope en kritikaliteit

Gebruik de denkwijze van ISO/IEC 27001:2022 Clauses 4.1 to 4.4. Identificeer belanghebbenden, wettelijke verplichtingen, contractuele verplichtingen, interfaces en afhankelijkheden. Maak een lijst van bedrijfsdiensten, kritieke of belangrijke functies, kernactiva, gegevenstypen en ICT-dienstverleners.

Output: DORA-register voor de testscope.

Dag 2: Maak de jaarlijkse testcatalogus

Gebruik de vier testfamilies: kwetsbaarheid, scenario, prestaties en penetratie. Definieer per dienst welke tests van toepassing zijn, de frequentie, eigenaar, mate van onafhankelijkheid en trigger. Neem triggers voor wijzigingen met hoog risico op.

Output: testcatalogus voor digitale operationele weerbaarheid voor 2026.

Dag 3: Koppel beheersmaatregelen en verplichtingen

Koppel elke test aan ISO/IEC 27001:2022 bijlage A, het risicoregister, de SoA, DORA-artikelen, leveranciersverplichtingen en relevante Zenith Controls-items. Maandelijkse externe kwetsbaarheidsscans mappen bijvoorbeeld naar 8.8 Beheer van technische kwetsbaarheden, risicobehandeling, monitoring, DORA ICT-risicobeheer en NIST CSF-uitkomsten voor kwetsbaarheden.

Output: matrix voor mapping van beheersmaatregelen.

Dag 4: Standaardiseer mappen voor bewijsmateriaal

Maak een beheerde bewijsstructuur:

• 01 Plan en autorisatie
• 02 Scope en uitvoeringsregels
• 03 Ruwe resultaten
• 04 Eindrapport
• 05 Bevindingenregister
• 06 Remediatietickets
• 07 Hertestbewijsmateriaal
• 08 Managementrapportage
• 09 Geleerde lessen en beleidsactualisaties

Output: bewaarplaats voor bewijsmateriaal met bewaarregels.

Dag 5: Beoordeel bevindingen en rapportage

Consolideer openstaande bevindingen naar ernst, dienst, risico-eigenaar en vervaldatum. Identificeer achterstallige remediatie, geaccepteerde risico’s en hertesthiaten. Bereid een dashboard voor het leidinggevend orgaan voor met testdekking, majeure bevindingen, achterstallige acties, kwesties met derden en restrisico.

Output: bestuursgereed DORA- en ISO-testdashboard.

Veelvoorkomende valkuilen in DORA-testprogramma’s

De meest voorkomende tekortkoming is niet een gebrek aan testen. Het is een gebrek aan governance.

Let op deze kwesties:

• Penetratietests worden jaarlijks uitgevoerd, maar bevindingen worden niet tot afsluiting opgevolgd
• Kwetsbaarheidsscans draaien frequent, maar kritieke activa ontbreken in de scope
• Tabletop-oefeningen worden gehouden, maar zonder besluitlogboek of actieplan voor geleerde lessen
• Back-uphersteltests zijn afgerond, maar niet gekoppeld aan RTO en RPO
• Loadtests worden door engineering uitgevoerd, maar niet gerapporteerd aan risk of compliance
• ICT-dienstverleners worden uitgesloten van scenario- en hersteltests
• Bewijsmateriaal wordt opgeslagen in persoonlijke mappen, chatthreads of onbeheerde schijven
• Bestuursrapportages richten zich op aantallen activiteiten in plaats van onopgelost weerbaarheidsrisico
• De SoA zegt dat een beheersmaatregel van toepassing is, maar er bestaat geen testbewijsmateriaal
• Testen creëren productierisico omdat autorisatie en grenzen onduidelijk zijn

Elk hiaat is oplosbaar. De remedie is niet meer willekeurig testen. De remedie is één beheerd programma dat risico, testactiviteit, remediatie, bewijsmateriaal en managementtoezicht verbindt.

Wat de raad van bestuur daadwerkelijk moet zien

DORA maakt ICT-weerbaarheid een verantwoordelijkheid van het leidinggevend orgaan. Een nuttige bestuursrapportage hoeft niet elke technische bevinding te bevatten. Zij moet beantwoorden of de organisatie voldoende weerbaar is ten opzichte van haar risicobereidheid en verstoringstolerantie.

Een sterke kwartaal- of halfjaarlijkse rapportage bevat:

• Testdekking ten opzichte van kritieke of belangrijke functies
• Afgeronde versus geplande tests
• Kritieke en hoge bevindingen per dienst
• Achterstallige remediatie per eigenaar
• Slagingspercentage van hertests
• Leveranciersgerelateerde bevindingen en concentratiezorgen
• Lessen uit scenariotests die crisis- of incidentplannen raken
• Capaciteitsrisico’s ten opzichte van bedrijfsgroei en piekperioden
• Restrisico’s die managementacceptatie vereisen
• Beperkingen in budget, middelen of tooling

Deze rapportage wordt input voor ISO-directiebeoordeling, DORA-governancebewijsmateriaal en een praktisch besluitvormingsinstrument.

Van verspreide tests naar strategische weerbaarheid

Het oorspronkelijke probleem van de CISO was niet dat testen ontbrak. De organisatie had scans, tabletops, loadrapporten en PDF’s van penetratietests. Het probleem was dat deze activiteiten nog geen coherent bewijsverhaal vormden.

Een geïntegreerd DORA- en ISO/IEC 27001:2022-testprogramma verandert dat. De risicobeoordeling stuurt de catalogus. De catalogus stuurt geautoriseerde tests. Tests leveren bevindingen op. Bevindingen sturen remediatie en hertests. Resultaten voeden managementrapportage. Geleerde lessen actualiseren beleid, procedures, contracten en beheersmaatregelen.

Zo wordt een compliancelast een strategisch vermogen.

Clarysec helpt organisaties parallelle complianceprogramma’s te vermijden. DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 en COBIT 2019 hebben geen afzonderlijke bewijsuniversums nodig. Zij hebben één bestuurd operationeel model nodig dat via verschillende auditperspectieven kan worden gepresenteerd.

Onze aanpak combineert:

• De Zenith Blueprint voor gefaseerde ISO-implementatie en gereedheid voor audits
• Zenith Controls voor cross-compliancemapping over beheersmaatregelen, kaders en auditverwachtingen heen
• Enterprise- en mkb-beleid voor beveiligingstests, auditmonitoring, kwetsbaarhedenbeheer, applicatiebeveiliging, continuïteit en informatiebeveiliging
• Praktische registers, bewijsstructuren en sjablonen voor managementrapportage

Als uw DORA-testbewijsmateriaal voor 2026 verspreid is over scantools, engineeringmappen, tabletop-notities en PDF’s van penetratietests, is dit het moment om het te consolideren.

Begin met één jaarlijkse testcatalogus die is gekoppeld aan ISO/IEC 27001:2022-risicobehandeling, uw SoA, kritieke of belangrijke functies, externe ICT-dienstverleners en managementrapportage. Gebruik daarna Clarysec’s Zenith Blueprint, Zenith Controls en beleidstoolkit om die catalogus om te zetten in verdedigbaar auditbewijsmateriaal.

Clarysec kan u helpen het programma te ontwerpen, de beheersmaatregelen te mappen, het bewijspakket te structureren en het weerbaarheidsrapport voor de raad van bestuur voor te bereiden voordat het volgende verzoek van de toezichthouder binnenkomt.