Auditgids voor governance van gezamenlijke verwerkingsverantwoordelijken onder GDPR Article 26
Het telefoontje kwam op een dinsdagochtend. Voor de CISO van CareConnect, een snelgroeiende MedTech SaaS-aanbieder, was dit het moment waarop alles kantelde.
Aan de andere kant van de lijn zat de Head of Compliance van MetroHealth, hun belangrijkste ziekenhuispartner. Een patiënt die hun gezamenlijk beheerde platform voor monitoring op afstand gebruikte, had een maand eerder een inzageverzoek als betrokkene ingediend. Geen van beide organisaties had volledig gereageerd. Beide gingen ervan uit dat de andere partij verantwoordelijk was.
Daarna stuurde Legal een tweede bericht door. Een junior ontwikkelaar bij CareConnect had per ongeluk een niet-kritiek API-endpoint blootgesteld waarin beperkte patiëntidentificatoren stonden. Het probleem leek beheersbaar en de GDPR-termijn van 72 uur voor melding van een datalek was nog niet verstreken. Maar dezelfde vraag zette beide teams stil.
Wie informeert de toezichthoudende autoriteit? Wie communiceert met patiënten? Wie beheert de privacyverklaring? Wie valideert het verzoek van de betrokkene? Wie registreert het besluit?
De commerciële overeenkomst was uitgebreid over service credits, facturatie, aansprakelijkheidslimieten en mijlpalen in de productroadmap. Over de operationele werkelijkheid van governance van gezamenlijke verwerkingsverantwoordelijken onder GDPR Article 26 zei het contract vrijwel niets.
Hier gaat het in veel samenwerkingsverbanden mis. Het probleem is niet dat privacy-, juridische, beveiligings- en inkoopteams de term “regeling voor gezamenlijke verwerkingsverantwoordelijken” nooit hebben gehoord. Het probleem is dat niemand vóór de start van de verwerking kan aantonen wie verantwoordelijk is voor transparantie, rechtsgrondslag, rechten van betrokkenen, escalatie bij datalekken, doorlegverplichtingen richting leveranciers, doorgiften, bewaartermijnen, bewijsmateriaal en communicatie met toezichthouders.
GDPR definieert de verplichting. ISO/IEC 27701:2025 geeft privacyteams een managementsysteemstructuur. De PIMS-beleidsdocumenten van Clarysec, de Zenith Blueprint: een 30-stappenroadmap voor auditors en Zenith Controls: de cross-compliancegids vertalen Article 26 naar operationeel bewijsmateriaal dat auditgereed is.
Waarom governance van gezamenlijke verwerkingsverantwoordelijken faalt voordat iemand het merkt
Er is sprake van gezamenlijke verwerkingsverantwoordelijkheid wanneer twee of meer partijen gezamenlijk de doeleinden en middelen van de verwerking van persoonsgegevens bepalen. De trigger is niet de formulering in het contract. Het gaat om feitelijke beslissingsbevoegdheid.
In het voorbeeld van CareConnect en MetroHealth levert CareConnect het platform, de analytics, de technische architectuur, de gebruikersinterface en de gegevensstromen. MetroHealth levert de patiëntrelatie, de klinische context, het dienstverleningsmodel en de patiëntgegevens. Beide partijen beïnvloeden waarom persoonsgegevens worden verwerkt en hoe de verwerking werkt. Dat is wezenlijk anders dan een leverancier die uitsluitend een database host of berichten verstuurt op basis van gedocumenteerde instructies.
Hetzelfde patroon komt voor bij campagnes voor financiële gezondheid, embedded-insurancepartnerschappen, online marktplaatsen, consortia voor fraudedetectie, connected-healthplatforms, loyaliteitsprogramma’s, ecosystemen voor identiteitsverificatie en samenwerkingen rond analytics. Een bank, verzekeraar en SaaS-platform kunnen gezamenlijk doelgroepen, profileringsregels, conversiemetingen en marketingkanalen bepalen. Een verwerkersovereenkomst lost dat probleem niet op als de partijen in werkelijkheid gezamenlijke verwerkingsverantwoordelijken zijn.
De praktische tekortkomingen zijn voorspelbaar:
- De privacyverklaring zegt weinig meer dan “wij kunnen gegevens delen met partners.”
- De verwerkingsinventaris identificeert partijen, maar niet de verdeling van verplichtingen.
- De workflow voor rechten van betrokkenen bevat geen route voor het doorsturen, valideren of beantwoorden van verzoeken.
- Het incidentplan zegt “meld Legal”, maar niet welke gezamenlijke verwerkingsverantwoordelijke de externe communicatie leidt.
- Het contract wordt behandeld als commerciële administratie, niet als bewijsmateriaal voor verantwoordingsplicht.
- Beëindigingsbepalingen behandelen geen teruggave van gegevens, verwijdering, anonimisering, intrekking van toegang of bewaring van bewijsmateriaal.
GDPR Article 5 maakt deze tekortkomingen auditgevoelig, omdat verwerkingsverantwoordelijken niet alleen moeten voldoen aan beginselen zoals rechtmatigheid, behoorlijkheid, transparantie, doelbinding, dataminimalisatie, juistheid, opslagbeperking, integriteit, vertrouwelijkheid en verantwoordingsplicht. Zij moeten naleving ook kunnen aantonen. Article 6 voegt de eis van een rechtsgrondslag toe. Article 3 kan niet-EU SaaS-, fintech-, healthtech- en analyticsaanbieders binnen het toepassingsgebied brengen wanneer zij diensten aanbieden aan personen in de EU of hun gedrag monitoren.
De les voor CISO’s en compliancemanagers is duidelijk: governance van gezamenlijke verwerkingsverantwoordelijken is niet “alleen Legal”. Het is een multidisciplinair stelsel van beheersmaatregelen met privacy, beveiliging, inkoop, product, engineering, support, incidentrespons, marketing en toezicht door het topmanagement.
Het PIMS-principe van ISO/IEC 27701:2025: beslis vóórdat de verwerking start
Een privacy-informatiemanagementsysteem conform ISO/IEC 27701:2025 werkt alleen als privacyrollen worden vastgesteld voordat de verwerking begint. Deze operationele discipline voorkomt dat Article 26 na een incident moet worden gereconstrueerd.
Clarysec’s Privacy Information Management System Policy, clausule 4.2.2, bepaalt:
[Gezamenlijke verwerkingsverantwoordelijke] De leveranciers-/inkoopeigenaar MOET de verdeling van verantwoordelijkheden tussen gezamenlijke verwerkingsverantwoordelijken in REG08 documenteren voordat gezamenlijke verwerking begint.
De formulering “voordat gezamenlijke verwerking begint” is het controlepunt. Dit betekent: vóórdat de platformintegratie live gaat, vóórdat het gedeelde dashboard wordt ingeschakeld, vóórdat CRM-synchronisatie start, vóórdat campagnedoelgroepen worden geactiveerd en vóórdat verzoeken van betrokkenen binnenkomen.
De ondersteunende inventarisatieverplichting staat in de PII Processing Inventory and Lawful Basis Policy, clausule 4.3.5:
[Gezamenlijke verwerkingsverantwoordelijke] De leveranciers-/inkoopeigenaar MOET het verwerkingsdoel van de gezamenlijke verwerkingsverantwoordelijken en de referentie naar de verdeling van verantwoordelijkheden in REG02 en REG08 registreren voordat verwerking door gezamenlijke verwerkingsverantwoordelijken begint.
Samen creëren deze clausules de bewijsketen die auditors verwachten:
- REG02 registreert de verwerkingsactiviteit, het doel, de gegevenscategorieën, de rechtsgrondslag, bewaartermijnen, systemen, ontvangers, doorgiften en de referentie naar gezamenlijke verwerkingsverantwoordelijkheid.
- REG08 registreert de regeling voor gezamenlijke verwerkingsverantwoordelijken en de verdeling van verantwoordelijkheden.
- REG07 registreert de publiek toegankelijke transparantiesamenvatting.
- REG06 kan de intake, routering, validatie, termijnen en responsbewijsmateriaal voor verzoeken van betrokkenen registreren.
- REG10 registreert besluiten over incidenten en datalekbeoordelingen.
Deze keten maakt van Article 26 geen juridische verklaring, maar een managementsysteemproces.
Begin met scope, stakeholders en een RACI
De Zenith Blueprint begint met scope en stakeholders, omdat governance van gezamenlijke verwerkingsverantwoordelijken faalt wanneer belanghebbenden en vereisten te laat worden geïdentificeerd.
In de fase ISMS Foundation & Leadership, Step 2, Stakeholder Needs and ISMS Scope, beveelt de Zenith Blueprint een stakeholderanalyse aan die expliciete en impliciete vereisten vastlegt:
Hoe behoeften en verwachtingen te identificeren: vermeld voor elke geïdentificeerde stakeholdergroep wat zij
nodig heeft met betrekking tot informatiebeveiliging. Sommige vereisten zijn expliciet (wetten, contracten,
SLA’s), terwijl andere impliciet zijn (verwachtingen of algemeen aanvaarde goede praktijken). Het helpt om:✓ Juridische en regelgevende vereisten te beoordelen die op uw context van toepassing zijn (uit de
contextanalyse van Step 1). Maak een lijst van specifieke clausules of verplichtingen die verband houden met informatie-
beveiliging of privacy.
✓ Contracten en overeenkomsten te beoordelen: veel zakelijke contracten bevatten vertrouwelijkheids- of
beveiligingsbijlagen. Haal deze vereisten eruit.
✓ Stakeholderinterviews of workshops uit te voeren: betrek vertegenwoordigers van
elke groep (bijv. een HR-manager voor het werknemersperspectief, een salesmanager voor klant-
verwachtingen) om hun zorgen of behoeften te begrijpen.
✓ Rekening te houden met sectornormen of gedragscodes waarvan stakeholders verwachten dat u die
volgt.
Voor een aantoonbare regeling voor gezamenlijke verwerkingsverantwoordelijken onder GDPR Article 26 moet de stakeholderanalyse klanten, patiënten, gebruikers, toezichthoudende autoriteiten, de andere verwerkingsverantwoordelijke partijen, verwerkers, subverwerkers, verzekeraars, cloudproviders, interne afdelingen, toezichthouders en leidinggevende organen omvatten.
Step 4, Roles and Responsibilities in the ISMS, vertaalt die analyse vervolgens naar eigenaarschap. De Zenith Blueprint benadrukt de waarde van een RACI-model:
✓ Accountability versus Responsibility: een nuttig hulpmiddel hiervoor is een RACI-matrix (Responsible,
Accountable, Consulted, Informed). Identificeer voor elk belangrijk ISMS-proces of elke beheersmaatregel
wie Responsible is (voert het werk uit), wie Accountable is (uiteindelijk aanspreekbaar, vaak een
manager), wie Consulted is (levert input) en wie Informed is.
Voor gezamenlijke verwerkingsverantwoordelijken is de RACI in de praktijk niet optioneel. Zonder RACI gaat Legal ervan uit dat Privacy het verzoek beantwoordt, Privacy gaat ervan uit dat Support de intakewachtrij beheert, Support gaat ervan uit dat de partner zal reageren en de wettelijke termijn loopt door.
Het Clarysec-bewijsmodel voor gezamenlijke verwerkingsverantwoordelijken
Een volwassen regeling voor gezamenlijke verwerkingsverantwoordelijken moet op één pagina te begrijpen zijn en binnen tien minuten aantoonbaar zijn. Het doel is niet om teams te begraven onder juridisch papierwerk. Het doel is verantwoordelijkheden zichtbaar, geaccepteerd en testbaar te maken.
| Bewijsobject | Wat het aantoont | Locatie in de Clarysec-toolkit | Eigenaar |
|---|---|---|---|
| Registratie van rolbepaling | Waarom de partijen gezamenlijke verwerkingsverantwoordelijken zijn en geen verwerkers of afzonderlijke verwerkingsverantwoordelijken | PIMS-rolbepaling, REG08 | Privacy Lead of leveranciersverantwoordelijke |
| Verwerkingsinventarisitem | Doel, PII-categorieën, rechtsgrondslag, bewaartermijnen, systemen, ontvangers en doorgiften | REG02 | Privacy Lead of Legal |
| Verdeling van verantwoordelijkheden | Wie privacyverklaringen, rechten, coördinatie bij datalekken, bewaartermijnen, doorgiften, beveiligingscontacten en auditondersteuning afhandelt | REG08 | Leveranciers- of inkoopeigenaar |
| Publieke samenvatting | Hoe personen worden geïnformeerd over de essentie van de regeling en het contactpunt | REG07 | Privacy Lead of PIMS-manager |
| Workflow voor verzoeken van betrokkenen | Intake, validatie, routering, partnerondersteuning, verantwoordelijke voor beantwoording, termijnen en bewijsmateriaal | REG06 of DSR-register | Privacy Lead en Support |
| Registratie van coördinatie bij datalekken | Leidende melder, communicatie-eigenaar, besluitvormingslogboek, incidentclassificatie en bewijsmateriaal | REG10 | Incidentmanager en Privacy Lead |
| Contractuele bepalingen | Gegevensdeling, aansprakelijkheid, audit, vertrouwelijkheid, beveiliging, doorgiften, beëindiging en regels voor onderaannemers | Contractregister | Legal en Inkoop |
De privacybeleidsdocumenten van Clarysec versterken elke laag.
De Privacy Notice and Transparency Policy, clausule 4.1.5, bepaalt:
[Gezamenlijke verwerkingsverantwoordelijke] De Privacy Lead / PIMS-manager MOET de publiek toegankelijke samenvatting van verantwoordelijkheden van gezamenlijke verwerkingsverantwoordelijken en het contactpunt in REG07 registreren voordat verwerking door gezamenlijke verwerkingsverantwoordelijken wordt gelanceerd of wezenlijk wordt gewijzigd.
De PII Principal Rights Management Policy, clausule 6.1.5, bepaalt:
[Gezamenlijke verwerkingsverantwoordelijke] De Privacy Lead / PIMS-manager MOET verantwoordelijkheden voor de afhandeling van rechten en contactroutes documenteren in REG02, REG06 of REG08 voordat verwerking door gezamenlijke verwerkingsverantwoordelijken begint.
De PII Incident and Breach Management Policy, clausule 4.2.5, voegt toe:
[Gezamenlijke verwerkingsverantwoordelijke] De Privacy Lead / PIMS-manager MOET de overeengekomen verantwoordelijkheid voor datalekken, de leidende communicatieverantwoordelijkheid en de coördinatieregeling verifiëren vóór elke externe melding of communicatie door een gezamenlijke verwerkingsverantwoordelijke, en MOET het besluit registreren in REG08 en REG10.
Hier worden ISO/IEC 27701:2025 en GDPR operationeel. De organisatie zegt niet alleen dat verantwoordelijkheden zijn verdeeld. Zij laat zien waar ze zijn geregistreerd, wie ze heeft goedgekeurd, wanneer ze zijn getest en hoe ze worden gebruikt.
Praktijkvoorbeeld: REG08 voor een platform voor monitoring op afstand
Stel dat CareConnect en MetroHealth gezamenlijk een platform voor monitoring op afstand exploiteren. Beide bepalen waarom patiëntgegevens worden verwerkt, welke gegevens worden verzameld, hoe monitoringwaarschuwingen worden geconfigureerd, hoe analytics worden gebruikt en hoe patiënten met de dienst omgaan.
Ten eerste moet REG02 de verwerkingsactiviteit registreren:
- Naam van de verwerking: dienst voor monitoring van patiënten op afstand
- Rol verwerkingsverantwoordelijke: gezamenlijke verwerkingsverantwoordelijke
- Partijen: CareConnect en MetroHealth
- Doel: patiëntmonitoring, zorgcoördinatie, verbetering van dienstverlening, platformanalytics
- PII-categorieën: contactgegevens, accountidentificatoren, klinische observaties, apparaatgebeurtenissen, supportinteracties
- Controle op bijzondere categorieën: gezondheidsgegevens worden verwerkt en vereisen verhoogde waarborgen
- Rechtsgrondslag: per partij en doel gedocumenteerd
- Bewaartermijnen: gedefinieerd op basis van klinische, platform-, juridische en operationele vereisten
- Systemen: mobiele app, monitoringplatform, supporttool, analyticswarehouse, identiteitsprovider
- Ontvangers: gezamenlijke verwerkingsverantwoordelijke partijen, hostingprovider, supportleveranciers, notificatieproviders
- Doorgiften: toegang op afstand en verwerking buiten de EER beoordeeld
- REG08-referentie: JC-2026-004
Ten tweede moet REG08 verantwoordelijkheid verdelen op een manier die operationele teams kunnen volgen.
| Verantwoordelijkheidsgebied | CareConnect | MetroHealth | Bewijsmateriaal |
|---|---|---|---|
| Opstellen privacyverklaring | Levert technische verwerkingsdetails | Leidt patiëntgerichte formulering en publicatie | REG07-registratie van privacyverklaring |
| Registratie rechtsgrondslag | Documenteert de grondslag voor platformanalytics | Documenteert de grondslag voor zorgverlening en patiëntrelatie | REG02-item voor rechtsgrondslag |
| Inzageverzoeken van betrokkenen | Levert platformgegevensexporten binnen overeengekomen SLA | Leidt intake, validatie, identiteitscontroles en respons | REG06-workflow |
| Verzoeken tot rectificatie en verwijdering | Voert goedgekeurde wijzigingen uit in platformsystemen | Bepaalt afhandeling van klinische dossiers en patiëntcommunicatie | DSR-bewijslogboek |
| Datalekbeoordeling | Detecteert, damt in en classificeert platformincidenten | Beoordeelt patiëntimpact en communicatie met toezichthouders | REG10-datalekregistratie |
| Externe melding | Leidt bij platformgerelateerde incidenten waar overeengekomen | Leidt patiënt- en autoriteitscontact waar overeengekomen | REG08 en incidentdraaiboek |
| Beveiligingswaarborgen | Onderhoudt platformbeheersmaatregelen, logging, toegang en cloudbeveiliging | Onderhoudt toegang en operationele beheersmaatregelen aan ziekenhuiszijde | SoA en bewijsmateriaal voor beheersmaatregelen |
| Verwerkersbeheer | Beheert cloud- en SaaS-subverwerkers | Beheert ziekenhuisverwerkers en downstreamontvangers | Leveranciersregister |
| Bewaring en verwijdering | Verwijdert of anonimiseert platformregistraties volgens schema | Bevestigt klinische bewaartermijnen en downstreamverwijderingsregels | Bewaartermijnenregister |
| Auditbewijsmateriaal | Levert logboeken, beleid, testresultaten en attesten | Levert governancegoedkeuringen en registraties van verzoeken van betrokkenen | Tracker voor auditverzoeken |
Ten derde moet REG07 de publiek toegankelijke samenvatting registreren. De privacyverklaring moet de essentie van de gezamenlijke regeling in duidelijke taal uitleggen, de gezamenlijke verwerkingsverantwoordelijken identificeren, beschrijven waarvoor elke partij verantwoordelijk is en een bruikbaar contactpunt bieden. Patiënten of gebruikers mogen niet worden gedwongen interne operationele complexiteit te ontcijferen.
Ten vierde: test de workflow vóór livegang. Stuur een gesimuleerd inzageverzoek naar het gepubliceerde contactpunt. Bevestig dat Support het als een verzoek van een betrokkene herkent, het naar Privacy routeert, REG08 controleert, partnerinput opvraagt, acties in REG06 registreert en een responspakket produceert. Voer daarna een tabletop-oefening voor datalekken uit met een scenario zoals “API-endpoint stelt patiëntidentificatoren bloot aan ongeautoriseerde gebruikers” of “gebruikers waarvoor verwijdering is onderdrukt, worden per ongeluk opgenomen in een engagementcampagne.”
Deze tests brengen de echte hiaten aan het licht: onbeheerde mailboxen, onduidelijke partner-SLA’s, niet-goedgekeurde tekst voor privacyverklaringen, onvolledige registraties van rechtsgrondslagen, ontbrekende controles op bijzondere categorieën en incidentdraaiboeken waarin de verantwoordelijke voor externe communicatie niet is benoemd.
Map Article 26 via Zenith Controls naar ISO/IEC 27002:2022-beheersmaatregelen
Een regeling voor gezamenlijke verwerkingsverantwoordelijken is niet alleen een juridisch artefact. Zij moet worden ondersteund door technische en organisatorische beheersmaatregelen. Zenith Controls helpt teams de verwachtingen voor beheersmaatregelen uit ISO/IEC 27001:2022 en ISO/IEC 27002:2022 te mappen naar privacy-, leveranciers-, incident-, cloud- en governancebewijsmateriaal.
Drie ISO/IEC 27002:2022-beheersmaatregelen zijn bijzonder relevant.
Beheersmaatregel 5.2, Information Security Roles and Responsibilities, ondersteunt het operationele model. Deze sluit aan op ISO/IEC 27001:2022 Clause 5.3, Organizational roles, responsibilities and authorities. De beheersmaatregel ondersteunt ook incidentgereedheid, omdat onduidelijke rollen ISO/IEC 27002:2022 Control 5.24, Information Security Incident Management Planning and Preparation, ondermijnen. Binnen governance van gezamenlijke verwerkingsverantwoordelijken is Control 5.2 de plaats waar de RACI, REG08-eigenaren, DSR-afhandelaars, datalekleads en escalatiecontacten auditbewijsmateriaal worden.
Beheersmaatregel 5.31, Legal, Statutory, Regulatory and Contractual Requirements, is waar GDPR Article 26 onderdeel wordt van het ISMS in plaats van een uitsluitend juridische kwestie. Deze ondersteunt de identificatie en het beheer van verantwoordingsplicht onder GDPR Article 5, rechtsgrondslag onder Article 6, verdeling van verantwoordelijkheden onder Article 26, beveiliging onder Article 32, melding aan de toezichthoudende autoriteit onder Article 33 en communicatie aan getroffen personen onder Article 34. De beheersmaatregel sluit ook aan op ISO/IEC 27001:2022 Clause 4.2, het begrijpen van de behoeften en verwachtingen van belanghebbenden, en Clause 6.1.3, behandeling van informatiebeveiligingsrisico’s.
Beheersmaatregel 5.34, Privacy and Protection of PII, brengt bescherming van PII in het operationele beveiligingsmodel. Dit is vooral belangrijk wanneer de regeling gebruikmaakt van cloudanalytics, gedeelde dashboards, data clean rooms, monitoringplatforms, marketingautomatisering of supporttooling. Gerelateerde waarborgen kunnen ISO/IEC 27002:2022 Control 5.23, Information Security for Use of Cloud Services, en Control 8.11, Data Masking, omvatten.
Het ondersteunende ISO-ecosysteem is eveneens relevant. ISO/IEC 27018 helpt waar publieke clouddiensten PII verwerken. ISO/IEC 29100 biedt privacybeginselen zoals transparantie, toestemming, gerechtvaardigd doel, beperking van gegevensverzameling, dataminimalisatie, gebruiksbeperking, juistheid, beveiligingswaarborgen en verantwoordingsplicht. ISO/IEC 27001:2022 levert de managementsysteemruggengraat via context, belanghebbenden, scope, leiderschap, risicobeoordeling, risicobehandeling, Verklaring van Toepasselijkheid, interne audit, directiebeoordeling en voortdurende verbetering.
Contracten moeten aansluiten op het operationele model
Een regeling voor gezamenlijke verwerkingsverantwoordelijken kan niet alleen in een privacyverklaring bestaan. Zij moet terugkomen in contracten, bijlagen, operationele procedures, incidentdraaiboeken, escalatieroutes en beëindigingsbepalingen.
Clarysec’s Legal and Regulatory Compliance Policy, clausule 5.3.1.2, brengt contracttypen expliciet onder governance, waaronder:
Contracten met betrekking tot gegevensdeling, intellectuele-eigendomsrechten, aansprakelijkheidsbeperkingen of auditclausules
De Data Protection and Privacy Policy, clausule 5.1, legt de ondernemingsbrede basis:
De organisatie MOET een formeel privacygovernancekader onderhouden dat is geïntegreerd in het Informatiebeveiligingsmanagementsysteem (ISMS) om dit beleid af te dwingen.
Voor mkb-organisaties wordt hetzelfde principe opgeschaald naar de operationele werkelijkheid. De Data Protection and Privacy Policy-sme - SME, clausule 5.2.1, bepaalt:
De privacycoördinator MOET een register bijhouden van alle verwerkingsactiviteiten met persoonsgegevens, inclusief gegevenscategorieën, doel, rechtsgrondslag en bewaartermijnen.
Clausule 5.2.2 voegt toe:
Contracten met derde partijen die persoonsgegevens verwerken, MOETEN gegevensbeschermingsclausules bevatten en MOETEN worden beoordeeld door de algemeen directeur of juridisch adviseur.
Dit is proportionele governance. Een multinational kan afzonderlijke juridische, privacy-, inkoop-, beveiligings-, risico- en complianceteams hebben. Een mkb-organisatie kan steunen op een privacycoördinator, algemeen directeur en externe juridisch adviseur. De verwachting ten aanzien van bewijsmateriaal blijft gelijk: verwerkingsactiviteiten, verantwoordelijkheden, rechtsgrondslag, privacyverklaringen, afhandeling van verzoeken van betrokkenen, escalatie van incidenten en beëindigingsverplichtingen moeten gedocumenteerd en toetsbaar zijn.
De Zenith Blueprint, Step 23, Organizational controls, ondersteunt discipline in leveranciersovereenkomsten via vertrouwelijkheid, verantwoordelijkheden voor toegangscontrole, technische en organisatorische maatregelen, meldtermijnen voor incidenten, auditrechten, beheersmaatregelen voor onderaannemers en bepalingen voor het einde van het contract. In relaties tussen gezamenlijke verwerkingsverantwoordelijken moeten deze clausules worden aangepast aan gegevensdeling en verdeling van verantwoordelijkheden, in plaats van te worden gekopieerd uit een verwerkerssjabloon.
Governance voor incidenten en datalekken: bepaal de lead vóór het datalek
Datalekken bij gezamenlijke verwerkingsverantwoordelijken worden chaotisch wanneer teams wachten tot het incident om te bepalen wie extern communiceert.
GDPR definieert een inbreuk in verband met persoonsgegevens als een inbreuk op de beveiliging die leidt tot toevallige of onrechtmatige vernietiging, verlies, wijziging, ongeoorloofde verstrekking van of ongeoorloofde toegang tot persoonsgegevens. Waar vereist moet melding aan de toezichthoudende autoriteit zonder onredelijke vertraging plaatsvinden en, indien mogelijk, binnen 72 uur nadat kennis is genomen van het datalek. NIS2 en DORA kunnen aanvullende verwachtingen toevoegen voor melding van cyberincidenten en communicatie met klanten.
Clarysec’s Incident Response Policy-sme - SME, clausule 5.3.2, legt de termijndiscipline vast:
Responstermijnen, inclusief gegevensherstel en meldingsverplichtingen, MOETEN worden gedocumenteerd en afgestemd op wettelijke vereisten, zoals de GDPR-meldplicht van 72 uur voor inbreuken in verband met persoonsgegevens.
De Zenith Blueprint, Step 5, Communication, Awareness, and Competence, benadrukt planning van externe communicatie, onder meer met klanten, toezichthouders, partners en het publiek. Voor gezamenlijke verwerkingsverantwoordelijken moet de incidentmatrix vastleggen wie de initiële classificatie van het datalek uitvoert, wie contact opneemt met de andere verwerkingsverantwoordelijke, wie bepaalt of PII is geraakt, wie meldingsdrempels beoordeelt, wie meldingen aan autoriteiten opstelt, wie met personen communiceert, wie NIS2- of DORA-rapportage coördineert, wie publieke verklaringen goedkeurt en wie bewijsmateriaal in REG10 registreert.
Als de regeling een financiële entiteit onder DORA omvat, moet het incidentproces ook classificatie van ernstige ICT-gerelateerde incidenten, escalatie naar het hoger management, tussentijdse updates, eindrapportage en klantcommunicatie ondersteunen wanneer financiële belangen worden geraakt. Als de organisatie binnen het toepassingsgebied van NIS2 valt, kan rapportage van significante incidenten gefaseerde melding en communicatie met dienstontvangers vereisen.
De veiligste praktijk is een gezamenlijke tabletop-oefening vóór livegang. Een goed scenario dwingt teams om REG08, REG10, het incidentdraaiboek, partnercontacten, meldingssjablonen, escalatiebomen en bewijslogboeken onder tijdsdruk te gebruiken.
Cross-compliance: Article 26 staat zelden op zichzelf
Regelingen voor gezamenlijke verwerkingsverantwoordelijken bevinden zich vaak binnen bredere gereguleerde ecosystemen. Een fintechcampagne, connected-healthplatform, managedservicerelatie, integratie met een cloudmarktplaats of partnerschap voor digitale infrastructuur kan verplichtingen activeren die verder gaan dan GDPR.
NIS2 kan van toepassing zijn op middelgrote en grote essentiële of belangrijke entiteiten in sectoren zoals digitale infrastructuur, cloudcomputing, datacenters, managed service providers, managed security service providers, online marktplaatsen, zoekmachines en sociale netwerkplatforms. NIS2 Article 20 legt toezicht op cybersecurityrisicobeheer bij leidinggevende organen. Article 21 vereist technische, operationele en organisatorische maatregelen, waaronder risicoanalyse, incidentenafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige ontwikkeling, afhandeling van kwetsbaarheden, training, encryptie, HR-beveiliging, toegangscontrole, beheer van bedrijfsmiddelen en authenticatie. Article 23 introduceert gefaseerde rapportage voor significante incidenten.
DORA is vanaf 17 januari 2025 van toepassing op veel financiële entiteiten. DORA omvat ICT-risicobeheer, rapportage van ernstige ICT-gerelateerde incidenten, testen van digitale operationele weerbaarheid, ICT-risico’s van derde partijen, contractuele regelingen met ICT-aanbieders en toezicht op kritieke ICT-dienstverleners van derde partijen. DORA Article 5 legt ICT-risicogovernance op het niveau van het leidinggevend orgaan. Articles 8 to 14 behandelen identificatie van bedrijfsmiddelen, bescherming, detectie, continuïteit, back-up, herstel, geleerde lessen, training en crisiscommunicatie. Articles 17 to 20 definiëren incidentlevenscyclus en rapportage. Articles 28 to 30 maken ICT-risico’s van derde partijen, contractvoorwaarden, registers, concentratierisico, auditrechten en exitplanning tot centrale verplichtingen.
NIST CSF 2.0 biedt een praktische integratielaag. De GOVERN Function omvat juridische, regelgevende, contractuele, privacy- en burgerrechtenverplichtingen, verantwoordingsplicht van leiderschap, risicobereidheid, beleid, toezicht en leveranciersrisico. Uitkomsten zoals GV.OC-03 en GV.SC-02 sluiten natuurlijk aan op bewijsmateriaal voor Article 26, omdat zij vereisen dat wettelijke verplichtingen en partnerrollen worden begrepen, beheerd, gecommuniceerd en gecoördineerd.
| Nalevingslens | Wat deze vraagt in een regeling voor gezamenlijke verwerkingsverantwoordelijken | Clarysec-bewijsmateriaal |
|---|---|---|
| GDPR | Wie doeleinden en middelen bepaalt, hoe verantwoordelijkheden zijn verdeeld, hoe personen worden geïnformeerd en hoe rechten en datalekken worden afgehandeld | REG02, REG07, REG08, REG10, DSR-logboeken |
| ISO/IEC 27701:2025 PIMS | Of privacyrollen, verwerkingsregistraties, rechtsgrondslag, transparantie, workflows voor verzoeken van betrokkenen, incidentenafhandeling en bewijsmateriaal voor verantwoordingsplicht systematisch worden beheerd | PIMS-beleid, registers, bewijsmateriaal van directiebeoordeling |
| ISO/IEC 27001:2022 | Of juridische vereisten, privacyverplichtingen, leveranciersafhankelijkheden, cloudgebruik, incidentrollen en risicobehandeling binnen het ISMS vallen | Scope, register van belanghebbenden, risicoregister, SoA, Annex A-bewijsmateriaal |
| NIS2 | Of governance, incidentenafhandeling, toeleveringsketen, toegangscontrole, continuïteit, training en rapportage zijn geïntegreerd | Incidentplan, leveranciersregister, trainingsregistraties, continuïteitstests |
| DORA | Of ICT-risico’s van derde partijen, incidentrapportage, weerbaarheidstesten, gegevensbescherming en contractuele beheersmaatregelen voor financiële dienstverlening worden beheerst | ICT-register, contractuele bepalingen, incidentclassificatie, exitplannen |
| NIST CSF 2.0 | Of huidige en beoogde governance-uitkomsten, leveranciersrisico, incidentrespons en herstel zijn gedefinieerd en meetbaar zijn | CSF-profiel, hiaatplan, POA&M, risicoregister |
| COBIT 2019 | Of governancedoelstellingen, verantwoordingsplicht, prestatiemeting en assurancebewijsmateriaal traceerbaar zijn naar ondernemingsdoelen | RACI, control metrics, managementrapportage, auditbewijspakket |
Het voordeel van het Clarysec-model is hergebruik van bewijsmateriaal. REG08 is niet alleen een GDPR-registratie. Het ondersteunt verantwoordingsplicht onder ISO/IEC 27701:2025, governance onder ISO/IEC 27001:2022, duidelijkheid over leveranciersrollen binnen NIST CSF 2.0, governance van derde partijen onder DORA waar financiële dienstverlening betrokken is en toezicht door het management onder NIS2 waar de entiteit binnen het toepassingsgebied valt.
Wat auditors en toezichthouders zullen toetsen
Verschillende beoordelaars benaderen governance van gezamenlijke verwerkingsverantwoordelijken vanuit verschillende invalshoeken, maar zij komen uit bij dezelfde kernvraag: kan de organisatie aantonen dat verantwoordingsplicht werkt?
| Auditorlens | Waarschijnlijke auditvraag | Bewijsmateriaal dat gereed moet zijn |
|---|---|---|
| ISO/IEC 27001:2022-auditor | Zijn juridische, regelgevende, contractuele, privacy-, leveranciers-, incident- en cloudvereisten geïdentificeerd en opgenomen in ISMS-scope en risicobehandeling? | Scope, register van belanghebbenden, nalevingsregister, risicobeoordeling, SoA, leveranciersbeheersmaatregelen |
| ISO/IEC 27701:2025 PIMS-auditor | Zijn PIMS-rollen vastgesteld en zijn verantwoordelijkheden van gezamenlijke verwerkingsverantwoordelijken gedocumenteerd voordat de verwerking begint? | REG02, REG07, REG08, workflow voor verzoeken van betrokkenen, datalekregistraties, directiebeoordeling |
| GDPR-gerichte auditor of DPO-beoordelaar | Kan de organisatie verantwoordingsplicht onder Article 5 en verdeling van verantwoordelijkheden onder Article 26 aantonen? | Regeling voor gezamenlijke verwerkingsverantwoordelijken, samenvatting van de privacyverklaring, registraties van rechtsgrondslagen, DSR-logboeken, besluitvormingslogboeken voor datalekken |
| NIST CSF 2.0-assessor | Zijn privacy-, juridische, leveranciers-, incident- en hersteluitkomsten opgenomen in Current Profiles en Target Profiles met een herstelplan? | CSF-profiel, hiaatanalyse, risicoregister, POA&M, leveranciersmonitoring |
| DORA-beoordelaar | Worden ICT-afhankelijkheden van derde partijen, incidentrapportage, weerbaarheid, contractuele rechten en exitplannen beheerst waar financiële dienstverlening betrokken is? | ICT-contractregister, incidentclassificatie, weerbaarheidstests, auditrechten, exitstrategie |
| NIS2-toezichthouder | Heeft het management risicomaatregelen, leveranciersbeveiliging, incidentenafhandeling, continuïteit, toegangscontroles en training goedgekeurd en bewaakt? | Bestuursnotulen, beleid, incidentplan, continuïteitstests, trainingsregistraties, leveranciersrisicobeoordelingen |
| COBIT 2019- of ISACA-auditor | Is verantwoordingsplicht toegewezen, gemonitord, gemeten en gerapporteerd via governancestructuren? | RACI, KPI’s, toetsing van beheersmaatregelen, managementrapportage, herstel van issues |
De sterkste auditpositie is traceerbaarheid. Begin met de wettelijke eis, koppel die aan het PIMS-beleid, verwijs naar het registeritem, toon de workflow en toon vervolgens testbewijsmateriaal of een echte casusregistratie.
GDPR Article 26 vereist bijvoorbeeld verdeling van verantwoordelijkheden tussen gezamenlijke verwerkingsverantwoordelijken. De Privacy Information Management System Policy vereist REG08 voordat de verwerking begint. REG08 toont de verdeling van verantwoordelijkheden voor privacyverklaringen, rechten, datalekken, bewaartermijnen, leveranciersmanagement en contactpunten. REG07 toont de publiek toegankelijke samenvatting. Een DSR-simulatie bewijst dat de workflow werkt. Notulen van de directiebeoordeling tonen uitzonderingen, besluiten en verbeteringen.
Dat is aantoonbare governance.
Directiebeoordeling vertaalt privacyrisico naar verantwoordingsplicht van het management
Governance van gezamenlijke verwerkingsverantwoordelijken hoort niet verborgen te zitten in een privacymap. Zij hoort thuis in de directiebeoordeling, omdat zij gevolgen heeft voor blootstelling aan regelgeving, klantvertrouwen, patiëntvertrouwen, incidentgereedheid, leveranciersrisico, contractuele aansprakelijkheid en operationele weerbaarheid.
ISO/IEC 27001:2022 vereist betrokkenheid van leiderschap, rollen, middelen, beleidsafstemming, risicogebaseerde planning, prestatie-evaluatie en voortdurende verbetering. NIS2 legt verplichtingen voor toezicht op cyberbeveiliging bij leidinggevende organen. DORA legt de uiteindelijke verantwoordelijkheid voor ICT-risico bij het leidinggevend orgaan van financiële entiteiten.
Clarysec’s Governance Roles and Responsibilities Policy-sme - SME, clausule 5.5, bepaalt:
Alle significante beveiligingsbesluiten, uitzonderingen en escalaties MOETEN worden geregistreerd en traceerbaar zijn.
Voor ondernemingen vereist de Governance Roles and Responsibilities Policy, clausule 5.2:
Een rollen- en verantwoordelijkhedenregister MOET worden onderhouden en MOET het volgende bevatten:
Dat register moet privacygovernancerollen omvatten waar deze impact hebben op beveiliging, incidentrespons, leveranciersassurance, operationele weerbaarheid en rapportage aan het management. Uitzonderingen rond gezamenlijke verwerkingsverantwoordelijkheid moeten vóór livegang worden geëscaleerd, niet pas na een klacht worden ontdekt.
Een praktisch pakket voor de directiebeoordeling moet bevatten:
- Nieuwe en gewijzigde regelingen voor gezamenlijke verwerkingsverantwoordelijken
- Voltooiingsstatus van REG08
- Verwerkingsactiviteiten met hoog risico en DPIA-status waar van toepassing
- Openstaande kwesties rond rechtsgrondslag of transparantie
- DSR-prestaties en achterstallige partneracties
- Resultaten van tabletop-oefeningen voor datalekken en onopgeloste hiaten
- Afhankelijkheden van leveranciers, subverwerkers, cloud en doorgiften
- Uitzonderingen op bewaartermijnen en beëindiging
- Auditbevindingen en herstelstatus
- Rapportage-impact voor GDPR, NIS2, DORA, NIST CSF 2.0 en COBIT 2019
Een Clarysec-aanpak in vijf stappen om Article 26 aantoonbaar te maken
Als uw organisatie beslissingsbevoegdheid over PII-verwerking deelt met een andere partij, wacht dan niet op een klacht, audit, datalek of partnergeschil om verantwoordelijkheden te verduidelijken.
Gebruik deze aanpak in vijf stappen:
- Gebruik Zenith Blueprint Step 2 om stakeholders, wettelijke vereisten, partnerverwachtingen, privacyverplichtingen en regelgevend toepassingsgebied te identificeren.
- Gebruik Zenith Blueprint Step 4 om een RACI op te stellen voor privacyverklaringen, rechtsgrondslag, rechten, communicatie bij datalekken, bewaartermijnen, doorgiften, leveranciers, auditbewijsmateriaal en beëindiging.
- Registreer de verwerkingsactiviteit in REG02 en de verdeling van verantwoordelijkheden tussen gezamenlijke verwerkingsverantwoordelijken in REG08 met de PIMS-beleidsset van Clarysec.
- Map de regeling via Zenith Controls, met name ISO/IEC 27002:2022 Control 5.2, Control 5.31 en Control 5.34.
- Test de regeling met een DSR-simulatie en een tabletop-oefening voor datalekken voordat de verwerking begint.
CareConnect en MetroHealth hadden geen behoefte aan meer informele afstemming. Zij hadden een gedocumenteerde verdeling van verantwoordelijkheden nodig, een publiek toegankelijke samenvatting, een workflow voor verzoeken van betrokkenen, een registratie voor coördinatie bij datalekken, contractuele bepalingen en bewijsmateriaal uit de directiebeoordeling.
Dat is het verschil tussen “wij dachten dat de partner dit afhandelde” en “hier is de goedgekeurde regeling, privacyverklaring, workflow, testbewijs en registratie van het datalekbesluit.”
Clarysec kan u helpen ISO/IEC 27701:2025 PIMS-governance te implementeren, deze af te stemmen op GDPR Article 26, te integreren in uw ISO/IEC 27001:2022 ISMS en auditgereed bewijsmateriaal te produceren voor verwachtingen rond GDPR, NIS2, DORA, NIST CSF 2.0 en COBIT 2019.
Klaar om ambiguïteit rond gezamenlijke verwerkingsverantwoordelijkheid te vervangen door auditgereed bewijsmateriaal? Bekijk de Zenith Blueprint: een 30-stappenroadmap voor auditors, gebruik Zenith Controls: de cross-compliancegids of neem contact op met Clarysec voor een PIMS- en ISMS-beoordeling die Article 26 omzet in een operationeel stelsel van beheersmaatregelen voordat uw volgende partnerschap live gaat.
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
