DORA TLPT-bewijs met ISO 27001-beheersmaatregelen

Het is 07:40 op maandagochtend en de CISO van een middelgrote betaalinstelling kijkt naar drie varianten van dezelfde ongemakkelijke vraag.

Het bestuur wil weten of de organisatie een door ransomware veroorzaakte uitval van haar klantportaal voor betalingen kan doorstaan. De toezichthouder wil bewijs dat testen van digitale operationele weerbaarheid geen PowerPoint-oefening zijn. Interne audit wil een duidelijke lijn van DORA-verplichtingen naar ICT-risico, ISO 27001-beheersmaatregelen, testresultaten, remediatieplannen, leveranciersbewijs en formele managementgoedkeuring.

De CISO heeft een red-teamrapport. Het SOC heeft screenshots van alerts. Infrastructuur heeft een logboek van back-upherstel. Juridische Zaken heeft een DORA-readinesstracker. Inkoop heeft attesten van cloudproviders.

Niets daarvan is met elkaar verbonden.

Hier falen veel DORA TLPT- en weerbaarheidstestprogramma’s. Niet omdat de tests zwak zijn, maar omdat het bewijs gefragmenteerd is. Wanneer een auditor vraagt: “Laat zien hoe deze test de weerbaarheid van een kritieke of belangrijke functie aantoont”, kan het antwoord geen map met screenshots zijn. Het moet een verdedigbare bewijsketen zijn.

Die keten is waar een op ISO/IEC 27001:2022 afgestemd ISMS ISO/IEC 27001:2022 krachtig wordt. ISO 27001 geeft structuur aan scope, risicobeoordeling, selectie van beheersmaatregelen, Verklaring van Toepasselijkheid, operationele beheersing, interne audit, directiebeoordeling en continue verbetering. DORA levert de sectorspecifieke druk. De methodologie en cross-compliance tooling van Clarysec verbinden beide tot één auditgereed bewijsmodel.

DORA TLPT is een governancetest, niet alleen een aanvalssimulatie

Threat-led penetration testing, of TLPT, wordt gemakkelijk verkeerd begrepen. Technisch kan het lijken op een geavanceerde red-teamoefening: Threat Intelligence, realistische aanvalspaden, stealth, exploitpogingen, scenario’s voor laterale beweging en validatie van de blue-teamrespons.

Voor DORA is het onderliggende vraagstuk digitale operationele weerbaarheid. Kan de financiële entiteit ernstige ICT-verstoringen die bedrijfsprocessen raken weerstaan, erop reageren en ervan herstellen? Kan zij aantonen dat kritieke of belangrijke functies binnen de impacttoleranties blijven? Kan het management aantonen dat ICT-risico wordt bestuurd, gefinancierd, getest, geremedieerd en verbeterd?

Artikel 1 van DORA stelt een uniform EU-kader vast voor de beveiliging van netwerk- en informatiesystemen die de bedrijfsprocessen van financiële entiteiten ondersteunen. Het omvat ICT-risicobeheer, melding van ernstige ICT-gerelateerde incidenten, testen van digitale operationele weerbaarheid, beheer van ICT-risico’s van derde aanbieders, verplichte contractuele vereisten voor ICT-leveranciers, toezicht op kritieke ICT-dienstverleners van derde partijen en samenwerking met toezichthouders. DORA is van toepassing vanaf 17 januari 2025.

Voor organisaties die ook onder NIS2 vallen, fungeert DORA als de sectorspecifieke Unierechtelijke handeling voor overlappende cyberbeveiligingsvereisten. In de praktijk moeten financiële entiteiten DORA prioriteren voor ICT-risicobeheer, incidentmelding, testen en ICT-derdepartijrisico waar de regimes overlappen, terwijl zij de NIS2-verwachtingen voor groepsstructuren, leveranciers en niet-financiële digitale diensten blijven begrijpen.

DORA legt de verantwoordingsplicht ook aan de top. Artikel 5 vereist dat het leidinggevend orgaan regelingen voor ICT-risicobeheer definieert, goedkeurt, bewaakt en implementeert. Dit omvat de strategie voor digitale operationele weerbaarheid, het ICT-bedrijfscontinuïteitsbeleid, respons- en herstelplannen, auditplannen, budgetten, ICT-beleid voor derde partijen, meldkanalen en voldoende kennis van ICT-risico door regelmatige training.

De auditvraag is dus niet simpelweg: “Hebt u een TLPT uitgevoerd?”

De vraag is:

• Was de TLPT gekoppeld aan kritieke of belangrijke functies?
• Was de TLPT geautoriseerd, afgebakend, veilig en risicobeoordeeld?
• Werden leveranciers, cloudafhankelijkheden en uitbestede ICT-diensten waar relevant meegenomen?
• Leverden de tests bewijs op van detectie, respons, herstel en geleerde lessen?
• Werden bevindingen omgezet in risicobehandeling, opgevolgde remediatie, hertests en managementrapportage?
• Legde de Verklaring van Toepasselijkheid uit welke ISO 27001-beheersmaatregelen uit bijlage A waren geselecteerd om het risico te beheersen?

Daarom behandelt Clarysec DORA TLPT-bewijs als een ISMS-bewijsvraagstuk, niet alleen als een deliverable van penetratietesten.

Bouw de ISO 27001-bewijsbasis voordat de test begint

ISO 27001 vereist dat een organisatie een ISMS vaststelt, implementeert, onderhoudt en continu verbetert dat vertrouwelijkheid, integriteit en beschikbaarheid borgt via een risicobeheerproces. Clausules 4.1 tot en met 4.4 vereisen dat de organisatie interne en externe kwesties, belanghebbenden, wettelijke en regelgevende verplichtingen, interfaces en afhankelijkheden begrijpt en vervolgens het ISMS-toepassingsgebied documenteert.

Voor een DORA-gereguleerde entiteit moet deze scopebepaling expliciet kritieke of belangrijke functies, ICT-activa, cloudplatformen, uitbestede activiteiten, betaalsystemen, klantportalen, identiteitsdiensten, loggingplatformen, herstelomgevingen en ICT-dienstverleners van derde partijen omvatten. Als de TLPT-scope niet herleidbaar is tot het ISMS-toepassingsgebied, is de audittrail al zwak.

ISO 27001 Clausules 6.1.1, 6.1.2 en 6.1.3 vereisen, samen met Clausules 8.2 en 8.3, een proces voor risicobeoordeling en risicobehandeling. Risico’s moeten worden geïdentificeerd ten aanzien van vertrouwelijkheid, integriteit en beschikbaarheid. Risico-eigenaren moeten worden toegewezen. Waarschijnlijkheid en impact moeten worden beoordeeld. Beheersmaatregelen moeten worden geselecteerd en vergeleken met bijlage A. Restrisico moet door risico-eigenaren worden geaccepteerd.

Dit is de brug tussen DORA en auditgereed testen.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint beschrijft in de fase Risicobeheer, stap 13, deze traceerbaarheidsrol helder:

De SoA is in feite een brugdocument: het koppelt uw risicobeoordeling/-behandeling aan de feitelijke beheersmaatregelen die u hebt. Door deze in te vullen, controleert u ook of u geen beheersmaatregelen hebt gemist.

Voor DORA TLPT mag de Verklaring van Toepasselijkheid geen statisch certificeringsartefact zijn. Zij moet uitleggen waarom beheersmaatregelen zoals leveranciersbeveiliging, incidentbeheer, ICT-gereedheid voor bedrijfscontinuïteit, logging, monitoring, technisch kwetsbaarhedenbeheer, back-ups, veilige ontwikkeling en beveiligingstesten van toepassing zijn op het weerbaarheidsscenario.

Een praktisch risicoscenario kan luiden:

“Compromittering van inloggegevens van een geprivilegieerde identiteitsprovider stelt een aanvaller in staat toegang te krijgen tot beheersystemen voor betalingsverwerking, routeringsconfiguraties te wijzigen en een kritieke betalingsfunctie te verstoren, met dienstuitval, wettelijke rapportageverplichtingen, schade voor klanten en reputatieschade tot gevolg.”

Dat ene scenario kan de TLPT-scope, detectie-use-cases, leveranciersbetrokkenheid, hersteloefening, bestuursrapportage en bewijsset sturen.

De Zenith Blueprint raadt ook aan om regelgevende traceerbaarheid expliciet te maken:

Verwijs kruiselings naar regelgeving: als bepaalde beheersmaatregelen specifiek zijn geïmplementeerd om te voldoen aan GDPR, NIS2 of DORA, kunt u dat vermelden in het risicoregister (als onderdeel van de onderbouwing van de risico-impact) of in de SoA-notities.

Dat advies is eenvoudig, maar verandert het auditgesprek. In plaats van een auditor te vertellen dat DORA is meegewogen, kan de organisatie laten zien waar DORA terugkomt in het risicoregister, de SoA, het testprogramma, de beleidsset en de directiebeoordeling.

Koppel DORA-testen aan ISO 27001-beheersmaatregelen die auditors herkennen

Artikel 6 van DORA verwacht een gedocumenteerd ICT-risicobeheerkader dat is geïntegreerd in het algemene risicobeheer. ISO 27001 bijlage A biedt de catalogus van beheersmaatregelen die dit operationeel maakt.

Voor DORA TLPT en weerbaarheidstesten zijn deze ISO/IEC 27001:2022-beheersmaatregelen uit bijlage A bijzonder belangrijk:

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls helpt organisaties te voorkomen dat zij deze beheersmaatregelen als geïsoleerde checklistitems behandelen. Het koppelt ISO/IEC 27002:2022-beheersmaatregelen aan attributen, domeinen, operationele capaciteiten, auditverwachtingen en cross-frameworkpatronen.

Zo classificeert Zenith Controls ISO/IEC 27002:2022-beheersmaatregel 5.30, ICT-gereedheid voor bedrijfscontinuïteit, als “corrigerend”, afgestemd op “beschikbaarheid”, gekoppeld aan het cyberbeveiligingsconcept “Respond” en geplaatst in het domein “Resilience”. Die classificatie is nuttig om auditors uit te leggen waarom een hersteloefening niet slechts een IT-operatie is, maar een weerbaarheidsmaatregel met een gedefinieerde rol in de beheersingsomgeving.

Zenith Controls classificeert beheersmaatregel 8.29, beveiligingstesten bij ontwikkeling en acceptatie, ook als een preventieve beheersmaatregel die vertrouwelijkheid, integriteit en beschikbaarheid ondersteunt, met operationele capaciteiten in applicatiebeveiliging, assurance over informatiebeveiliging en systeem- en netwerkbeveiliging. Voor TLPT-bevindingen die terug te voeren zijn op zwaktes in applicatieontwerp, onveilig API-gedrag, gebrekkige authenticatiestromen of onvoldoende validatie, is dit het beheersingspad naar governance voor veilige ontwikkeling.

Beheersmaatregel 5.35, onafhankelijke beoordeling van informatiebeveiliging, is eveneens belangrijk. Deze ondersteunt onafhankelijke challenge, assurance over governance en corrigerende verbetering. Interne teams kunnen tests coördineren, maar auditgereed bewijs vereist beoordeling, escalatie en toezicht buiten de mensen die de geteste systemen hebben gebouwd of beheerd.

Bescherm het systeem terwijl u het test

Een gevaarlijke aanname bij weerbaarheidstesten is dat testen automatisch goed is. In werkelijkheid kunnen invasieve tests uitval veroorzaken, gevoelige gegevens blootstellen, logboeken vervuilen, geautomatiseerde verdedigingsmaatregelen activeren, klantsessies verbreken of leveranciers ertoe brengen noodprocedures te starten.

Clarysecs Security Testing and Red-Teaming Policy Security Testing and Red-Teaming Policy biedt organisaties een governancepatroon voor veilige uitvoering. Clausule 6.1 stelt:

Soorten tests: het programma voor beveiligingstesten moet minimaal omvatten: (a) kwetsbaarheidsscans, bestaande uit geautomatiseerde wekelijkse of maandelijkse scans van netwerken en applicaties om bekende kwetsbaarheden te identificeren; (b) penetratietesten, 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, inclusief social engineering en andere tactieken, om de detectie- en responsmogelijkheden van de organisatie als geheel te testen.

Voor TLPT ligt het red-teamingelement voor de hand, maar de auditwaarde komt uit de programmaopzet. Kwetsbaarheidsscans, penetratietesten, red-teamoefeningen, weerbaarheidsoefeningen en hertests moeten een cyclus vormen, geen verzameling losstaande tests.

Clausule 6.2 van hetzelfde beleid behandelt veilige uitvoering:

Scope en spelregels voor de uitvoering: voor elke test of oefening moet de STC de scope definiëren, inclusief systemen en IP-reeksen binnen scope, toegestane testmethoden, doelstellingen, timing en duur. Spelregels voor de uitvoering moeten worden gedocumenteerd. Operationeel gevoelige systemen kunnen bijvoorbeeld worden aangewezen als alleen-monitoren om verstoring te voorkomen, en elke test in productie moet rollback- en stopprocedures omvatten. Veiligheidsmaatregelen, zoals gedefinieerde tijdvensters en communicatiekanalen, moeten worden vastgesteld om onbedoelde dienstuitval te voorkomen.

Dit sluit rechtstreeks aan op Zenith Blueprint, de fase Controls in Action, stap 21, die zich richt op ISO 27001-beheersmaatregel A.8.34 uit bijlage A, bescherming van informatiesystemen tijdens audittesten. De Zenith Blueprint waarschuwt dat audits, penetratietesten, forensische beoordelingen en operationele evaluaties verhoogde toegang, invasieve tools of tijdelijke wijzigingen in systeemgedrag kunnen omvatten. De nadruk ligt op autorisatie, scope, tijdvensters, goedkeuring door de systeemeigenaar, rollback, monitoring en veilige behandeling van testgegevens.

De auditgereede bewijsbundel moet omvatten:

• TLPT-charter en doelstellingen
• Samenvatting van Threat Intelligence en onderbouwing van het scenario
• Kritieke of belangrijke functies binnen scope
• Systemen, IP-reeksen, identiteiten, leveranciers en omgevingen binnen scope
• Uitsluitingen en systemen die alleen worden gemonitord
• Spelregels voor de uitvoering
• Risicobeoordeling voor testen in productie
• Rollback- en stopprocedures
• SOC-kennisgevingsmodel, inclusief wat wordt gedeeld en wat wordt achtergehouden
• Juridische, privacy- en leveranciersgoedkeuringen
• Bewijs van aanmaak en intrekking van testaccounts
• Veilige opslaglocatie voor testartefacten en logboeken

Een DORA TLPT die geen veilige autorisatie en beheersing van testactiviteiten kan aantonen, kan weerbaarheidslacunes blootleggen, maar creëert ook governancehiaten.

Zet TLPT-output om in risicobehandeling

De meest voorkomende fout na de test is het red-teamrapport dat op de plank belandt. Een hoogwaardig rapport wordt opgeleverd, verspreid, besproken en verliest daarna langzaam momentum. Bevindingen blijven openstaan. Compenserende beheersmaatregelen worden niet gedocumenteerd. Geaccepteerde risico’s blijven informeel. Hertests vinden nooit plaats.

De Security Testing and Red-Teaming Policy maakt dit onacceptabel. Clausule 6.6 stelt:

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 en bevindingen met hoge ernst binnen 60 dagen worden verholpen, 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.

Clausule 6.7 voegt de governancelaag toe:

Rapportage: na afloop van elke test moet een formeel rapport worden uitgebracht. Voor penetratietesten moet het rapport een managementsamenvatting, methodologie en gedetailleerde bevindingen bevatten, inclusief onderbouwend bewijs en aanbevelingen. Voor red-teamoefeningen moet het rapport de scenario’s beschrijven, welke aanvalspaden succesvol waren, wat door het blue team is gedetecteerd en welke lessen zijn geleerd over detectie- en responslacunes. De CISO moet samengevatte resultaten en remediatiestatus aan het hoger management presenteren en deze, waar relevant, opnemen in het jaarlijkse beveiligingsrapport aan de raad van bestuur.

Dit sluit aan op de ISO/IEC 27005:2022-richtlijnen voor risicobehandeling: selecteer behandelopties, bepaal beheersmaatregelen uit ISO 27001 bijlage A en sectorspecifieke vereisten, stel een risicobehandelplan op, wijs verantwoordelijken toe, definieer tijdlijnen, volg de status, verkrijg goedkeuring van de risico-eigenaar en documenteer acceptatie van restrisico.

Elke significante TLPT-bevinding moet een van vier dingen worden: een remediatieactie, een verbetering van een beheersmaatregel, een formele risicoacceptatie of een vereiste voor een hertest.

Het doel is niet om meer documenten te produceren. Het doel is dat elk document de volgende beslissing verklaart.

Weerbaarheidstesten moeten herstel aantonen, niet alleen detectie

Een succesvolle TLPT kan aantonen dat het SOC command-and-control-verkeer detecteerde, laterale beweging blokkeerde en correct escaleerde. Dat is waardevol, maar DORA-weerbaarheidstesten gaan verder. Ze vragen of de organisatie bedrijfsdiensten kan voortzetten of herstellen.

De Zenith Blueprint, fase Controls in Action, stap 23, legt beheersmaatregel 5.30, ICT Readiness for Business Continuity, uit in taal die elke CISO met het bestuur zou moeten gebruiken:

Vanuit auditperspectief wordt deze beheersmaatregel vaak getest met één zin: Laat het zien. Laat het laatste testresultaat zien. Laat de hersteldocumentatie zien. Laat zien hoe lang failover en failback duurden. Laat het bewijsmateriaal zien dat wat is toegezegd ook geleverd kan worden.

Die “Laat het zien”-norm is het verschil tussen beleidsvolwassenheid en operationele weerbaarheid.

Clarysecs Business Continuity Policy and Disaster Recovery Policy-sme Business Continuity Policy and Disaster Recovery Policy - SME, uit de sectie “Vereisten voor beleidsimplementatie”, clausule 6.4.1, stelt:

De organisatie moet zowel haar BCP- als DR-capaciteiten ten minste jaarlijks testen. Tests moeten omvatten:

De handhavingssectie van hetzelfde beleid, clausule 8.5.1, maakt de verantwoordingsplicht voor bewijs expliciet:

De algemeen directeur moet ervoor zorgen dat het volgende wordt onderhouden en gereed is voor audits:

Voor een door DORA gereguleerde financiële entiteit kan jaarlijkse testing de ondergrens zijn, niet de ambitie. Kritieke of belangrijke functies met een hoger risico moeten vaker worden getest, vooral na architectuurwijzigingen, migraties naar cloudgehoste systemen, ernstige incidenten, nieuwe ICT-leveranciers, materiële applicatiereleases of wijzigingen in dreigingsblootstelling.

Een sterk bewijsdossier voor weerbaarheidstesten moet omvatten:

• Business Impact Analysis met mapping van de kritieke of belangrijke functie
• RTO en RPO goedgekeurd door bedrijfseigenaren
• Afhankelijkhedenkaart van systemen, inclusief identiteit, DNS, netwerk, cloud, database, monitoring, back-up en diensten van derde partijen
• Resultaten van back-up- en hersteltests
• Tijdstempels van failover en failback
• Bewijs dat beveiligingsmaatregelen tijdens de verstoring bleven werken
• Templates voor communicatie met klanten, toezichthouders en intern
• Deelname-logboeken van incidentleider en crisisteam
• Geleerde lessen en verbeteracties
• Bewijs van hertests voor eerdere herstelhiaten

Hier komt ook GDPR in beeld. Artikelen 2 en 3 van GDPR brengen de meeste SaaS- en fintechverwerkingen van persoonsgegevens uit de EU binnen scope. Artikel 4 definieert persoonsgegevens, verwerking, verwerkingsverantwoordelijke, verwerker en inbreuk in verband met persoonsgegevens. Artikel 5 vereist integriteit, vertrouwelijkheid en verantwoordingsplicht, wat betekent dat de organisatie naleving moet kunnen aantonen. Als TLPT of hersteltesten productiegegevens met persoonsgegevens gebruikt, logboeken met identificatoren kopieert of respons op inbreuken valideert, moeten privacywaarborgen worden gedocumenteerd.

Leveranciersbewijs is de DORA-blinde vlek die auditors niet zullen negeren

Moderne financiële diensten zijn opgebouwd uit cloudplatformen, SaaS-applicaties, managed security providers, betalingsverwerkers, dataplatformen, identiteitsproviders, observability-tools, uitbestede ontwikkelteams en back-upproviders.

Artikel 28 van DORA vereist dat financiële entiteiten ICT-risico’s van derde aanbieders beheren als onderdeel van het ICT-risicobeheerkader en volledig verantwoordelijk blijven, ook wanneer ICT-diensten zijn uitbesteed. Artikel 30 vereist schriftelijke ICT-dienstcontracten met dienstbeschrijvingen, voorwaarden voor onderaanneming, verwerkingslocaties, gegevensbescherming, toegang en herstel, serviceniveaus, incidentondersteuning, samenwerking met autoriteiten, beëindigingsrechten, sterkere voorwaarden voor kritieke of belangrijke functies, auditrechten, beveiligingsmaatregelen, TLPT-deelname waar relevant en exitregelingen.

Dit betekent dat een TLPT-scenario niet bij de firewall van de organisatie kan stoppen als de kritieke functie afhankelijk is van een leverancier.

Clarysecs Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME, uit de sectie “Vereisten voor beleidsimplementatie”, clausule 6.3.1, stelt:

Kritieke leveranciers of leveranciers met een hoog risico moeten ten minste jaarlijks worden beoordeeld. De beoordeling moet verifiëren:

De Security Testing and Red-Teaming Policy voegt in clausule 6.9 een testgerelateerde leveranciersvereiste toe:

Coördinatie van tests met derde partijen: wanneer een kritieke leverancier of dienstverlener binnen de scope van de algemene beveiliging van de organisatie valt, in overeenstemming met het beleid voor beveiliging van derde partijen en leveranciers, moet de organisatie waar mogelijk assurance verkrijgen over hun beveiligingstestpraktijken of gezamenlijke tests coördineren. Wanneer bijvoorbeeld een Cloud Service Provider (CSP) wordt gebruikt, kan de organisatie vertrouwen op diens penetratietestrapporten of deze opnemen in gezamenlijke red-teamscenario’s, onder voorbehoud van contractuele bepalingen.

Voor auditgereed DORA-bewijs moet leveranciersassurance worden gekoppeld aan hetzelfde risicoscenario als de TLPT. Als de identiteitsprovider essentieel is voor herstel van betalingen, moet het bewijsdossier leveranciers-due diligence, contractuele beveiligingsvereisten, voorwaarden voor incidentondersteuning, testcoördinatie, assurancerapporten, bewijs over serviceniveaus, exitstrategie en testbeperkingen bevatten.

Artikel 21 van NIS2 is ook relevant voor SaaS-, cloud-, managed service-, managed security-, datacenter-, CDN-, trust service-, DNS-, TLD-, online marktplaats-, zoekmachine- en socialenetwerkaanbieders. Het vereist een all-hazards-benadering die risicoanalyse, incidentenafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige ontwikkeling, doeltreffendheidsbeoordeling, training, cryptografie, toegangscontrole, beheer van bedrijfsmiddelen, MFA en beveiligde communicatie omvat.

Het praktische resultaat is eenvoudig: financiële entiteiten moeten één bewijsmodel bouwen dat eerst aan DORA voldoet en vervolgens NIS2-verwachtingen kruiselings verwijst waar leveranciers, groepsentiteiten of niet-financiële digitale diensten betrokken zijn.

Een praktisch Clarysec TLPT-bewijsregister

Neem aan dat het scenario luidt:

“Een dreigingsactor compromitteert een beheerdersaccount bij een SaaS-supportplatform, beweegt door naar de betalingsoperatieomgeving, wijzigt configuratie en verstoort transactieverwerking.”

Maak een bewijsregister met één rij per bewijsobject. Wacht niet tot de test is afgelopen. Vul het tijdens planning, uitvoering, remediatie en afsluiting.

Gebruik vervolgens Zenith Blueprint stap 13 om traceerbaarheid toe te voegen aan het risicoregister en de Verklaring van Toepasselijkheid. Elk bewijsitem moet verbonden zijn met een risicoscenario, risico-eigenaar, geselecteerde beheersmaatregel, behandelplan en besluit over restrisico.

Als een bevinding betrekking heeft op een softwarezwakte, verwijs dan naar beheersmaatregelen voor veilige ontwikkeling en testen. Clarysecs Secure Development Policy-sme Secure Development Policy - SME, uit de sectie “Vereisten voor beleidsimplementatie”, clausule 6.5.2, vereist:

Testen moet worden gedocumenteerd met:

Als een bevinding forensisch materiaal oplevert, borg dan de chain of custody. Clarysecs Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy - SME, uit de sectie “Governancevereisten”, clausule 5.2.1, stelt:

Elk digitaal bewijsobject moet worden gelogd met:

Dit is het punt dat veel teams missen. Bewijs bestaat niet alleen uit eindrapporten. Het is de gecontroleerde registratie van wie heeft goedgekeurd, wie heeft uitgevoerd, wat er is gebeurd, wat is gedetecteerd, wat is hersteld, wat is gewijzigd, welke blootstelling resteert en wie die blootstelling heeft geaccepteerd.

Hoe auditors hetzelfde TLPT-bewijs inspecteren

DORA TLPT-bewijs wordt verschillend gelezen, afhankelijk van de achtergrond van de auditor. Clarysec ontwerpt bewijsdossiers zo dat elke invalshoek kan vinden wat nodig is, zonder teams te dwingen dubbel werk te doen.

COBIT 2019 komt voor in de cross-compliance referentie van de Zenith Blueprint voor veilige audit- en testuitvoering, waaronder DSS05.03 en MEA03.04. De relevantie is niet dat COBIT DORA of ISO 27001 vervangt, maar dat assuranceprofessionals in ISACA-stijl zoeken naar gecontroleerde uitvoering, monitoring, evaluatie en nalevingsbewijs.

Het bestuursverhaal: wat het management moet goedkeuren

Bestuursrapportage moet technisch theater vermijden. Het bestuur heeft geen exploitpayloads nodig. Het heeft besluitwaardig bewijs nodig:

• Welke kritieke of belangrijke functie is getest?
• Welk dreigingsscenario is gesimuleerd en waarom?
• Werkte detectie?
• Werkte responsescalatie?
• Voldeed herstel aan RTO en RPO?
• Welke leveranciers waren betrokken of vormden een beperking?
• Welke materiële zwaktes blijven bestaan?
• Wat zijn de remediatiekosten, eigenaar en tijdlijn?
• Welke restrisico’s vereisen formele acceptatie?
• Wat wordt opnieuw getest?

Hier wordt ISO 27001 Clausule 5 belangrijk. Topmanagement moet ervoor zorgen dat het informatiebeveiligingsbeleid en de doelstellingen zijn vastgesteld, afgestemd zijn op de strategische richting, geïntegreerd zijn in bedrijfsprocessen, voorzien zijn van middelen, gecommuniceerd worden en continu worden verbeterd. Rollen en verantwoordelijkheden moeten worden toegewezen. Doelstellingen moeten waar uitvoerbaar meetbaar zijn en rekening houden met toepasselijke vereisten en resultaten van risicobehandeling.

Als TLPT vaststelt dat de hersteltijd zes uur bedraagt tegenover een zakelijke tolerantie van vier uur, is dit niet slechts een item op de infrastructuurbacklog. Het is een managementbesluit dat risicobereidheid, budget, klantverplichtingen, regelgevingsblootstelling, contracten, architectuur en operationele capaciteit raakt.

Veelvoorkomende bewijsfouten bij DORA-weerbaarheidstesten

Clarysec-beoordelingen vinden vaak dezelfde bewijshiaten bij financiële entiteiten en ICT-dienstverleners die zich op DORA voorbereiden.

Ten eerste sluit de TLPT-scope niet aan op kritieke of belangrijke functies. De test kan technisch indrukwekkend zijn, maar bewijst niet de weerbaarheid van het bedrijfsproces waar toezichthouders om vragen.

Ten tweede worden leveranciersafhankelijkheden erkend maar niet onderbouwd. Teams zeggen dat de cloudprovider, het managed SOC of het SaaS-platform binnen scope valt, maar contracten, auditrechten, testtoestemmingen, voorwaarden voor incidentondersteuning en exitplannen ontbreken.

Ten derde levert testen bewijs op, maar geen behandeling. Bevindingen blijven in een red-teamrapport staan in plaats van te worden omgezet in updates van het risicoregister, wijzigingen in beheersmaatregelen, eigenaren, datums, hertests en besluiten over restrisico.

Ten vierde wordt herstel verondersteld in plaats van aangetoond. Back-upbeleid bestaat, maar niemand kan failovertijdstempels, integriteitscontroles van herstel, toegangsvalidatie of bevestiging door een bedrijfseigenaar tonen.

Ten vijfde zijn privacy- en forensisch bewijs ongecontroleerd. Logboeken en screenshots bevatten persoonsgegevens, testartefacten worden opgeslagen op gedeelde schijven, tijdelijke accounts blijven actief en de chain of custody van bewijs is onvolledig.

Ten zesde is managementrapportage te technisch. Senior leiders kunnen niet zien of de weerbaarheid is verbeterd, of het risico binnen de risicobereidheid ligt of welke investeringsbeslissingen nodig zijn.

Elk van deze hiaten kan worden opgelost door DORA TLPT te behandelen als een gestructureerde ISO 27001-bewijsworkflow.

Clarysecs geïntegreerde aanpak voor auditgereede weerbaarheid

De aanpak van Clarysec combineert drie lagen.

De eerste laag is de Zenith Blueprint-implementatieroadmap in 30 stappen. Voor dit onderwerp bouwt stap 13 traceerbaarheid voor risicobehandeling en SoA op, beschermt stap 21 systemen tijdens audittesten en valideert stap 23 ICT-gereedheid voor bedrijfscontinuïteit. Deze stappen veranderen TLPT van een technische gebeurtenis in een gedocumenteerde governancecyclus.

De tweede laag is de beleidsbibliotheek van Clarysec. De Security Testing and Red-Teaming Policy definieert testtypen, scope, spelregels voor de uitvoering, remediatie, rapportage en leverancierscoördinatie. De Business Continuity Policy and Disaster Recovery Policy-sme stelt verwachtingen vast voor jaarlijkse BCP- en DR-tests en auditgereed continuïteitsbewijs. De Third-Party and Supplier Security Policy-sme ondersteunt leveranciersassurance. De Secure Development Policy-sme zorgt dat beveiligingstesten worden gedocumenteerd. De Evidence Collection and Forensics Policy-sme ondersteunt bewijslogging en discipline voor chain of custody.

De derde laag is Zenith Controls, Clarysecs cross-compliance guide. Deze helpt ISO/IEC 27002:2022-beheersmaatregelen te koppelen aan attributen, domeinen, operationele capaciteiten en cross-frameworkverwachtingen. Voor DORA TLPT is het belangrijkste patroon niet één beheersmaatregel. Het is de relatie tussen testen, continuïteit, incidentbeheer, leveranciersmanagement, logging, monitoring, veilige ontwikkeling, onafhankelijke beoordeling en governance.

Wanneer deze lagen samenwerken, verandert het maandagochtendprobleem van de CISO. In plaats van drie losstaande vragen van bestuur, toezichthouder en interne audit heeft de organisatie één bewijsverhaal:

“Wij hebben de kritieke functie geïdentificeerd. Wij hebben het ICT-risico beoordeeld. Wij hebben beheersmaatregelen geselecteerd en onderbouwd. Wij hebben TLPT geautoriseerd en veilig uitgevoerd. Wij hebben gedetecteerd, gereageerd en hersteld. Wij hebben leveranciers betrokken waar vereist. Wij hebben bewijs gedocumenteerd. Wij hebben bevindingen geremedieerd. Wij hebben hertests uitgevoerd. Het management heeft het resterende risico beoordeeld en geaccepteerd.”

Dat is auditgereede weerbaarheid.

Volgende stappen

Als uw DORA TLPT-programma nog steeds rond rapporten is georganiseerd in plaats van rond bewijsketens, begin dan met een Clarysec evidence walkthrough.

Gebruik Zenith Blueprint Zenith Blueprint stap 13 om TLPT-scenario’s te koppelen aan risico’s, beheersmaatregelen en de Verklaring van Toepasselijkheid. Gebruik stap 21 om veilige autorisatie, spelregels voor de uitvoering, rollback, monitoring en opschoning te verifiëren. Gebruik stap 23 om ICT-gereedheid voor bedrijfscontinuïteit aan te tonen met herstelbewijs.

Stem vervolgens uw operationele documenten af op Clarysecs Security Testing and Red-Teaming Policy Security Testing and Red-Teaming Policy, Business Continuity Policy and Disaster Recovery Policy-sme Business Continuity Policy and Disaster Recovery Policy - SME, Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME, Secure Development Policy-sme Secure Development Policy - SME en Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy - SME.

Gebruik ten slotte Zenith Controls Zenith Controls om uw DORA TLPT-bewijs kruiselings te koppelen aan ISO 27001-beheersmaatregelen, NIS2, GDPR, COBIT 2019 en auditorverwachtingen.

Als u wilt dat uw volgende weerbaarheidstest meer oplevert dan bevindingen, gebruik dan Clarysec om deze om te zetten in een verdedigbare bewijsketen. Download de toolkits, plan een beoordeling van bewijs-gereedheid of vraag een walkthrough aan van hoe Clarysec DORA TLPT koppelt aan ISO 27001:2022-beheersmaatregelen, van planning tot en met bestuursgoedkeuring.