DORA-ICT-risicobereidheid: gids voor goedkeuring door het bestuursorgaan in 2026

Het is 08:15 op een dinsdag en de CISO van een middelgroot betalings­technologiebedrijf staat buiten de bestuurskamer met drie documenten geopend op een tablet.

Het eerste is het ICT-risicoregister. Het bevat 137 regels, kleurgecodeerde classificaties en meerdere hoge risico’s die verband houden met cloudconcentratie, beheer van geprivilegieerde toegang (PAM), ransomwareherstel, blootstelling van klantgegevens en respons op leveranciersincidenten. Het tweede is de DORA-gereedheidstracker. Daarin staat dat de onderneming beleid, incidentprocedures, registers voor derde partijen en plannen voor weerbaarheidstesten heeft. Het derde is het bestuurspakket voor een overleg met de toezichthouder.

De voorzitter heeft één vraag, en die is niet technisch:

“Welk niveau van ICT-risico hebben wij feitelijk afgesproken te accepteren?”

De ruimte wordt stil, omdat het bedrijf wel risicobeoordelingen heeft, maar geen door het bestuursorgaan goedgekeurde ICT-risicobereidheid. Het heeft impactclassificaties, maar geen meetbare tolerantiedrempels. Het heeft escalatieoverleggen, maar geen formele trigger die bepaalt wanneer een cyberrisico een besluit van het bestuursorgaan wordt. Het heeft restrisico’s geaccepteerd, maar sommige daarvan worden gerechtvaardigd als “zakelijke beslissingen” zonder duidelijke koppeling aan risicocriteria, proportionaliteit onder GDPR Article 32, DORA-tolerantieverwachtingen of NIS2-verantwoordingsplicht van het management.

Die kloof wordt in 2026 steeds zichtbaarder. DORA is van toepassing sinds 17 januari 2025 en vereist dat financiële entiteiten een governance- en beheerkader voor ICT-risico onderhouden, inclusief verantwoordelijkheid van het bestuursorgaan voor het ICT-risicobeheerkader, de strategie voor digitale operationele weerbaarheid en de ICT-risicotolerantie. NIS2 verplicht bestuursorganen maatregelen voor het beheer van cyberbeveiligingsrisico’s goed te keuren en toezicht te houden op de uitvoering ervan. GDPR Article 32 vereist passende technische en organisatorische beveiligingsmaatregelen op basis van risico. ISO/IEC 27001:2022 levert de mechanismen van het managementsysteem: context, belanghebbenden, risicocriteria, behandelplannen, gedocumenteerde informatie en directiebeoordeling.

De ontbrekende schakel is een verklaring over ICT-risicobereidheid en -tolerantie die een bestuursorgaan kan begrijpen, goedkeuren, bevragen en gebruiken.

Deze gids legt uit hoe u die schakel bouwt met Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap, Clarysec’s Beleid inzake risicobeheer, Clarysec’s Beleid inzake risicobeheer voor mkb en Zenith Controls: The Cross-Compliance Guide.

Waarom risicoregisters geen risicobereidheid zijn

Veel organisaties verwarren een risicoregister met risicogovernance. Een risicoregister laat zien welke risico’s bestaan, hoe ze zijn geclassificeerd, wie de eigenaar is en welke behandeling gepland is. Het beantwoordt niet automatisch de vragen op bestuursniveau die DORA, NIS2, GDPR en ISO/IEC 27001:2022 van leiders verwachten.

Een volwassen verklaring over ICT-risicobereidheid beantwoordt vragen zoals:

• Welke ICT-risico’s zijn onaanvaardbaar, ongeacht de kosten?
• Welke operationele uitvaltijd kan de organisatie tolereren voor een kritieke of belangrijke functie?
• Welk niveau van gegevensverlies of aantasting van gegevensintegriteit valt buiten de risicobereidheid?
• Welk concentratierisico bij derde partijen vereist aandacht van het bestuursorgaan?
• Wie mag ICT-restrisico accepteren, en op welk niveau?
• Wanneer moet een risico worden geëscaleerd naar het hoger management of het bestuursorgaan?
• Hoe worden wettelijke, regelgevende en contractuele eisen opgenomen in risicocriteria?

Onder DORA is dit geen optionele verfijning van governance. Article 5 vereist dat het bestuursorgaan het ICT-risicobeheerkader definieert, goedkeurt, overziet en ervoor verantwoordelijk is, inclusief de strategie voor digitale operationele weerbaarheid en ICT-risicotolerantie. Article 6 vereist een gedocumenteerd ICT-risicobeheerkader, jaarlijkse beoordeling voor niet-micro-ondernemingen, interne audit, remediatie van kritieke auditbevindingen en een strategie voor digitale operationele weerbaarheid met ICT-doelstellingen, risicotolerantie, impacttolerantie, architectuur, testen en strategie voor incidentcommunicatie.

NIS2 voegt een parallel verantwoordingsmodel toe. Article 20 vereist dat bestuursorganen van essentiële en belangrijke entiteiten maatregelen voor het beheer van cyberbeveiligingsrisico’s goedkeuren, toezicht houden op de uitvoering ervan en training ontvangen. Article 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen op basis van een all-hazardsbenadering, waaronder risicoanalyse, incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige ontwikkeling, doeltreffendheid van beheersmaatregelen, training, cryptografie, HR-beveiliging, toegangsbeveiliging, beheer van bedrijfsmiddelen en MFA waar passend.

Voor financiële entiteiten wordt DORA behandeld als een sectorspecifieke rechtshandeling van de Unie waar overlappende NIS2-verplichtingen van toepassing zijn. In de praktijk verdringt DORA doorgaans overlappende NIS2-eisen voor risicobeheer en incidentmelding voor financiële entiteiten binnen haar toepassingsgebied, terwijl NIS2 belangrijk blijft voor coördinatie en voor aanbieders buiten de directe verplichtingen van DORA voor financiële entiteiten. Voor SaaS-, cloud-, managed-service- en managed-securityproviders kan NIS2 rechtstreeks van toepassing zijn wanneer aan de toepassingsvoorwaarden wordt voldaan.

Daarom is door het bestuursorgaan goedgekeurde ICT-risicobereidheid niet langer een artefact van financieel risicobeheer. Het is een beheersmaatregel voor cyberbeveiligingsgovernance.

Gebruik ISO/IEC 27001:2022 als besturingssysteem

DORA en NIS2 vertellen leiders wat bestuurd moet worden. ISO/IEC 27001:2022 geeft organisaties een praktisch besturingssysteem voor hoe zij dat moeten besturen.

ISO/IEC 27001:2022 clausules 4.1 tot en met 4.4 vereisen dat de organisatie context, belanghebbenden, eisen, ISMS-toepassingsgebied en ISMS-processen definieert. Dit is van belang omdat DORA, NIS2, GDPR, contracten, toezichtsverwachtingen, klanten, cloudproviders en uitbestedingsregelingen allemaal eisen worden die risicocriteria beïnvloeden.

Clausules 5.1 tot en met 5.3 vereisen betrokkenheid van leiderschap, afstemming van beleid, middelen, verantwoordelijkheden en rapportage over ISMS-prestaties aan het topmanagement. Clausules 6.1.1 tot en met 6.1.3 vereisen risicogebaseerde planning, een gedocumenteerd risicobeoordelingsproces, risicoacceptatiecriteria, consistente beoordelingscriteria, risico-eigenaren, vergelijking met risicocriteria, behandelplanning, een Verklaring van Toepasselijkheid en goedkeuring van restrisico.

Dit vormt de basis voor DORA-ICT-risicotolerantie.

In de fase Risicobeheer schrijft stap 10 van de Zenith Blueprint voor dat organisaties risicocriteria definiëren voordat zij risico’s beoordelen:

“Risicocriteria zijn de regels en referentiepunten die uw organisatie gebruikt om het belang van elk risico te beoordelen. Door deze criteria vooraf vast te stellen, spreekt iedereen dezelfde risicotaal.”

Dezelfde stap waarschuwt dat regelgevende impact in risicodefinities moet worden opgenomen:

“Elk risico dat kan leiden tot niet-naleving van toepasselijke wetgeving (GDPR enz.) is onaanvaardbaar en moet worden gemitigeerd.”

De Zenith Blueprint geeft ook praktische richtlijnen voor impactschalen:

“Bij het definiëren van impact is het verstandig niveaus te relateren aan de specifieke schaal van uw organisatie. Bijvoorbeeld: ‘Grote financiële impact = verlies > $100k’ (aanpassen aan uw context). Houd ook rekening met regelgevende impact: een datalek met persoonsgegevens kan bijvoorbeeld automatisch ‘Groot’ of ‘Ernstig’ zijn vanwege GDPR-boetes en meldplichten, zelfs wanneer het directe financiële verlies onduidelijk is. Evenzo kan, als u binnen het toepassingsgebied van NIS2 valt (essentiële diensten), een incident dat dienstverstoring veroorzaakt ten minste ‘Groot’ zijn vanwege juridische implicaties. Neem dergelijke overwegingen op in uw definities.”

Die richtlijn voorkomt een veelvoorkomende fout: een cyberrisico als matig classificeren omdat het onmiddellijke financiële verlies klein lijkt, terwijl juridische impact, operationele weerbaarheid, impact op betrokkenen of klantimpact wordt genegeerd.

Een bestuursklaar model moet vier lagen onderscheiden:

Deze structuur maakt risicobereidheid auditeerbaar omdat elke uitspraak kan worden herleid tot risicocriteria, beheersmaatregelen, bewijs en besluiten.

Een bestuursklare DORA-verklaring over ICT-risicobereidheid

Een sterke verklaring over ICT-risicobereidheid is kort genoeg voor goedkeuring door het bestuursorgaan, specifiek genoeg voor toepassing door het management en meetbaar genoeg voor toetsing door auditors. Ze moet jargon vermijden, maar mag niet vaag zijn.

Een praktische verklaring op hoofdlijnen kan luiden:

“Onze onderneming heeft een lage risicobereidheid voor ICT-risico’s die kunnen leiden tot wezenlijke schade voor cliënten, verstoring van kritieke of belangrijke functies, ongeautoriseerde openbaarmaking of wijziging van gereguleerde gegevens, het niet nakomen van wettelijke verplichtingen of verlies van weerbaarheid in kritieke ICT-diensten van derde partijen.”

Die verklaring vereist vervolgens meetbare tolerantiedrempels en escalatietriggers.

Deze tabel verandert het gesprek. Het bestuursorgaan keurt niet langer een slogan goed. Het keurt operationele grenzen goed voor beschikbaarheid, vertrouwelijkheid, integriteit, leveranciers, kwetsbaarheden, herstel en naleving.

Clarysec’s Beleid inzake risicobeheer ondersteunt dit governancemodel. Het ondernemingsbeleid stelt:

“Keurt het risicobeheerkader goed en definieert aanvaardbare risicobereidheid en tolerantiedrempels.”

Clausule 6.2.1 maakt de meetvereiste expliciet:

“Risico’s moeten worden beoordeeld op waarschijnlijkheid en impact met behulp van een standaard risicomatrix met duidelijk gedefinieerde scoreschalen.”

Clausule 6.3.4 creëert de acceptatieregel die auditors verwachten:

“Risico’s die zonder behandeling worden geaccepteerd, moeten schriftelijk worden onderbouwd, gekoppeld zijn aan de risicobereidheid van de organisatie en op het juiste niveau worden goedgekeurd.”

Voor het mkb houdt het Beleid inzake risicobeheer voor mkb hetzelfde governanceprincipe aan in een lichtere vorm:

“Zorg voor betrokkenheid van het management bij het goedkeuren van risicotolerantie en belangrijke risicobehandelingsplannen.”

Het vereist ook escalatie van hoge risico’s:

“Hoge risico’s moeten ter besluitvorming worden geëscaleerd naar de algemeen directeur.”

Dit is proportionaliteit in de praktijk. DORA Article 4 vereist dat eisen worden toegepast op een wijze die evenredig is aan omvang, risicoprofiel en de aard, schaal en complexiteit van diensten. ISO/IEC 27001:2022 maakt hetzelfde principe mogelijk via toepassingsgebied, context, risicocriteria en behandelbesluiten. De governancestandaard is niet dat elke organisatie dezelfde comitéstructuur nodig heeft. De governancestandaard is dat risicobereidheid, tolerantie, escalatie en acceptatie zijn gedefinieerd, goedgekeurd, onderbouwd en toegepast.

GDPR Article 32 verandert het risicogesprek

GDPR Article 32 wordt vaak behandeld als een technische beveiligingsclausule. Vanuit governanceperspectief is het ook een clausule over risicobereidheid.

Article 32 vereist dat verwerkingsverantwoordelijken en verwerkers passende technische en organisatorische maatregelen implementeren om een op het risico afgestemd beveiligingsniveau te waarborgen. Die risicogebaseerde benadering houdt rekening met de stand van de techniek, implementatiekosten, aard, omvang, context en doeleinden van verwerking, en risico’s voor de rechten en vrijheden van natuurlijke personen.

Dit beïnvloedt ICT-risicobereidheid op drie manieren.

Ten eerste kan de impact op persoonsgegevens niet worden teruggebracht tot financieel verlies. Een kleine blootstelling van een database kan beperkte directe kosten hebben, maar ernstige gevolgen voor vertrouwelijkheid, identiteit, fraude, discriminatie of rechten. Als bijzondere categorieën persoonsgegevens betrokken zijn, zoals gezondheids-, biometrische of genetische gegevens, moet de risicobereidheid wezenlijk lager zijn.

Ten tweede moeten verwerkingsrollen worden gekoppeld aan risico-eigenaarschap. GDPR onderscheidt verwerkingsverantwoordelijken en verwerkers. DORA onderscheidt financiële entiteiten en ICT-dienstverleners van derde partijen. NIS2 onderscheidt essentiële en belangrijke entiteiten. ISO/IEC 27001:2022 vereist risico-eigenaren. Een volwassen verklaring over risicobereidheid moet vastleggen wie eigenaar is van risicobesluiten rond persoonsgegevens, uitbestede verwerking, kritieke diensten en grensoverschrijdende afhankelijkheden.

Ten derde moet proportionaliteit onder Article 32 zichtbaar zijn in de selectie van beheersmaatregelen. Encryptie, pseudonimisering, toegangsbeveiliging, back-up, logging, monitoring, incidentrespons en weerbaarheid zijn geen geïsoleerde technische taken. Het zijn behandelmaatregelen die zijn geselecteerd omdat een risico de risicobereidheid of tolerantie overschreed.

Clarysec’s Beleid inzake risicobeheer legt deze verbinding expliciet:

“Article 32: vereist een risicogebaseerde benadering van beveiligingsmaatregelen, ingevuld via impactgebaseerde risicobeoordelingen en selectie van beheersmaatregelen.”

Dat is de operationele koppeling waar auditors naar zoeken: eis uit Article 32, risicobeoordeling, risicoclassificatie, risicobehandelingsplan, selectie van beheersmaatregelen, restrisico en goedkeuring.

Hoe Zenith Controls bewijs voor compliance over meerdere kaders ondersteunt

Een door het bestuursorgaan goedgekeurde verklaring over risicobereidheid wordt krachtig wanneer zij wordt gemapt naar beheersmaatregelen. Zenith Controls fungeert als Clarysec’s gids voor compliance over meerdere kaders en helpt teams bewijs te hergebruiken voor ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF en assurance volgens COBIT.

Drie beheersmaatregelgebieden uit ISO/IEC 27002:2022 zijn bijzonder belangrijk:

Dit is geen papieren mapping-oefening. Het verandert hoe besluiten worden genomen.

Als een proceseigenaar vraagt om een vertraagde MFA-uitrol voor beheerders te accepteren, helpt Zenith Controls de CISO te laten zien waarom dit niet alleen een toegangscontrolevraagstuk is. Het raakt beleidsgovernance, managementverantwoordelijkheid, wettelijke en regelgevende eisen, GDPR-beveiliging van de verwerking, DORA-ICT-risicobeheer, NIS2-cyberbeveiligingsmaatregelen, incidentimpact en auditbewijs.

Als een productteam wil lanceren in een nieuwe EU-markt met een nieuwe clouddienst, brengt ISO/IEC 27002:2022 beheersmaatregel 5.31 de beoordeling van wettelijke en regelgevende eisen binnen het ISMS-toepassingsgebied. ISO/IEC 27001:2022 Clause 4.2 vereist dat eisen van belanghebbenden worden geïdentificeerd, inclusief wettelijke, regelgevende en contractuele verplichtingen. Clause 8.1 vereist operationele planning en beheersing, inclusief beheersing van extern geleverde processen, producten of diensten die relevant zijn voor het ISMS.

Het doel is één risicotaal, geen afzonderlijke compliancedialecten.

Goedkeuringsworkflow: wie beslist wat

Een CISO kan ICT-risicobereidheid voorstellen, maar het bestuur of bestuursorgaan moet eigenaar zijn. Dat eigenaarschap vereist een workflow.

Dit sluit ook aan op NIST CSF 2.0. De GOVERN-functie, met name GV.RM, verwacht overeengekomen risicobeheerdoelstellingen, verklaringen over risicobereidheid en risicotolerantie, integratie van risicoactiviteiten in enterprise risk management, gedefinieerde opties voor risicoreactie, communicatielijnen en gestandaardiseerde methoden voor het berekenen, documenteren, categoriseren en prioriteren van cyberbeveiligingsrisico’s. GV.RR verwacht verantwoordingsplicht van leiderschap, rollen, bevoegdheden en middelen die zijn afgestemd op de risicostrategie. GV.PO verwacht dat beleid wordt vastgesteld, gecommuniceerd, afgedwongen, beoordeeld en bijgewerkt.

Assuranceprofessionals die werken met COBIT 19 of ISACA zullen vragen of risicobereidheid is geïntegreerd in de enterprise governance van informatie en technologie, en niet slechts als bijlage aan een cyberbeleid is toegevoegd.

Bouw een ICT-risicobereidheidspakket in één werksessie

Een praktische workshop over ICT-risicobereidheid kan een organisatie van verspreide registers naar een auditeerbaar bestuurspakket brengen.

Stap 1: verzamel de juiste input

Bereid het actuele ICT-risicoregister voor, de Business Impact Analysis, hersteldoelstellingen, de lijst met kritieke of belangrijke functies, de ICT-inventaris van bedrijfsmiddelen, de ICT-diensteninventaris, het register van leveranciers- en cloudafhankelijkheden, criteria voor incidentclassificatie, de GDPR-verwerkingsinventaris, DPIA’s waar relevant, het register van wettelijke verplichtingen, beleidsdocumenten, de Verklaring van Toepasselijkheid en de bestaande verklaring over risicobereidheid op ondernemingsniveau.

Dit sluit aan op ISO/IEC 27001:2022 clausules 4, 6 en 8, en op NIST CSF-profielmethoden die beginnen met bedrijfsprioriteiten, risicoprioriteiten, eisen, waarborgen en rollen.

Stap 2: definieer impactschalen waarin regelgeving is opgenomen

Gebruik stap 10 van Zenith Blueprint om waarschijnlijkheid en impact in bedrijfstaal te definiëren. Neem financieel verlies, operationele verstoring, klantimpact, reputatieschade, juridische en regelgevende impact, schade voor betrokkenen en impact op kritieke functies op.

Een “Grote” impact kan bijvoorbeeld bestaan uit langdurige uitval van een kritieke dienst, een bevestigde inbreuk in verband met persoonsgegevens waarvoor melding vereist is, het niet voldoen aan een DORA-verplichting voor incidentmelding of een leveranciersfalen dat een kritieke of belangrijke functie raakt.

Stap 3: formuleer risicobereidheid per domein

Maak geen generieke cyberrisicobereidheid. Definieer domeinen zoals beschikbaarheid van kritieke diensten, vertrouwelijkheid van persoonsgegevens, gegevensintegriteit, geprivilegieerde toegang, ICT-afhankelijkheid van derde partijen, cloudconcentratie, blootstelling aan kwetsbaarheden, gereedheid voor incidentmelding, back-up en herstel, en wijzigingsrisico bij veilige ontwikkeling.

Schrijf voor elk domein één verklaring over risicobereidheid, één of meer tolerantiedrempels en escalatietriggers.

Stap 4: koppel behandeling aan de Verklaring van Toepasselijkheid

Stap 13 van Zenith Blueprint draagt organisaties op om opties voor risicobehandeling te kiezen: mitigeren, vermijden, overdragen of accepteren. De stap benadrukt ook goedkeuring door het management:

“Risicobehandelingsbesluiten en de SoA moeten door het topmanagement worden beoordeeld en goedgekeurd.”

Voor DORA en NIS2 is dit bewijs dat het bestuursorgaan of gedelegeerd leiderschap kernrisico’s, behandelingen en geaccepteerde restblootstelling heeft beoordeeld. Voor GDPR ondersteunt dit de verantwoordingsplicht doordat wordt aangetoond waarom geselecteerde maatregelen passend waren voor het risico.

Stap 5: registreer acceptatie met vervaldatum en voorwaarden

Elk geaccepteerd middelgroot of hoog restrisico moet het volgende bevatten:

• Risico-ID en eigenaar
• Zakelijke onderbouwing
• Verwijzing naar de verklaring over risicobereidheid
• Betrokken tolerantiedrempel
• Juridische en regelgevende analyse
• Compenserende beheersmaatregelen
• Verval- of beoordelingsdatum
• Goedkeurder
• Locatie van bewijs
• Trigger voor heropening van het besluit

Het Beleid inzake risicobeheer voor mkb stelt:

“Elke beslissing om behandeling van een hoog of middelgroot risico te accepteren of uit te stellen, moet worden gedocumenteerd in het risicoregister. Deze documentatie moet het volgende bevatten:”

In enterprise-omgevingen wordt dit een goedkeuringsworkflow en een pakket voor het risicocomité. In kleinere organisaties kan het een gestructureerd tabblad in het risicoregister zijn met goedkeuring door het management. Het punt is niet bureaucratie. Het punt is verdedigbaarheid.

Incidenttolerantie: waar risicobereidheid de klok ontmoet

Risicobereidheid wordt reëel tijdens incidenten.

DORA Article 17 vereist dat financiële entiteiten een ICT-gerelateerd incidentbeheerproces opzetten om incidenten te detecteren, te beheren en te melden, alle incidenten en significante cyberdreigingen te registreren, oorzaken te identificeren, vroegtijdige waarschuwingsindicatoren te gebruiken, incidenten te classificeren naar prioriteit, ernst en servicekritikaliteit, rollen toe te wijzen, met stakeholders te communiceren, ten minste majeure ICT-gerelateerde incidenten te escaleren naar het hoger management en het bestuursorgaan, en beveiligde operaties tijdig te herstellen.

DORA Article 18 classificeert incidenten aan de hand van factoren zoals getroffen cliënten, duur, uitvaltijd, geografische spreiding, gegevensverliezen die beschikbaarheid, authenticiteit, integriteit of vertrouwelijkheid raken, kritikaliteit van getroffen diensten en economische impact. Article 19 vereist dat majeure ICT-gerelateerde incidenten aan de bevoegde autoriteit worden gemeld, waarbij cliënten worden geïnformeerd wanneer hun financiële belangen zijn geraakt.

NIS2 Article 23 kent gefaseerde rapportage voor significante incidenten, inclusief vroegtijdige waarschuwing zonder onnodige vertraging en waar van toepassing binnen 24 uur, incidentmelding zonder onnodige vertraging en waar van toepassing binnen 72 uur, tussentijdse updates wanneer daarom wordt verzocht en een eindrapport uiterlijk één maand na de incidentmelding. Significante incidenten omvatten incidenten die ernstige operationele verstoring, financieel verlies of materiële of immateriële schade aan anderen veroorzaken.

De verklaring over risicobereidheid moet escalatiedrempels definiëren voordat het incident plaatsvindt.

Annex A-beheersmaatregelen rond incidentplanning, beoordeling van informatiebeveiligingsgebeurtenissen, incidentrespons, leren van incidenten, bewijsverzameling, behoud van informatiebeveiliging tijdens verstoring en ICT-gereedheid voor bedrijfscontinuïteit ondersteunen al deze drempels. NIST CSF-uitkomsten in IDENTIFY, PROTECT, DETECT, RESPOND en RECOVER ondersteunen hetzelfde operationele model, inclusief back-ups, monitoring, incidentverklaring, escalatie, oorzaakanalyse, communicatie met stakeholders en verificatie van herstel.

Leveranciers- en cloudtolerantie die bestuursorganen vaak missen

DORA maakt ICT-risico van derde partijen tot een kernverplichting voor compliance. Article 28 vereist dat financiële entiteiten ICT-risico van derde partijen beheren als onderdeel van het ICT-risicobeheerkader, terwijl zij volledig verantwoordelijk blijven voor naleving. Het vereist een strategie voor ICT-risico van derde partijen, registers van contractuele regelingen voor ICT-diensten, onderscheid van diensten die kritieke of belangrijke functies ondersteunen, jaarlijkse rapportage, kennisgeving van geplande regelingen, precontractuele beoordelingen, due diligence, audit- en inspectierechten, beëindigingsrechten en gedocumenteerde exitstrategieën.

Article 29 voegt een analyse van concentratierisico toe, inclusief niet-vervangbaarheid, meervoudige afhankelijkheden van dezelfde of verbonden aanbieders, onderaannemingsrisico’s, onderaannemers in derde landen, naleving van gegevensbescherming, afdwingbaarheid en complexe onderaannemingsketens. Article 30 vereist schriftelijke contractuele rechten en verplichtingen, dienstbeschrijvingen, locaties, beveiligingswaarborgen, toegang tot en teruggave van gegevens, serviceniveaus, hulp bij incidenten, samenwerking met autoriteiten, beëindigingsrechten, geteste noodplannen, monitoring en exitafspraken.

Een door het bestuursorgaan goedgekeurde verklaring over leverancierstolerantie kan luiden:

“Wij hebben een lage risicobereidheid voor afhankelijkheid van kritieke of belangrijke functies van een ICT-dienstverlener van een derde partij wanneer contractuele auditrechten, geteste exitafspraken, incidentmeldingsplichten, serviceniveaudoelen, rechten op teruggave van gegevens of zichtbaarheid van wezenlijke onderaanneming ontbreken.”

Die zin geeft inkoop een praktische regel. Als het contract niet aan de drempel voldoet, kan het risico niet stilzwijgend door het projectteam worden geaccepteerd.

Hoe auditors uw ICT-risicobereidheid zullen toetsen

Een sterke verklaring over risicobereidheid is ontworpen met audit in gedachten.

Stap 28 van Zenith Blueprint, in de fase Audit, beoordeling en verbetering, versterkt de laag van directiebeoordeling. De stap draagt organisaties op input te verzamelen zoals veranderingen in externe en interne issues, ISMS-prestaties, auditresultaten, monitoring en meting, incidenten, non-conformiteiten, verbetermogelijkheden en middelenbehoeften. De stap stelt ook dat directiebeoordeling moet leiden tot besluiten en acties, niet alleen tot presentaties.

Ten minste jaarlijks, en telkens wanneer wezenlijke wijzigingen optreden, moet het management beoordelen of tolerantiedrempels nog steeds aansluiten op het bedrijfsmodel, incidenten de risicobereidheid hebben overschreden, geaccepteerde risico’s binnen goedgekeurde grenzen blijven, nieuwe DORA-, NIS2-, GDPR- of contractuele eisen de baseline hebben gewijzigd, leveranciers binnen concentratietoleranties blijven en KRI’s tijdige escalatie veroorzaken.

Als het antwoord nee is, moet de verklaring over risicobereidheid worden aangepast, of moeten de beheersmaatregelen worden aangepast.

Veelvoorkomende faalpatronen in gereedheidswerk voor 2026

In DORA-, NIS2-, GDPR- en ISO/IEC 27001:2022-projecten komen steeds dezelfde zwaktes terug:

• Risicobereidheid zonder drempels, waarbij het bestuursorgaan een verklaring goedkeurt maar niemand kan aangeven wanneer die is overschreden.
• Drempels zonder bevoegdheid, waarbij ernstniveaus bestaan maar risico-eigenaren uitzonderingen kunnen accepteren zonder goedkeuring van hoger management.
• Juridisch risico buiten het scoremodel, waarbij GDPR, DORA, NIS2 en contracten afzonderlijk worden vermeld maar niet zijn ingebed in impactcriteria.
• Leverancierstolerantie ontbreekt in het bestuurspakket, ook al zijn kritieke ICT-afhankelijkheden bekend bij inkoop of IT.
• Directiebeoordeling als theater, waarbij slides worden gepresenteerd maar besluiten, acties, middelenbehoeften en risicoacceptaties niet worden gedocumenteerd.
• Fragmentatie van auditbewijs, waarbij beleid, registers, KRI’s, incidentrapportages, leveranciersbeoordelingen en notulen van het bestuursorgaan op verschillende plaatsen bestaan zonder kruisverwijzing.

Clarysec’s aanpak is ontworpen om deze hiaten weg te nemen. De Zenith Blueprint biedt het gefaseerde implementatiepad. Het Beleid inzake risicobeheer en het Beleid inzake risicobeheer voor mkb bieden governanceclausules die zijn geschaald voor enterprise- en mkb-omgevingen. Zenith Controls mapt de kern van beheersmaatregelen over informatiebeveiligingsbeleid, managementverantwoordelijkheid en wettelijke of regelgevende eisen, waardoor bewijs herbruikbaar wordt voor ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF en assurance volgens COBIT.

Zet bestuursintentie om in auditeerbare ICT-risicogovernance

Als uw organisatie een risicoregister heeft maar geen door het bestuursorgaan goedgekeurde ICT-risicobereidheid, meetbare tolerantiedrempels, escalatietriggers en formele acceptatieregels kan aantonen, is de kloof niet cosmetisch. Zij raakt DORA-governance, NIS2-verantwoordingsplicht van het management, verdedigbaarheid van GDPR Article 32 en de capaciteit om naleving van ISO/IEC 27001:2022 tijdens audits aan te tonen.

Een praktische volgende stap is het uitvoeren van een gerichte workshop over ICT-risicobereidheid met Clarysec’s toolkit:

1. Gebruik Zenith Blueprint stap 10 om risicocriteria en impactschalen te definiëren.
2. Gebruik Zenith Blueprint stap 13 om behandelopties, restrisico en goedkeuring van de Verklaring van Toepasselijkheid te koppelen.
3. Gebruik Zenith Blueprint stap 14 om GDPR-, NIS2- en DORA-verplichtingen te kruisverwijzen.
4. Gebruik Zenith Blueprint stap 28 om risicobereidheid, KRI’s, geaccepteerde risico’s en besluiten over middelen in de directiebeoordeling op te nemen.
5. Pas Beleid inzake risicobeheer of Beleid inzake risicobeheer voor mkb toe om goedkeurings- en acceptatieregels te formaliseren.
6. Gebruik Zenith Controls om governancebeheersmaatregelen te mappen naar auditbewijs en verwachtingen voor compliance over meerdere kaders.

Clarysec kan u helpen verspreide risicoartefacten om te zetten in een door het bestuursorgaan goedgekeurd, toezichthouderklaar model voor ICT-risicobereidheid dat uw teams kunnen gebruiken wanneer de volgende cloudstoring, leveranciersuitval, openbaarmaking van een kwetsbaarheid of incident met persoonsgegevens de werkelijke tolerantie van de organisatie test.