⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

Voorbij de vragenlijst: de definitieve CISO-gids voor audits bij hoogrisicoleveranciers onder NIS2 en DORA

Clarysec AI Editor
18 min read
Processtroomdiagram voor audits bij hoogrisicoleveranciers, met een levenscyclus in 4 fasen: van initiële risicobeoordeling en contractbeoordeling tot doorlopende monitoring, technische audits en het bewaren van toezichtsdocumentatie voor NIS2- en DORA-compliance.

Het rapport belandde met een zachte klap op het bureau van CISO Maria Valen, maar het voelde eerder als een alarmsignaal. Het was het vooronderzoek voor hun aanstaande DORA-compliancebeoordeling, en één regel was felrood gemarkeerd: “Onvoldoende assurance voor kritieke externe dienstverlener, CloudSphere.”

CloudSphere was niet zomaar een leverancier. Het bedrijf vormde de ruggengraat van het nieuwe digitale bankplatform van de organisatie en verwerkte dagelijks miljoenen transacties. Maria had hun ISO/IEC 27001:2022-certificaat in het dossier. Ze had hun ingevulde beveiligingsvragenlijst, een omvangrijk document met 200 vragen. Maar de pre-auditors gaven aan dat afvinkcompliance voor een hoogrisico- en kritieke leverancier niet langer volstond. De spelregels waren veranderd.

Nu zowel de NIS2-richtlijn als de Digital Operational Resilience Act (DORA) volledig van kracht zijn, kijken toezichthouders verder dan het papieren spoor. Zij verlangen concreet bewijs van due diligence, doorlopende monitoring en robuuste governance over de volledige toeleveringsketen. Maria staat voor dezelfde uitdaging als CISO’s overal: hoe komt u voorbij de vragenlijst om uw meest kritieke leveranciers daadwerkelijk te auditen en te beveiligen? Dat vereist een strategische verschuiving van passieve validatie naar actieve, op auditbewijs gebaseerde assurance.

De tekortkoming van de statische vragenlijst in een dynamische wereld

Jarenlang was de beveiligingsvragenlijst de hoeksteen van derdepartijrisicobeheer. Maar het blijft een statische momentopname in een dynamisch dreigingslandschap. Het risicoprofiel van een leverancier staat niet vast; het verandert met iedere nieuwe dreiging, systeemwijziging of ingeschakelde onderaannemer. Uitsluitend vertrouwen op zelfverklaringen voor een kritieke leverancier als CloudSphere is alsof u door een storm navigeert met de weerkaart van vorig jaar.

De NIS2-richtlijn vraagt expliciet om een risicogebaseerde aanpak en vereist dat beveiligingsmaatregelen in verhouding staan tot de werkelijke risico’s. Dat betekent dat een uniforme vragenlijst fundamenteel niet aansluit op moderne toezichtverwachtingen. De tijd dat een certificaat of ingevulde checklist kon dienen als vervanging voor auditbewijs, is voorbij. Het werkelijke risico ligt voorbij het papieren spoor.

Daarom is een gestructureerde, op de levenscyclus gebaseerde aanpak essentieel. Het gaat niet om het afschaffen van vragenlijsten, maar om het aanvullen ervan met diepgaandere en indringendere verificatie voor leveranciers die er echt toe doen. Dit is het kernprincipe in Clarysec’s Beleid voor beveiliging van derde partijen en leveranciers. Een van de fundamentele doelstellingen luidt:

“Vereis formele due diligence en gedocumenteerde risicobeoordelingen voordat nieuwe leveranciers worden ingeschakeld of hoogrisico-dienstverleningsovereenkomsten worden verlengd.”

  • Uit sectie ‘Doelstellingen’, beleidsclausule 3.3

Deze clausule verschuift de denkwijze van een eenvoudige controle naar een formeel onderzoek: een cruciale eerste stap om een verdedigbaar programma op te bouwen dat standhoudt bij toetsing door toezichthouders.

Leveranciersrisico onder NIS2 en DORA: de nieuwe verwachtingen

Zowel NIS2 als DORA vereisen dat organisaties risico’s binnen hun leverancierslandschap systematisch identificeren, beoordelen en doorlopend monitoren. Zij maken van leveranciersbeheer niet langer uitsluitend een inkoopfunctie, maar een kernpijler van operationele weerbaarheid en informatiebeveiliging.

Het nieuwe toezichtsklimaat vereist duidelijke raamwerken die nauw zijn gekoppeld aan gevestigde normen zoals ISO/IEC 27001:2022. Hieronder staat een samenvatting op hoofdlijnen van wat deze raamwerken verwachten van uw programma voor leveranciersgovernance:

VereisteNIS2DORAISO/IEC 27001:2022-beheersmaatregelen
Risicobeoordeling van leveranciersArticle 21(2)(d)Articles 28–305.19, 5.21
Contractuele beveiligingsclausulesArticle 21(3), Article 22Article 305.20
Doorlopende monitoringArticle 21, Article 22Articles 30, 315.22
Kwetsbaarhedenbeheer en incidentresponsArticle 23Article 9, 115.29, 8.8

Een robuust leveranciersauditprogramma hoeft niet vanaf nul te worden ontworpen. Het ISO/IEC 27001:2022-raamwerk, met name de beheersmaatregelen in Annex A, biedt een krachtige blauwdruk. Bij Clarysec begeleiden wij klanten bij het opbouwen van hun programma rond drie onderling verbonden beheersmaatregelen die samen een volledige levenscyclus voor leveranciersgovernance vormen.

Een verdedigbaar auditkader opbouwen: de ISO 27001:2022-levenscyclus

Om een programma te bouwen dat aan de verwachtingen van toezichthouders voldoet, hebt u een gestructureerde aanpak nodig die is gebaseerd op een wereldwijd erkende norm. De beheersmaatregelen voor leveranciersbeveiliging in ISO/IEC 27001:2022 bieden een levenscyclus voor het beheren van risico’s van derde partijen, van initiatie tot beëindiging. Laten we bekijken hoe Maria deze levenscyclus kan gebruiken om een verdedigbaar auditplan voor CloudSphere op te stellen.

Stap 1: de basis - informatiebeveiliging in leveranciersrelaties (5.19)

Beheersmaatregel 5.19 is het strategische startpunt. Deze vereist dat u formele processen vaststelt voor het identificeren, beoordelen en beheren van informatiebeveiligingsrisico’s die samenhangen met uw volledige leveranciersecosysteem. Hier definieert u wat “hoog risico” voor uw organisatie betekent en stelt u de spelregels vast.

Clarysec’s Zenith Controls: The Cross-Compliance Guide biedt een gedetailleerde uitwerking van 5.19 en laat zien hoe deze beheersmaatregel fungeert als centraal knooppunt voor leveranciersgovernance. Deze beheersmaatregel is intrinsiek verbonden met gerelateerde beheersmaatregelen, zoals 5.21 (Informatiebeveiliging in de ICT-toeleveringsketen), die hardware- en softwarecomponenten afdekt, en 5.14 (Informatieoverdracht), die veilige gegevensuitwisseling regelt. U kunt een leveranciersrelatie niet effectief beheren zonder ook de technologie die zij leveren en de gegevens die u deelt te beheersen.

Voor Maria betekent dit dat haar audit van CloudSphere verder moet gaan dan het algemene informatiebeveiligingsrisicoprofiel van de leverancier en moet doordringen tot de beveiliging van het daadwerkelijke platform dat zij leveren. De gids Zenith Controls benadrukt dat een sterke implementatie van 5.19 rechtstreeks bijdraagt aan naleving van belangrijke regelgeving:

  • NIS2 (Article 21(2)(d)): verplicht organisaties om toeleveringsketenrisico’s te beheren als kernonderdeel van hun beveiligingskader.
  • DORA (Articles 28–30): verplicht tot een robuust kader voor ICT-risicobeheer van derde partijen, inclusief kritikaliteitsclassificatie en precontractuele due diligence.
  • GDPR (Article 28): vereist dat verwerkingsverantwoordelijken uitsluitend verwerkers inschakelen die voldoende garanties bieden voor gegevensbescherming.

Deze beheersmaatregel verplicht tot risicoclassificatie van leveranciers, doorlopende monitoring en tijdige intrekking van toegangsrechten. Het doel is te waarborgen dat beveiliging is ingebed in de leverancierslevenscyclus en niet achteraf wordt toegevoegd.

Stap 2: de afdwinging - informatiebeveiliging opnemen in leveranciersovereenkomsten (5.20)

Een beveiligingseis die niet in het contract staat, is slechts een suggestie. Beheersmaatregel 5.20 is waar governance juridisch afdwingbaar wordt. Voor een hoogrisicoleverancier is uw contract uw krachtigste auditinstrument.

Zoals Zenith Controls benadrukt, moeten deze overeenkomsten expliciet zijn. Vage beloften over “sectorleidende beveiliging” zijn waardeloos. Voor een leverancier als CloudSphere moet Maria verifiëren dat het contract specifieke, meetbare clausules bevat die haar organisatie concreet toezicht geven:

  • Auditrechten: een clausule die haar organisatie expliciet het recht geeft om technische beoordelingen uit te voeren, auditbewijs te beoordelen of namens haar een derde partij een audit te laten uitvoeren.
  • Meldtermijnen voor inbreuken: specifieke, strikte termijnen, bijvoorbeeld binnen 24 uur na ontdekking, voor het melden van een beveiligingsincident aan haar organisatie, in plaats van een vage formulering als “zonder onredelijke vertraging”.
  • Beheer van onderaannemers en vierde partijen: een clausule die de leverancier verplicht dezelfde beveiligingsstandaarden af te dwingen bij de eigen kritieke onderaannemers en haar te informeren over wijzigingen. Dit is cruciaal voor het beheren van downstream-risico.
  • Veilige exitstrategie: duidelijke verplichtingen voor teruggave of gecertificeerde vernietiging van gegevens bij beëindiging van het contract.

DORA is hier bijzonder voorschrijvend. Article 30 bevat verplichte contractuele bepalingen, waaronder onbelemmerde toegang voor auditors en toezichthouders, specifieke gegevens over dienstverleningslocaties en uitgebreide exitstrategieën. Auditors zullen contracten met hoogrisicoleveranciers steekproefsgewijs beoordelen en rechtstreeks controleren op deze clausules.

Stap 3: de doorlopende cyclus - monitoring, beoordeling en wijzigingsbeheer van leveranciersdiensten (5.22)

Het laatste onderdeel van de levenscyclus is beheersmaatregel 5.22, die leverancierstoezicht transformeert van een momentopname naar een doorlopend proces. Een audit mag geen verrassingsmoment zijn, maar moet een validatiepunt vormen binnen een voortdurende relatie waarin transparantie centraal staat.

Hier schieten veel organisaties tekort. Zij laten het contract ondertekenen en bergen het op. Maar bij hoogrisicoleveranciers begint het echte werk pas na onboarding. De gids Zenith Controls koppelt 5.22 aan kritieke operationele processen zoals 8.8 (Beheer van technische kwetsbaarheden) en 5.29 (Informatiebeveiliging tijdens verstoring). Dit betekent dat effectieve monitoring veel verder gaat dan een jaarlijkse beoordelingsvergadering. Het omvat:

  • Beoordelen van auditbewijs van derde partijen: het actief verkrijgen en analyseren van SOC 2 Type II-rapporten, resultaten van ISO 27001-controleaudits of samenvattingen van penetratietesten. De kern is het beoordelen van de uitzonderingen en het opvolgen van de herstelmaatregelen.
  • Monitoren op incidenten: het volgen van publiek bekendgemaakte inbreuken of beveiligingsincidenten waarbij de leverancier betrokken is, en het formeel beoordelen van de mogelijke impact op uw organisatie.
  • Beheren van wijzigingen: het implementeren van een proces waarbij elke significante wijziging in de dienst van de leverancier, zoals een nieuwe datacenterlocatie of een nieuwe kritieke onderaannemer, automatisch een nieuwe risicobeoordeling triggert.

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap biedt hiervoor praktische richtlijnen, met name in stap 24, die betrekking heeft op onderaannemersrisico. Het advies luidt:

“Identificeer voor elke kritieke leverancier of zij onderaannemers (subverwerkers) gebruiken die toegang kunnen hebben tot uw gegevens of systemen. Documenteer hoe uw informatiebeveiligingseisen aan deze partijen worden doorgelegd… Vraag waar mogelijk een lijst van belangrijke onderaannemers op en zorg ervoor dat uw auditrecht of recht op assurance ook op hen van toepassing is.”

Dit is een cruciaal punt voor Maria. Gebruikt CloudSphere een externe aanbieder voor data-analyse? Wordt hun infrastructuur gehost in een grote publieke cloud? Deze downstream-afhankelijkheden vormen een significant en vaak onzichtbaar risico dat haar audit zichtbaar moet maken.

Van theorie naar praktijk: Maria’s praktische auditplan voor CloudSphere

Gewapend met deze ISO 27001:2022-levenscyclus stelt Maria’s team een nieuw auditplan voor CloudSphere op dat ver voorbij de vragenlijst gaat en de volwassen, risicogebaseerde governance aantoont die toezichthouders verlangen.

  1. Contractbeoordeling: zij beginnen met het mappen van het bestaande CloudSphere-contract tegen DORA Article 30 en de best practices voor beheersmaatregel 5.20. Zij stellen een hiaatanalyserapport op als input voor de volgende verlengingscyclus en om prioriteiten te bepalen voor de huidige audit.

  2. Gericht verzoek om auditbewijs: in plaats van een generieke vragenlijst sturen zij een formeel verzoek om specifiek auditbewijs, waaronder:

    • het meest recente SOC 2 Type II-rapport en een samenvatting van hoe alle vastgestelde uitzonderingen zijn verholpen;
    • de managementsamenvatting van hun meest recente externe penetratietest;
    • een volledige lijst van alle onderaannemers (vierde partijen) die hun gegevens zullen verwerken of er toegang toe zullen hebben;
    • bewijs dat beveiligingseisen contractueel zijn doorgelegd naar deze onderaannemers;
    • logboeken of rapportages waaruit tijdige patching van kritieke kwetsbaarheden blijkt, bijvoorbeeld Log4j en MOVEit, over de afgelopen zes maanden.
  3. Technische validatie: zij roepen hun clausule over auditrechten in om een technische verdiepingssessie met het beveiligingsteam van CloudSphere te plannen. De agenda richt zich op hun incidentresponsdraaiboeken, tools voor beheer van cloudbeveiligingsrisico’s en beheersmaatregelen ter voorkoming van gegevenslekkage.

  4. Formeel uitzonderingsbeheer: als CloudSphere bezwaar maakt tegen het leveren van bepaald auditbewijs, is Maria voorbereid. Het governanceproces van haar organisatie, vastgelegd in het Beleid voor beveiliging van derde partijen en leveranciers, is duidelijk:

“Hoogrisico-uitzonderingen (bijv. leveranciers die gereguleerde gegevens verwerken of kritieke systemen ondersteunen) moeten worden goedgekeurd door de CISO, Juridische Zaken en Inkoopleiding en worden geregistreerd in het ISMS-uitzonderingenregister.”

  • Uit sectie ‘Risicobehandeling en uitzonderingen’, beleidsclausule 7.3

Dit zorgt ervoor dat een weigering om auditbewijs te leveren niet eenvoudig wordt genegeerd, maar formeel als risico wordt geaccepteerd op het hoogste niveau van de organisatie: een proces dat auditors respecteren.

Het perspectief van de auditor: wat verschillende auditors zullen verlangen

Om een werkelijk weerbaar programma op te bouwen, moet u denken als een auditor. Verschillende auditraamwerken kijken vanuit verschillende invalshoeken, en het anticiperen op hun vragen is essentieel voor succes. Hieronder staat een geconsolideerd overzicht van wat verschillende auditors zullen verlangen bij de beoordeling van uw programma voor leveranciersgovernance:

Achtergrond van de auditorBelangrijkste focusgebied en beheersmaatregelenAuditbewijs dat zij zullen verlangen
ISO/IEC 27001:2022-auditor5.19, 5.20, 5.22Leveranciersinventaris met risicoclassificaties; steekproefsgewijs geselecteerde contracten voor hoogrisicoleveranciers om beveiligingsclausules te verifiëren; registraties van due diligence en doorlopende beoordelingsvergaderingen.
COBIT 2019-auditorAPO10 (Manage Suppliers), DSS04 (Manage Continuity)Auditbewijs van doorlopende prestatiemonitoring ten opzichte van SLA’s; documentatie van hoe leveranciersgerelateerde incidenten worden beheerd; registraties van leveranciersrisicobeoordelingen en wijzigingsbeheer.
DORA / financiële toezichthouderArticles 28-30Het contract met de kritieke ICT-dienstverlener, gemapt tegen de verplichte clausules van DORA; de beoordeling van concentratierisico; auditbewijs van het testen of beoordelen van de exitstrategie.
NIST SP 800-53-auditorSA-9 (External System Services), SR Family (Supply Chain)Bewijs van een risicobeheerplan voor de toeleveringsketen; registraties van compliancebewijs van leveranciers, bijvoorbeeld FedRAMP en SOC 2; documentatie van zichtbaarheid op vierdepartijrisico.
ISACA / IT-auditorITAF Performance Standard 2402Logboeken die aantonen dat toegang voor beëindigd leverancierspersoneel tijdig is ingetrokken; auditbewijs van unieke, met MFA beveiligde accounts voor toegang van derden; registraties van incidentrespons.

Dit perspectief vanuit meerdere invalshoeken laat zien dat een robuust programma niet draait om het voldoen aan één norm, maar om het bouwen van een holistisch governancekader dat het auditbewijs oplevert dat nodig is om aan alle relevante eisen te voldoen.

Kritieke valkuilen: waar leveranciersaudits mislukken

Veel programma’s voor leverancierstoezicht schieten tekort door veelvoorkomende, vermijdbare fouten. Wees alert op deze kritieke valkuilen:

  • Auditen als een gebeurtenis: vertrouwen op eenmalige audits tijdens onboarding of verlenging in plaats van doorlopende monitoring te implementeren.
  • Certificeringszelfgenoegzaamheid: een ISO- of SOC 2-certificaat voor waar aannemen zonder de rapportdetails, reikwijdte en uitzonderingen te beoordelen.
  • Vage contracten: nalaten expliciete, afdwingbare clausules op te nemen voor auditrechten, meldplicht bij inbreuken en gegevensverwerking.
  • Gebrekkig inventarisbeheer: geen volledige, naar risico ingedeelde inventaris kunnen opleveren van alle leveranciers en de gegevens waartoe zij toegang hebben.
  • Downstream-risico negeren: nalaten de risico’s te identificeren en te beheren die voortkomen uit de eigen kritieke onderaannemers van een leverancier, oftewel vierdepartijrisico.
  • Niet-geverifieerd kwetsbaarhedenbeheer: erop vertrouwen dat een leverancier kritieke kwetsbaarheden patcht zonder om auditbewijs te vragen.

Praktische checklist voor audits bij hoogrisicoleveranciers

Gebruik deze checklist, gebaseerd op de Zenith Blueprint, om te waarborgen dat uw auditproces voor elke hoogrisicoleverancier volledig en verdedigbaar is.

StapActieTe verzamelen en te bewaren auditbewijs
Due diligenceVoer vóór onboarding of verlenging een formele risicobeoordeling uit en documenteer deze.Ingevuld werkblad voor leveranciersrisico; classificatieregistratie; due-diligencerapport.
ContractbeoordelingVerifieer dat clausules voor beveiliging, privacy en audit aanwezig en afdwingbaar zijn.Ondertekend contract met gemarkeerde clausules; formele goedkeuring van juridische toetsing; verwerkersovereenkomst.
Doorlopende monitoringPlan en voer kwartaal- of jaarbeoordelingen uit op basis van het risiconiveau.Notulen; beoordeelde SOC 2- / ISO 27001-rapporten; samenvattingen van kwetsbaarheidsscans.
Toezicht op onderaannemersIdentificeer en documenteer alle kritieke downstream-leveranciers (vierde partijen).Lijst van subverwerkers die door de leverancier is verstrekt; auditbewijs van doorleggingsclausules voor beveiligingseisen.
KwetsbaarhedenbeheerVereis auditbewijs van een volwassen programma voor kwetsbaarhedenbeheer.Recente managementsamenvatting van een penetratietest; voorbeelden van kwetsbaarheidsscanrapporten; patchtermijnen.
IncidentmeldingTest en valideer het incidentmeldingsproces van de leverancier.Registraties van eerdere incidentmeldingen; gedocumenteerde SLA’s voor meldplicht bij inbreuken.
WijzigingsbeheerBeoordeel alle significante technische of organisatorische wijzigingen bij de leverancier.Wijzigingslogboeken van leveranciers; rapportages van door wijzigingen getriggerde hernieuwde risicobeoordelingen.
RegelgevingsmappingKoppel uw geïmplementeerde beheersmaatregelen rechtstreeks aan NIS2-, DORA- en GDPR-vereisten.Interne compliancemapping; auditbewijslogboek voor toezichthouders.

Conclusie: bouwen aan een weerbare en verdedigbare toeleveringsketen

Het tijdperk van afvinkcompliance voor kritieke leveranciers is voorbij. De intensieve toetsing vanuit regelgeving zoals NIS2 en DORA vereist een fundamentele verschuiving naar een model van doorlopende, op auditbewijs gebaseerde assurance. CISO’s zoals Maria moeten het voortouw nemen om hun organisaties voorbij de statische vragenlijst te brengen.

Door een programma te bouwen op de bewezen levenscyclus van ISO/IEC 27001:2022-beheersmaatregelen creëert u een kader dat niet alleen aan de eisen voldoet, maar ook daadwerkelijk effectief is in het reduceren van risico. Dit betekent dat leveranciersbeveiliging als een strategische discipline wordt behandeld, dat afdwingbare eisen in contracten worden opgenomen en dat gedurende de volledige relatie alert toezicht wordt gehouden.

De beveiliging van uw organisatie is slechts zo sterk als de zwakste schakel. In het huidige onderling verbonden ecosysteem bevindt die schakel zich vaak bij een derde partij. Het is tijd om de controle terug te nemen.

Klaar om voorbij de vragenlijst te gaan?

De geïntegreerde toolkits van Clarysec bieden de basis die u nodig hebt om een leveranciersrisicobeheerprogramma van wereldklasse te bouwen dat elke audit kan doorstaan.

Frequently Asked Questions

About the Author

Igor Petreski

Igor Petreski

Compliance Systems Architect, Clarysec LLC

Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council

Share this article

Related Articles

De zwakke schakel: een CISO-draaiboek voor het opzetten van een NIS2-conform risicoprogramma voor de toeleveringsketen

De zwakke schakel: een CISO-draaiboek voor het opzetten van een NIS2-conform risicoprogramma voor de toeleveringsketen

Dit kernartikel begeleidt CISO’s en complianceverantwoordelijken bij een praktijkgerichte aanpak voor het opzetten van een NIS2-conform risicoprogramma voor de toeleveringsketen. Het combineert inzicht in regelgeving, uitvoerbare beheersmaatregelen en deskundige begeleiding van Clarysec om uw toeleveringsketen te transformeren van een kritieke kwetsbaarheid naar een weerbaar en controleerbaar bedrijfsmiddel.

Voorbij herstel: een CISO-gids voor echte operationele weerbaarheid met ISO 27001:2022

Voorbij herstel: een CISO-gids voor echte operationele weerbaarheid met ISO 27001:2022

Een ransomware-aanval vindt plaats tijdens een bestuursvergadering. Uw back-ups werken, maar geldt dat ook voor uw beveiliging? Ontdek hoe u de weerbaarheidsmaatregelen van ISO/IEC 27001:2022 implementeert om beveiliging onder druk te handhaven, auditors te overtuigen en met de deskundige roadmap van Clarysec te voldoen aan strenge DORA- en NIS2-vereisten.

Van compliance naar weerbaarheid: hoe CISO's de governancekloof dichten

Van compliance naar weerbaarheid: hoe CISO's de governancekloof dichten

Compliancechecklists voorkomen geen incidenten; actieve governance doet dat wel. We analyseren de grootste governancemythen voor CISO’s aan de hand van een praktijkincident en bieden een routekaart om echte organisatiebrede weerbaarheid op te bouwen met concrete stappen, beleidsvoorbeelden en raamwerkoverstijgende mappings voor ISO 27001:2022, NIS2, DORA en meer.