ISO/IEC 27701:2025-transitieplan voor GDPR-PIMS

De bestuursvraag die een hiaat in privacybewijs blootlegt
Anya, de CISO van een snelgroeiende FinTech, keek naar de agenda voor de bestuursvergadering. Tussen omzetprognoses en marktuitbreiding stond het agendapunt dat haar week had beheerst: GDPR-naleving en gereedheid voor ISO/IEC 27701:2025.
Het bedrijf had een GDPR-programma. Er was een Functionaris voor gegevensbescherming (FG), er waren privacyverklaringen, verwerkersovereenkomsten, een DPIA-sjabloon en een proces voor verzoeken van betrokkenen. Sales had zakelijke klanten al meegedeeld dat het bedrijf toewerkte naar een ISO/IEC 27701:2025 privacy-informatiemanagementsysteem, of PIMS. Product bereidde een AI-ondersteunde analyticsfunctie voor die gebruikersgedrag van klanten, supporttickets, factureringsmetadata en accountactiviteit zou verwerken. Een grote EU-klant had gevraagd om bewijs dat verplichtingen van verwerkingsverantwoordelijken en verwerkers afzonderlijk werden beheerd.
De ongemakkelijke waarheid was niet dat privacydocumentatie ontbrak. Het probleem was bewijs.
Het verwerkingsregister liet niet consequent de rechtsgrondslag, bewaring, afhankelijkheden van subverwerkers, internationale doorgiften of de rol van het bedrijf als verwerkingsverantwoordelijke of verwerker per verwerkingsdoel zien. Leveranciersbeoordelingen richtten zich op beveiliging, maar onvoldoende op privacy-instructies, verwijdering, ondersteuning bij inbreuken, auditrechten en doorlegverplichtingen voor subverwerkers. Engineering voerde beveiligingsbeoordelingen uit, maar gegevensbescherming door ontwerp werd niet altijd geactiveerd wanneer een functie het verwerkingsdoel wijzigde. Interne audit toetste GDPR op hoofdlijnen, maar kon een verplichting niet altijd herleiden tot een eigenaar, beheersmaatregel, registratie, test en besluit uit de directiebeoordeling.
Dat is de werkelijke uitdaging van de ISO/IEC 27701:2025-transitie. Het is niet alleen een certificeringstraject. Het is een volwassenheidstoets: kan uw organisatie privacy uitvoeren als een beheerd systeem, en niet als een map met juridische documenten?
Voor GDPR-gedreven organisaties is het antwoord: breid het ISO/IEC 27001:2022 managementsysteem voor informatiebeveiliging uit naar een privacymanagementsysteem dat PIMS-scope, registraties van verwerkingsactiviteiten, privacyrisicobeoordeling, DPIA’s, leveranciersgovernance, afhandeling van inbreuken, mapping van beheersmaatregelen, interne audit en continue verbetering integreert.
Waarom gefragmenteerde GDPR-naleving onder auditdruk tekortschiet
Veel organisaties behandelen privacynaleving als een afzonderlijke werkstroom naast informatiebeveiliging. Juridische Zaken beheert contracten. IT beheert encryptie. Inkoop beheert leveranciers. De FG behandelt inzageverzoeken van betrokkenen. Productteams lanceren functies. Security handelt incidenten af. Elke functie kan nuttig werk leveren, maar zonder één operationeel model raakt privacybewijs gefragmenteerd.
Dit leidt tot vier terugkerende problemen.
Ten eerste dupliceren teams werk. Beveiligings- en privacyrisicobeoordelingen kunnen verschillende methoden, verschillende scores en verschillende eigenaren gebruiken.
Ten tweede ontstaan hiaten in diensten van derden, cloudconfiguraties, analytics-pijplijnen, supporttools en nieuwe ontwikkelprojecten omdat niemand volledig zicht heeft op PII-stromen.
Ten derde wordt assurance richting bestuur en klanten lastig. Een verzameling losstaande beleidsdocumenten bewijst niet dat privacyverplichtingen zijn geïmplementeerd, worden gemonitord en worden verbeterd.
Ten vierde convergeren moderne verwachtingen van toezichthouders. GDPR verwacht verantwoordingsplicht en bewijs. NIS2 verwacht governance, risicobeheer, incidentafhandeling, toegangscontrole, beheer van bedrijfsmiddelen en beveiliging van de toeleveringsketen. DORA verwacht dat financiële entiteiten ICT-risico’s, incidenten, weerbaarheidstesten, contracten met derde partijen en exitstrategieën beheren. Een geïsoleerd privacyprogramma kan dit niet efficiënt ondersteunen.
De sterkere aanpak is om de ISO/IEC 27701:2025-transitie op het ISO/IEC 27001:2022 ISMS te bouwen. ISO/IEC 27001:2022 biedt de managementsysteemstructuur voor context, belanghebbenden, scope, risicobeoordeling, risicobehandeling, doelstellingen, operationele planning, interne audit, directiebeoordeling, corrigerende maatregelen en continue verbetering. ISO/IEC 27002:2022 biedt de basis voor beheersmaatregelen voor wettelijke verplichtingen, inventaris van bedrijfsmiddelen, leveranciersrelaties, in de cloud gehoste diensten, toegangscontrole, logging, monitoring, verwijdering, datamasking en privacy en bescherming van PII.
De transitie moet vijf vragen beantwoorden:
- Wat is de PIMS-scope, inclusief rollen als verwerkingsverantwoordelijke, verwerker, gezamenlijke verwerkingsverantwoordelijke en subverwerker?
- Welke verwerkingsactiviteiten, gegevenscategorieën, doelen, rechtsgrondslagen, ontvangers, doorgiften en bewaarregels vallen binnen de scope?
- Welke privacyrisico’s vereisen een DPIA, behandeling, goedkeuring en acceptatie van restrisico?
- Welke beleidslijnen, beheersmaatregelen, contracten, technische waarborgen en registraties tonen GDPR-verantwoordingsplicht aan?
- Hoe bevestigen interne audit en directiebeoordeling dat het PIMS werkt en verbetert?
Fase 1: keur de PIMS-scope goed voordat beleid wordt herschreven
Een sterk ISO/IEC 27701:2025-transitieplan begint niet met het herschrijven van elk privacybeleid. Het begint met governance en scope.
Uw bestaande ISMS-scope is het vertrekpunt, maar de PIMS-scope moet PII-verwerking, bedrijfseenheden, diensten, systemen, regio’s, cloudomgevingen, leveranciers en privacyrollen expliciet identificeren. Het bestuur of topmanagement moet begrijpen waarom de transitie relevant is, vooral waar klanten, toezichthouders of sectorspecifieke verplichtingen zoals DORA afhankelijk zijn van aantoonbaar privacy- en weerbaarheidsbewijs.
Clarysec’s Beleid voor privacy-informatiemanagementsysteem [PIMS-beleid] stelt scopegoedkeuring verplicht:
[Beide] Topmanagement MOET de PIMS-scope in REG01 goedkeuren vóór de initiële PIMS-implementatie en binnen 30 dagen na elke wezenlijke wijziging.
Voor transitieprogramma’s die de clausulenummering uit de Clarysec-beleidsbibliotheek gebruiken, is dit de kernverwachting in Clausule 4.1.1. Dit is belangrijk omdat impliciete privacyscope een van de meest voorkomende auditbevindingen is. Als een productlijn, jurisdictie, verwerkingsrol, leverancier, cloudregio of bedrijfsproces wezenlijk wijzigt, mag de PIMS-scope niet voor interpretatie vatbaar blijven.
Hetzelfde beleid maakt van de transitie ook een beheerd programma:
[Beide] De privacyverantwoordelijke / PIMS-manager MOET het PIMS-implementatieplan in REG12 vastleggen vóór de PIMS-uitrol of een majeure PIMS-wijziging.
REG12 is geen administratieve overhead. Het is het stuurinstrument voor de transitie. Het moet laten zien wat verandert, waarom dat relevant is, wie eigenaar is, welk bewijs vereist is, welke risico’s openstaan en wanneer gereedheid wordt getoetst.
Fase 2: bouw een registergestuurde transitie-inventaris op
Voor GDPR-privacymanagementsystemen moet de eerste praktische oplevering een inventaris van bewijs zijn, geen herschreven beleid. Clarysec gebruikt een registergestuurde aanpak omdat registers privacy-intentie omzetten in auditbaar bewijs.
De PIMS-scope in REG01 sluit aan op verwerkingsactiviteiten in REG02, toepasselijkheid van beheersmaatregelen in REG03, privacyrisico en DPIA-screening in REG04, en implementatieplanning in REG12.
Het Beleid inzake gegevensbescherming en privacy - mkb [mkb-privacybeleid] stelt de basis vast:
De privacycoördinator moet een register bijhouden van alle verwerkingsactiviteiten van persoonsgegevens, inclusief gegevenscategorieën, doel, rechtsgrondslag en bewaartermijnen
Voor grotere omgevingen verhoogt het Beleid inzake gegevensbescherming en privacy [P17 Beleid inzake gegevensbescherming en privacy] de governanceverwachting:
De organisatie moet een formeel privacygovernancekader onderhouden dat is geïntegreerd in het Managementsysteem voor informatiebeveiliging (ISMS) om dit beleid af te dwingen.
Die integratie is het transitieprincipe. Een verwerkingsregister zonder risicobehandeling is een spreadsheet. Een DPIA zonder eigenaarschap van beheersmaatregelen is een juridische memo. Een leveranciers-DPA zonder monitoring is een contractenlade. ISO/IEC 27701:2025-transitiewerk moet deze artefacten samenbrengen in één beheerd PIMS.
| Transitie-item | Te verzamelen bewijs | Clarysec-artefact |
|---|---|---|
| PIMS-scope | Bedrijfseenheden, systemen, regio’s, verwerkingsrollen, uitsluitingen, afhankelijkheden | REG01 PIMS-scope |
| Verwerkingsactiviteiten | Doel, rechtsgrondslag, gegevenscategorieën, betrokkenen, bewaring, ontvangers, doorgiften | REG02 Verwerkingsregister |
| Toepasselijkheid van beheersmaatregelen | Opgenomen beheersmaatregelen, uitgesloten beheersmaatregelen, implementatiestatus, rechtvaardiging | REG03 PIMS-toepasselijkheid van beheersmaatregelen |
| DPIA-triggers | Hoogrisicoverwerking, nieuwe doelen, bijzondere categorieën persoonsgegevens, monitoring, geautomatiseerde beslissingen | REG04 Privacyrisico- en DPIA-screening |
| Transitieplan | Eigenaren, mijlpalen, auditplanning, input voor directiebeoordeling, herstelmaatregelen | REG12 PIMS-implementatieplan |
Deze inventaris ondersteunt ook een NIST Cybersecurity Framework 2.0-aanpak met een huidig profiel en doelprofiel. Het huidige profiel documenteert bestaande privacyprocessen, beheersmaatregelen en bewijs. Het doelprofiel definieert het gewenste PIMS dat is afgestemd op ISO/IEC 27701:2025. Het verschil tussen beide wordt de transitiebacklog.
Fase 3: map GDPR-verantwoordingsplicht naar het PIMS
GDPR-verantwoordingsplicht vormt de ruggengraat van privacybewijs. GDPR is van toepassing op verwerking in het kader van een vestiging in de EU en kan ook van toepassing zijn op niet-EU-verwerkingsverantwoordelijken of -verwerkers die goederen of diensten aanbieden aan personen in de EU of hun gedrag monitoren. GDPR definieert persoonsgegevens breed, inclusief directe en indirecte identificatoren. GDPR onderscheidt verwerkingsverantwoordelijken van verwerkers en definieert een inbreuk in verband met persoonsgegevens als een inbreuk op de beveiliging die leidt tot de accidentele of onrechtmatige vernietiging, het verlies, de wijziging of de ongeoorloofde verstrekking van of toegang tot persoonsgegevens.
Voor transitieplanning is het belangrijk dat GDPR niet wordt afgedekt door te stellen: “wij hebben beveiligingsmaatregelen.” Article 5 vereist rechtmatige, behoorlijke en transparante verwerking, doelbinding, gegevensminimalisatie, juistheid, opslagbeperking, integriteit en vertrouwelijkheid, en aantoonbare verantwoordingsplicht. Article 6 vereist een rechtsgrondslag. Article 9 voegt strengere voorwaarden toe voor bijzondere categorieën persoonsgegevens. Article 25 vereist gegevensbescherming door ontwerp en door standaardinstellingen. Article 28 vereist governance voor verwerkers. Article 32 vereist beveiliging van de verwerking.
Clarysec’s Beleid inzake juridische en regelgevende naleving - mkb [mkb-beleid inzake juridische en regelgevende naleving] geeft kleinere organisaties een eenvoudig startpunt:
De algemeen directeur moet een eenvoudig, gestructureerd Nalevingsregister onderhouden met daarin:
Het enterprise Beleid inzake juridische en regelgevende naleving [P37 Beleid inzake juridische en regelgevende naleving] is explicieter:
Alle wettelijke en regelgevende verplichtingen moeten binnen het Managementsysteem voor informatiebeveiliging (ISMS) worden gekoppeld aan specifieke beleidslijnen, beheersmaatregelen en eigenaren.
Die zin markeert het verschil tussen informele GDPR-naleving en auditbaar privacymanagement. Elke wezenlijke GDPR-verplichting moet worden gekoppeld aan een beleid, beheersmaatregel, eigenaar, registerveld en bron van bewijs.
| GDPR-verplichtingsgebied | PIMS-transitiebewijs | Operationele eigenaar |
|---|---|---|
| Rechtsgrondslag en doelbinding | REG02-verwerkingsregistratie met doel, rechtsgrondslag, rol en beoordelingsdatum | Privacyverantwoordelijke en proceseigenaar |
| Gegevensbescherming door ontwerp en door standaardinstellingen | Intakechecklist voor wijzigingen, DPIA-screening, architectuurbeoordeling, goedkeuringsregistratie | Producteigenaar en beveiligingsarchitect |
| Governance voor verwerkers | DPA, leveranciersrisicobeoordeling, subverwerkerslijst, auditrechten, clausule voor ondersteuning bij inbreuken | Inkoop en Juridische Zaken |
| Rechten van betrokkenen | Verzoekenlogboek, registratie van identiteitsverificatie, bewijs van afhandeling, uitzonderingsbesluiten | Privacy Operations |
| Afhandeling van inbreuken in verband met persoonsgegevens | Incidentregistratie, ernstbeoordeling, meldingsbesluit, geleerde lessen | Incidentmanager en FG |
| Bewaring en verwijdering | Bewaarschema, verwijderingsbewijs, goedkeuring van uitzonderingen | Gegevenseigenaar en IT-operaties |
Bewijs voor verwerkingsverantwoordelijken en verwerkers moet gescheiden zijn. Een verwerkingsverantwoordelijke moet rechtsgrondslag, transparantie, afhandeling van rechten, besluiten over doelen en bewaring aantonen. Een verwerker moet aantonen dat verwerking plaatsvindt op basis van gedocumenteerde instructies, met governance voor subverwerkers, ondersteuning aan de verwerkingsverantwoordelijke, beveiligingsmaatregelen, ondersteuning bij melding van inbreuken en teruggave of verwijdering aan het einde van de dienstverlening. Als de organisatie in beide rollen optreedt, volstaat één generiek bewijsmodel niet.
Fase 4: gebruik de SoA als brug voor privacybeheersmaatregelen
Een veelgemaakte transitiefout is het maken van een losstaande PIMS-spreadsheet met beheersmaatregelen terwijl de ISMS-Verklaring van Toepasselijkheid ongemoeid blijft. Dat creëert twee concurrerende werelden van beheersmaatregelen.
ISO/IEC 27001:2022 vereist dat besluiten over risicobehandeling worden weerspiegeld in de Verklaring van Toepasselijkheid. Clarysec’s Beleid inzake risicobeheer [Beleid inzake risicobeheer] stelt:
Een Verklaring van Toepasselijkheid (SoA) moet alle behandelbesluiten weerspiegelen en moet worden bijgewerkt wanneer de dekking van beheersmaatregelen wordt gewijzigd.
Voor de ISO/IEC 27701:2025-transitie wordt de SoA de brug tussen het ISMS en het PIMS. Als een DPIA of behandeling van privacyrisico’s leidt tot encryptie, datamasking, verwijderingsmaatregelen, toestemmingsmechanismen, due diligence van verwerkers, toegangsbeperkingen of monitoring van DSAR-werkstromen, moeten de SoA en REG03 het besluit weerspiegelen.
De Zenith Blueprint: een 30-stappenroutekaart voor auditors [Zenith Blueprint] bevestigt dit in stap 6:
✓ Aanvullende beheersmaatregelen: zijn er beheersmaatregelen buiten Annex A die u zou kunnen opnemen? ISO 27001
staat toe om andere beheersmaatregelen aan de SoA toe te voegen. U kunt bijvoorbeeld
naleving van NIST CSF of specifieke privacybeheersmaatregelen uit ISO 27701 opnemen.
Forceer privacyverplichtingen niet in beheersmaatregelen die niet passen. Voeg privacy-specifieke beheersmaatregelen toe waar nodig, maar beheer ze via hetzelfde model voor risicobehandeling, eigenaarschap, implementatiestatus, bewijs en audit.
De ISO/IEC 27002:2022-beheersmaatregelen die de transitie verankeren
In Zenith Controls: de gids voor naleving over meerdere kaders [Zenith Controls] staan twee ISO/IEC 27002:2022-beheersmaatregelen centraal in de ISO/IEC 27701:2025-transitie: 5.31 Wettelijke, statutaire, regelgevende en contractuele vereisten, en 5.34 Privacy en bescherming van PII.
Beheersmaatregel 5.31 is de nalevingshub. Deze ondersteunt de identificatie, documentatie, het eigenaarschap en de beoordeling van wettelijke, regelgevende, statutaire en contractuele vereisten. De beheersmaatregel sluit vanzelf aan op GDPR-verantwoordingsplicht, NIS2-governance, DORA ICT-risicoverplichtingen, privacyclausules van klanten en toezeggingen over cloudverwerking.
Beheersmaatregel 5.34 is het operationele privacyanker. Zenith Controls legt de afhankelijkheid duidelijk uit:
Een inventaris van informatieactiva (5.9) moet PII-gegevensverzamelingen omvatten (klantdatabanken, HR-dossiers). Dit ondersteunt 5.34 doordat de organisatie weet welke PII zij heeft en waar deze zich bevindt; dat is de eerste stap om deze te beschermen.
De crosswalk van beheersmaatregelen moet worden gebruikt als praktische ontwerpchecklist.
| ISO/IEC 27002:2022-beheersmaatregel | Relevantie voor de transitie naar GDPR-PIMS |
|---|---|
| 5.9 Inventaris van informatie en andere gerelateerde activa | Identificeert PII-repositories, systemen, eigenaren en gegevensstromen |
| 5.12 Classificatie van informatie | Labelt PII en bijzondere categorieën persoonsgegevens zodat strengere beheersmaatregelen gelden |
| 5.14 Informatieoverdracht | Beheerst interne en externe overdracht van persoonsgegevens |
| 5.15 Toegangscontrole | Dwingt need-to-know-toegang tot PII af |
| 5.16 Identiteitsbeheer | Waarborgt dat identiteiten met toegang tot PII worden beheerd en traceerbaar zijn |
| 5.19 Informatiebeveiliging in leveranciersrelaties | Ondersteunt privacy bij leveranciers, assurance over verwerkers en monitoring van derde partijen |
| 5.20 Informatiebeveiliging opnemen in leveranciersovereenkomsten | Verankert beveiligings- en privacyvereisten in contracten |
| 5.21 Informatiebeveiliging beheren in de ICT-toeleveringsketen | Ondersteunt governance voor subverwerkers en ICT-afhankelijkheden |
| 5.23 Informatiebeveiliging bij gebruik van in de cloud gehoste diensten | Waarborgt dat cloudproviders voldoen aan privacy-, locatie-, verwijderings- en contractuele verwachtingen |
| 5.31 Wettelijke, statutaire, regelgevende en contractuele vereisten | Mapt GDPR-, DORA-, NIS2-, klant- en contractuele verplichtingen |
| 5.33 Bescherming van registraties | Ondersteunt bewaring, integriteit en bescherming van registraties met bewijs |
| 5.34 Privacy en bescherming van PII | Verankert privacybeheersmaatregelen gedurende de PII-levenscyclus |
| 5.35 Onafhankelijke beoordeling van informatiebeveiliging | Ondersteunt interne audit en externe assurance |
| 5.36 Naleving van beleid, regels en normen voor informatiebeveiliging | Toetst of privacybeheersmaatregelen worden nageleefd |
| 5.8 Informatiebeveiliging in projectmanagement | Verankert privacy en beveiliging in projectgovernance |
| 8.10 Verwijdering van informatie | Ondersteunt opslagbeperking en verwijderingsverplichtingen |
| 8.11 Datamasking | Beschermt PII in niet-productieomgevingen en analytics-use-cases |
| 8.15 Logging | Levert bewijs van toegang tot en activiteit met PII |
| 8.16 Monitoringactiviteiten | Detecteert verdachte activiteit en ondersteunt incidentonderzoek |
| 8.32 Wijzigingsbeheer | Waarborgt dat privacy-impact wordt beoordeeld vóór productiewijzigingen |
Hier wordt privacy operationeel. Stel voor elke hoogrisicoverwerking de volgende vragen: welke activa bevatten de PII, hoe is deze geclassificeerd, wie heeft toegang, waarheen wordt de PII doorgegeven, welke in de cloud gehoste diensten verwerken de PII, welke bewaarregel geldt, welke monitoring detecteert misbruik en welk bewijs toont aan dat die beheersmaatregelen werken?
Voorbeeldwerkstroom: onboarding van een AI-ondersteunde analyticsfunctie
Terug naar Anya’s FinTech. Het productteam wil een AI-ondersteunde analyticsfunctie lanceren die gebruikersidentificatoren, accountactiviteit, supportmetadata, factureringsmetadata en gedragssignalen verwerkt. Sommige zakelijke klanten kunnen de output gebruiken voor monitoring van werknemers, wat het privacyrisico verhoogt.
Een PIMS-transitiewerkstroom moet de lancering behandelen als een gecontroleerde privacygebeurtenis.
Stap 1: werk REG02 bij voor verwerkingsrollen en doelen
De proceseigenaar maakt of werkt de verwerkingsregistratie bij. Vereiste velden zijn onder meer doel, gegevenscategorieën, categorieën betrokkenen, rechtsgrondslag of verwerkersinstructie, bewaartermijn, systemen, leveranciers, ontvangers, doorgiften en rolcontext.
Als het bedrijf verwerker is voor klantanalytics, moet REG02 verwerking op basis van klantinstructies tonen. Als het ook geaggregeerde gegevens gebruikt om het eigen product te verbeteren, kan dat afzonderlijke doel betekenen dat het bedrijf verwerkingsverantwoordelijke is voor verdere verwerking. De registratie mag de rollen niet vermengen.
Stap 2: voltooi REG04-screening
Clarysec’s Beleid inzake privacyrisicobeoordeling en DPIA [Beleid inzake privacyrisicobeoordeling en DPIA] vereist:
[Beide] De proceseigenaar / bedrijfseigenaar MOET baseline REG04-screening voltooien voor alle actieve REG02-verwerkingsactiviteiten binnen de scope, binnen 30 werkdagen na goedkeuring of uitbreiding van de PIMS-scope.
De screening moet monitoring, profilering, bijzondere categorieën persoonsgegevens, kwetsbare personen, nieuwe technologie, grootschalige verwerking, grensoverschrijdende doorgiften of een gewijzigd doel identificeren. Als drempelwaarden worden bereikt, wordt een DPIA geactiveerd.
Stap 3: voer de DPIA uit en definieer de behandeling
Het P17 Beleid inzake gegevensbescherming en privacy vereist:
Alle significante wijzigingen in systemen of processen waarbij persoonsgegevens (PII) betrokken zijn, moeten een gedocumenteerde gegevensbeschermingseffectbeoordeling (DPIA) vereisen, beoordeeld door de Functionaris voor gegevensbescherming (FG).
In de Clarysec-bibliotheek is dit gekoppeld aan Clausule 5.6. De DPIA moet risico’s beoordelen zoals overmatige gegevensverzameling, onduidelijk doel, heridentificatie, ongeautoriseerde toegang door klantbeheerders, onduidelijke bewaring en blootstelling aan subverwerkers. Behandelingen kunnen bestaan uit gegevensminimalisatie op veldniveau, pseudonimisering, configuratiemogelijkheden voor klanten, standaardinstellingen voor bewaring, sterkere auditlogging, DPA-updates, productverklaringen en beperkingen op modeltraining.
Stap 4: werk REG03 en de SoA bij
Het PIMS-beleid vereist:
[Beide] De privacyverantwoordelijke / PIMS-manager MOET REG03 onderhouden met opgenomen beheersmaatregelen, uitgesloten beheersmaatregelen, implementatiestatus en rechtvaardiging, jaarlijks en binnen 30 dagen na elke wijziging in de behandeling van privacyrisico’s.
Als de DPIA masking voor niet-productieanalytics, logging voor beheerderstoegang, verwijderingsmaatregelen, leveranciersclausules of klantconfiguratiewaarborgen toevoegt, moeten REG03 en de SoA worden bijgewerkt.
Stap 5: toon gegevensbescherming door ontwerp aan
Het mkb-privacybeleid formuleert het principe helder:
Privacy by design en by default moeten worden afgedwongen in alle nieuwe systemen en diensten
Bewijs moet bestaan uit de DPIA, architectuurbeoordeling, besluit over gegevensminimalisatie, toegangsmodel, loggingconfiguratie, bewaarinstelling, testresultaten, releasegoedkeuring en beoordeling na livegang. Zo wordt de functielancering herbruikbaar PIMS-bewijs.
Governance van privacy bij leveranciers in een DORA- en NIS2-wereld
Governance van privacy bij leveranciers is waar veel transities mislukken. GDPR Article 28 vereist dat verwerkingsverantwoordelijken verwerkers gebruiken die voldoende garanties bieden en verwerkersverplichtingen in schriftelijke contracten opnemen. DORA Articles 28 tot 30 vereisen dat financiële entiteiten ICT-risico’s van derde partijen beheren, registers van contractuele afspraken bijhouden, due diligence uitvoeren, auditrechten en exitvoorwaarden opnemen, onderaanneming beheren en kritieke of belangrijke functies adresseren. NIS2 Article 21 vereist beveiligingsmaatregelen voor de toeleveringsketen, inclusief aandacht voor kwetsbaarheden van leveranciers, cyberbeveiligingspraktijken en procedures voor veilige ontwikkeling.
ISO/IEC 27002:2022-beheersmaatregel 5.19, Informatiebeveiliging in leveranciersrelaties, is het operationele anker. Zenith Controls koppelt dit gebied aan leveranciersovereenkomsten, beveiliging van de ICT-toeleveringsketen, informatieoverdracht, nalevingsmonitoring, aanvaardbaar gebruik, GDPR-verwerkersverplichtingen, NIS2-cyberbeveiliging van de toeleveringsketen, DORA ICT-risico’s van derde partijen, NIST-leveranciersgovernance en COBIT-leveranciersmanagement.
| Leverancierscategorie | Vereist privacybewijs |
|---|---|
| Verwerker die PII van klanten verwerkt | DPA, instructies, technische en organisatorische maatregelen, subverwerkerslijst, ondersteuning bij melding van inbreuken, auditrechten |
| Subverwerker in SaaS-leveringsketen | Doorlegverplichtingen, locatie, doorgiftemechanisme, verwijderingstoezegging, wijzigingsmelding |
| Cloudhostingprovider | Regiokeuze, encryptie, toegangscontrole, incidentondersteuning, voorwaarden voor verwijdering en teruggave |
| Leverancier van supporttools | Toegangsbeperking, redactie van tickets, bewaring, logging, vertrouwelijkheid van supportmedewerkers |
| Analytics- of AI-leverancier | Doelbinding, beperking op modeltraining, pseudonimisering, opt-out of configuratiemogelijkheden |
Voor financiële entiteiten die onder DORA vallen, moet dit bewijs aansluiten op ICT-registers van derde partijen en beoordelingen van kritieke of belangrijke functies. Voor NIS2-entiteiten ondersteunen dezelfde leveranciersregistraties het risicobeheer van de toeleveringsketen. Voor NIST CSF 2.0 sluit leveranciersgovernance aan op de GOVERN-functie, met name op uitkomsten voor risicobeheer in de toeleveringsketen. Voor COBIT 2019 sluit leveranciersgovernance aan op doelstellingen zoals APO10 Managed Vendors en DSS-gerelateerde operationele beheersmaatregelen voor leveranciers.
Gereedheid voor incidenten en inbreuken moet geïntegreerd zijn
Privacytransitieplannen richten zich vaak te sterk op documentatie en te weinig op afhandeling van inbreuken. Dat is riskant, omdat GDPR, NIS2 en DORA allemaal gedisciplineerde incidentprocessen verwachten, ook al verschillen drempelwaarden en rapportagetermijnen.
GDPR vereist een beoordeling of een beveiligingsgebeurtenis heeft geleid tot een inbreuk in verband met persoonsgegevens en of melding aan de toezichthoudende autoriteit of betrokken personen vereist is. NIS2 stelt gefaseerde rapportage vast voor significante incidenten, inclusief een vroege waarschuwing binnen 24 uur, melding binnen 72 uur en een eindrapport binnen één maand. DORA vereist dat financiële entiteiten ICT-gerelateerde incidenten detecteren, beheren, classificeren, registreren, melden, erop reageren en ervan leren, met gefaseerde rapportage voor majeure incidenten.
| Incidentbewijs | GDPR-doel | NIS2- of DORA-doel |
|---|---|---|
| Incidentclassificatieregistratie | Bepaalt of een inbreuk in verband met persoonsgegevens heeft plaatsgevonden | Bepaalt classificatie als significant of majeur ICT-incident |
| Data-impactbeoordeling | Identificeert betrokkenen en risico voor rechten en vrijheden | Ondersteunt rapportage over ernst en impact |
| Tijdlijnlogboek | Toont tijdstip van kennisname, escalatie, besluiten en meldingstermijnen aan | Ondersteunt gefaseerde rapportage en communicatie met toezichthouders |
| Oorzaakanalyse | Ondersteunt herstelmaatregelen en verantwoordingsplicht | Ondersteunt eindrapportage en verbetering van weerbaarheid |
| Geleerde lessen | Werkt DPIA’s, beheersmaatregelen, training en leverancierstoezicht bij | Voedt testen, audit en directiebeoordeling |
NIST CSF 2.0 ondersteunt deze cyclus via de uitkomsten Detect, Respond, Recover en Govern. Het transitieteam moet waarborgen dat besluiten over privacy-inbreuken zijn ingebed in de werkstroom voor beveiligingsincidenten en niet worden behandeld als een losstaande juridische nagedachte.
Eén routekaart, meerdere nalevingsuitkomsten
De ISO/IEC 27701:2025-transitie wordt waardevoller wanneer zij dubbel werk voor naleving vermindert. Zenith Blueprint, stap 14, beveelt aan GDPR, NIS2 en DORA onderling te refereren, zodat organisaties kunnen aantonen dat risicobehandeling en beheersmaatregelen aan meerdere verplichtingen voldoen:
Voor elke regelgeving kunt u, indien van toepassing, een eenvoudige mappingtabel maken (bijvoorbeeld als
bijlage bij een rapport) met de belangrijkste beveiligingsvereisten van de regelgeving en de
bijbehorende beheersmaatregelen/beleidslijnen in uw ISMS.
Voor privacytransitieplanning moet de mapping praktisch en bewijsgericht zijn.
| Raamwerk | Wat auditors of beoordelaars verwachten | PIMS-transitierespons |
|---|---|---|
| GDPR | Verantwoordingsplicht, rechtsgrondslag, DPIA’s, governance voor verwerkers, afhandeling van inbreuken, ondersteuning van rechten | REG02, REG04, DPIA-registraties, DPA-register, besluitvormingslogboeken voor inbreuken, DSAR-bewijs |
| NIS2 | Risicoanalyse, incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, toegangscontrole, beheer van bedrijfsmiddelen | ISMS-risicoregister, leverancierstiers, incidentwerkstroom, toegangsrechtenbeoordelingen, inventaris van bedrijfsmiddelen |
| DORA | ICT-risicokader, incidentrapportage, weerbaarheidstesten, ICT-risico van derde partijen, contractuele clausules | Register van ICT-afhankelijkheden, mapping van kritieke leveranciers, incidentrapportages, testbewijs, exitplannen |
| NIST CSF 2.0 | Governance, wettelijke en privacyverplichtingen, risicoprofielen, leveranciersrisico, incident- en hersteluitkomsten | Huidige en doelprofielen, nalevingsmapping, monitoring van leveranciers, respons- en herstelbewijs |
| COBIT 2019 | Governance van het privacyprogramma, nalevingsmonitoring, leveranciersovereenkomsten, operationele privacybeheersmaatregelen | Bestuursrapportage, nalevingsregister, bewijs afgestemd op APO en DSS, interne-auditbevindingen |
In Zenith Controls ondersteunt ISO/IEC 27002:2022-beheersmaatregel 5.31 juridische en regelgevende traceerbaarheid over GDPR-verantwoordingsplicht, DORA-nalevingsverplichtingen, NIS2-governanceverwachtingen, NIST CSF 2.0 GV.OC-03 en externe nalevingsmonitoring volgens COBIT. Beheersmaatregel 5.34 ondersteunt GDPR Articles 25 en 32, bescherming gedurende de PII-levenscyclus, verwachtingen voor PII-verwerking in de cloud en privacybewuste beveiligingsmaatregelen.
Het resultaat is geen simplistisch model waarin “één beheersmaatregel gelijkstaat aan één wet”. Het is een verdedigbaar bewijsmodel waarin één goed ontworpen set beheersmaatregelen meerdere assurancebehoeften ondersteunt.
Hoe auditors de transitie zullen toetsen
Een sterk transitieplan anticipeert op audittechnieken.
Een auditor van ISO-managementsystemen begint met scope, belanghebbenden, wettelijke vereisten, risico’s, doelstellingen, operationele beheersmaatregelen, interne audits, directiebeoordelingen, non-conformiteiten en verbetering. De auditor verifieert of de PIMS-scope is goedgekeurd, of privacyverplichtingen in het nalevingsregister zijn opgenomen, of beheersmaatregelen in de SoA zijn gerechtvaardigd en of implementatiebewijs overeenkomt met de vastgestelde scope.
Een privacyauditor neemt steekproeven uit verwerkingsregistraties, DPIA’s, DSAR’s, besluiten over inbreuken, verwerkerscontracten, bewaarbeheersmaatregelen en projectonboarding. Beleidsintentie wordt niet geaccepteerd wanneer operationeel bewijs ontbreekt.
Een NIST-georiënteerde beoordelaar zoekt naar governance, wettelijke en contractuele verplichtingen, doelprofielen, leveranciersrisico, monitoring, respons en herstelbewijs.
Een COBIT 2019-auditor richt zich op bestuurstoezicht, nalevingsrapportage, leveranciersgovernance, rollen en verantwoordelijkheden, en of privacyrisico gedurende de levenscyclus van informatie wordt beheerd.
Clarysec’s PIMS-beleid voor monitoring, audit en verbetering [PIMS-beleid voor monitoring, audit en verbetering] stelt het auditprogramma verplicht:
[Alle] De interne-audit-/compliancebeoordelaar MOET jaarlijks, vóór de eerste geplande PIMS-auditcyclus, een risicogebaseerd intern PIMS-auditprogramma in REG12 opstellen.
Het Beleid voor audit en toezicht op naleving [Beleid voor audit en toezicht op naleving] past dezelfde discipline toe op ISMS-niveau:
Een risicogebaseerd auditplan moet jaarlijks worden opgesteld en goedgekeurd, rekening houdend met:
Voor kleinere organisaties houdt het Beleid voor audit en toezicht op naleving - mkb [mkb-beleid voor audit en toezicht op naleving] auditplanning gericht:
Het plan moet de belangrijkste systemen en beleidslijnen identificeren die moeten worden beoordeeld, met focus op:
Tijdens de transitie moet de eerste interne audit niet alles toetsen. De audit moet de hoogste transitierisico’s toetsen: onvolledige verwerkingsregistraties, ontbrekende DPIA-triggers, zwakke privacyclausules voor leveranciers, niet-geteste besluiten over inbreuken, onduidelijke rollen van verwerkingsverantwoordelijke en verwerker, en een mismatch met de SoA.
Een praktische 90-daagse ISO/IEC 27701:2025-transitieroutekaart
Een realistische routekaart moet kort genoeg zijn om uit te voeren en gestructureerd genoeg om bewijs op te leveren.
| Tijdlijn | Transitiedoelstelling | Belangrijkste outputs |
|---|---|---|
| Dag 1 tot en met 15 | Scope en governance vaststellen | REG01-goedkeuring, sponsor, rollenkaart, update van nalevingsregister, REG12-transitieplan |
| Dag 16 tot en met 35 | Uitgangssituatie voor privacybewijs opbouwen | Opschoning van REG02, gegevenscategorieën, doelen, rechtsgrondslagen, bewaring, systemen, leveranciers, doorgiften |
| Dag 36 tot en met 55 | Privacyrisico- en DPIA-screening uitvoeren | REG04-screening, DPIA-triggers, besluiten over risicobehandeling, goedkeuringen voor restrisico |
| Dag 56 tot en met 70 | Beheersmaatregelen, contracten en waarborgen bijwerken | REG03-update, SoA-update, DPA-herstelmaatregelen, toegang, verwijdering, masking, logging, cloudbeheersmaatregelen |
| Dag 71 tot en met 85 | Bewijs toetsen via interne audit | Steekproefaudit van één verwerkingsverantwoordelijk proces, één verwerkersdienst, één leverancier, één DPIA, één DSAR, één scenario voor een inbreuk |
| Dag 86 tot en met 90 | Directiebeoordeling houden en gereedheid bepalen | Beoordelingsacties, leverancierskwesties, incidenten, auditbevindingen, privacydoelstellingen, besluit over externe beoordeling |
De doelstelling van 90 dagen betekent niet dat elk herstelpunt is afgesloten. Het betekent dat de leiding een goedgekeurde scope, een geloofwaardige uitgangssituatie voor bewijs, geprioriteerde risicobehandeling, gerichte auditresultaten en een managementbesluit over gereedheid moet hebben.
Maak de transitie bewijsgericht
Organisaties die slagen met de ISO/IEC 27701:2025-transitie zijn niet de organisaties met het langste privacybeleid. Het zijn de organisaties die kunnen aantonen hoe privacyverplichtingen van wet naar scope gaan, van scope naar verwerkingsregistraties, van verwerkingsregistraties naar risicobeoordeling, van risicobeoordeling naar beheersmaatregelen, van beheersmaatregelen naar bewijs en van bewijs naar verbetering.
Clarysec helpt teams om die transitie praktisch te maken. Onze PIMS-beleidsset, GDPR-mappings, bewijsregisters voor verwerkingsverantwoordelijken en verwerkers, DPIA-werkstromen, sjablonen voor governance van privacy bij leveranciers, materialen voor afhandeling van inbreuken, agenda’s voor directiebeoordelingen, Zenith Blueprint en Zenith Controls geven CISO’s, FG’s, compliance managers, auditors en bedrijfseigenaren een gestructureerd pad van privacy-intentie naar een auditgereed operationeel model.
Als uw organisatie zich voorbereidt op ISO/IEC 27701:2025, begin dan deze week met drie acties: keur de PIMS-transitiescope in REG01 goed, vul REG02 voor uw dienst met het hoogste risico en voer de eerste REG04-screening uit. Gebruik daarna Clarysec om deze set bewijs om te zetten in een volledige GDPR-afgestemde PIMS-transitieroutekaart, gereed voor klanten, auditors, toezichthouders en het bestuur.
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


