Privacyrisicobeoordeling voor ISO 27701 en GDPR

De maandagochtendvergadering voelde vertrouwd voor Maria, de CISO van een snelgroeiende healthtechorganisatie.

De CEO wilde een eenvoudig dashboard dat de GDPR-risicoblootstelling liet zien voordat het bedrijf zijn AI-gedreven platform voor patiëntanalytics zou lanceren. De nieuwe privacyfunctionaris, David, had een register van verwerkingsactiviteiten, oftewel RoPA, met 50 tabbladen. Engineering had de cloudomgeving beveiligd. Product was klaar voor release. De leverancier omschreef zijn subverwerkersstack als “enterprise grade”.

Maar één vraag legde de vergadering stil.

“Wat is ons daadwerkelijke risico, en kunnen wij aan grootzakelijke klanten aantonen dat wij het onder controle hebben?”

De RoPA liet zien wat het bedrijf verwerkte. Het beveiligingsrisicoregister liet infrastructuurrisico’s zien. Enkele DPIA’s stonden in afzonderlijke documenten. Leveranciersbeoordelingen zaten in inkoopmappen. Niemand kon één traceerbare besluitvormingsketen tonen van verwerkingsactiviteit naar privacyrisico, DPIA-besluit, behandelplan, mapping van beheersmaatregelen, goedkeuring van restrisico en beoordelingsdatum.

Dat is de kloof waarmee veel organisaties te maken krijgen wanneer zij toewerken naar ISO/IEC 27701:2025 en GDPR-verantwoordingsplicht. Zij beschikken over privacyverklaringen, leveranciersvragenlijsten, RoPA-vermeldingen, gegevenskaarten, DPIA-sjablonen en ISO/IEC 27001:2022-beheersmaatregelen. Wat vaak ontbreekt, is de operationele laag die deze elementen met elkaar verbindt.

Een volwassen privacy-informatiemanagementsysteem, of PIMS, behandelt privacyrisicobeoordeling niet als een juridisch bijdocument. Het behandelt dit als een herhaalbare besluitvormingsworkflow: verwerking identificeren, risico screenen, bepalen of een DPIA nodig is, beheersmaatregelen selecteren, eigenaren toewijzen, restrisico goedkeuren, triggers monitoren en bewijs bewaren.

Daar helpen de beleidspakketten van Clarysec, Zenith Blueprint en Zenith Controls teams om van losse spreadsheets over te gaan naar een verdedigbaar mechanisme voor privacyrisico’s.

Privacyrisicobeoordeling is de ontbrekende operationele laag

GDPR-verantwoordingsplicht wordt vaak teruggebracht tot “documentatie hebben”. Documentatie is belangrijk, maar Article 5(2) gaat verder. De verwerkingsverantwoordelijke is verantwoordelijk voor naleving van de beginselen in Article 5(1), en moet die naleving kunnen aantonen. Dat omvat rechtmatigheid, behoorlijkheid, transparantie, doelbinding, gegevensminimalisatie, juistheid, opslagbeperking, integriteit en vertrouwelijkheid.

Daarvoor is meer nodig dan een RoPA. De organisatie moet kunnen uitleggen waarom een verwerkingsactiviteit aanvaardbaar is, welke risico’s deze voor betrokkenen veroorzaakt, welke beheersmaatregelen die risico’s verminderen, wie eigenaar is van het besluit en wanneer het moet worden herzien.

ISO/IEC 27701:2025 versterkt deze verwachting door privacygovernance in te bedden in een beheerd PIMS. In de praktijk moet privacyrisicobeoordeling zes operationele objecten met elkaar verbinden:

1. De inventaris van PII-verwerkingen of RoPA.
2. Documentatie van rechtsgrondslag en doel.
3. Privacyrisicoscreening en DPIA-besluitvorming.
4. Risicobehandeling en selectie van beheersmaatregelen.
5. Governance voor leveranciers, verwerkers en subverwerkers.
6. Bewijs dat in het ISMS en PIMS wordt bewaard.

Clarysec maakt die verbinding expliciet. In het Enterprise Beleid inzake privacyrisicobeoordeling en DPIA vindt de trigger plaats voordat de verwerking begint:

[Beide] De proces- of bedrijfseigenaar MOET privacyrisicoscreening in REG04 initiëren voordat nieuwe of wezenlijk gewijzigde verwerking van PII die in REG02 is vastgelegd begint.

Dezelfde vroegtijdige discipline komt terug in het Enterprise Beleid inzake inventaris van PII-verwerkingen en rechtsgrondslag:

[Beide] De proces- of bedrijfseigenaar MOET privacyrisico- en DPIA-screening in REG04 initiëren voordat nieuwe of wezenlijk gewijzigde verwerking van PII doorgaat.

Dit voorkomt een veelvoorkomend tekortkomingspatroon: het product gaat live, de RoPA wordt later bijgewerkt, de DPIA-vraag komt te laat en het risicoregister ontvangt nooit het privacyscenario.

Voor verwerkingsverantwoordelijken ondersteunt dit discipline rond de rechtsgrondslag onder GDPR Article 6, gegevensbescherming door ontwerp en door standaardinstellingen onder Article 25, beveiliging van de verwerking onder Article 32 en verantwoordingsplicht onder Article 5. Voor verwerkers ondersteunt het gedocumenteerde instructies, assurance richting klanten, contractuele grenzen en transparantie over subverwerkers.

Begin met de feitelijke verwerking, niet met een leeg sjabloon

Een privacyrisicobeoordeling faalt wanneer deze begint met een leeg formulier zonder operationele context. De eerste vraag moet niet zijn: “Hebben we een DPIA nodig?” De eerste vraag moet zijn: “Welke verwerking verandert er feitelijk?”

Voor een SaaS-, fintech- of healthtechorganisatie kan de wijziging betrekking hebben op:

• Een nieuwe gegevenscategorie, zoals gedragsgegevens over gebruik, gezondheidsgegevens, biometrische signalen of betalingsmetadata.
• Een nieuw doel, zoals fraudescore, patiëntanalytics, AI-ondersteunde support, churnvoorspelling of personalisatie.
• Een nieuwe ontvanger, verwerker of subverwerker.
• Een nieuwe supportworkflow of grensoverschrijdend toegangspad.
• Een nieuwe bewaartermijn.
• Een nieuw model, algoritme of geautomatiseerde aanbeveling.
• Een nieuwe groep betrokkenen, zoals minderjarigen, werknemers, patiënten of financieel kwetsbare personen.

De definities in de GDPR zijn breed. Persoonsgegevens omvatten identificatoren, online identificatoren, locatiegegevens en factoren die aan identiteit zijn gekoppeld. Verwerking omvat verzamelen, opslaan, opvragen, gebruiken, verstrekken, beperken, wissen en vernietigen. Een inbreuk in verband met persoonsgegevens omvat onopzettelijke of onrechtmatige vernietiging, verlies, wijziging, ongeoorloofde verstrekking van of toegang tot persoonsgegevens.

Dat betekent dat een privacyrisicoworkflow meer moet vastleggen dan alleen of de database is versleuteld. De workflow moet vastleggen waarom de verwerking bestaat, of het doel verenigbaar is, of de rechtsgrondslag geldig is, of bijzondere categorieën persoonsgegevens betrokken zijn, of betrokkenen de verwerking kunnen begrijpen en of waarborgen evenredig zijn.

Voor kleinere teams biedt het SME Beleid inzake gegevensbescherming en privacy het startpunt in clausule 5.2.1:

De privacycoördinator moet een register bijhouden van alle verwerkingsactiviteiten van persoonsgegevens, waaronder gegevenscategorieën, doel, rechtsgrondslag en bewaartermijnen

Dat register is geen administratieve bijzaak. Het is het invoermodel voor privacyrisicobeoordeling. Zonder gegevenscategorieën, doel, rechtsgrondslag en bewaartermijnen kan de beoordeling doelbinding, gegevensminimalisatie, opslagbeperking, transparantie of behoorlijkheid niet betrouwbaar beoordelen.

Hetzelfde SME-beleid maakt risicobeoordeling ook tot een terugkerende verplichting in clausule 7.1.1:

De privacycoördinator moet privacyrisico’s jaarlijks en bij majeure systeemwijzigingen beoordelen

Voor ondernemingen is de governancecadans sterker. Het Enterprise Beleid inzake gegevensbescherming en privacy bepaalt:

Privacyrisicoregisters moeten binnen het ISMS worden bijgehouden en ten minste elk kwartaal worden beoordeeld door de Functionaris voor gegevensbescherming (FG) en de CISO.

Hier wordt de integratie van ISO/IEC 27701:2025 en ISO/IEC 27001:2022 praktisch. Privacyrisico’s verdwijnen niet in juridische mappen. Zij worden beoordeeld naast beveiligingsrisico’s, leveranciersrisico’s, incidenten, auditbevindingen, behandelplannen en managementrapportage.

De Clarysec-workflow van REG02 naar REG04

Het meest effectieve proces voor privacyrisicobeoordeling is eenvoudig genoeg voor bedrijfseigenaren en robuust genoeg voor auditors. Het model van Clarysec gebruikt REG02 als inventaris van PII-verwerkingen en REG04 als registratie van privacyrisicobeoordeling en DPIA.

Het Beleid inzake privacyrisicobeoordeling en DPIA definieert het minimale bewijs dat nodig is voordat REG04 kan worden gesloten:

[Beide] De privacyfunctionaris / PIMS-manager MOET ervoor zorgen dat elke REG04-beoordeling vóór afsluiting de risicoclassificatie, behandelbeslissing, eigenaar, vervaldatum, restrisico, goedkeuringsstatus en beoordelingsdatum vastlegt.

Die zin vormt de operationele ruggengraat. Een privacyrisicobeoordeling is niet gesloten omdat iemand “laag risico” in een opmerkingenveld heeft geschreven. Zij is gesloten wanneer de registratie de classificatie, behandelbeslissing, eigenaar, vervaldatum, restrisico, goedkeuringsstatus en beoordelingsdatum bevat.

Voor mkb-organisaties wordt dezelfde discipline vereenvoudigd toegepast. Het SME Beleid inzake risicobeheer bepaalt:

Elke risicovermelding moet bevatten: beschrijving, waarschijnlijkheid, impact, score, eigenaar en behandelplan.

Het uitgangspunt is proportionaliteit, niet informaliteit. Kleinere organisaties kunnen een eenvoudiger register gebruiken, maar elk risico heeft nog steeds een beschrijving, score, eigenaar en behandelplan nodig.

Gebruik de ISO/IEC 27001:2022-risico-engine voor privacy

Privacyrisico mag niet buiten de risicobeheermethode van de organisatie staan. ISO/IEC 27001:2022 biedt al de managementsysteem-engine: context, belanghebbenden, scope, leiderschap, risicobeoordeling, behandeling, operationele beheersing, gedocumenteerde informatie, prestatie-evaluatie en voortdurende verbetering.

Clausules 4.1 tot en met 4.4 vereisen dat de organisatie inzicht heeft in interne en externe kwesties, eisen van belanghebbenden, het ISMS-toepassingsgebied en ISMS-processen. Voor privacy omvatten belanghebbenden klanten, betrokkenen, werknemers, toezichthouders, verwerkers, subverwerkers, toezichthoudende autoriteiten, toezichthouders in de financiële sector waar relevant en contractuele klanten.

Clausule 6.1.2 vereist een proces voor risicobeoordeling van informatiebeveiliging. Clausule 6.1.3 vereist risicobehandeling van informatiebeveiliging, waaronder het selecteren van beheersmaatregelen, het opstellen van een Verklaring van Toepasselijkheid, het formuleren van een risicobehandelingsplan en het verkrijgen van goedkeuring door de risico-eigenaar van het plan en de restrisico’s. Clausules 8.2 en 8.3 vereisen het uitvoeren van risicobeoordelingen en risicobehandelingen voor informatiebeveiliging op geplande intervallen of wanneer significante wijzigingen optreden, met behoud van gedocumenteerde resultaten.

Clarysec’s Enterprise Beleid inzake risicobeheer sluit daarop aan in clausule 5.1:

Een formeel risicobeheerproces moet worden onderhouden in overeenstemming met ISO/IEC 27005 en ISO 31000, en moet risico-identificatie, analyse, evaluatie, behandeling, monitoring en communicatie omvatten.

Voor privacy moeten de risicocriteria impact op betrokkenen omvatten, niet alleen bedrijfsimpact. Een laag financieel verlies kan nog steeds een hoge privacy-impact zijn wanneer de verwerking bijzondere categorieën persoonsgegevens, kwetsbare personen, profilering, ondoorzichtigheid, onrechtmatige bewaring, onvermogen om rechten uit te oefenen of immateriële schade omvat.

Clarysec’s Zenith Blueprint: een 30-stappenroadmap voor auditors legt dit uit in de fase Risicobeheer, stap 10:

Bij het definiëren van impact is het verstandig om niveaus te relateren aan de schaal van uw specifieke bedrijf. Bijvoorbeeld: “Majeure financiële impact = verlies > $100k” (pas dit aan uw context aan). Houd ook rekening met regelgevende impact: een datalek van persoonsgegevens kan bijvoorbeeld automatisch “Majeur” of “Ernstig” zijn vanwege GDPR-boetes en meldingsvereisten, zelfs als het directe financiële verlies onduidelijk is.

Die guidance is vooral belangrijk voor AI-analytics, gezondheidsgegevens, financiële profilering, monitoring van werknemers en klantenscores. De schade kan juridisch, reputatiegebonden, discriminerend, operationeel, contractueel of persoonlijk zijn.

Een praktisch voorbeeld: AI-patiëntanalytics

Terug naar Maria en David. Hun healthtechplatform zal bijzondere categorieën gezondheidsgegevens verwerken onder GDPR Article 9. Het gebruikt patiëntgeschiedenis, afspraakgegevens, notities van clinici en modeluitvoer om risico-inzichten te genereren.

Met Zenith Blueprint beginnen zij bij stap 9: het identificeren van bedrijfsmiddelen, dreigingen en kwetsbaarheden:

Leg voor elk bedrijfsmiddel de belangrijkste gegevens vast: naam/beschrijving, eigenaar, locatie en classificatie (gevoeligheid). Een bedrijfsmiddel kan bijvoorbeeld zijn: “Klantendatabase – eigendom van IT-afdeling – gehost op AWS – bevat persoonsgegevens en financiële gegevens (hoge gevoeligheid).”

Dezelfde stap voegt de privacybril toe:

Zorg ervoor dat bedrijfsmiddelen met persoonsgegevens zijn gemarkeerd (voor GDPR- relevantie) en dat kritieke dienstmiddelen zijn aangeduid (voor mogelijke NIS2-toepasselijkheid als u in een gereguleerde sector actief bent).

Maria’s team identificeert het AI Patient Analytics Platform, de patiëntendatabase, het datawarehouse, de modeltrainingspijplijn, het clinici-dashboard, cloudopslag, de identiteitsprovider, auditlogboeken, het supportticketplatform en de analytics-tool van een derde partij. Elk bedrijfsmiddel krijgt een eigenaar, locatie, classificatie en PII-relatie.

Daarna definiëren zij risicoscenario’s. Eén scenario is ongeautoriseerde toegang tot gezondheidsdossiers. Een ander is onbedoelde verstrekking via analytics-exporten. Een derde is bias in een AI-model door scheefgetrokken trainingsdata, wat leidt tot oneerlijke of discriminerende risicoscores voor patiënten.

Stap 11 van Zenith Blueprint legt de rol van het risicoregister uit:

Het risicoregister is doorgaans een spreadsheet (ons sjabloon “Risk Register and SoA Builder.xlsx” heeft hiervoor een eigen werkblad). Het dient als centraal logboek van risico’s.

Een privacyrisicovermelding voor het scenario van bias in het AI-model kan er als volgt uitzien:

Deze vermelding doet wat de oude spreadsheet niet kon. Zij verbindt een verwerkingsactiviteit met een bedrijfsmiddel, dreiging, kwetsbaarheid, risico voor betrokkenen, eigenaar, score, behandelplan en bewijsspoor.

Omdat de verwerking een hoog risico heeft en bijzondere categorieën persoonsgegevens omvat, is de DPIA geen losse nagedachte. De DPIA wordt de diepgaandere beoordelingsfase voor een risico dat al in het systeem is vastgelegd. Het Enterprise Beleid inzake gegevensbescherming en privacy bepaalt:

Alle significante wijzigingen aan systemen of processen waarbij persoonlijke informatie (PII) betrokken is, moeten een gedocumenteerde gegevensbeschermingseffectbeoordeling (DPIA) vereisen, beoordeeld door de Functionaris voor gegevensbescherming (FG).

Voor een hoog restrisico bij de verwerkingsverantwoordelijke voegt het Beleid inzake privacyrisicobeoordeling en DPIA daaraan toe:

[Verwerkingsverantwoordelijke] Topmanagement MOET acceptatie van een hoog resterend privacyrisico in REG04 goedkeuren voordat verwerking met een hoog risico door de verwerkingsverantwoordelijke begint of doorgaat.

Het lanceringsbesluit is nu traceerbaar: wat is gewijzigd, wat is beoordeeld, welke risico’s zijn geïdentificeerd, welke beheersmaatregelen zijn geselecteerd, wie eigenaar is van de behandeling, wie het restrisico heeft goedgekeurd en wanneer het besluit wordt herzien.

Van risico’s naar beheersmaatregelen met Zenith Controls

Privacyrisicobeoordeling heeft alleen waarde als zij leidt tot besluiten over beheersmaatregelen. Clarysec’s Zenith Controls: The Cross-Compliance Guide is de cross-compliance guide die beheersmaatregelen uit ISO/IEC 27001:2022 en ISO/IEC 27002:2022 koppelt aan gerelateerde eisen in andere raamwerken. Het is geen afzonderlijke set beheersmaatregelen. Het helpt teams begrijpen hoe bewijs voor beheersmaatregelen meerdere verplichtingen ondersteunt.

Voor privacyrisicobeoordeling belicht Zenith Controls drie centrale ISO/IEC 27002:2022-beheersmaatregelen:

Beheersmaatregel 5.34 ondersteunt ook GDPR Article 25 en Article 32, NIS2 Article 21-maatregelen voor cyberbeveiligingsrisicobeheer, DORA-verwachtingen voor ICT-risicobeheer en uitkomsten uit NIST CSF 2.0 zoals GV.OC-03 voor wettelijke, regelgevende, contractuele, privacy- en burgerrechtenverplichtingen, plus PR.DS-01 voor bescherming van gegevens in rust.

Stap 13 van Zenith Blueprint verbindt deze besluiten met de Verklaring van Toepasselijkheid:

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

Zo wordt een privacybevinding een besluit over beheersmaatregelen in het ISMS en PIMS, en niet slechts een juridische opmerking.

Leveranciers- en verwerkersrisico moet vóór goedkeuring worden beoordeeld

Veel privacytekortkomingen beginnen in leveranciersgovernance. Een verwerker voegt een nieuwe subverwerker toe. Een supportleverancier krijgt productietoegang. Een analyticsplatform slaat gebeurtenisgegevens op in een nieuwe regio. Inkoop tekent het contract voordat privacy het risico heeft gezien.

Clarysec’s Enterprise Beleid inzake privacybeheer voor verwerkers, subverwerkers en derde partijen voorkomt dit door leveranciersbeoordeling, REG04 en het derdenregister met elkaar te verbinden:

[Beide] De privacyfunctionaris / PIMS-manager MOET privacyrisico- en DPIA-screening in REG04 activeren voor verwerkersrelaties met een hoog risico en wezenlijke privacywijzigingen bij derde partijen vóór goedkeuring, waarbij de REG04-referentie in REG08 wordt vastgelegd.

Voor mkb-organisaties legt het Beleid inzake beveiliging van derde partijen en leveranciers de eis voor beoordeling vóór contractering vast:

Voorafgaand aan de opdracht moet elke leverancier worden beoordeeld op potentiële risico’s. Deze beoordeling moet omvatten:

De operationele boodschap is duidelijk. Leveranciersrisico wordt vóór goedkeuring beoordeeld, niet na ondertekening.

Dit ondersteunt ook NIS2 en DORA. NIS2 Article 21 vereist beveiliging van de toeleveringsketen als onderdeel van maatregelen voor cyberbeveiligingsrisicobeheer. DORA Articles 28 to 30 vereisen dat financiële entiteiten ICT-risico’s van derde partijen beheren, precontractuele beoordelingen uitvoeren, contractuele waarborgen handhaven, onderuitbestedingsrisico begrijpen, afhankelijkheden monitoren en exits plannen voor kritieke of belangrijke functies.

Als een leverancier PII aanraakt of privacykritische verwerking ondersteunt, moet de privacyrisicoregistratie de leverancier, verwerkingsrol, gegevenslocatie, afhankelijkheid van subverwerkers, contractuele waarborgen, incidentverplichtingen, bewaartermijnregels, monitoringsaanpak en exitplan tonen.

Eén workflow, veel nalevingsuitkomsten

Het voordeel van een geïntegreerde PIMS-workflow is dat hetzelfde bewijs meerdere raamwerken ondersteunt zonder dubbel werk.

NIST CSF 2.0 is bijzonder nuttig voor communicatie met leidinggevenden. De GOVERN-functie omvat organisatiecontext, risicobeheerstrategie, beleid, rollen, toezicht en risico’s in de toeleveringsketen. De Organizational Profiles helpen huidige en doeluitkomsten te vertalen naar een geprioriteerd actieplan, zoals een risicoregister of een plan met acties en mijlpalen.

Voor organisaties die onder NIS2, DORA of sectorspecifieke regels vallen, ondersteunt privacyrisicobewijs ook cyberbeveiligingsgovernance, leverancierstoezicht, paraatheid voor incidenten en weerbaarheidsrapportage.

Privacyrisicobehandeling is breder dan encryptie

Encryptie is belangrijk, maar zij kan geen ongeldige rechtsgrondslag, overmatige gegevensverzameling, niet-gemelde profilering, onbehoorlijke verwerking, onrechtmatige bewaring of een verwerker die buiten instructies handelt herstellen.

Het SME Beleid inzake gegevensbescherming en privacy bepaalt:

Beheersmaatregelen moeten worden geïmplementeerd om geïdentificeerde risico’s te verminderen, waaronder encryptie, anonimisering, veilige vernietiging en toegangsbeperkingen

Dat zijn sterke voorbeelden, maar de behandeling moet passen bij het scenario. Een privacyrisicobehandelingsplan kan bestaan uit het beperken van het verwerkingsdoel, verwijderen van onnodige gegevenscategorieën, aggregeren of pseudonimiseren van gegevens, bijwerken van privacyverklaringen, wijzigen van de rechtsgrondslag waar passend, beperken van bewaartermijnen, beperken van toegang, toevoegen van logging, bijwerken van contracten, afronden van een DPIA, uitstellen van lancering of afwijzen van verwerking die onaanvaardbaar blijft.

Het Enterprise Beleid inzake risicobeheer versterkt behandelplanning voor risico’s boven de tolerantiegrens:

Alle risico’s die boven het tolerantieniveau zijn geclassificeerd, moeten een bijbehorend risicobehandelingsplan hebben waarin wordt gespecificeerd:

In de praktijk betekent dit dat een hoog privacyrisico niet stilzwijgend kan worden geaccepteerd. Het moet worden behandeld, waar passend worden overgedragen, worden vermeden of formeel worden geaccepteerd door de juiste verantwoordelijke eigenaar.

Beoordelingstriggers houden de beoordeling actueel

Een privacyrisicobeoordeling die nooit opnieuw wordt bekeken, wordt verouderd bewijs. ISO/IEC 27001:2022 clausules 8.2 en 8.3 vereisen risicobeoordeling en risicobehandeling op geplande intervallen of wanneer significante wijzigingen optreden. GDPR-verantwoordingsplicht verwacht actuele besluiten. ISO/IEC 27701:2025 is afhankelijk van monitoring en voortdurende verbetering.

Een REG04-beoordeling moet opnieuw worden geopend wanneer het doel wijzigt, nieuwe gegevenscategorieën worden toegevoegd, bijzondere categorieën persoonsgegevens betrokken raken, de rechtsgrondslag wijzigt, een verwerker of subverwerker wijzigt, opslag naar een nieuwe regio verhuist, bewaartermijnen wijzigen, profileringslogica wijzigt, een inbreuk of bijna-incident optreedt, klantcontracten wijzigen of een nieuwe NIS2-, DORA- of sectorspecifieke verplichting van toepassing wordt.

Incidentprocessen moeten terugkoppelen naar de privacyrisicoworkflow. NIS2 Article 23 stelt gefaseerde melding van significante incidenten vast. DORA Articles 17 to 20 vereisen registratie, classificatie, escalatie, communicatie, oorzaakanalyse en verbetering van ICT-gerelateerde incidenten. GDPR-verplichtingen voor inbreuken in verband met persoonsgegevens kunnen eveneens worden geactiveerd. Als een incident zwakke toegangscontroles, overmatige bewaring, onduidelijke leveranciersmeldingen of gebrekkige klantinstructies blootlegt, moet REG04 worden bijgewerkt.

Wat auditors verwachten te zien

Een sterke privacyrisicoworkflow moet bestand zijn tegen meerdere assuranceperspectieven.

Het Enterprise Beleid inzake gegevensbescherming en privacy vereist ook interne auditactiviteiten:

Een interne audit op privacynaleving moet jaarlijks worden uitgevoerd of bij majeure organisatorische of regelgevende wijzigingen. De auditscope moet omvatten:

Dit creëert een feedbacklus voor het management. Zijn REG02-registraties volledig? Zijn REG04-screenings tijdig? Worden DPIA’s uitgevoerd wanneer dat vereist is? Worden hoge restrisico’s goedgekeurd? Worden leverancierswijzigingen vastgelegd? Worden behandelplannen gesloten? Zijn privacyverklaringen afgestemd op de daadwerkelijke verwerking?

Checklist voor uw volgende overleg over privacywijzigingen

Gebruik deze checklist voordat een nieuwe verwerkingsactiviteit, productfunctie, leverancier, model of supportworkflow live gaat.

Deze checklist is geen vervanging voor beleid. Het is een praktische manier om beleid operationeel te maken in overleggen met product, inkoop, engineering, compliance, juridische zaken en het management.

Maak van privacyverantwoordingsplicht een werkend systeem

ISO/IEC 27701:2025 en GDPR-verantwoordingsplicht vereisen meer dan documenten. Zij vereisen een werkend systeem dat verwerkingsregistraties, rechtsgrondslag, privacyrisico, DPIA-besluiten, leveranciers, beheersmaatregelen, eigenaren, goedkeuringen en bewijs met elkaar verbindt.

Begin met de fase Risicobeheer in Zenith Blueprint, vooral stap 9 tot en met 13. Gebruik de Risk Register and SoA Builder om bedrijfsmiddelen, dreigingen, kwetsbaarheden, privacyrisico’s, behandelbeslissingen en verwijzingen naar beheersmaatregelen met elkaar te verbinden. Gebruik vervolgens Zenith Controls om PII-bescherming, inventaris van bedrijfsmiddelen en leveranciersbeveiliging te mappen naar assuranceverwachtingen onder GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 en COBIT 19.

Stem de operationele beleidsdocumenten af die de workflow afdwingbaar maken: Beleid inzake privacyrisicobeoordeling en DPIA, Beleid inzake inventaris van PII-verwerkingen en rechtsgrondslag, Beleid inzake privacybeheer voor verwerkers, subverwerkers en derde partijen, Beleid inzake risicobeheer en Beleid inzake gegevensbescherming en privacy. Kleinere teams kunnen ook gebruikmaken van Clarysec’s SME-beleidsdocumenten, terwijl grotere organisaties governance kunnen structureren via Enterprise-beleidsdocumenten.

Als uw team nieuwe verwerking lanceert, leveranciers wijzigt, zich voorbereidt op ISO/IEC 27701:2025 of probeert GDPR-bewijs voor verantwoordingsplicht herhaalbaar te maken, begin dan met één live verwerkingsactiviteit. Open REG02, voer REG04-screening uit, map de risico’s naar beheersmaatregelen, wijs eigenaren van behandelmaatregelen toe en beoordeel het restrisico met de juiste besluitvormer.

Die ene workflow is waar privacygovernance operationeel wordt.