GDPR Article 32 TOMs-bewijs met ISO, NIS2 en DORA
De e-mail belandt in de inbox van de CISO met het herkenbare gewicht van een deal die het kwartaalresultaat van de organisatie kan veranderen.
Een grote zakelijke prospect wil bewijs zien van “technische en organisatorische maatregelen onder GDPR Article 32, gemapt naar ISO 27001:2022, NIS2 en DORA waar van toepassing.” Tegelijkertijd heeft Legal de raad van bestuur geïnformeerd over bestuurdersaansprakelijkheid onder NIS2 en de verwachtingen van DORA rond operationele weerbaarheid. De opdracht van de raad klinkt eenvoudig: toon naleving aan, voorkom dubbel werk en maak hier geen drie afzonderlijke projecten van.
De organisatie heeft beheersmaatregelen. MFA is ingeschakeld. Back-ups draaien. Ontwikkelaars voeren code reviews uit. Het privacyteam onderhoudt registraties van verwerkingsactiviteiten. Het infrastructuurteam scant op kwetsbaarheden. Leveranciers worden tijdens inkoop beoordeeld. Maar zodra de prospect om bewijs vraagt, valt het antwoord uiteen.
Het rapport van de identiteitsprovider staat op één plek. Back-uplogboeken staan ergens anders. Het risicoregister is sinds de laatste productrelease niet bijgewerkt. Bewijs over leveranciersbeveiliging zit in inkoopmails. Notities van tabletop-oefeningen voor incidentrespons bestaan, maar niemand kan aantonen dat geleerde lessen zijn teruggevoerd in de risicobehandeling. De raad heeft beveiligingsuitgaven goedgekeurd, maar die goedkeuring is niet gekoppeld aan een ICT-risico of aan een gedocumenteerd besluit over een beheersmaatregel.
Dat is het echte probleem met technische en organisatorische maatregelen onder GDPR Article 32, meestal TOMs genoemd. De meeste organisaties falen niet omdat zij geen beheersmaatregelen hebben. Zij falen omdat zij niet kunnen aantonen dat beheersmaatregelen risicogebaseerd, goedgekeurd, geïmplementeerd, bewaakt en verbeterd zijn.
De verantwoordingsplicht onder GDPR maakt die verwachting expliciet. GDPR Article 5 vereist dat persoonsgegevens worden beschermd met passende beveiliging tegen ongeoorloofde of onrechtmatige verwerking en tegen onopzettelijk verlies, vernietiging of beschadiging. Article 5(2) maakt de verwerkingsverantwoordelijke verantwoordelijk voor het aantonen van naleving. Ook de definities in GDPR zijn van belang. Persoonsgegevens zijn breed gedefinieerd, verwerking omvat vrijwel elke bewerking met gegevens, pseudonimisering is een erkende waarborg en een inbreuk in verband met persoonsgegevens omvat onopzettelijke of onrechtmatige vernietiging, verlies, wijziging, ongeoorloofde verstrekking of ongeoorloofde toegang.
Een bewijsdossier voor Article 32 kan daarom geen map met willekeurige screenshots zijn. Het moet een levend systeem van beheersmaatregelen zijn.
De aanpak van Clarysec is om GDPR Article 32 TOMs om te zetten in een traceerbare bewijsmotor die is gebouwd op ISO/IEC 27001:2022 ISO/IEC 27001:2022, versterkt met ISO/IEC 27005:2022-risicobeheer en waar van toepassing gekruist met NIS2- en DORA-verplichtingen. Het doel is niet papierwerk om het papierwerk. Het doel is dat de organisatie auditgereed is voordat een klant, auditor, toezichthouder of bestuurslid de moeilijke vraag stelt.
Waarom GDPR Article 32 TOMs in de praktijk falen
Article 32 wordt vaak ten onrechte opgevat als een lijst met beveiligingstools: encryptie, back-ups, logging, toegangscontrole en incidentrespons. Die maatregelen zijn belangrijk, maar zij zijn alleen verdedigbaar wanneer zij passend zijn voor het risico en gekoppeld zijn aan de levenscyclus van persoonsgegevens.
Voor een SaaS-organisatie die medewerkersgegevens van klanten verwerkt, is “wij gebruiken encryptie” niet genoeg. Een auditor kan vragen welke gegevens door encryptie worden beschermd, waar encryptie verplicht is, hoe sleutels worden beheerd, of back-ups zijn versleuteld, of productiegegevens in testomgevingen worden gemaskeerd, wie beheersmaatregelen kan omzeilen en hoe uitzonderingen worden goedgekeurd.
Het enterprise Beleid inzake gegevensbescherming en privacy van Clarysec legt het operationele uitgangspunt vast:
“Implementeer technische en organisatorische maatregelen (TOMs) die de vertrouwelijkheid, integriteit en beschikbaarheid van persoonsgegevens (PII) gedurende de volledige levenscyclus beschermen.”
Bron: Beleid inzake gegevensbescherming en privacy, Doelstellingen, beleidsclausule 3.3. Beleid inzake gegevensbescherming en privacy
De formulering “gedurende de volledige levenscyclus” is waar veel TOM-programma’s zwak worden. Persoonsgegevens kunnen in productie zijn beschermd, maar vervolgens worden gekopieerd naar analysesystemen, logboeken, supportexports, testomgevingen, back-ups, leveranciersplatforms en apparaten van medewerkers. Elke locatie creëert beveiligings- en privacyrisico’s.
GDPR Article 6 vereist een rechtsgrondslag voor verwerking, waaronder toestemming, overeenkomst, wettelijke verplichting, vitale belangen, taak van algemeen belang of gerechtvaardigde belangen. Wanneer gegevens voor een ander doel worden hergebruikt, moeten verenigbaarheid en waarborgen zoals encryptie of pseudonimisering worden beoordeeld. Voor gegevens met een hoger risico neemt de bewijslast toe. GDPR Article 9 stelt strikte grenzen aan bijzondere categorieën persoonsgegevens, zoals gezondheidsgegevens, biometrische gegevens die voor identificatie worden gebruikt en andere gevoelige informatie. Article 10 beperkt de verwerking van gegevens over strafrechtelijke veroordelingen en strafbare feiten.
Voor mkb-organisaties formuleert Clarysec risicobehandeling in praktische taal:
“Beheersmaatregelen moeten worden geïmplementeerd om geïdentificeerde risico’s te verminderen, waaronder encryptie, anonimisering, veilige afvoer en toegangsbeperkingen”
Bron: Beleid inzake gegevensbescherming en privacy-sme, Risicobehandeling en uitzonderingen, beleidsclausule 7.2.1. Beleid inzake gegevensbescherming en privacy - SME
Dat is een sterke TOMs-baseline. Om auditgereed te zijn, moet elke beheersmaatregel ook worden gekoppeld aan een risico, eigenaar, beleidsvereiste, bewijsitem en beoordelingsritme.
ISO 27001:2022 is de ruggengraat voor Article 32-bewijs
ISO 27001:2022 werkt goed voor GDPR Article 32, omdat de norm beveiliging behandelt als een managementsysteem en niet als een losse checklist met beheersmaatregelen. De norm vereist een informatiebeveiligingsmanagementsysteem, of ISMS, dat is ontworpen om vertrouwelijkheid, integriteit en beschikbaarheid via risicobeheer te behouden.
De eerste kritieke stap is de scope. ISO 27001:2022-clausules 4.1 tot en met 4.4 vereisen dat de organisatie interne en externe kwesties begrijpt, belanghebbenden en vereisten identificeert, bepaalt welke vereisten door het ISMS worden behandeld en de ISMS-scope vastlegt, inclusief interfaces en afhankelijkheden met externe organisaties. Voor Article 32 TOMs moet de ISMS-scope de verwerking van persoonsgegevens, klantverplichtingen, verwerkers, subverwerkers, cloudplatforms, werken op afstand, supportfuncties en productomgevingen weerspiegelen.
De tweede stap is leiderschap. Clausules 5.1 tot en met 5.3 vereisen betrokkenheid van topmanagement, een informatiebeveiligingsbeleid, middelen, rollen en verantwoordelijkheden en prestatierapportage. Dit is van belang omdat GDPR Article 32, NIS2 en DORA allemaal steunen op governance. Een beheersmaatregel zonder eigenaarschap, financiering of beoordeling is zwak bewijs.
Het enterprise Informatiebeveiligingsbeleid van Clarysec maakt dit expliciet:
“Het ISMS moet gedefinieerde scopegrenzen, een risicobeoordelingsmethodologie, meetbare doelstellingen en gedocumenteerde beheersmaatregelen bevatten die in de Verklaring van Toepasselijkheid (SoA) zijn onderbouwd.”
Bron: Informatiebeveiligingsbeleid, Vereisten voor beleidsimplementatie, beleidsclausule 6.1.2. Informatiebeveiligingsbeleid
Hetzelfde beleid legt de verwachting voor bewijs vast:
“Alle geïmplementeerde beheersmaatregelen moeten geschikt zijn voor audits, worden ondersteund door gedocumenteerde procedures en beschikken over bewaard bewijsmateriaal van werking.”
Bron: Informatiebeveiligingsbeleid, Vereisten voor beleidsimplementatie, beleidsclausule 6.6.1.
ISO 27001:2022-clausules 6.1.1 tot en met 6.1.3 vereisen vervolgens risicobeoordeling, risicobehandeling, een Verklaring van Toepasselijkheid, goedkeuring van restrisico en verantwoordingsplicht van de risico-eigenaar. Clausule 6.2 vereist meetbare doelstellingen. Clausules 7.5, 9.1, 9.2, 9.3 en 10.2 vereisen gedocumenteerde informatie, monitoring, interne audit, directiebeoordeling en corrigerende maatregelen.
Voor GDPR Article 32 levert dit een verdedigbare structuur op.
| Bewijsvraag voor GDPR Article 32 | Bewijsantwoord vanuit ISO 27001:2022 |
|---|---|
| Hoe heeft u bepaald welke TOMs passend zijn? | Risicobeoordelingscriteria, risicoregister, scoring van waarschijnlijkheid en impact, risicobehandelingsplan |
| Welke beheersmaatregelen zijn van toepassing en waarom? | Verklaring van Toepasselijkheid met onderbouwingen voor opname en uitsluiting |
| Wie heeft het restrisico goedgekeurd? | Goedkeuring door de risico-eigenaar en formele managementgoedkeuring |
| Werken de beheersmaatregelen? | Logboeken, tickets, beoordelingsregistraties, testresultaten, monitoringrapportages |
| Worden beheersmaatregelen beoordeeld? | Interne-auditrapporten, notulen van directiebeoordelingen, register voor corrigerende maatregelen |
| Worden risico’s voor persoonsgegevens meegenomen? | Risico-items voor gegevensbescherming, privacyvereisten binnen de scope, DPIA of gelijkwaardige beoordeling waar van toepassing |
ISO/IEC 27005:2022 versterkt deze structuur. De norm adviseert organisaties om vereisten te identificeren uit ISO 27001:2022 Annex A, wet- en regelgeving, contracten, sectorstandaarden, interne regels en bestaande beheersmaatregelen, en deze vervolgens op te nemen in risicobeoordeling en risicobehandeling. Ook vereist de norm risicocriteria en acceptatiecriteria die juridische, regelgevende, operationele, leveranciers-, technologie- en menselijke factoren meenemen, inclusief privacy.
Het Beleid inzake risicobeheer van Clarysec sluit hier direct op aan:
“Er moet een formeel risicobeheerproces worden onderhouden in overeenstemming met ISO/IEC 27005 en ISO 31000, dat risico-identificatie, analyse, evaluatie, behandeling, monitoring en communicatie omvat.”
Bron: Beleid inzake risicobeheer, Governancevereisten, beleidsclausule 5.1. Beleid inzake risicobeheer
Voor mkb-organisaties wordt dezelfde eis eenvoudig en uitvoerbaar:
“Elke risico-entry moet het volgende bevatten: beschrijving, waarschijnlijkheid, impact, score, eigenaar en behandelplan.”
Bron: Beleid inzake risicobeheer-sme, Governancevereisten, beleidsclausule 5.1.2. Beleid inzake risicobeheer - SME
Die zin is een snelle toets op auditgereedheid. Als een risico geen eigenaar of behandelplan heeft, is het nog geen risico dat als bewijs kan dienen.
De Clarysec-brug: risico, SoA, beheersmaatregelen en regelgeving
Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint behandelt naleving als traceerbaarheidswerk. In de fase Risicobeheer richt stap 13 zich op risicobehandelingsplanning en de Verklaring van Toepasselijkheid. De stap legt uit dat organisaties beheersmaatregelen aan risico’s moeten koppelen, Annex A-verwijzingen naar beheersmaatregelen moeten toevoegen aan risicobehandelingsitems, externe regelgeving kruislings moeten verwijzen en managementgoedkeuring moeten verkrijgen.
De Zenith Blueprint is duidelijk over de rol van de SoA:
“De SoA is feitelijk een brugdocument: het verbindt uw risicobeoordeling/-behandeling met de feitelijke beheersmaatregelen waarover u beschikt. Door het document in te vullen, controleert u ook of u geen beheersmaatregelen hebt gemist.”
Bron: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase Risicobeheer, stap 13: risicobehandelingsplanning en Verklaring van Toepasselijkheid (SoA). Zenith Blueprint
Stap 14 van de Zenith Blueprint voegt de laag met verwijzingen naar regelgeving toe. De stap adviseert organisaties te documenteren hoe vereisten uit GDPR, NIS2 en DORA worden afgedekt door beleid en beheersmaatregelen. Voor GDPR benadrukt deze stap de bescherming van persoonsgegevens in risicobeoordelingen en behandelingen, inclusief encryptie als technische maatregel en respons op inbreuken als onderdeel van de beheersingsomgeving. Voor NIS2 ligt de nadruk op risicobeoordeling, netwerkbeveiliging, toegangscontrole, incidentafhandeling en bedrijfscontinuïteit. Voor DORA wijst de stap op ICT-risicobeheer, incidentrespons, rapportage en toezicht op ICT-derden.
Dat is de kern van de Clarysec-methode: één ISMS, één risicoregister, één SoA, één bewijsbibliotheek en meerdere nalevingsuitkomsten.
Zenith Controls: The Cross-Compliance Guide Zenith Controls ondersteunt dit door organisaties te helpen ISO/IEC 27002:2022 ISO/IEC 27002:2022-beheersmaatregelonderwerpen te gebruiken als ankers voor naleving over meerdere kaders heen. Voor GDPR Article 32 zijn de belangrijkste ankers vaak Privacy and Protection of PII, beheersmaatregel 5.34; Independent Review of Information Security, beheersmaatregel 5.35; en Use of Cryptography, beheersmaatregel 8.24.
| ISO/IEC 27002:2022-beheersmaatregelanker in Zenith Controls | Waarom dit van belang is voor Article 32 TOMs | Voorbeelden van bewijs |
|---|---|---|
| 5.34 Privacy and Protection of PII | Koppelt informatiebeveiligingsmaatregelen aan de verwerking van persoonsgegevens en privacyverplichtingen | Gegevensinventaris, privacyrisicobeoordeling, bewaarschema, DPA-registraties, toegangsrechtenbeoordelingen |
| 5.35 Independent Review of Information Security | Toont objectieve assurance, auditgeschiktheid en verbetering aan | Interne-auditrapport, externe beoordeling, register voor corrigerende maatregelen, directiebeoordeling |
| 8.24 Use of Cryptography | Beschermt de vertrouwelijkheid en integriteit van gegevens tijdens transport, in rust en in back-ups | Encryptiestandaard, sleutelbeheerregistraties, bewijs van schijfversleuteling, TLS-configuratie, back-upencryptie |
NIS2 maakt van TOMs een cyberbeveiligingskwestie op bestuursniveau
Veel organisaties behandelen GDPR TOMs als een verantwoordelijkheid van het privacyteam. NIS2 verandert dat gesprek.
NIS2 is van toepassing op veel middelgrote en grote entiteiten in aangewezen sectoren, en in sommige gevallen ongeacht omvang. Gedekte digitale en technologiesectoren omvatten cloudcomputingaanbieders, datacenterdienstverleners, content delivery networks, DNS-dienstverleners, TLD-registers, vertrouwensdienstverleners, aanbieders van openbare elektronischecommunicatiediensten, managed service providers, managed security service providers, online marktplaatsen, zoekmachines en sociale-netwerkplatforms. De toepasselijkheid voor SaaS- en technologiemkb hangt af van sector, omvang, aanwijzing door de lidstaat en systemische of grensoverschrijdende impact.
NIS2 Article 20 legt verantwoordelijkheid voor cyberbeveiliging bij de bestuursorganen. Zij moeten cyberbeveiligingsrisicobeheersmaatregelen goedkeuren, toezicht houden op de implementatie en training volgen. Essentiële entiteiten kunnen administratieve boetes krijgen van ten minste EUR 10 miljoen of ten minste 2 procent van de wereldwijde jaaromzet. Belangrijke entiteiten kunnen boetes krijgen van ten minste EUR 7 miljoen of ten minste 1,4 procent.
NIS2 Article 21 is rechtstreeks relevant voor Article 32 TOMs, omdat het passende en evenredige technische, operationele en organisatorische maatregelen vereist. Deze maatregelen moeten rekening houden met de stand van de techniek, Europese en internationale normen, kosten, blootstelling, omvang, waarschijnlijkheid, ernst en maatschappelijke of economische impact. Vereiste gebieden omvatten risicoanalyse, beveiligingsbeleid, incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige verwerving en ontwikkeling, afhandeling van kwetsbaarheden, beoordeling van doeltreffendheid, cyberhygiëne, training, cryptografie, HR-beveiliging, toegangscontrole, beheer van bedrijfsmiddelen, MFA of continue authenticatie en beveiligde communicatie waar passend.
NIS2 Article 23 voegt gefaseerde incidentmelding toe: een vroegtijdige waarschuwing binnen 24 uur, een incidentmelding binnen 72 uur, tussentijdse updates indien gevraagd en een eindrapport uiterlijk één maand na de melding van 72 uur. Als een inbreuk in verband met persoonsgegevens ook kwalificeert als een significant NIS2-incident, moet uw bewijsdossier zowel privacy- als cyberbeveiligingsbesluiten over rapportage ondersteunen.
DORA legt de lat hoger voor financiële weerbaarheid en ICT-aanbieders
DORA is van toepassing vanaf 17 januari 2025 en creëert een regelgevingskader voor digitale operationele weerbaarheid in de financiële sector. Het omvat ICT-risicobeheer, melding van majeure ICT-gerelateerde incidenten, testen van operationele weerbaarheid, delen van informatie over cyberdreigingen en kwetsbaarheden, ICT-risico’s van derde partijen, contractuele eisen voor ICT-aanbieders, toezicht op kritieke ICT-dienstverleners van derde partijen en toezicht.
Voor financiële entiteiten die ook onder nationale NIS2-regels zijn aangewezen, functioneert DORA als de sectorspecifieke Unierechtelijke handeling voor overlappende verplichtingen rond cyberbeveiligingsrisicobeheer en incidentmelding. In de praktijk moeten gedekte financiële entiteiten DORA prioriteit geven voor die overlappende gebieden, terwijl zij waar relevant afstemming behouden met bevoegde NIS2-autoriteiten en CSIRT’s.
Voor GDPR Article 32-bewijs is DORA op twee manieren relevant. Ten eerste kunnen fintechorganisaties rechtstreeks binnen de scope vallen als financiële entiteiten, waaronder kredietinstellingen, betalingsinstellingen, rekeninginformatiedienstverleners, instellingen voor elektronisch geld, beleggingsondernemingen, aanbieders van cryptoactivadiensten, handelsplatformen en crowdfundingdienstverleners. Ten tweede kunnen SaaS-, cloud-, data-, software- en managed service providers door financiële klanten worden behandeld als ICT-dienstverleners van derde partijen, omdat DORA ICT-diensten breed definieert.
DORA Article 5 vereist governance en interne beheersmaatregelen voor ICT-risicobeheer, waarbij het bestuursorgaan ICT-risicoregelingen definieert, goedkeurt, er toezicht op houdt en ervoor verantwoordelijk blijft. Article 6 vereist een gedocumenteerd ICT-risicobeheerkader, inclusief strategieën, beleid, procedures, ICT-protocollen en tools om informatie en ICT-activa te beschermen. Article 17 vereist een ICT-gerelateerd incidentbeheerproces dat detectie, beheer, kennisgeving, registratie, oorzaakanalyse, vroegtijdige waarschuwingsindicatoren, classificatie, rollen, communicatie, escalatie en respons omvat. Article 19 vereist dat majeure ICT-gerelateerde incidenten aan bevoegde autoriteiten worden gemeld.
DORA Articles 28 en 30 maken ICT-risico van derde partijen tot een gereguleerd domein van beheersmaatregelen. Financiële entiteiten blijven verantwoordelijk voor naleving wanneer zij ICT-diensten gebruiken. Zij hebben een strategie voor risico’s van derde partijen, contractregisters, criticaliteitsbeoordelingen, due diligence, beoordeling van concentratierisico, audit- en inspectierechten, beëindigingstriggers, exitstrategieën en contractuele bepalingen nodig die gegevenslocaties, beschikbaarheid, authenticiteit, integriteit, vertrouwelijkheid, ondersteuning bij incidenten, herstel, serviceniveaus en samenwerking met autoriteiten omvatten.
Voor Article 32 betekent dit dat leveranciers deel uitmaken van het TOMs-dossier. U kunt de beveiliging van verwerking niet aantonen als kritieke verwerkers, cloudplatforms, analyticsaanbieders, supporttools en ICT-aanbieders niet worden beheerst.
Een praktische Article 32-bewijsopbouw in één week
Een sterk bewijsdossier begint met één helder risicoscenario.
Gebruik dit voorbeeld: “Ongeautoriseerde toegang tot persoonsgegevens van klanten in de productieapplicatie.”
Maak de risico-entry aan of werk deze bij. Neem beschrijving, waarschijnlijkheid, impact, score, eigenaar en behandelplan op. Wijs de eigenaar toe aan het hoofd Engineering, de securitymanager of een gelijkwaardige verantwoordelijke rol. Beoordeel waarschijnlijkheid op basis van het toegangsmodel, het blootgestelde aanvalsoppervlak, bekende kwetsbaarheden en eerdere incidenten. Beoordeel impact op basis van het volume persoonsgegevens, gevoeligheid, klantcontracten, GDPR-gevolgen en mogelijke NIS2- of DORA-impact op de dienstverlening.
Selecteer behandelingen zoals MFA voor geprivilegieerde toegang, rolgebaseerde toegangscontrole, kwartaalgewijze toegangsrechtenbeoordelingen, encryptie van gegevens in rust, TLS, kwetsbaarheidsscans, logging, alarmering, veilige back-up, incidentresponsprocedures en datamasking in niet-productieomgevingen.
Map het risico vervolgens naar de SoA. Voeg ISO/IEC 27002:2022-verwijzingen toe, zoals 5.34 Privacy and Protection of PII, 8.24 Use of Cryptography, 5.15 Access Control, 5.18 Access Rights, 8.13 Information Backup, 8.15 Logging, 8.16 Monitoring Activities, 8.8 Management of Technical Vulnerabilities, 8.25 Secure Development Life Cycle en 8.10 Information Deletion waar van toepassing. Voeg opmerkingen toe die laten zien hoe deze beheersmaatregelen GDPR Article 32, NIS2 Article 21 en DORA ICT-risicobeheer ondersteunen waar relevant.
Houd bij mapping naar regelgeving de namen van beheersmaatregelen nauwkeurig en forceer geen schijnbare gelijkwaardigheid.
| ISO/IEC 27002:2022-beheersmaatregel | Naam van beheersmaatregel | Waarom opgenomen | Mapping naar regelgeving |
|---|---|---|---|
| 8.24 | Use of Cryptography | Beschermt de vertrouwelijkheid en integriteit van persoonsgegevens tijdens transport, in rust en in back-ups | GDPR Art. 32; NIS2 Art. 21(2)(h) |
| 5.20 | Addressing information security within supplier agreements | Zorgt ervoor dat beveiligingsverplichtingen van leveranciers contractueel zijn vastgelegd en afdwingbaar zijn | GDPR-beheersmaatregelen voor verwerkers; NIS2 Art. 21(2)(d); DORA Art. 28 en Art. 30 |
| 5.24 | Information security incident management planning and preparation | Richt gereedheid in voor detectie, escalatie, beoordeling en rapportage | Verantwoordingsplicht bij GDPR-inbreuken; NIS2 Art. 23; DORA Art. 17 en Art. 19 |
| 8.13 | Information Backup | Ondersteunt beschikbaarheid, herstel en weerbaarheid na verstoring of gegevensverlies | GDPR Art. 32; NIS2 Art. 21(2)(c); DORA-verwachtingen voor ICT-continuïteit |
| 8.10 | Information Deletion | Ondersteunt veilige verwijdering, afdwinging van bewaartermijnen en gegevensminimalisatie | GDPR-opslagbeperking en Art. 32; contractuele klantvereisten |
Bouw nu de bewijsmap op. Het SME Beleid voor audit en toezicht op naleving van Clarysec geeft een eenvoudige regel:
“Al het bewijsmateriaal moet worden opgeslagen in een gecentraliseerde auditmap.”
Bron: Beleid voor audit en toezicht op naleving-sme, Vereisten voor beleidsimplementatie, beleidsclausule 6.2.1. Beleid voor audit en toezicht op naleving - SME
Voor dit ene risicoscenario moet de map het volgende bevatten:
| Bewijsitem | Wat bewaren | Waarom dit van belang is |
|---|---|---|
| Risico-entry | Risicobeschrijving, eigenaar, score, behandelplan en besluit over restrisico | Toont risicogebaseerde selectie van TOMs aan |
| SoA-uittreksel | Van toepassing zijnde beheersmaatregelen en opmerkingen voor GDPR, NIS2 en DORA | Laat traceerbaarheid zien van risico naar beheersmaatregel |
| Toegangsbeoordeling | Beoordeelde gebruikers, besluiten, verwijderingen en uitzonderingen | Toont de werking van toegangscontrole aan |
| MFA-rapportage | Export waaruit afdwinging van MFA voor geprivilegieerde toegang blijkt | Ondersteunt authenticatiebewijs |
| Encryptiebewijs | Configuratieregistratie, architectuurnotitie of sleutelbeheerregistratie | Ondersteunt vertrouwelijkheid en integriteit |
| Kwetsbaarheidsregistratie | Laatste scan, herstelmaatregeltickets en geaccepteerde uitzonderingen | Ondersteunt technische risicoreductie |
| Bewijs van logging | SIEM-gebeurtenisvoorbeeld, waarschuwingsregel en retentie-instelling | Ondersteunt detectie en onderzoek |
| Back-uptest | Resultaat van hersteltest en registratie van back-updekking | Ondersteunt beschikbaarheid en weerbaarheid |
| Incidentoefening | Tabletop-notities, testincidentlogboek of registratie van geleerde lessen | Ondersteunt responsgereedheid |
| Managementgoedkeuring | Notulen, formele goedkeuring of registratie van risicoacceptatie | Ondersteunt verantwoordingsplicht en proportionaliteit |
Bewijs voor toegang mag niet stoppen bij screenshots. Het Access Control Policy-sme voegt een nuttige operationele vereiste toe:
“De IT-manager moet beoordelingsresultaten en corrigerende maatregelen documenteren.”
Bron: Access Control Policy-sme, Governancevereisten, beleidsclausule 5.5.3. Access Control Policy - SME
Bewijs voor back-ups moet herstelbaarheid aantonen, niet alleen succesvolle jobs. Het Backup and Restore Policy-sme bepaalt:
“Hersteltests worden ten minste elk kwartaal uitgevoerd en de resultaten worden gedocumenteerd om herstelbaarheid te verifiëren”
Bron: Backup and Restore Policy-sme, Governancevereisten, beleidsclausule 5.3.3. Backup and Restore Policy - SME
Dit levert een volledige bewijslus op: regelgeving creëert de vereiste, risico verklaart waarom die van belang is, de SoA selecteert de beheersmaatregel, het beleid definieert de werking en bewaard bewijs toont aan dat de beheersmaatregel werkt.
Beheersmaatregelen in de praktijk: van beleid naar operationeel bewijs
De fase Controls in Action van de Zenith Blueprint, stap 19, richt zich op technische verificatie. Deze stap beveelt aan om naleving van endpointbeveiliging, identiteits- en toegangsbeheer, authenticatieconfiguraties, beveiliging van broncodebeheer, capaciteit en beschikbaarheid, kwetsbaarheden- en patchbeheer, veilige baselines, malwarebescherming, verwijdering en gegevensminimalisatie, masking en testgegevens, DLP, back-up en herstel, redundantie, logging en monitoring en tijdsynchronisatie te beoordelen.
Voor GDPR Article 32 TOMs is stap 19 het punt waarop abstracte beheersmaatregelentaal bewijs wordt. Een sterk bewijsdossier moet aantonen dat:
- Endpointencryptie is ingeschakeld en wordt gemonitord.
- Geprivilegieerde gebruikers MFA hebben.
- Instroom-, doorstroom- en uitstroomprocessen worden afgestemd op HR-registraties.
- Serviceaccounts zijn gedocumenteerd en beperkt.
- Toegang tot coderepositories wordt beheerst en secretscanning wordt uitgevoerd.
- Kwetsbaarheidsscans worden uitgevoerd en tot herstelmaatregelen worden opgevolgd.
- Productiegegevens niet achteloos naar testomgevingen worden gekopieerd.
- Beleid voor veilige verwijdering en bewaring wordt afgedwongen.
- DLP-waarschuwingen worden beoordeeld.
- Back-uphersteltests herstelbaarheid aantonen.
- Logboeken centraal worden verzameld, bewaard en beoordeelbaar zijn.
- Tijdsynchronisatie betrouwbaar incidentonderzoek ondersteunt.
De sleutel is samenhang. Een patchrapport zonder verwijzing naar risico, beleid en SoA is een IT-artefact. Een patchrapport dat is gekoppeld aan GDPR Article 32, NIS2 Article 21, DORA ICT-risicobeheer en een ISO 27001:2022-risicobehandelingsplan is auditgereed bewijs.
Eén bewijsdossier, meerdere auditperspectieven
Hetzelfde TOMs-bewijs wordt door verschillende stakeholders anders gelezen. Een privacybeoordelaar kan zich richten op persoonsgegevens, noodzakelijkheid, proportionaliteit en verantwoordingsplicht. Een ISO 27001-auditor kan zich richten op scope, risicobehandeling, SoA en bewijs van werking. Een NIS2-autoriteit kan zich richten op toezicht door management, maatregelen onder Article 21 en gereedheid voor rapportage onder Article 23. Een DORA-toezichthouder of financiële klant kan zich richten op ICT-risicogovernance, weerbaarheidstesten en afhankelijkheden van derde partijen.
Clarysec gebruikt Zenith Controls als cross-compliancegids voor deze vertaling.
| Doelgroep | Wat zij zullen vragen | Hoe het bewijs moet antwoorden |
|---|---|---|
| GDPR-privacybeoordelaar | Zijn TOMs passend voor het risico voor persoonsgegevens en kan verantwoordingsplicht worden aangetoond? | Risicoregister, gegevensinventaris, privacybeheersmaatregelen, bewaartermijnregistraties, toegangsbeperkingen, encryptiebewijs en registraties van inbreukbeoordelingen |
| ISO 27001:2022-auditor | Is het ISMS afgebakend, risicogebaseerd, geïmplementeerd, bewaakt en verbeterd? | Scope, risicomethodologie, SoA, interne audit, directiebeoordeling en corrigerende maatregelen |
| NIS2-beoordelaar | Zijn cyberbeveiligingsmaatregelen goedgekeurd, evenredig en dekken zij de gebieden van Article 21 af? | Goedkeuring door de raad, beveiligingsbeleid, incidentafhandeling, continuïteit, leveranciersrisico, training, MFA en kwetsbaarhedenbeheer |
| DORA-toezichthouder of financiële klant | Wordt ICT-risico bestuurd, getest en weerbaar beheerst, inclusief ICT-risico van derde partijen? | ICT-risicokader, weerbaarheidsstrategie, incidentproces, testbewijs, leveranciersregister en exitplannen |
| NIST-georiënteerde assessor | Kan de organisatie identificeren, beschermen, detecteren, reageren en herstellen met herhaalbaar bewijs? | Asset- en gegevensinventaris, beschermingsmaatregelen, monitoringregistraties, responslogboeken en hersteltests |
| COBIT 2019- of ISACA-auditor | Is governance verantwoord, gemeten en afgestemd op ondernemingsdoelstellingen? | Rollen, managementrapportage, risicobereidheid, prestatiemetrieken, assuranceresultaten en verbetermaatregelen |
Dit voorkomt dubbel nalevingswerk. Bouw in plaats van afzonderlijke bewijsdossiers voor GDPR, NIS2 en DORA één dossier met bewijs voor beheersmaatregelen en tag elk item voor de verplichtingen die het ondersteunt.
Veelvoorkomende hiaten in Article 32 TOMs-programma’s
Het meest voorkomende hiaat is verweesd bewijs bij beheersmaatregelen. Een organisatie heeft een beheersmaatregel, zoals encryptie, maar kan niet uitleggen welk risico deze behandelt, welk beleid deze vereist, wie eigenaar is of hoe de maatregel wordt beoordeeld.
Het tweede hiaat is zwak leveranciersbewijs. Onder GDPR zijn verwerkers en subverwerkers belangrijk. Onder NIS2 maakt beveiliging van de toeleveringsketen deel uit van cyberbeveiligingsrisicobeheer. Onder DORA is ICT-risico van derde partijen een gereguleerd domein met registers, due diligence, contractuele waarborgen, auditrechten en exitplanning. Een leveranciersspreadsheet is niet genoeg als kritieke afhankelijkheden niet risicobeoordeeld en beheerst zijn.
Het derde hiaat is incidentbewijs. Organisaties hebben vaak een Incident Response Plan, maar geen bewijs dat classificatie, escalatie, rapportage aan autoriteiten en klantcommunicatie zijn getest. NIS2 en DORA verhogen hier de verwachtingen, en de GDPR-beoordeling van inbreuken in verband met persoonsgegevens moet in dezelfde workflow worden geïntegreerd.
Het vierde hiaat is back-upbewijs. Een succesvolle back-upjob toont geen herstelbaarheid aan. Een gedocumenteerde hersteltest doet dat wel.
Het vijfde hiaat is directiebeoordeling. Article 32 TOMs moeten evenredig zijn aan het risico. Als het management risico’s, incidenten, leverancierskwesties, budget, auditbevindingen en restrisico nooit beoordeelt, wordt proportionaliteit moeilijk aantoonbaar.
De uiteindelijke auditklare toolkit
De fase Audit, Review and Improvement van de Zenith Blueprint, stap 30, biedt de definitieve checklist voor gereedheid. Deze omvat de ISMS-scope en context, ondertekend informatiebeveiligingsbeleid, documenten voor risicobeoordeling en -behandeling, SoA, Annex A-beleid en -procedures, opleidingsregistraties, operationele registraties, interne-auditrapport, register voor corrigerende maatregelen, notulen van directiebeoordelingen, bewijs voor voortdurende verbetering en registraties van nalevingsverplichtingen.
Het enterprise Beleid voor audit en toezicht op naleving van Clarysec beschrijft het doel van deze discipline:
“Het genereren van verdedigbaar bewijsmateriaal en een audittrail ter ondersteuning van verzoeken van toezichthouders, gerechtelijke procedures of assuranceverzoeken van klanten.”
Bron: Beleid voor audit en toezicht op naleving, Doelstellingen, beleidsclausule 3.4. Beleid voor audit en toezicht op naleving
Een volwassen bewijsdossier voor Article 32 TOMs moet het volgende bevatten:
| Bewijscategorie | Minimale inhoud die geschikt is voor audits |
|---|---|
| Governance | ISMS-scope, beleidsgoedkeuring, rollen, doelstellingen, notulen van directiebeoordelingen |
| Risico | Risicomethodologie, risicoregister, behandelplan, goedkeuringen van restrisico |
| SoA | Van toepassing zijnde beheersmaatregelen, uitsluitingen, onderbouwingen en mapping naar regelgeving |
| Privacy | Gegevensinventaris, PII-beheersmaatregelen, bewijs van bewaartermijnen, DPIA of privacyrisicobeoordeling waar van toepassing |
| Technische beheersmaatregelen | MFA, toegangsrechtenbeoordelingen, encryptie, kwetsbaarhedenbeheer, logging, monitoring en bewijs voor veilige ontwikkeling |
| Weerbaarheid | Back-updekking, hersteltests, continuïteitsplannen, incidentoefeningen en herstelmetrieken |
| Leveranciersassurance | Leveranciersregister, due diligence, contractuele clausules, monitoring, auditrechten en exitplanning |
| Verbetering | Interne audits, corrigerende maatregelen, geleerde lessen en beoordelingen van de doeltreffendheid van beheersmaatregelen |
Volgende stappen: bouw Article 32 TOMs-bewijs met Clarysec
Als u technische en organisatorische maatregelen onder GDPR Article 32 moet aantonen, begin dan niet met het verzamelen van willekeurige screenshots. Begin met traceerbaarheid.
- Definieer de ISMS-scope en de grenzen van de verwerking van persoonsgegevens.
- Identificeer GDPR-, NIS2-, DORA-, contractuele en klantvereisten.
- Bouw risicocriteria op met ISO/IEC 27005:2022 en door het management goedgekeurde risicobereidheid.
- Maak het risicoregister aan of werk het bij.
- Map elke behandeling naar ISO 27001:2022-beheersmaatregelen en de SoA.
- Gebruik Zenith Controls om privacy-, cryptografie-, leveranciers-, incident- en onafhankelijke beoordelingsmaatregelen over nalevingsverwachtingen heen kruislings te verwijzen.
- Volg Zenith Blueprint stap 13 en stap 14 om risico’s, beheersmaatregelen en regelgevende verplichtingen te verbinden.
- Gebruik Zenith Blueprint stap 19 om technische beheersmaatregelen in werking te verifiëren.
- Gebruik Zenith Blueprint stap 30 om het definitieve auditwaardige bewijsdossier samen te stellen.
- Sla al het bewijs centraal op, label het per risico en beheersmaatregelthema en houd corrigerende maatregelen zichtbaar.
Clarysec kan u helpen GDPR Article 32 om te zetten van een vage nalevingsverplichting in een verdedigbaar, risicogebaseerd bewijssysteem dat is afgestemd op ISO 27001:2022, NIS2 en DORA.
Begin met de Zenith Blueprint, versterk deze met Clarysec-beleid en gebruik Zenith Controls om elke TOM traceerbaar, testbaar en auditwaardig te maken.
Frequently Asked Questions
About the Author
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
