Algemene inleiding - Logboek dataverwerkingen

Samenvatting

De overheid wil voor burgers en bedrijven zo transparant mogelijk zijn in de omgang met hun gegevens. Daarom is het bij de informatieverwerking in datasets belangrijk om voor elke mutatie of raadpleging vast te leggen wie deze actie wanneer uitvoert, en waarom. Deze herleidbaarheid speelt zowel een rol in het kader van de wetgeving op het gebied van privacy als ook het streven naar openheid en transparantie bij de overheid. Voor een optimale samenwerking over organisaties en bronnen heen is voor deze logging een algemene standaard nodig.

Het project Logboek Dataverwerkingen (voorheen: Verwerkingenlogging) maakt deel uit van het actieplan Data bij de Bron en onderzoekt met Digilab in samenwerking met diverse overheidspartijen (ministeries, uitvoeringsorganisaties en gemeentes) of we op basis van de tot nu toe opgedane inzichten een overheidsbrede standaard kunnen vaststellen. Na het succesvol beproeven van de standaard wordt deze voorgesteld voor opname in de ‘Pas toe of leg uit’-lijst van het Forum voor Standaardisatie.

bron: https://digilab.overheid.nl/projecten/logboek-dataverwerkingen/

De Logboek Dataverwerkingen (LDV) standaard bestaat uit de volgende vier documenten:

Beschrijving van het document	Gepubliceerde versie	Werk versie	Repository
1. De LDV Normatieve Standaard	-	Logboek dataverwerkingen (werkversie)	logboek-dataverwerkingen
2. De Algemene Inleiding	-	De Algemene Inleiding (werkversie)	logboek-dataverwerkingen_Inleiding
3. het Juridische Beleidskader	-	Juridisch Beleidskader (werkversie)	logboek-dataverwerkingen_Juridisch-beleidskader
4. LDV Extensie voor objecten	-	Onderzoek logboek dataverwerkingen voor (geo) objecten	logboek-dataverwerkingen-voor-objecten

De standaard Logboek dataverwerkingen levert geen kant-en-klare softwareoplossing. Wel biedt de standaard richtlijnen waar het Logboek dataverwerkingen van een applicatie aan moet voldoen. Dit document geeft aan hoe de standaard zich verhoudt tot de Architectuur Digitale Overheid 2030 en de Domeinarchitectuur Gegevensuitwisseling

Diensten en producten
- De standaard Logboek dataverwerkingen is als product voornamelijk gericht op het verantwoorden van gegevensverwerkingen door overheden in het kader van hun taken (Regie op Gegevens en de Transparante Overheid). Dit betekent dat het gebruik van deze standaard door overheidsorganisaties de informatiepositie van burgers en bedrijven ten opzichte van de overheid sterk verbetert zodat zij meer grip op en inzicht in hun persoonsgebonden gegevens hebben (inzicht in gegevens over jezelf). Daarnaast draagt deze standaard aan bij Verantwoord datagebruik en ruimer meervoudig gebruik gegevens. Implementatie van deze standaard draagt bij aan de verantwoording over, en het doelmatig gebruik van data.
Kanalen
- Het Logboek dataverwerkingen is een service behorend bij een applicatie die specifieke data verwerkt waarover uiteindelijk verantwoording moet kunnen worden afgelegd (bijvoorbeeld persoonsgegevens of data over geografische objecten). De standaard geeft geen richtlijnen ten aanzien de ontsluiting van deze logdata richting belanghebbenden, wel geeft het een richting ten aanzien van de inrichting en het gedrag van het Logboek dataverwerkingen.
Organisatie
- De Overheid bestaat uit vele (semi)autonome organisaties. Door gezamenlijke afspraken te maken ten aanzien van logging van verwerkte data, ondersteunt de standaard het doel om naar de burger toe als één organisatie te kunnen verantwoorden.
Processen
- Voor het verwerken van data zijn vaak ook data nodig van andere (overheids)organisaties. De implementatie van de standaard Logboek dataverwerkingen zorgt er voor dat loggings tracing-metadata bevat zodat altijd kan worden nagegaan wat de bron van specifieke data was. De standaard ondersteunt hiermee het uitgangspunt dat (overheids)organisaties zorgen voor onderlinge samenhang van data.
Bedrijfsfuncties
- Overheidsfuncties moeten eenduidig een helder belegd zijn, het moet helder zijn welke (overheids)organisaties verantwoordelijk zijn voor het leveren van product of dienst. Door het gebruiken van de standaard Logboek datalogverwerkingen door alle dataverwerkende (overheids)organisaties op een soortgelijke manier wordt het duidelijk welke data gebruikt zijn en door wie.

Api’s / Services
- Naast richtlijnen voor de inrichting en het gedrag van het Logboek dataverwerkingen, biedt deze standaard ook een aantal voorbeeld API’s:
- Inzicht API: deze service geeft de mogelijkheid een query uit te voeren op loggings van dataverwerkingen (nog niet beschikbaar).
- Register van de Verwerkingsactiviteiten: deze service geeft de mogelijkheid de gegevens van een Register van Verwerkingsactiviteiten te bekijken (nog niet beschikbaar).

De API’s zijn ontworpen en ontwikkeld volgens de standaard Rest-API Design Rules.

Applicaties
- De standaard biedt geen applicatie aan, wel biedt het richtlijnen ten aanzien van het gedrag en invulling van het Logboek dataverwerkingen. Hiermee geeft de standaard de vrijheid aan organisaties om zelf op basis van de specifieke implementatie van een dataverwerkende Applicatie een Logboek te ontwikkelen wat qua gedrag en (meta)data gelijkvormig is over alle (overheids)organisaties heen.
Berichtenverkeer / gegevensuitwisseling
- Het berichten verkeer met betrekking tot het Logboek dataverwerkingen heeft geen directe connectie met de burger. Wel is het van belang bij opvraag van gegevens bij andere organisaties traceringsdata worden verstuurd en opgeslagen in het Logboek zodat altijd duidelijk wat de bron is van data die verwerkt zijn. Deze standaard biedt een traceringsmethodiek aan zodat de gegevensuitwisseling tussen organisaties soepel en geautomatiseerd kan verlopen.
Data / gegevens
- De Nederlandse Basisregistraties vervullen een essentiële rol in het vastleggen en gecontroleerd beheren van data. Organisaties kunnen aan elkaar data ter beschikking te stellen vanuit ‘kernregistraties’. Deze data staan gedefinieerd in het Federatief Datastelsel. De standaard Logboek dataverwerkingen biedt een richtlijn voor het loggen van verwerkte data van al deze basisregistraties.

Onderstaande stelselplaat geeft een globaal overzicht van de bronhouders, de aanbieders en afnemers van data.

Architectuur Digitale Overheid 2030

[bron: Architectuur Digitale Overheid 2030]

Een belangrijk kader voor de standaard Logboek dataverwerkingen is de uitwerking van het GDI meerjarenvisie op basis van de Architectuur Digitale Overheid 2030 met als specifiek onderwerp Gegevensuitwisseling. De standaard Logboek dataverwerking kan gepositioneerd worden in de GDI Gegevensuitwisseling als standaard waarin een 'Uitwisselingsafspraak' geformaliseerd wordt. Waarbij de daadwerkelijke logging betrekking heeft op de 'Operatie' in de modelplaat ‘GDI-Gegevensuitwisseling’.

Bedrijfsobjectenmodel

[Bron: GDI – Gegevensuitwisseling]

Onderstaand figuur geeft een overzicht van de architectuurprincipes uit het GDI meerjarenvisie en hun relatie met de belangrijkste functie voor data en gegevensuitwisseling.

architectuurprincipes

[Bron: MIDO/GDI Domeinarchitectuur Gegevensuitwisseling]

De relatie en invulling van de standaard Logboek dataverwerkingen staat uitgewerkt in de volgenda paragraaf.

De standaard Logboek dataverwerkingen kan ook worden toegepast in een middleware- of cloud-omgeving. Het netwerkcomponent logt binnenkomende en uitgaande berichten.

technische architectuur

Ook voor mobiele Apps en IoT (Internet of Things) geldt dat het netwerkcomponent de gegevensberichten logt.

Hoofdstuk 2.2 Componenten geeft een globaal overzicht van de benodigde softwarecomponenten om de standaard te implementeren.

De standaard Logboek dataverwerkingen gaat er vanuit dat de het Logboekcomponent op een beveiligd platform in een beveiligd datacenter is geïnstalleerd.

Informatiebeveiliging
- De standaard Logboek dataverwerkingen gaat er vanuit dat zowel het Logboekcomponent als de gegevens in het Logboek beveiligd zijn volgens de BIO (=Baseline Informatiebeveiliging Overheid) – zie ook zie Beleidskader 8.9.
Beheer en exploitatie
- Logius verzorgt het beheer en onderhoud van deze standaard volgens het BOMOS-model.

Architectuurprincipe	Relatie met de standaard
1.1. Gegevens die kunnen worden gedeeld zijn vindbaar, toegankelijk, interoperabel en herbruikbaar	- Logregels zijn voorzien van metagegevens ten aanzien van tracering zodat gerelateerde Logeregels altijd gevonden kunnen worden. - Identificatoren worden aangemaakt zodat deze over de gehele wereld uniek zijn. - Het processingActivityId is gerelateerd aan het Register van Verwerkingsactiviteiten zodat per Logregel altijd verwezen kan worden naar een activiteit van een (overheids)organisatie en daarmee de context direct duidelijk wordt.
1.2. Gegevensuitwisseling is gebaseerd op open standaarden	- API’s gerelateerd aan deze standaard moeten worden ontworpen en gebouwd volgens de standaarden REST-API Design Rules, OpenAPI en DigiKoppeling. - Het metadatamodel van deze standaard is gebaseerd op OpenTelemetry. Dit is een internationale standaard voor het genereren, verzamelen en exporteren van telemetrie gegevens (metrieken, logging en tracering).
1.3 De kwaliteit van gegevens is afgestemd op het gebruik	- Door de registratie van verwerkte data in een Logboek kan er op een later moment inzicht gegeven worden aan andere (overheids)organisaties en burgers. Eventuele foutieve data komen dan direct aan het licht en kunnen hersteld worden.
1.4. Gegevensdiensten zijn afgestemd op de behoeften van afnemers	- Gegevens die gelogd worden bij een gegevensverwerking zijn afgestemd op het doel waarvoor er gelogd moet worden (bijvoorbeeld de gegevens die gevraagd worden op basis van de AVG-wetgeving). Er wordt niet minder opgeslagen, meer zeker niet meer dan nodig is. - Het ontwerp van het gegevensmodel van deze standaard is gebaseerd op OpenTelemetry, vertaling van gegevens is dus niet nodig.
1.5. De bron van de gegevens is leidend	- Overheidsapplicaties moeten rekening houden met de onderhoud van data bij de bron. Dit betekent dat gegevens niet zonder meer gekopieerd opgeslagen mogen worden. Bij sommige dataverwerkingen zijn data nodig van andere databronnen (in de eigen organisatie of bij een andere organisatie). De standaard Logboek Dataverwerkingen schrijft een traceringsmechanisme voor zodat kopiëren van specifieke data naar het Logboek niet nodig is, er kan altijd nagegaan worden waar data vandaan kwamen en welke data er gebruikt werden. - De standaard verwijst zo veel mogelijk naar bestaande databronnen elders in plaats van de data te dupliceren (zie besluit 4.2 en 4.4)
1.6. Burgers en organisaties hebben regie over hun eigen gegevens	- Burgers, (overheids)organisaties en parlement hebben recht om inzicht te krijgen in verwerkte data. Door toepassing van deze standaard kan er een rapportage gemaakt worden die voldoet aan die informatiebehoefte. - De standaard Logboek dataverwerkingen biedt geen handreiking ten aanzien van de manier waarop gegevensinzicht plaats moet vinden richting belanghebbende, wel op de in de inhoud van het gegevensinzicht.
1.7. Persoonsgegevens zijn beschermd bij het uitwisselen van gegevens	- Deze standaard gaat er vanuit dat autorisatie- en beveiligingsmechanismen worden toegepast rondom Applicatie en Logboek, daarom zijn er geen extra richtlijnen op dit vlak. Zie ook Beleidskader 8.9.
1.8. Uitwisseling van gegevens wordt gelogd als deze later aantoonbaar moet zijn	- Logging van verwerkte data is de kern van deze standaard. Door gebruikt te maken van een traceringsmechanisme en unieke identificatoren, kan er altijd worden voldaan aan de eis dat ontvangen en verzonden data aan elkaar gerelateerd kunnen worden.
2.1. Gegevensuitwisseling is federatief georganiseerd	- Logboek Dataverwerkingen maakt het mogelijk om in een gefedereerde omgeving en in informatieketens verantwoording te kunnen afleggen over gegevensuitwisseling. Hiervoor wordt tracing ingezet, een concept dat gebaseerd op de open standaard OpenTelemetry. Zie voor enkele juridische en beleidsmatige uitgangspunten het Juridisch Beleidskader hoofdstuk 6 en hoofdstuk 8. - Nadere invulling t.a.v. gegevensuitwisseling in het kader van inzage zal volgen als de extensie voor inzage wordt gemaakt.
2.2. Voorwaarden en afspraken zijn expliciet en inzichtelijk	- Afspraken in het kader van deze standaard zullen vooral gemaakt worden op het gebied van tracering van data binnen organisaties en over organisaties heen.
3.1. Gemeenschappelijke begripsvorming is het startpunt	- De data die gebruikt worden in deze standaard, staan vermeld en uitgelegd in het Canoniek Gegevensmodel. Het is van belang dat alle (overheids)organisatie die gebruik maken van de standaard hetzelfde beeld hebben ten aanzien specifieke data en uitwisseling daarvan om foutsituaties en verwarring te voorkomen.
3.2. Metagegevens zijn begrijpelijk voor mensen	- De metagegevens zijn veelal ontstaan op basis van de internationale standaard OpenTelemetry. Daarnaast worden de begrippen ook uitgelegd in het Canoniek Gegevensmodel.
3.3. Gegevens worden contextrijk vastgelegd	- Het gebruik van metadata in deze standaard is essentieel. De context wordt uitgelegd in het Canoniek Gegevensmodel. Daarnaast zijn er verdiepingsdocumenten aanwezig zoals het traceringsmechanisme [nog toe te voegen] en concrete voorbeelden van loggingssituaties.
3.4. Metagegevens zijn aan elkaar verbonden	- Metagegevens tussen de verschillende Logboeken zijn aan elkaar gerelateerd middels de beschrijvingen en afspraken zoals gespecifieerd in de standaard .
3.5. Metagegevens zijn beschikbaar als Linked Data	- De gedefinieerde metadata is gerelateerd aan de standaard NL-SBB – standaard voor het beschrijven van begrippen.
4.1. Gegevens worden geleverd vanuit herbruikbare gegevensdiensten	- Nadere invulling volgt bij het ontwerp van de Inzage extensie.
4.2. Registraties bieden historische gegevens aan	- Data in het Logboek mogen niet fysiek worden verwijderd; als ze niet meer geldig zijn dan wordt alleen vastgelegd dat ze niet meer geldig zijn (tenzij ze om juridische redenen vernietigd moeten worden). - De historische integriteit van Logboekgegevens is geborgd; oude data mogen niet worden niet overschreven. - Nieuwe formele overheidsregistraties die worden ontwikkeld, moeten de formele historie van datawerking vastleggen conform de standaard Logboek dataverwerking. Ook de wijzigingen in Register van Verwerkingsactiviteiten worden toevoegd als nieuwe verwerkingsactiviteiten met een eigen unieke identificator. Bestaande verwerkingsactiviteiten mogen niet wijzigen of verwijderd worden. Hierdoor blijven de oude verwijzingen uit de Logboek Dataverwerking intact.
4.3. Aanbieders kunnen notificeren over belangrijke gebeurtenissen	- N.v.t. Standaard beschrijft geen notificatiemechanisme voor wijzigingen in de Log.
5.1. Informatieproducten zijn herleidbaar naar de onderliggende gegevens en regels	- Door gebruikt te maken van een traceringsmechanisme en unieke identificatoren, kan er altijd worden voldaan aan de eis dat ontvangen en verzonden data aan elkaar gerelateerd kunnen worden. De bron, en daarmee de kwaliteit en betrouwbaarheid van verwerkte data, kunnen snel en eenvoudig worden opgehaald. - Wordt eventueel nader ingevuld bij de ontwikkeling van een Inzage extensie.
6.1. Gegevens worden zo vroeg mogelijk gevalideerd	- Validatie van logdata is een taak van de Applicatie zelf, deze standaard geeft hiervoor geen handreiking.

Logging van gegevensverwerkingen kunnen vaak en veelvuldig plaatsvinden. Het geheel kan groot en complex worden want sommige Logregels zijn aan elkaar gerelateerd. Deze relaties kunnen gelegd worden met Logregels met andere applicaties binnen dezelfde organisatie of met logregels van applicaties van andere organisaties. Maar ook zijn er relaties nodig met activiteiten in het Register van Verwerkingsactiviteiten. Wat nu als alle Logregels zonder relaties worden opgeslagen? Bij een rapportage (bijvoorbeeld een verzoek tot inzage van een burger) moet nu handmatig worden uitgezocht welke gegevensverwerkingen bij elkaar horen en er moet, in het ernstigste geval, ook contact worden gezocht moet andere organisaties om te onderzoeken of daar ook de nodige gegevensverwerkingen zijn uitgevoerd. Als er bij elke Logregel de nodige relatiegegevens worden bijgevoegd, kan de rapportage snel en accuraat worden gegenereerd.

Om er zeker van te zijn dat de relatie tussen Logregels gelegd kan worden, moeten de volgende gegevens worden geregistreerd per Logregel:

• processingActivityId: elke gegevensverwerking die een organisatie doet, moet bekend zijn in het Register van Verwerkingsactiviteiten. Het processingActivity legt de relatie tussen de gegevensverwerking door een applicatie, en de activiteit gedefinieerd in het Register.

• traceId: alle logregels die voor een specifieke gegevensverwerking bij elkaar horen, krijgen een traceId. De traceId-waarde voor alle Logregels die bij elkaar horen is hetzelfde.

• operationId: elke individuele Logregel (Operation) krijgt een eigen, unieke operationId (net zoals elk databaserecord dat ook krijgt).

In werkelijkheid worden alle relaties door de Applicatie in een fractie van een seconde (in parallel) gelegd. Om het grote geheel beter te begrijpen, worden alle relaties hieronder stap voor stap uitgelegd.

Als er een Dataverwerking plaatsvindt, moet dit altijd een relatie hebben met het Register van Verwerkingsactiviteiten. In dit Register staat informatie over de gegevens die een organisatie verwerkt. Het Register is verplicht, een geautomatiseerde koppeling met het Logboek niet. Bij elke Dataverwerking wordt door het Logboek een relatie gelegd met het Register door middel van het processingActivityId. Als er meerdere dezelfde Dataverwerkingen (‘Operations’) zijn, krijgen deze dus allemaal dezelfde processingActivityId.

Alt text

In het geval er een Dataverwerking plaatsvindt ter ondersteuning van een andere Dataverwerking (suboperation), dan kan deze ondersteunende Dataverwerking een eigen processingActivityId krijgen. Deze kan anders zijn dan het processingActivityId van de ‘hoofdprocessingActivity’. Alt text

De subOperation heeft nu een eigen processingActivityId gekregen, maar het is nog niet duidelijk aan welke hoofdprocessingActivityId deze gekoppeld is. Om dit op te lossen, wordt ook een ‘parentProcessingActivityId’ geregistreerd. Bij de subOperation wordt in dit geval naast de processingActivityId ook een parentProcessingActivityId geregistreerd. De waarde van deze parentProcessingActivityId is gelijk aan de waarde van het hoofdProcessingActivityId. Alt text

Bij een Dataverwerking kan het zijn dat gegevens moeten worden opgevraagd bij een andere organisatie. Deze organisatie heeft zelf ook een Register van Verwerkingsactiviteiten. In dit Register staat beschreven dat een specifieke organisatie specifieke gegevens mag opvragen als aparte operation. Bij het verstrekken van deze gegevens aan de aanvragende organisatie, wordt het processingActivityId van de gegevensverstrekkende organisatie geregistreerd. Er is dus GEEN rechtstreekse koppeling tussen het Register van de aanvragende en het Register van de verstrekkende organisatie. Alt text

Operations kunnen bestaan uit meerdere (sub)Operations binnen de eigen organisatie maar ook over organisaties heen. Het geheel kan een grote en ingewikkelde constructie worden. Om toch het overzicht te kunnen behouden, is het noodzakelijk een ‘traceId’ te introduceren per (sub)Operation. Het traceId is als het ware de ‘lijm’ tussen alle (sub)Operations. Als er nog geen traceId bekend is, wordt deze automatisch gegenereerd voor de eerste Operation. Alt text

Alle bij elkaar horende (sub)Operations, krijgen vervolgens dezelfde traceId-waarde. Alt text

In het geval er gegevens worden opgevraagd aan een andere organisatie, krijgt elke operation bij verstrekkende organisatie een traceId. Om de relatie te leggen tussen de vragende en de verstrekkende organisatie, wordt bij elke Operation van de verstrekkende organisatie een ‘foreignOperationTraceId’ geregistreerd. De waarde van de foreignOperationTraceId van de verstrekkende organisatie is gelijk aan de waarde van traceId van de vragende organisatie. Alt text

Elke (sub)Operation krijgt een eigen, unieke operationId. Hiermee zijn alle loggings altijd uniek traceerbeer. Ook subOperations krijgen een eigen, unieke OperationId. Alt text

Als er ook subOperations plaatsvinden, moet er ook een ‘parentOperationId’ worden geregistreerd om de koppeling met de hoofdOperation te realiseren.

Alt text

In het geval er gegevens nodig zijn van een andere organisatie, krijgt de Operation van de verstrekkende organisatie ook een eigen, unieke operationId. Daarnaast wordt bij deze Operation ook het operationId geregistreerd die het verzoek voor informatie geïnitieerd heeft (vanuit de vragende organisatie). Deze specifieke operationId wordt het ‘foreignOperationId’ genoemd en krijgt de waarde gelijk aan het operationId van de initiërende Operation van de vragende organisatie. Alt text

Het nu volgende voorbeeld is volledig fictief en is puur bedoeld om een beeld te schetsen ten behoeve van een traceringsconstructie in een logboek.

Een persoon heeft een parkeervergunning in een gemeente. Er is een nieuwe auto aangeschaft, het kenteken moet worden aangepast ten behoeve van de vergunning. De persoon kan het kenteken online wijzigen in de ‘mijnGemeente’ applicatie. Om het voorbeeld eenvoudig te houden, worden foutsituaties buiten beschouwing gelaten.

Persoon logt in gemeenteapplicatie.
Gemeente toont huidige parkeervergunning.
Persoon wijzigt kenteken in de gemeenteapplicatie.
Gemeenteapplicatie vraagt het RDW om gegevens op basis van de tenaamstelling.
RDW geeft de gevraagde gegevens terug aan de gemeenteapplicatie.
Gemeenteapplicatie accepteert de wijziging van de persoon.

De traceringsgegevens worden als volgt vastgelegd:

processingActivityId

In de gemeenteapplicatie worden de volgende Operations uitgevoerd die een relatie hebben met het Register van Verwerkingsactiviteiten van de gemeente:

• Toon alle vergunningen: na het inloggen, worden de parkeervergunningen van de persoon getoond. Deze Operation is gerelateerd aan de processingActivity Parkeervergunningadministratie voeren.

• Wijzig kenteken: het wijzigen van het kenteken valt ook onder de processingActivity Parkeervergunningadministratie voeren. Hierdoor is het processingActivityId hetzelfde als die van de Operation Toon alle vergunningen.

• Controleer tenaamstelling: deze Operation zorgt voor de aanvraag van gegevens richting het RDW en controle van de terugontvangen gegevens. Deze Operation is een subOperation van Wijzig kenteken en krijgt een processingActivity wat hoort bij de processingActivity in het Register genaamd Tenaamstelling controleren. De processingActivity is op zijn beurt weer een subprocessingActivity van Parkeeradministratie voeren. Om deze relatie te leggen, moet ook een parentProcessingActivityId worden geregistreerd. De waarde hiervan is gelijk aan de waarde van het processingActivityId van Parkeervergunningadministratie voeren.

In de RDW-applicatie wordt het verstrekken van gegevens aan de gemeenteapplicatie ook geregistreerd. De Operation Verstrek houdergegevens is gerelateerd aan de processingActivity Kentekenhoudergegevens verstrekken. Merk op dat er hier dus GEEN directe relatie is tussen het Register van Verwerkingsactiviteiten van de gemeente en die van het RDW. Alt text

• De gemeenteOperations Toon alle vergunningen, Wijzig kenteken en Controleer tenaamstelling behoren tot dezelfde handeling (met als eindresultaat het wijzigingen van het kenteken op de vergunning). Deze Operations krijgen allemaal dezelfde traceId. • De RDW-Operation Verstrek houdergegevens krijgt een eigen traceId. • Om het geheel te koppelen over de organisaties heen, wordt bij het RDW ook een foreignOperationTraceId opgeslagen, de waarde hier van is gelijk aan de waarde van de traceId van de Operation Controleer tenaamstelling. Alt text

In de gemeente-applicatie krijgt elke (sub)Operation een eigen, unieke OperationId. • De (sub)Operation Controleer tenaamstelling krijgt daarnaast ook nog een parentOperationId met de waarde van OperationId van de Operation Wijzig kenteken om een relatie te leggen. • Ook de RDW-Operation Verstrek houdergegevens krijgt een eigen unieke OperationId. • Om de relatie over de organisaties heen te leggen, wordt er bij de RDW-Operation Verstrek houdergegevens ook een foreignOperationId moeten worden vastgelegd. De waarde van deze foreignOperationId is gelijk aan de waarde van de OperationId van de gemeente-Operation Controleer tenaamstelling. Alt text

Als alle relaties gelegd zijn, ziet de traceringsconstructie er als volgt uit: Alt text

Meer gedetailleerde voorbeelden staan beschreven in de inleiding van de standaard logboek dataverwerkingen.

Ter verduidelijking van de standaard is een Canoniek gegevensmodel uitgewerkt, dit gestandaardiseerd model voor datarepresentatie is ontworpen om de attributen eenduidig en consistenter te maken. Het biedt een uniforme structuur en terminologie voor alle relevante gegevens in de standaard. Zie voor de definitie van de gebruikte terminologie ook Paragraaf 1.2 van de standaard.

Attribuut	Beschrijving
Attribuutnaam	`attribute`
Definitie Engels	Attributes in the form of key value pairs.
Attribuutnaam Nederlands	attribuut
Definitie Nederlands	Attributen in de vorm van key value pairs.
Toelichting	Organisaties hebben de vrijheid om zelf key value pairs te bepalen als dit bijdraagt aan de inzichtelijkheid van een gegevensverwerkingsactie.
Noodzakelijkheid	Vanuit de standaard is het onmogelijk om alle attribuutsoorten te definiëren die belangrijk zijn voor de inzichtelijkheid van een gegevensverwerkingsactie. Daarom is er in de standaard rekening gehouden met een mogelijkheid om per organisatie of per systeem eigen attribuutsoorten te bepalen.
Datatype	-
Voorbeeld	-
Verplicht	Nee
Gebruikt in	Logboek
Enumeratiewaarden	-

Attribuut	Beschrijving
Attribuutnaam	`dplCoreDataSubjectId`
Definitie Engels	Refers to any individual person who can be identified, directly or indirectly, via an identifier such as a name, an ID number, location data, or via factors specific to the person's physical, physiological, genetic, mental, economic, cultural or social identity.
Attribuutnaam Nederlands	dplCorebetrokkeneId
Definitie Nederlands	De geïdentificeerde of identificeerbare natuurlijk persoon op wie de verwerkte en/of de te verwerken persoonsgegevens betrekking hebben.
Toelichting	Bij het gebruik van dataSubject (betrokkene) moet rekening gehouden met artikel 32-1a: Rekening houdend met de stand van de techniek, de uitvoeringskosten, alsook met de aard, de omvang, de context en de verwerkingsdoeleinden en de qua waarschijnlijkheid en ernst uiteenlopende risico's voor de rechten en vrijheden van personen, treffen de verantwoordelijke en de verwerker passende technische en organisatorische maatregelen om een op het risico afgestemd beveiligingsniveau te waarborgen, die, waar passend, onder meer het volgende omvatten: a) de pseudonimisering en versleuteling van persoonsgegevens.
Noodzakelijkheid	Gegevensverwerkingsacties moeten per betrokkene worden opgeslagen. Indien er gevraagd wordt om de gegevensverwerkingsacties van een betrokkene kan er niet gerapporteerd worden zonder dit attribuutsoort.
Datatype	URI
Voorbeeld	6e8bc430-9c3a-11d9-9669-0800200c9a66
Verplicht	Ja
Gebruikt in	Logboek
Enumeratiewaarden	Niet van toepassing

Attribuut	Beschrijving
Attribuutnaam	`dataSubjectCategories`
Definitie Engels	A classification of data subjects relevant to an organization. Can be used to categorize business-specific and regulation-specific categories. Examples: Employees Customers Suppliers
Attribuutnaam Nederlands	categorieënBetrokkenen
Definitie Nederlands	Een beschrijving van de categorieën van personen van wie gegevens verwerkt worden.
Toelichting	-
Noodzakelijkheid	In AVG artikel 30-1c wordt de volgende maatregel benoemd: Elke verantwoordelijke en, in voorkomend geval, de vertegenwoordiger van de verantwoordelijke houdt een register van de verwerkingsactiviteiten die onder hun verantwoordelijkheid plaatsvinden. Dat register bevat alle volgende gegevens: een beschrijving van de categorieën van betrokkenen en van de categorieën van persoonsgegevens.
Datatype	Enumwaarde
Voorbeeld	Burger
Verplicht	Ja
Gebruikt in	Register
Enumeratiewaarden	Afhankelijk van het type systeem en betrokken actoren. Er kunnen meerdere categorieën van toepassing zijn.

Attribuut	Beschrijving
Attribuutnaam	`dplCoreProcessingActivityId`
Definitie Engels	Reference to Register with more information about the processing activity.
Attribuutnaam Nederlands	dplCoreVerwerkingsactiviteitId
Definitie Nederlands	Verwijzing naar Register met meer informatie over de verwerkingsactiviteit.
Toelichting	-
Noodzakelijkheid	Elke gegevensverwerking in het logboek moet in lijn zijn met de vooraf gedefinieerde verwerkingsactiviteiten in het register (zie AVG artikel 30). Om te voorkomen dat alle attribuutsoorten van het register gedupliceerd worden in het logboek, wordt in het logboek alleen verwezen naar het VerwerkingsactiviteitId van het register.
Datatype	URI
Voorbeeld	6e8bc430-9c3a-11d9-9669-0800200c9a66
Verplicht	Ja
Gebruikt in	Register en Logboek
Enumeratiewaarden	Niet van toepassing

Attribuut	Beschrijving
Attribuutnaam	`endTime`
Definitie Engels	Timestamp representing the end of a data processing logging action.
Attribuutnaam Nederlands	eindTijd
Definitie Nederlands	Tijdstempel die het einde van een logboekactie voor gegevensverwerking vertegenwoordigt.
Toelichting	Een logboekregel wordt pas weggeschreven in het logboek als de volledige transactie (succesvol of niet succesvol) is afgerond.
Noodzakelijkheid	Bij een inzageverzoek van de Betrokkene ten aanzien van gegevensverwerkingsacties, wordt ook een tijdsspanne gevraagd. Alleen de details van een gegevenswerkingsactie binnen opgegeven tijdsspanne worden gerapporteerd. Zonder begin- en eindtijd van een gegevensverwerkingsactie is het onmogelijk de juiste details op te leveren.
Datatype	DateTime
Voorbeeld	2025-02-23T00:00:00
Verplicht	Ja
Gebruikt in	Logboek
Enumeratiewaarden	Niet van toepassing.

Attribuut	Beschrijving
Attribuutnaam	`envisagedTimeLimit`
Definitie Engels	The maximum period for which the personal data is necessary to achieve the purpose of the processing or no longer than the period anchored in sector-specific legislation.
Attribuutnaam Nederlands	bewaarTermijn
Definitie Nederlands	De maximale periode waarin de persoonsgegevens noodzakelijk worden bewaard om het doel van de verwerking te bereiken of niet langer dan de termijn die verankerd is in sectorspecifieke wetgeving.
Toelichting	Als het bewaartermijn van een bewaard gegeven verstreken is, dan moet het gegeven worden verwijderd uit het logboek.
Noodzakelijkheid	In AVG artikel 30-1f wordt de volgende maatregel benoemd: Elke verantwoordelijke en, in voorkomend geval, de vertegenwoordiger van de verantwoordelijke houdt een register van de verwerkingsactiviteiten die onder hun verantwoordelijkheid plaatsvinden. Dat register bevat alle volgende gegevens: indien mogelijk, de beoogde termijnen waarbinnen de verschillende categorieën van gegevens moeten worden gewist. De concrete datum waarop een gegevensverwerking moet worden gewist uit het logboek, kan bepaald worden door middel van het bewaartermijn in het register en de eindtijd waarop een gegevensverwerking is gelogd in het logboek. Daardoor is het onnodig om de concrete verwijderdatum van een gegevensverwerking te registreren in het logboek.
Datatype	DateTime
Voorbeeld	2025-02-23T00:00:00
Verplicht	Ja
Gebruikt in	Register
Enumeratiewaarden	Niet van toepassing

Attribuut	Beschrijving
Attribuutnaam	`foreignOperation.entity`
Definitie Engels	Reference to external entity.
Attribuutnaam Nederlands	entiteit
Definitie Nederlands	Verwijzing naar externe entiteit.
Toelichting	Indien er voor een verwerking ook een logging heeft plaatsgevonden door een externe informatiebron, dan wordt er een verwijzing aangemaakt om de gegevens van deze logging in te kunnen zien.
Noodzakelijkheid	Indien het noodzakelijk is ook gegevensverwerkingsacties van een externe gegevensbron te gebruiken, dan wordt een unieke referentie naar deze externe gegevensverwerkingsactie geregistreerd in het logboek. Door alleen te verwijzen naar de externe gegevensverwerkingsactie, kan voorkomen worden dat gegevens gedupliceerd worden opgeslagen in het logboek.
Datatype	URI
Voorbeeld	foo://techtarget.com:8042/over/there?name=parrot#beak
Verplicht	Nee
Gebruikt in	Logboek
Enumeratiewaarden	Niet van toepassing

Attribuut	Beschrijving
Attribuutnaam	`foreignOperation.operationId`
Definitie Engels	Unique name given to a foreign processing operation.
Attribuutnaam Nederlands	externeActie.actieId
Definitie Nederlands	Identificator die de externe verwerkingsactie uniek identificeert.
Toelichting	Externe verwerkingsacties kunnen een onderdeel zijn van de totale verwerkingsactie. OperationId is in dit geval een attribuutsoort van het objecttype foreignOperation.
Noodzakelijkheid	Indien het noodzakelijk is ook gegevensverwerkingsacties van een externe gegevensbron te gebruiken, dan wordt een unieke referentie naar deze externe gegevensverwerkingsactie geregistreerd in het logboek. Het foreignOperation.operationId refereert naar één specifieke gegevensverwerkingsactie door de externe gegevensbron. Door alleen te verwijzen naar de externe gegevensverwerkingsactie, kan voorkomen worden dat gegevens gedupliceerd worden opgeslagen in het logboek.
Datatype	URI
Voorbeeld	6e8bc430-9c3a-11d9-9669-0800200c9a66
Verplicht	Nee
Gebruikt in	Logboek
Enumeratiewaarden	Niet van toepassing

Attribuut	Beschrijving
Attribuutnaam	`LegalBasis`
Definitie Engels	The general conditions governing the lawfulness of processing by the controller.
Attribuutnaam Nederlands	grondslag
Definitie Nederlands	Algemene voorwaarden inzake de rechtmatigheid van verwerking door de verantwoordelijke.
Toelichting	De verwerking is alleen rechtmatig indien en voor zover aan ten minste één van de voorwaarden is voldaan.
Noodzakelijkheid	In AVG artikel 6-1 worden de volgende maatregelen benoemd:
	De verwerking is alleen rechtmatig indien en voor zover aan ten minste één van de voorwaarden is voldaan.
	a) de betrokkene heeft toestemming gegeven voor de verwerking van zijn persoonsgegevens voor een of meer specifieke doeleinden;
	b) de verwerking is noodzakelijk voor de uitvoering van een overeenkomst waarbij de betrokkene partij is, of om op verzoek van de betrokkene vóór de sluiting van een overeenkomst maatregelen te nemen;
	c) de verwerking is noodzakelijk om te voldoen aan een wettelijke verplichting die op de verantwoordelijke rust;
	d) de verwerking is noodzakelijk om de vitale belangen van de betrokkene of van een andere natuurlijke persoon te beschermen;
	e) de verwerking is noodzakelijk voor de vervulling van een taak van algemeen belang of van een taak in het kader van de uitoefening van het openbaar gezag dat aan de verantwoordelijke is opgedragen;
	f) de verwerking is noodzakelijk voor de behartiging van de gerechtvaardigde belangen van de verantwoordelijke of van een derde, behalve wanneer de belangen of de grondrechten en de fundamentele vrijheden van de betrokkene die tot bescherming van persoonsgegevens nopen, zwaarder wegen dan die belangen, met name wanneer de betrokkene een kind is.
	Er moet worden aangetoond dat de verwerking rechtmatig is op basis van één of meer grondslagen.
Datatype	Enumwaarden
Voorbeeld	Legal obligation
Verplicht	Ja
Gebruikt in	Register
Enumeratiewaarden EN	- Consent data subject (6-1a)
	- Necessary contract data subject (6-1b)
	- Legal obligation (6-1c)
	- Protect vital interests (6-1d)
	- Performance task (6-1e)
	- Legitimate interests (6-1f)
Enumeratiewaarden NL	- Toestemming betrokkene (6-1a)
	- Uitvoering overeenkomst betrokkene (6-1b)
	- Wettelijke verplichting (6-1c)
	- Vitaal belang (6-1d)
	- Algemeen belang (6-1e)
	- Gerechtvaardigd belang (6-1f)

Attribuut	Beschrijving
Attribuutnaam	`LegalBasisComment`
Definitie Engels	More detailed explanation of the general conditions governing the lawfulness of processing by the controller.
Attribuutnaam Nederlands	grondslagUitleg
Definitie Nederlands	Uitleg bij de algemene voorwaarden inzake de rechtmatigheid van verwerking door de verantwoordelijke.
Toelichting	-
Noodzakelijkheid	Organisaties mogen persoonsgegevens alleen verzamelen met een gerechtvaardigd doel. Dat doel moet specifiek zijn en vooraf uitdrukkelijk zijn omschreven. Artikel 5-1 van de AVG benoemt (onder andere) de volgende maatregelen:
	Persoonsgegevens moeten:
	a) worden verwerkt op een wijze die ten aanzien van de betrokkene rechtmatig, behoorlijk en transparant is ("rechtmatigheid, behoorlijkheid en transparantie");
	b) voor welbepaalde, uitdrukkelijk omschreven en gerechtvaardigde doeleinden worden verzameld en mogen vervolgens niet verder op een met die doeleinden onverenigbare wijze worden verwerkt; de verdere verwerking met het oog op archivering in het algemeen belang, wetenschappelijk of historisch onderzoek of statistische doeleinden wordt overeenkomstig artikel 89, lid 1, niet als onverenigbaar met de oorspronkelijke doeleinden beschouwd ("doelbinding");
	c) toereikend zijn, ter zake dienend en beperkt tot wat noodzakelijk is voor de doeleinden waarvoor zij worden verwerkt ("minimale gegevensverwerking").
Datatype	CharacterString
Voorbeeld	Paspoortenregeling Nederland
Verplicht	Nee
Gebruikt in	Register
Enumeratiewaarden	Niet van toepassing

Attribuut	Beschrijving
Attribuutnaam	`operationId`
Definitie Engels	Unique name given to a processing operation.
Attribuutnaam Nederlands	actieId
Definitie Nederlands	Identificator die de gegevensverwerkingsactie uniek identificeert.
Toelichting	Het iD is betekenisloos, kent geen volgorde en is uniek over alle systemen in de wereld.
Noodzakelijkheid	Elke gegevensverwerkingsactie wordt uniek opgeslagen in het logboek. Indien een rapportage moet worden gemaakt voor de betrokkene, moet de unieke gegevensverwerkingsactie opgehaald kunnen worden uit het logboek. Het ophalen van de gegevens gaat op basis van het operationId, dus zonder dit gegeven is het aanmaken van een rapportage niet mogelijk.
Datatype	URI
Voorbeeld	6e8bc430-9c3a-11d9-9669-0800200c9a66
Verplicht	Ja
Gebruikt in	Logboek
Enumeratiewaarden	Niet van toepassing

Attribuut	Beschrijving
Attribuutnaam	`operationName`
Definitie Engels	Specific operation addressed or referred to.
Attribuutnaam Nederlands	actieNaam
Definitie Nederlands	Naam van een specifieke gegevensverwerkingsactie.
Toelichting	Aanbevolen wordt om alle gegevensverwerkingsacties te beschrijven als een werkwoord (in de infinitief) gevolgd door een zelfstandig naamwoord.
Noodzakelijkheid	Om duidelijk te maken aan de betrokkene (bij een verzoek om gegevensinzage) wat er concreet is gebeurd bij een gegevensverwerkingsactie, wordt een operationName gedefinieerd. Zie ook artikel 4 van de AVG, waarin de definitie van ‘verwerking’ wordt genoemd:
	een bewerking of een geheel van bewerkingen met betrekking tot persoonsgegevens, al dan niet uitgevoerd via geautomatiseerde procedés, zoals het verzamelen, vastleggen, ordenen, structureren, opslaan, bijwerken of wijzigen, opvragen, raadplegen, gebruiken, verstrekken door middel van doorzending, verspreiden of op andere wijze ter beschikking stellen, aligneren of combineren, afschermen, wissen of vernietigen van gegevens.
Datatype	CharacterString
Voorbeeld	Opslaan persoonsgegevens
Verplicht	Ja
Gebruikt in	Logboek
Enumeratiewaarden	Niet van toepassing

Attribuut	Beschrijving
Attribuutnaam	`parentDplCoreProcessingActivityId`
Definitie Engels	A parent is one class, and a child is another class that inherits all of the attributes and functions assigned to the parent class. The parentId refers to the parent class.
Attribuutnaam Nederlands	parentDplCoreVerwerkingsactiviteitId
Definitie Nederlands	Een parent is één klasse, en een child is een andere klasse die alle attributen en functies overerft die aan de bovenliggende klasse zijn toegewezen. De parentId verwijst naar de bovenliggende klasse.
Toelichting	Een verwerkingsactiviteit kan onderdeel zijn een andere verwerkingsactiviteit. Op deze manier ontstaat er een hiërarchie van verwerkingsactiviteiten.
Noodzakelijkheid	Een bepaalde verwerkingsactiviteit kan een onderdeel zijn van een andere verwerkingsactiviteit. Door gebruik te maken van een ‘parent/child’-structuur, hoeven er geen nieuwe attributen gedefinieerd te worden om een hiërarchie van verwerkingsactiviteiten te creëren.
Datatype	URI
Voorbeeld	6e8bc430-9c3a-11d9-9669-0800200c9a66
Verplicht	Ja
Gebruikt in	Register en Logboek
Enumeratiewaarden	Niet van toepassing

Attribuut	Beschrijving
Attribuutnaam	`parentOperationId`
Definitie Engels	A parent is one class, and a child is another class that inherits all of the attributes and functions assigned to the parent class. The parentId refers to the parent class.
Attribuutnaam Nederlands	parentActieId
Definitie Nederlands	Een parent is één klasse, en een child is een andere klasse die alle attributen en functies overerft die aan de bovenliggende klasse zijn toegewezen. De parentId verwijst naar de bovenliggende klasse.
Toelichting	Een gegevensverwerkingsactie kan onderdeel zijn een andere verwerkingsactie. Op deze manier ontstaat er een hiërarchie van gegevensverwerkingsacties.
Noodzakelijkheid	Een bepaalde verwerkingsactie kan een onderdeel zijn van een andere verwerkingsactie. Door gebruik te maken van een ‘parent/child’-structuur, hoeven er geen nieuwe attributen gedefinieerd te worden om een hiërarchie van gegevensverwerkingsacties te creëren.
Datatype	URI
Voorbeeld	6e8bc430-9c3a-11d9-9669-0800200c9a66
Verplicht	Ja
Gebruikt in	Logboek
Enumeratiewaarden	Niet van toepassing

Attribuut	Beschrijving
Attribuutnaam	`personalDataCategories`
Definitie Engels	Category of information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier, or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.
Attribuutnaam Nederlands	categorieënPersoonsgegevens
Definitie Nederlands	Categorieën van Persoonsgegevens zijn alle gegevens die betrekking hebben op een geïdentificeerde of identificeerbare levende natuurlijke persoon. Losse gegevens die samengevoegd kunnen leiden tot de identificatie van een bepaalde persoon vormen ook persoonsgegevens.
Toelichting	Verwerking van persoonsgegevens waaruit ras of etnische afkomst, politieke opvattingen, religieuze of levensbeschouwelijke overtuigingen, of het lidmaatschap van een vakbond blijken, en verwerking van genetische gegevens, biometrische gegevens met het oog op de unieke identificatie van een persoon, of gegevens over gezondheid, of gegevens met betrekking tot iemands seksueel gedrag of seksuele gerichtheid zijn verboden.
Noodzakelijkheid	In AVG artikel 30-1c wordt de volgende maatregel benoemd: Elke verantwoordelijke en, in voorkomend geval, de vertegenwoordiger van de verantwoordelijke houdt een register van de verwerkingsactiviteiten die onder hun verantwoordelijkheid plaatsvinden. Dat register bevat alle volgende gegevens: een beschrijving van de categorieën van betrokkenen en van de categorieën van persoonsgegevens.
Datatype	Enumwaarde
Voorbeeld	Nummer van identiteitskaart
Verplicht	Ja
Gebruikt in	Register
Enumeratiewaarden	Afhankelijk van het type systeem en betrokken actoren. Er kunnen meerdere categorieën van toepassing zijn.

Attribuut	Beschrijving
Attribuutnaam	`purpose`
Definitie Engels	Personal data may only be processed for specified, explicit and legitimate purposes and may not be further processed in a manner incompatible with those purposes.
Attribuutnaam Nederlands	doelEinde
Definitie Nederlands	Persoonsgegevens mogen slechts worden verwerkt voor welbepaalde, uitdrukkelijk omschreven en gerechtvaardigde doeleinden en mogen vervolgens niet verder op een met die doeleinden onverenigbare wijze worden verwerkt.
Toelichting	Persoonsgegevens mogen alleen verwerken als je vóóraf de specifieke doeleinden voor de verwerking bepaald zijn.
Noodzakelijkheid	In AVG artikel 5-1b wordt de volgende maatregel benoemd: Persoonsgegevens moeten: voor welbepaalde, uitdrukkelijk omschreven en gerechtvaardigde doeleinden worden verzameld en mogen vervolgens niet verder op een met die doeleinden onverenigbare wijze worden verwerkt; de verdere verwerking met het oog op archivering in het algemeen belang, wetenschappelijk of historisch onderzoek of statistische doeleinden wordt overeenkomstig artikel 89, lid 1, niet als onverenigbaar met de oorspronkelijke doeleinden beschouwd („doelbinding”).
Datatype	CharacterString
Voorbeeld	Het aanvragen, afgeven en innemen van reisdocumenten en het verwerken van kennisgevingen van het in het buitenland afgegeven reisdocumenten.
Verplicht	Ja
Gebruikt in	Register
Enumeratiewaarden	Niet van toepassing

Attribuut	Beschrijving
Attribuutnaam	`recipientsCategories`
Definitie Engels	Categories of natural or legal person, public authority, agency or another body, to which the personal data are disclosed, whether a third party or not.
Attribuutnaam Nederlands	categorieënOntvangers
Definitie Nederlands	Categorieën van natuurlijke of rechtspersonen, overheidsinstanties, agentschap of andere instanties waaraan de persoonsgegevens worden bekendgemaakt, al dan niet een derde partij.
Toelichting	-
Noodzakelijkheid	In AVG artikel 30-1d wordt de volgende maatregel benoemd: Elke verantwoordelijke en, in voorkomend geval, de vertegenwoordiger van de verantwoordelijke houdt een register van de verwerkingsactiviteiten die onder hun verantwoordelijkheid plaatsvinden. Dat register bevat alle volgende gegevens: de categorieën van ontvangers aan wie de persoonsgegevens zijn of zullen worden verstrekt, onder meer ontvangers in derde landen of internationale organisaties.
Datatype	Enumwaarde
Voorbeeld	Aanvragers, rechthebbenden
Verplicht	Ja
Gebruikt in	Register
Enumeratiewaarden	Afhankelijk van het type systeem en betrokken actoren. Er kunnen meerdere categorieën van toepassing zijn.

Attribuut	Beschrijving
Attribuutnaam	`resource.attribute`
Definitie Engels	Attributes in the form of key value pairs.
Attribuutnaam Nederlands	informatiebron.attribuut
Definitie Nederlands	Attribuutsoorten in de vorm van key value pairs.
Toelichting	Organisaties hebben de vrijheid om zelf key value pairs te bepalen als dit bijdraagt aan de inzichtelijkheid voor de logging van een gegevensverwerkingsactie. Naast naam en versie van de informatiebron, kan de organisatie andere attribuutsoorten definiëren ten aanzien van de informatiebron.
Noodzakelijkheid	In AVG grond 61 wordt de volgende maatregel benoemd: De informatie over de verwerking van persoonsgegevens betreffende de betrokkene dient hem te worden meegedeeld bij het verzamelen bij de betrokkene van de gegevens of, indien de gegevens uit een andere bron zijn verkregen, binnen een redelijke termijn, die afhangt van de omstandigheden van het geval. Wanneer de persoonsgegevens rechtmatig aan een andere ontvanger kunnen worden verstrekt, dient de betrokkene te worden meegedeeld wanneer de persoonsgegevens voor het eerst aan de ontvanger worden verstrekt. Wanneer de verantwoordelijke voornemens is de persoonsgegevens te verwerken met een ander doel dan dat waarvoor zij zijn verzameld, moet de verantwoordelijke de betrokkene vóór die verdere verwerking informatie over dat andere doel en andere noodzakelijke informatie verstrekken. Wanneer de oorsprong van de persoonsgegevens niet aan de betrokkene kan worden meegedeeld omdat verschillende bronnen zijn gebruikt, moet algemene informatie worden verstrekt. De organisatie kan meerdere attribuutsoorten definiëren indien dit preciezere informatie oplevert ten aanzien van de gegevensbron.
Datatype	-
Voorbeeld	-
Verplicht	Nee
Gebruikt in	Logboek
Enumeratiewaarden	-

Attribuut	Beschrijving
Attribuutnaam	`resource.name`
Definitie Engels	Name of any tangible or intangible asset capable of generating, transmitting, receiving, processing, or representing data in electronic form, where the asset is owned, licensed, operated, managed, or made available by, or otherwise used by, a data processing organisation.
Attribuutnaam Nederlands	informatiebron.naam
Definitie Nederlands	Naam van een materieel of immaterieel bezit dat gegevens in elektronische vorm kan genereren, verzenden, ontvangen, verwerken of vertegenwoordigen, waarbij het actief eigendom is van, in licentie is gegeven, wordt geëxploiteerd, beheerd of beschikbaar wordt gesteld door, of anderszins wordt gebruikt door, een gegevensverwerkingsorganisatie.
Toelichting	Naam (name) is een attribuutsoort van het objecttype Informatiebron (Resource).
Noodzakelijkheid	In AVG grond 61 wordt de volgende maatregel benoemd: De informatie over de verwerking van persoonsgegevens betreffende de betrokkene dient hem te worden meegedeeld bij het verzamelen bij de betrokkene van de gegevens of, indien de gegevens uit een andere bron zijn verkregen, binnen een redelijke termijn, die afhangt van de omstandigheden van het geval. Wanneer de persoonsgegevens rechtmatig aan een andere ontvanger kunnen worden verstrekt, dient de betrokkene te worden meegedeeld wanneer de persoonsgegevens voor het eerst aan de ontvanger worden verstrekt. Wanneer de verantwoordelijke voornemens is de persoonsgegevens te verwerken met een ander doel dan dat waarvoor zij zijn verzameld, moet de verantwoordelijke de betrokkene vóór die verdere verwerking informatie over dat andere doel en andere noodzakelijke informatie verstrekken. Wanneer de oorsprong van de persoonsgegevens niet aan de betrokkene kan worden meegedeeld omdat verschillende bronnen zijn gebruikt, moet algemene informatie worden verstrekt.
Datatype	CharacterString
Voorbeeld	Vergunningenadministratie
Verplicht	Ja
Gebruikt in	Logboek
Enumeratiewaarden	Niet van toepassing

Attribuut	Beschrijving
Attribuutnaam	`resource.version`
Definitie Engels	Version of any tangible or intangible asset capable of generating, transmitting, receiving, processing, or representing data in electronic form, where the asset is owned, licensed, operated, managed, or made available by, or otherwise used by, a data processing organisation.
Attribuutnaam Nederlands	informatiebron.versie
Definitie Nederlands	Naam van een materieel of immaterieel bezit dat gegevens in elektronische vorm kan genereren, verzenden, ontvangen, verwerken of vertegenwoordigen, waarbij het actief eigendom is van, in licentie is gegeven, wordt geëxploiteerd, beheerd of beschikbaar wordt gesteld door, of anderszins wordt gebruikt door, een gegevensverwerkingsorganisatie.
Toelichting	Versie (version) is een attribuutsoort van het objecttype Informatiebron (Resource).
Noodzakelijkheid	In AVG grond 61 wordt de volgende maatregel benoemd: De informatie over de verwerking van persoonsgegevens betreffende de betrokkene dient hem te worden meegedeeld bij het verzamelen bij de betrokkene van de gegevens of, indien de gegevens uit een andere bron zijn verkregen, binnen een redelijke termijn, die afhangt van de omstandigheden van het geval. Wanneer de persoonsgegevens rechtmatig aan een andere ontvanger kunnen worden verstrekt, dient de betrokkene te worden meegedeeld wanneer de persoonsgegevens voor het eerst aan de ontvanger worden verstrekt. Wanneer de verantwoordelijke voornemens is de persoonsgegevens te verwerken met een ander doel dan dat waarvoor zij zijn verzameld, moet de verantwoordelijke de betrokkene vóór die verdere verwerking informatie over dat andere doel en andere noodzakelijke informatie verstrekken. Wanneer de oorsprong van de persoonsgegevens niet aan de betrokkene kan worden meegedeeld omdat verschillende bronnen zijn gebruikt, moet algemene informatie worden verstrekt. Van sommige informatiebronnen zijn meerdere versies aanwezig. In dit geval is de vermelding van de versie van deze informatiebron een preciezere definitie.
Datatype	CharacterString
Voorbeeld	1.0.1.e
Verplicht	Ja
Gebruikt in	Logboek
Enumeratiewaarden	Niet van toepassing

Attribuut	Beschrijving
Attribuutnaam	`startTime`
Definitie Engels	Timestamp representing the start of a data processing logging action.
Attribuutnaam Nederlands	startTijd
Definitie Nederlands	Tijdstempel die het begin van een logboekactie voor gegevensverwerking vertegenwoordigt.
Toelichting	Een logboekregel wordt pas weggeschreven in het logboek als de volledige transactie (succesvol of niet succesvol) is afgerond.
Noodzakelijkheid	Bij een inzageverzoek van de Betrokkene ten aanzien van gegevensverwerkingsactie, wordt ook een tijdsspanne gevraagd. Alleen de details van gegevenswerkingactie binnen opgegeven tijdsspanne worden gerapporteerd. Zonder begin- en eindtijd van een gegevensverwerkingactie is het onmogelijk de juiste details op te leveren.
Datatype	DateTime
Voorbeeld	2025-02-23T00:00:00
Verplicht	Ja
Gebruikt in	Logboek
Enumeratiewaarden	Niet van toepassing

Attribuut	Beschrijving
Attribuutnaam	`statusCode`
Definitie Engels	Indicates whether a request has been processed successfully or not by the server.
Attribuutnaam Nederlands	statusCode
Definitie Nederlands	Geeft aan of een verzoek al dan niet met succes door de server is verwerkt.
Toelichting	Als een geautomatiseerd verzoek correct wordt afgehandeld, dan zal de status 'OK' zijn. Bij een foutmelding (ongeacht het type foutmelding) zal de statusCode 'NOK' zijn.
Noodzakelijkheid	Indien een gegevensverwerkingactie heeft plaatsgevonden, is het van belang te weten of deze verwerkingsactie gelukt is of niet. Zonder de statuscode kan er niet worden gerapporteerd aan een betrokkene of een wijziging daadwerkelijk heeft plaatsgevonden.
Datatype	Enumwaarde
Voorbeeld	OK
Verplicht	Ja
Gebruikt in	Logboek
Enumeratiewaarden	0: Unknown 1: OK 2: NOK

Attribuut	Beschrijving
Attribuutnaam	`traceId`
Definitie Engels	Unique identifier of the request in the system, which adds the possibility of tracing the history of the request in detail.
Attribuutnaam Nederlands	traceerId
Definitie Nederlands	Unieke identificatie van een bericht in het systeem, waarmee de mogelijkheid ontstaat om de geschiedenis van het bericht in detail te volgen.
Toelichting	Een trace is het proces waarbij informatie wordt vastgelegd over de stroom van transacties of verzoeken van een applicatie of systeem. Logboekregistratie is doorgaans breder van opzet en legt een breder scala aan gebeurtenissen vast, terwijl tracering meer specifieke informatie biedt over het uitvoeringspad van individuele verzoeken.
Noodzakelijkheid	De traceId is de unieke factor die alle (sub)gegevenswerkingsacties die betrekking hebben op een (hoofd)gegevensverwerkingactie aan elkaar verbindt. Zonder de traceId kan een totaal aan elkaar gelieerde gegevensverwerkingsacties niet worden gerapporteerd.
Datatype	URI
Voorbeeld	6e8bc430-9c3a-11d9-9669-0800200c9a66
Verplicht	Ja
Gebruikt in	Logboek
Enumeratiewaarden	Niet van toepassing

Deze sectie is tijdelijk en niet normatief, bedoeld om informatie te geven over achterliggende afwegingen bij de standaard.

In de definitieve standaard wordt deze lijst niet opgenomen, omdat veel afwegingen specifiek zijn voor de context van de Nederlandse overheid waarin deze standaard is ontstaan. De standaard is breder inzetbaar, en voor de implementatie is het niet relevant om de afwegingen bij alle aspecten van de standaard in de context van de Nederlandse overheid te kennen.

Een aantal besluiten en overweging hebben relatie met het Juridische Beleidskader

Dit onderdeel is niet normatief.

Status: draft
Datum: 2024-06-24

Vanuit de wens om zoveel mogelijk context vast te leggen om zo een compleet beeld te schetsen van wat er is gebeurd rond een Dataverwerking kan de neiging ontstaan om informatie uit andere organisaties vast te leggen in de logregels.

Hierdoor kom je (juridisch gezien) al snel in lastig vaarwater. Er worden dan zaken vastgelegd die niet noodzakelijk zijn voor het verantwoorden van het handelen. Het is namelijk mogelijk om een compleet beeld te krijgen door de informatie te laten in de organisatie waar een dataverwerking is uitgevoerd. Vanuit het oogpunt van dataminimalisatie is dit een betere oplossing.

Voor de uitoefening van het Inzagerecht is de consequentie dat de Betrokkene informatie uit alle organisaties moet ophalen en deze volgens een paar relatief eenvoudige businessrules aan elkaar moet relateren voor het verkrijgen van een compleet beeld. Dit kan door alle organisaties te bevragen, of door gericht bij één organisatie te beginnen en vervolgens de URI's te volgen naar Logregels in andere organisaties.

Het kan zijn dat organisatie A de logs wel op orde heeft, en organisatie B (nog) niet. Dan is het resultaat dat geen compleet beeld kan worden gegeven. Daarmee komt de prikkel tot verbetering op de juiste plek, namelijk bij de organisatie die het Logboek nog niet op orde heeft.

Logregels bevatten alleen wat nodig is voor verantwoording door de Verantwoordelijke.

In logregels wordt alleen een identifier vastgelegd van gerelateerde Dataverwerkingen in een andere context (bijv. een andere organisatie), geen inhoudelijke informatie
Voor een analyse, bijvoorbeeld in het kader van een audit of uitoefening inzagerecht, is het nodig om op dat moment de URI's naar logs in andere organisaties te volgen

Dit onderdeel is niet normatief.

Status: proposed
Datum: 2024-02-01

Om logs zo begrijpelijk mogelijk te maken is het aantrekkelijk om de benodigde informatie redundant weg te schrijven in elk logrecord, zodat er geen afhankelijkheid bestaat van andere bronnen.

Dit heeft nadelen, zoals:

Wanneer de statische gegevens (zoals bewaartermijn, verantwoordelijke, etc.) wijzigen, zou dit moeten worden aangepast in alle Logregels. Dat verhoudt zich slecht tot het 'inmutable' (onveranderbaar) zijn van deze Logregels.
De grote vrijheid in alle clients om invulling te geven aan deze gegevens leidt er vrijwel zeker toe dat verdere divergentie optreedt. Dit heeft o.a. tot gevolg dat het lastig wordt om te rapporteren uit de logs
De API voor het wegschrijven van logs wordt ingewikkeld en relatief traag voor het wegschrijven van records
We niet voldoen aan alle uitgangspunten die horen bij dataminimalisatie

In de gewenste situatie:

staan alle statische gegevens in het Register van de Verwerkingsactiviteiten (RvVA), en bevatten Logregels verwijzingen naar dat Register. Specifiek gaat dit om de resources 'verwerkingsactiviteiten' en 'organisaties'.
kan bij het configureren van clients in de RvVA-API worden opgezocht welke organisaties en verwerkingsactiviten van toepassing zijn
kunnen wijzigingen in verwerkingsactiviteiten worden doorgevoerd zonder dat Logregels gewijzigd behoeven te worden

Met name het wegschrijven van logs kan op deze manier met hogere performance worden uitgevoerd. Dit kan nog verder worden geoptimaliseerd door niet te vereisen dat dit middels REST API calls gebeurt, maar een interface te definiëren die kan worden geïmplementeerd met bijvoorbeeld gRPC of andere streaming protocollen.

Wanneer het aan de gebruiker is om in de software die de Logboek API aanroept de namen van acties, de vetrouwelijkheid en de bewaartermijn te bepalen, zal de invulling daarvan op allerlei manieren uiteen gaan lopen. Door dit in het RvVA te bepalen zal eerder uniformering plaatsvinden. De vulling van RvVA's kan waarschijnlijk zelfs in hoge mate gestandaardiseerd worden.

Met meer gestandaardiseerde namen en bewaartermijnen en een eenduidige omgang met vertrouwelijkheid is het ook eenvoudiger om eenduidige te communiceren naar de Betrokkene. Bijvoorbeeld: een portaal dat aan de Betrokkene toont hoe de persoonsgegevens zijn verwerkt, is lastig vorm te geven wanneer in de praktijk blijkt dat software-leveranciers verschillende interpretaties hebben van het niveau waarbij sprake is van een verwerking, handeling of actie. Eenduidige interpretatie is cruciaal, en dit kan waarschijnlijk alleen in het RvVA.

Overigens werkt het conceptueel wél wanneer men geen API op het RvVA aanbiedt, deze link kan ook handmatig worden gelegd iedere keer als deze informatie nodig is, en het RvVA bijvoorbeeld alleen bestaat als Excel document.

Logregels bevatten geen informatie over Verwerkingsactiviteiten en Verantwoordelijkheden die al vastliggen in een Register

In de standaard Logboek Dataverwerkingen is het nodig om ook de benodigde interface op de RvVA te standaardiseren. Dit is nodig om de logs geautomatiseerd en realtime te kunnen interpreteren: zonder een gestandaardiseerde manier om informatie over verwerkingsactiviteiten op te vragen kan men aan logregels niet zien of het verwerkingen, handelingen of acties betreft.

Met de volgende sequentie diagrammen wordt in beeld gebracht wat de gevolgen zijn voor de diverse flows in het gebruik van de standaard.

Het wegschrijven van een verwerking in de log-API is uiterst simpel:

Deze transactie is geoptimaliseerd op eenvoud en snelheid, want deze heeft rechtstreeks invloed op de snelheid van verwerkingen. Deze transactie moet schaalbaar zijn naar bijv. tienduizenden transacties per seconde.

Om verwerkingen op een significante manier te tonen aan bijvoorbeeld een Betrokkene, is het noodzakelijk om gegevens op te vragen uit zowel de logs als het RvVA. Deze flow mag wat complexer zijn, omdat deze niet voor alle vastgelegde data wordt uitgevoerd en het belang van de bevraging rechtvaardigt dat een bevraging wat langer kan duren.

Dit onderdeel is niet normatief.

Status: draft
Datum: 2024-05-23

Logregels moeten op enig moment worden verwijderd. Wanneer?

Voor vrijwel alle vastgelegde gegevens geldt dat deze op enig moment moeten worden vernietigd of overgebracht naar een archief. Dit geldt ook voor Logregels.

Anders dan bij gegevens over rechtsfeiten zullen Logregels typisch allemaal dezelfde bewaartermijn hebben. Het kan zijn dat de Dataverwerking waar het logrecord betrekking op heeft leidt tot gegevens waarvoor complexe bewaartermijnen gelden (bijvoorbeeld een dynamische termijn die duurt totdat Betrokkene is overleden gevolgd door een statische termijn van enkele tientallen jaren). De Logregels die de Dataverwerking beschrijven kennen deze complexe bewaartermijn niet, deze kunnen statisch zijn en generiek worden vastgesteld per organisatie of eventueel per verwerkingsactiviteit. Het is aan de organisatie zelf om daarin keuzes te maken.

Voor samenwerkende organisaties die zich ten doel stellen om gezamenlijk op eenduidige manier te verantwoorden over dataverwerkingen kan het nuttig zijn afspraken voor bewaartermijnen vast te leggen in een Profiel.

Bewaartermijnen worden in het Profiel vastgelegd.

In de Logregel liggen geen gegevens vast over bewaartermijnen.
Vanuit een beheercomponent (een applicatie die functionaliteit biedt voor beheren van logboek. Is een kwestie van implementatie en valt buiten scope van deze standaard) kunnen Logregels worden verwijderd door te kijken naar de datum van de Logregel in relatie tot de bewaartermijn die de organisatie hanteert voor Logregels. Deze bewaartermijn kan gezamenlijk zijn afgesproken en ligt dan vast in het Profiel.

Dit onderdeel is niet normatief.

Status: draft
Datum: 2024-05-23

Om te verantwoorden dat een dataverwerking correct is uitgevoerd is het nodig te weten wie de dataverwerking heeft geïnitieerd, zodat kan worden nagegaan dat dit met de juiste autorisatie is gedaan.

De wens zou kunnen bestaan om in elke logregel vast te leggen welke gebruiker een rol heeft gehad bij de betreffende Dataverwerking.

Echter, de vastlegging van een handeling van een gebruiker als medewerker van een organisatie betreft ook een Dataverwerking die onder de AVG valt, waardoor rechten ontstaan voor de betreffende gebruiker om Inzage te verkrijgen. De vastlegging van de betrokkenheid van de gebruiker is een Dataverwerking op zich. Door een dergelijke vastlegging in de logregels te doen ontstaat een ongewenste recursiviteit.

Ook is de relatie van de gebruiker tot de Dataverwerking niet eenvoudig eenduidig te modelleren, o.a. omdat bij een enkele Dataverwerking meerdere gebruikers in meerdere rollen betrokken kunnen zijn.

Daarnaast kan het goed zijn dat de Dataverwerking in het Audit Log (Een log file die activiteiten van gebruikers, uitzonderingen en informatiebeveiligingsgebeurtenissen vastgelegd. Dit is o.a. vanuit BIO verplicht) onder een andere Verantwoordelijke valt dan de Dataverwerking die op dat moment door de gebruiker wordt uitgevoerd. Bijvoorbeeld:

Een Dataverwerking wordt door een gebruiker bij een Verwerker uitgevoerd
De Dataverwerking valt onder verantwoordelijkheid van de Verantwoordelijke, namelijk de organisatie die de Verwerker heeft ingehuurd
De Audit Log is een aparte Dataverwerking die valt onder verantwoordelijkheid van de Verwerker, in de rol van Verantwoordelijke over de eigen bedrijfsvoering.

Het is daarom zuiverder om een andere oplossing te kiezen, namelijk:

Betrokkenheid van gebruiker wordt vastgelegd in een Audit Log (buiten scope van deze standaard)
In het Audit Log kan eventueel een relatie worden gelegd met het Processing ID dat ook in het Logboek Dataverwerkingen wordt gebruikt
Iedere keer dat in het Audit Log gegevens over een gebruiker worden vastgelegd, moet tevens een Dataverwerking worden gelogd in het Logboek Dataverwerkingen.

Let wel, deze Dataverwerking is een andere Dataverwerking dan de Dataverwerking die op dat moment wordt uitgevoerd door de Gebruiker, heeft een eigen Trace Context, en wordt gerelateerd aan een andere Verwerkingsactiviteit.

In logregels worden geen identificerende gegevens over gebruikers van de Applicaties vastgelegd.

In gevallen dat het nodig is te achterhalen welke gebruiker een specifieke Dataverwerking heeft uitgevoerd, moet dit worden achterhaald door de Dataverwerking te koppelen aan het Audit Log (buiten scope van de standaard).
Het koppelen van Dataverwerking aan Audit Log is mogelijk door in Audit Logs hetzelfde Processing ID op te nemen als in de logregel die in het Logboek Dataverwerkingen wordt opgenomen.

Dit onderdeel is niet normatief.

Status: draft
Datum: 2024-05-24

Logregels moeten op enig moment worden vernietigd. Moet er een interface in de standaard worden gedefinieerd voor het verwijderen van vastgelegde Logregels?

De wijze waarop Logregels worden weggeschreven is sterk afhankelijk van de keuzes die een organisatie maakt bij de implementatie van de standaard.

Interoperabiliteit is daarbij niet relevant, omdat het wijzigen of verwijderen van Logregels niet gebeurt vanuit de applicatie die oorspronkelijk de dataverwerking uitvoerde en het wegschrijven van het logrecord veroorzaakte. Wijzigen en verwijderen gebeurt vanuit een beheercomponent. Deze zijn vaak hard gekoppeld aan de voor logging gekozen oplossing, waardoor het voorschrijven van een interface tot onnodige complexiteit leidt.

De standaard beschrijft geen interface voor het wijzigen of verwijderen van Logregels

Iedere organisatie kan een bij de eigen implementatie passende oplossing kiezen voor het verwijderen van Logregels
Het wijzigen van Logregels is in principe ongewenst maar kan op soortgelijke manier opgelost worden

Dit onderdeel is niet normatief.

Status: draft
Datum: 2024-05-23

Alle verwerkingen worden gelogd. Een deel van deze verwerkingen mag bekend worden bij Betrokkenen, een deel niet. Hoe moet dit onderscheid geïmplementeerd worden?

Voorbeeld:

Opsporingsinstantie A bevraagt bij Overheidsorgaan B gegevens op over Betrokkene X in het kader van opsporingsactiviteiten rond een misdrijf
Betrokkene krijgt geen inzage in / wordt niet geïnformeerd over de verwerking van Opsporingsinstantie A, dit zou het onderzoek hinderen
Als Betrokkene wel inzage krijgt / wordt geïnformeerd over de verwerking van Overheidsorgaan B, zou Betrokkene alsnog zien dat Opsporingsinstantie A deze gegevens heeft opgevraagd, met hetzelfde ongewenste effect.

Er zijn meerdere oplossingen denkbaar. Wat is de gewenste oplossingsrichting, hoe wordt deze gespecificeerd?

Mogelijke oplossingsrichtingen:

Ken aan iedere Dataverwerking een status toe waarmee de vertrouwelijkheid wordt aangeduid, en geef deze status mee in de verwerking zodat alle betrokken organisaties dit in de logs kunnen verwerken
Leg vertrouwelijkheid meer categorisch vast op het niveau van Verwerkingsactiviteiten (in het Register)

Overwegingen:

Vertrouwelijke verwerkingen moeten meer strikt gescheiden moeten worden van niet-vertrouwelijke verwerkingen. Als een bevraging zowel vertrouwelijk als niet-vertrouwelijk kan zijn, zoals bij het opvragen van eigenaargegevens van een voertuig, moeten hiervoor twee gescheiden processen bestaan. De vertrouwelijke variant moet apart worden gelogd en aan strengere regels voldoen. Dit omvat bijvoorbeeld eisen aan betrokken beheerders, de classificatie van gegevens en andere specifieke voorschriften.

Pogingen om het geschetste probleem op te lossen door op logrecord-niveau vast te leggen of een verwerking vertrouwelijk is leiden tot veel complexiteit en uitzonderingsgevallen in de implemenentatie van de standaard. Een aantal voorbeelden van ongewenste complexiteit:

Vertrouwelijkheid vastleggen per logrecord betekent dat deze vertrouwelijkheid ook moet kunnen worden opgeheven
Logregels zijn dan niet langer 'immutable' tenzij ingewikkelde constructies worden gekozen waarbij een logrecord logisch wordt vervangen door een nieuw record toe te voegen
Er zou een interface gedefinieerd moeten worden voor het wijzigen van de status 'vertrouwelijkheid'
Vertrouwelijkheid van een handeling aan het einde van een proces zou gevolgen kunnen hebben voor reeds vastgelegde Logregels

Bovendien geldt dat Overheidsorganisatie B op impliciete wijze zou leren dat Betrokkene X onderwerp is van een opsporingsonderzoek, terwijl dit beter op expliciete wijze geregeld kan worden. Door het expliciet te regelen kan Overheidsorganisatie B alle benodigde maatregelen nemen om te zorgen dat de vertrouwelijkheid ook in die organisatie geborgd is.

Vertrouwelijkheid wordt vastgelegd per Verwerkingsactiviteit

Vertrouwelijkheid wordt niet vastgelegd in Logregels
Vertrouwelijkheid wordt per logrecord afgeleid uit wat over vertrouwelijkheid is vastgelegd bij de bijbehorende Verwerkingsactiviteit
Vertrouwelijkheid wordt NIET uitgewisseld tussen organisaties
Wanneer een verwerking niet langer vertrouwelijk is, bijvoorbeeld na verjaring, dan volgt dit uit gegevens die vastliggen in het Register (bijvoorbeeld status vertrouwelijkheid, duur vertrouwelijkheid) en wat vastligt in een logrecord (verwerkingsactiviteit_id en datum)
Organisaties moeten vooraf borgen dat vertrouwelijke Dataverwerkingen worden uitgevoerd op een manier die verantwoord kan worden, door dit te regelen op het niveau van Verwerkingsactiviteit. Dit kan tot gevolg hebben dat twee aparte processen nodig zijn voor het vertrouwelijk en niet-vertrouwelijk opvragen van gegvens.

Dit onderdeel is niet normatief.

Status: proposed
Datum: 2024-05-24

In de Logregels staat zo min mogelijk inhoudelijke informatie. Informatie over verwerkingsactiviteiten ligt vast in specifieke registers.

Er kunnen meerdere van deze Registers zijn
Deze kunnen ook van andere organisaties zijn
Naar welk Register wordt verwezen is afhankelijk van het type dataverwerking. Verwerkingen in het kader van de Algemene Verordening Gegevensbescherming (AVG) verwijzen naar een Register van Verwerkingsactiviteiten zoals beschreven in AVG art. 30.
Het Register van Verwerkingsactiviteiten (RvVA) is voor veel organisaties verplicht vanuit AVG art. 30, echter niet voor alle organisaties
Als een Register bestaat, betekent dit niet dat het ook ontsloten wordt met eeen API. In de huidige praktijk bestaat het vaak alleen in een statisch document.

De standaard voor logging moet functioneren gegeven bovenstaande feiten.

De link naar de uitwerking van een verwerkingsactiviteit bestaat uit een identifier en daarnaast een URI, URL of URN, in de vorm van key value pairs. Eventuele nadere invulling voor het verwijzen naar specifieke Registers (zoals het RvVA) wordt uitgewerkt in extensies.

Door de verwijzingen naar de registers los te houden van de Registers wordt voorkomen dat er in de logs directe afhankelijkheden ontstaan van de registers.

Dit onderdeel is niet normatief.

Status: proposed
Datum: 2024-06-20

Een bij logging veelgebruikte techniek is het zogenaamde 'Log Samplen', waarbij bijvoorbeeld slechts 1 op de 10 of 1 op de 100 acties die een log zouden veroorzaken daadwerkelijk worden weggeschreven. Dit wordt gedaan uit overwegingen van performance, opslagruimte en/of kosten. Voor veel toepassingen is het voldoende om uit deze logs trends te destilleren om zo fouten op te sporen of voorstellen voor verbetering te kunnen doen.

Wanneer dit zou worden toegepast bij onderhanden standaard, zou kunnen worden betoogd dat verantwoording nog altijd slaagt, omdat data voor een relevante, gerandomiseerde steekproef beschikbaar is. Echter, gelet op het belang van de verantwoording, en de wettelijke verplichtingen waaraan met de standaard invulling wordt gegeven, is dit onwenselijk voor het Logboek Dataverwerkingen. De Logregels vormen o.a. de basis voor de Informatieplicht en het Inzagerecht uit de AVG. Daarvoor is het nodig om over iedere Dataverwerking metagegevens vast te leggen.

Log Sampling is niet toegestaan.

Iedere logregel wordt weggeschreven in het LogBoek Dataverwerkingen
Wanneer een techniek voor loggen wordt toegepast waarbij Log Sampling is ingericht, moet ervoor worden gewaakt dat dit niet geldt voor de logregels die beschreven worden in deze standaard.

In dit hoofdstuk worden er voorbeelden beschreven van hoe de standaard gebruikt kan worden in verschillende scenario's om de lezer een beter beeld te geven van de standaard in zijn echte werking. Hierbij zijn er vier voorbeelden met elk een schets van de situatie, de uitgangspunten, het globale proces, de relatie tussen gegevens, de relatie met het Logboek Dataverwerkingen en het gedrag van de applicatie.

Een persoon heeft bij een gemeente een parkeervergunning in gebruik en wil de gegevens van deze vergunning bekijken.

Het beschreven proces is een voorbeeld, het werkelijke proces kan anders verlopen.
Het proces is een ‘happy flow’, dit betekent dat validaties en eventuele foutsituaties in dit voorbeeld niet in ogenschouw worden genomen.
Autorisatieprocessen zijn in dit voorbeeld niet meegenomen.
Een Loggingsregel wordt toegevoegd aan het logboek per geheel afgeronde transactie. Er wordt dus geen aparte logregel aangemaakt per ontvangen of verstuurd bericht.
Een aantal gegevens staan nog ter discussie (vanuit juridisch oogpunt). Voor de volledigheid worden een aantal gegevens in dit voorbeeld meegenomen. Het betreft de gegevens:
- resource/name/version
- receiver
- dataSubject

Een persoon vraagt in zijn ‘MijnOmgeving’ van de gemeente om de bestaande parkeervergunninggegevens.
De ‘MijnOmgeving’ van de gemeente verzoekt de parkeervergunningapplicatie om de actuele parkeervergunninggegevens van de persoon.
Het parkeervergunningsysteem voert dit verzoek uit. Daarna verzendt de parkeervergunningapplicatie de gevraagde gegevens naar de gemeente. Het parkeervergunningensysteem logt dat er gegevens verzonden zijn naar de gemeente.
De gemeente toont de gegevens aan de persoon en logt dat deze gegevens zijn getoond aan de persoon.

Schematisch ziet dit proces er als volgt uit:

De volgende gegevens worden gelogd in de diverse logmomenten:

Log opvragenVergunningen (log vergunningenapplicatie):

Attribuut	Waarde
operationId	8451dcd9ede037cb
operationName	opvragenVergunningen
parentOperationId	`<leeg>`
traceId	ccf5064a324163ed939bfa09c2bcb210
startTime	2024-05-30 08:40:37.000
endTime	2024-05-30 08:40:37.000
statusCode	OK
resource.name	Parkeeradmin
resource.version	2.1.6
receiver	`<leeg>`
attributeKey	dplCoreProcessingActivityId
attributeValue	rva:12f2ec2a-0cc4-3541-9ae6-219a178fcfe4
attributeKey	`<leeg>`
attributeValue	`<leeg>`
foreignOperation.traceId	c7a26dcd0bee0c8900e2174c43c3393c
foreignOperation.operationId	9f8971bfd093637d

Log opvragenVergunningen (log gemeente)

Attribuut	Waarde
operationId	9f8971bfd093637d
operationName	tonenVergunningen
parentOperationId	`<leeg>`
traceId	c7a26dcd0bee0c8900e2174c43c3393c
startTime	2024-05-30 10:40:37.821
endTime	2024-05-30 10:40:37.845
statusCode	OK
resource.name	MijnOmgeving
resource.version	1.0.5
receiver	27fdey98605etc48
attributeKey	dplCoreProcessingActivityId
attributeValue	rva:11x2ec2a-0774-3541-9b16-21ba179fcf15
attributeKey	dplCoreDataSubjectId
attributeValue	rva:13j2ec27-0cc4-3541-9av6-219a178fcfe5

Om uiteindelijk alle gegevens te kunnen rapporteren, is het van belang dat gegevens op een bepaalde manier aan elkaar gekoppeld zijn. In dit voorbeeld zijn de gegevens op de volgende manier gekoppeld: Alt text

De relatie met de doelstellingen die gesteld zijn in de standaard Logboek dataverwerkingen worden, op basis van dit voorbeeld, als volgt concreet gerealiseerd:

het wegschrijven van logs van dataverwerkingen: In dit voorbeeld is het de betrokkene zelf die via een portaal zijn eigen gegevens kan bekijken. Deze actie is een gegevensverwerking en wordt gelogd bij zowel de gemeenteapplicatie (gegevens worden getoond aan de betrokkene) als bij de vergunningenapplicatie (verstrekking specifieke informatie aan de gemeenteapplicatie).
het aan elkaar relateren van logs van dataverwerkingen: Er zijn in dit voorbeeld twee applicaties nodig om het totaal aan gevraagde informatie te kunnen tonen aan de betrokkene. Beide applicaties hebben een logboek voor verwerkte gegevens. Om een totaalbeeld van de gelogde gegevens te kunnen construeren, is een relatie tussen de logs nodig. In dit voorbeeld wordt de koppeling gelegd door het operationId en traceId (gemeentelogboek) te linken aan het foreignOperationId en foreignTraceId (vergunningenlogboek).
het aan elkaar relateren van dataverwerkingen over de grenzen van systemen: Naast het koppelen van logs van diverse applicaties, wordt ook een koppeling gelegd met het Register van verwerkingsactiviteiten. Dit gebeurt per applicatie op basis van het ProcessingActivityId (register) te koppelen aan dplCoreProcessingActivityId (logboek). De diverse registers hebben geen directe koppeling met elkaar.

Standaard Logverwerkingen: paragraaf 3.3.1 Gedrag

De applicatie MOET een Trace starten voor iedere Dataverwerking waarvan nog geen Trace bekend is. Bij elke start van een verwerking wordt een traceId aangemaakt. Bijvoorbeeld: in het voorbeeld komt er een bericht binnen bij de ‘MijnOmgeving’ van de gemeente (opvragenVergunningenVraag). Er wordt direct een traceId aangemaakt.
De applicatie MOET voor iedere Dataverwerking een logregel wegschrijven in een Logboek. Log Sampling is niet toegestaan. Een dataverwerking wordt opgeslagen als deze volledig is afgerond. In het voorbeeld is te zien dat een logregel wordt geschreven op het moment dat de vraag- en het antwoordbericht zijn afgerond.
De applicatie MOET bijhouden of een Dataverwerking geslaagd of mislukt is en dit per Dataverwerking als status meegeven aan het Logboek. Bij elke logregel in het voorbeeld staat de statusCode vermeld (‘OK’).
Als een Dataverwerking meerdere Betrokkenen heeft dan MOET de applicatie voor iedere betrokkene een aparte logregel wegschrijven. Een logregel kan naar 0 of 1 betrokkenen verwijzen. In het voorbeeld gaat het om één betrokkene (dplCoreDataSubjectId), er wordt steeds één logregel aangemaakt.
Als een applicatie aangeroepen kan worden vanuit een andere applicatie MOET de applicatie Trace Context metadata accepteren bij een dergelijke aanroepen deze metadata kunnen omzetten naar een foreign_operation bericht. Bij een externe verwerking (bijvoorbeeld opvragenVergunningen) geeft de ‘MijnOmgeving’ de traceId en OperationId mee aan de Vergunningenapplicatie. De vergunningenapplicatie registreert de traceId en operationId beide als ‘foreignOperation’.

Een persoon heeft bij een gemeente een parkeervergunning in gebruik en wil de gegevens van het kenteken van deze vergunning wijzigen.

Het beschreven proces is een voorbeeld, het werkelijke proces kan anders verlopen.
Het proces is een ‘happy flow’, dit betekent dat validaties en eventuele foutsituaties in dit voorbeeld niet in ogenschouw worden genomen.
Autorisatieprocessen zijn in dit voorbeeld niet meegenomen.
Een Loggingsregel wordt toegevoegd aan het logboek per geheel afgeronde transactie. Er wordt dus geen aparte logregel aangemaakt per ontvangen of verstuurd bericht.
Een aantal gegevens staan nog ter discussie (vanuit juridisch oogpunt). Voor de volledigheid worden een aantal gegevens in dit voorbeeld meegenomen. Het betreft de gegevens:
- resource/name/version
- receiver
- dataSubject

Een persoon vraagt in zijn 'MijnOmgeving' van de gemeente om de bestaande parkeervergunninggegevens.
De 'MijnOmgeving' van de gemeente verzoekt de parkeervergunningapplicatie om de actuele parkeervergunninggegevens van de persoon.
De parkeervergunningapplicatie voert dit verzoek uit. Daarna verzendt de parkeervergunningapplicatie de gevraagde gegevens naar de gemeente. De parkeervergunningapplicatie logt dat er gegevens verzonden zijn naar de gemeente.
De gemeente toont de gegevens aan de persoon en logt dat deze gegevens zijn getoond aan de persoon.
De persoon wijzigt het kenteken in de 'MijnOmgeving' van de gemeente.
De 'MijnOmgeving' van de gemeente verzoekt de parkeervergunningapplicatie om de wijziging af te handelen.
De parkeervergunningapplicatie verzoekt het RDW te controleren of het kenteken ook daadwerkelijk bij de persoon hoort.
Het RDW stuurt een antwoord terug naar de parkeervergunningapplicatie en logt de gegevensverwerking.
De parkeervergunningapplicatie logt het controleverzoek aan het RDW.
De parkeervergunningapplicatie wijzigt het kenteken van de persoon en logt het wijzigingsverzoek van de persoon.
Nadat de wijziging is gedaan in de parkeervergunningapplicatie, wordt het wijzigingsverzoek gelogd in de 'MijnOmgeving' van de gemeente.
De persoon vraagt in zijn 'MijnOmgeving' van de gemeente om de bestaande parkeervergunninggegevens.
De 'MijnOmgeving' van de gemeente verzoekt de parkeervergunningapplicatie om de actuele parkeervergunninggegevens van de persoon.
De parkeervergunningapplicatie voert dit verzoek uit. Daarna verzendt de parkeervergunningapplicatie de gevraagde gegevens naar de gemeente. De parkeervergunningapplicatie logt dat er gegevens verzonden zijn naar de gemeente.
De gemeente toont de gegevens aan de persoon en logt dat deze gegevens zijn getoond aan de persoon.

Schematisch ziet dit proces er als volgt uit:

De volgende gegevens worden gelogd in de diverse logmomenten:

1. Log opvragenVergunningen (log vergunningenapplicatie):

Attribuut	Waarde
operationId	8ee7b01aca8d01d9
operationName	opvragenVergunningen
parentOperationId	`<leeg>`
traceId	c6adf4df949d03c662b53e95debdc411
startTime	2024-07-29 08:16:49.000
endTime	2024-07-29 08:16:49.000
statusCode	OK
resource.name	Parkeeradmin
resource.version	2.1.6
receiver	`<leeg>`
attributeKey	dplCoreProcessingActivityId
attributeValue	12f2ec2a-0cc4-3541-9ae6-219a178fcfe4
attributeKey	`<leeg>`
attributeValue	`<leeg>`
foreignOperation.traceId	bc9126aaae813fd491ee10bf870db292
foreignOperation.operationId	b2e339a595246e01

2. Log tonenVergunningen (log gemeente)

Attribuut	Waarde
operationId	b2e339a595246e01
operationName	tonenVergunningen
parentOperationId	`<leeg>`
traceId	bc9126aaae813fd491ee10bf870db292
startTime	2024-07-29 10:16:49.690
endTime	2024-07-29 10:16:49.723
statusCode	OK
resource.name	MijnOmgeving
resource.version	1.0.5
receiver	27fdey98605etc48
attributeKey	dplCoreProcessingActivityId
attributeValue	11x2ec2a-0774-3541-9b16-21ba179fcf15
attributeKey	dplCoreDataSubjectId
attributeValue	13j2ec27-0cc4-3541-9av6-219a178fcfe5

3. Log controlerenKenteken (log RDW)

Attribuut	Waarde
operationId	433f276975204ccf
operationName	controlerenKenteken
parentOperationIdcontrolerenKenteken	`<leeg>`
traceId	8ccfd3c567c51d68937c263e00a352be
startTime	2024-07-29 08:17:02
endTime	2024-07-29 08:17:02
statusCode	OK
resource.name	BRV
resource.version	2.0
receiver	`<leeg>`
attributeKey	dplCoreProcessingActivityId
attributeValue	8c714e4a-a538-36f7-8b1f-37a6884cc68c
attributeKey	dplCoreDataSubjectId
attributeValue	`<leeg>`
foreignOperation.traceId	f176a58de7fe249ea37ed4f5979da02b
foreignOperation.operationId	414514cf1d40d6b2

4. Log controlerenKenteken (log vergunningenapplicatie)

Attribuut	Waarde
operationId	414514cf1d40d6b2
operationName	controlerenKenteken
parentOperationId	7a95b6989d2b28c7
traceId	f176a58de7fe249ea37ed4f5979da02b
startTime	2024-07-29 08:17:02.000
endTime	2024-07-29 08:17:02.000
statusCode	OK
resource.name	Parkeeradmin
resource.version	2.1.6
receiver	`<leeg>`
attributeKey	dplCoreProcessingActivityId
attributeValue	19u2dd2a-0cb7-3541-9ae6-217a178fc9e6
attributeKey	dplCoreDataSubjectId
attributeValue	`<leeg>`
foreignOperation.traceId	8a1325a32aef8de4ffba7d7c931eeaec
foreignOperation.operationId	ba7cac7ca0489e42

5. Log wijzigenKenteken (log vergunningenapplicatie)

Attribuut	Waarde
operationId	7a95b6989d2b28c7
operationName	wijzigenKenteken
parentOperationId	`<leeg>`
traceId	f176a58de7fe249ea37ed4f5979da02b
startTime	2024-07-29 08:17:02.000
endTime	2024-07-29 08:17:02.000
statusCode	OK
resource.name	Parkeeradmin
resource.version	2.1.6
receiver	`<leeg>`
attributeKey	dplCoreProcessingActivityId
attributeValue	0b1ff20a-3ecb-34bf-8cf5-e4cbacb046ab
attributeKey	dplCoreDataSubjectId
attributeValue	`<leeg>`
foreignOperation.traceId	c0a7a38d56f3f16a2163ca0071d3779a
foreignOperation.operationId	df524ee2a3fd5ddf

6. Log wijzigenKenteken (log gemeente)

Attribuut	Waarde
operationId	df524ee2a3fd5ddf
operationName	wijzigenKenteken
parentOperationId	`<leeg>`
traceId	c0a7a38d56f3f16a2163ca0071d3779a
startTime	2024-07-29 10:17:02.010
endTime	2024-07-29 10:17:02.039
statusCode	OK
resource.name	MijnOmgeving
resource.version	1.0.5
receiver	27fdey98605etc48
attributeKey	dplCoreProcessingActivityId
attributeValue	12c21c2a-0875-3543-9b16-21ja179fcf16
attributeKey	dplCoreDataSubjectId
attributeValue	13j2ec27-0cc4-3541-9av6-219a178fcfe5
foreignOperation.traceId	`<leeg>`
foreignOperation.operationId	`<leeg>`

7. Log opvragenVergunningen (log vergunningenapplicatie)

Attribuut	Waarde
operationId	6042d706f53fec76
operationName	opvragenVergunningen
parentOperationId	`<leeg>`
traceId	c6c2d53a5762d47779c57057d7983311
startTime	2024-07-29 08:17:02.000
endTime	2024-07-29 08:17:02.000
statusCode	OK
resource.name	Parkeeradmin
resource.version	2.1.6
receiver	`<leeg>`
attributeKey	dplCoreProcessingActivityId
attributeValue	12f2ec2a-0cc4-3541-9ae6-219a178fcfe4
attributeKey	`<leeg>`
attributeValue	`<leeg>`
foreignOperation.traceId	8a1325a32aef8de4ffba7d7c931eeaec
foreignOperation.operationId	ba7cac7ca0489e42

8. Log tonenVergunningen (log gemeente)

Attribuut	Waarde
operationId	ba7cac7ca0489e42
operationName	tonenVergunningen
parentOperationId	`<leeg>`
traceId	8a1325a32aef8de4ffba7d7c931eeaec
startTime	2024-07-29 10:17:02.274
endTime	2024-07-29 10:17:02.291
statusCode	OK
resource.name	MijnOmgeving
resource.version	1.0.5
receiver	27fdey98605etc48
attributeKey	dplCoreProcessingActivityId
attributeValue	11x2ec2a-0774-3541-9b16-21ba179fcf15
attributeKey	dplCoreDataSubjectId
attributeValue	13j2ec27-0cc4-3541-9av6-219a178fcfe5

De relatie met de doelstellingen die gesteld zijn in de standaard Logboek dataverwerkingen worden, op basis van dit voorbeeld, als volgt concreet gerealiseerd:

het wegschrijven van logs van dataverwerkingen: In dit voorbeeld is het de betrokkene zelf die via een portaal zijn eigen gegevens kan bekijken en wijzigen. Deze acties zijn gegevensverwerkingen en worden gelogd bij zowel de gemeenteapplicatie (gegevens worden getoond aan de betrokkene) als bij de vergunningenapplicatie (verstrekking specifieke informatie aan de gemeenteapplicatie).
het aan elkaar relateren van logs van dataverwerkingen: Er zijn in dit voorbeeld twee applicaties nodig om het totaal aan gevraagde informatie te kunnen tonen aan de betrokkene. Beide applicaties hebben een logboek voor verwerkte gegevens. Om een totaalbeeld van de gelogde gegevens te kunnen construeren, is een relatie tussen de logs nodig. In dit voorbeeld wordt de koppeling gelegd door het operationId en traceId (gemeentelogboek) te linken aan het foreignOperationId en foreignTraceId (vergunningenlogboek).
het aan elkaar relateren van dataverwerkingen over de grenzen van systemen: Naast het koppelen van logs van diverse applicaties, wordt ook een koppeling gelegd met het Register van verwerkingsactiviteiten. Dit gebeurt per applicatie op basis van het ProcessingActivityId (register) te koppelen aan dplCoreProcessingActivityId (logboek). De diverse registers hebben geen directe koppeling met elkaar.

De applicatie MOET een Trace starten voor iedere Dataverwerking waarvan nog geen Trace bekend is. Bij elke start van een verwerking wordt een traceId aangemaakt. Bijvoorbeeld: in het voorbeeld komt er een bericht binnen bij de ‘MijnOmgeving’ van de gemeente (opvragenVergunningenVraag). Er wordt direct een traceId aangemaakt.
De applicatie MOET voor iedere Dataverwerking een logregel wegschrijven in een Logboek. Log Sampling is niet toegestaan. Een dataverwerking wordt opgeslagen als deze volledig is afgerond. In het voorbeeld is te zien dat een logregel wordt geschreven op het moment dat de vraag- en het antwoordbericht zijn afgerond.
De applicatie MOET bijhouden of een Dataverwerking geslaagd of mislukt is en dit per Dataverwerking als status meegeven aan het Logboek. Bij elke logregel in het voorbeeld staat de statusCode vermeld (‘OK’).
Als een Dataverwerking meerdere Betrokkenen heeft dan MOET de applicatie voor iedere betrokkene een aparte logregel wegschrijven. Een logregel kan naar 0 of 1 betrokkenen verwijzen. In het voorbeeld gaat het om één betrokkene (dplCoreDataSubjectId), er wordt steeds één logregel aangemaakt.
Als een applicatie aangeroepen kan worden vanuit een andere applicatie MOET de applicatie Trace Context metadata accepteren bij een dergelijke aanroepen deze metadata kunnen omzetten naar een foreign_operation bericht. Bij een externe verwerking (bijvoorbeeld opvragenVergunningen) geeft de ‘MijnOmgeving’ de traceId en OperationId mee aan de Vergunningenapplicatie. De vergunningenapplicatie registreert de traceId en operationId beide als ‘foreignOperation’.

Deze case beschrijft de binnengemeentelijke verhuizing van een persoon. De beschrijving is functioneel zo eenvoudig mogelijk. De burger komt aan de balie en er is geen sprake van meeverhuizende gezinsleden.

Het beschreven proces is een voorbeeld, het werkelijke proces kan anders verlopen.
Het proces is een ‘happy flow’, dit betekent dat validaties en eventuele foutsituaties in dit voorbeeld niet in ogenschouw worden genomen.
Autorisatieprocessen zijn in dit voorbeeld niet meegenomen.
Een Loggingsregel wordt toegevoegd aan het logboek per geheel afgeronde transactie. Er wordt dus geen aparte logregel aangemaakt per ontvangen of verstuurd bericht.
Een aantal gegevens staan nog ter discussie (vanuit juridisch oogpunt). Voor de volledigheid worden een aantal gegevens in dit voorbeeld meegenomen. Het betreft de gegevens:
- resource/name/version
- receiver
- dataSubject

Schematisch ziet dit proces er als volgt uit:

De Baliemedewerker voert BSN van de burger in.
De Browser vraagt om persoonsgegevens bij de gemeentelijke Balieapplicatie.
De gemeentelijke Balieapplicatie vraag persoonsgegevens bij het BRP-systeem.
Het BRP systeem stuurt gevraagde gegevens naar de gemeentelijke Balieapplicatie en logt de aanvraag.
De gemeentelijke Balieapplicatie stuurt de gegevens naar de Browser en worden getoond aan de Baliemedewerker. De aanvraag wordt gelogd door de Balieapplicatie.
De Baliemedewerker voert de wijziging in en de Browser verstuurt de gegevens naar de gemeentelijke Balieapplicatie.
De gemeentelijke Balieapplicatie verstuurt de gegevens naar het BRP-systeem.
Het BRP-systeem verwerkt de wijziging, stuurt bevestiging terug naar de gemeentelijke Balieapplicatie en logt de verwerkingsactie.
De Browser vraagt de actuele persoonsgegevens op de gemeentelijke Balieapplicatie.
De gemeentelijke Balieapplicatie vraagt de persoonsgegevens op bij het BRP-systeem.
Het BRP-systeem stuurt de persoonsgegevens naar de gemeentelijke Balieapplicatie en logt de aanvraag.
De gemeentelijke Balieapplicatie stuurt de persoonsgegevens naar de Browser en logt de aanvraag.

Schematisch ziet dit proces er als volgt uit:

De volgende gegevens worden gelogd in de diverse logmomenten:

1. Log opvragenPersoonsgegevens (log BRP):

Attribuut	Waarde
operationId	7a22eb38-bca6-463f-9955-54ab040287cb
operationName	opvragenPersoonsgegevens
parentOperationId	`<leeg>`
traceId	c6adf4df949d03c662b53e95debdc411
startTime	2024-07-29 08:16:49.000
endTime	2024-07-29 08:16:49.000
statusCode	OK
resource.name	BRP
resource.version	2.0
receiver	`<leeg>`
attributeKey	dplCoreProcessingActivityId
attributeValue	12f2ec2a-0cc4-3541-9ae6-219a178fcfe4
attributeKey	`<leeg>`
attributeValue	`<leeg>`
foreignOperation.traceId	bc9126aaae813fd491ee10bf870db292
foreignOperation.operationId	b2e339a595246e01

2. Log tonenNAWGegevens (log gemeente)

Attribuut	Waarde
operationId	b2e339a595246e01
operationName	tonenNAWGegevens
parentOperationId	`<leeg>`
traceId	bc9126aaae813fd491ee10bf870db292
startTime	2024-07-29 10:16:49.690
endTime	2024-07-29 10:16:49.723
statusCode	OK
resource.name	Balieapp
resource.version	1.0.5
receiver	27fdey98605etc48
attributeKey	dplCoreProcessingActivityId
attributeValue	11x2ec2a-0774-3541-9b16-21ba179fcf15
attributeKey	dplCoreDataSubjectId
attributeValue	13j2ec27-0cc4-3541-9av6-219a178fcfe5

3. Log wijzigenPersoonsgegevens (log BRP)

Attribuut	Waarde
operationId	433f276975204ccf
operationName	wijzigenPersoonsgegevens
parentOperationId	`<leeg>`
traceId	8ccfd3c567c51d68937c263e00a352be
startTime	2024-07-29 08:17:02
endTime	2024-07-29 08:17:02
statusCode	OK
resource.name	BRP
resource.version	2.0
receiver	`<leeg>`
attributeKey	dplCoreProcessingActivityId
attributeValue	8c714e4a-a538-36f7-8b1f-37a6884cc68c
attributeKey	`<leeg>`
attributeValue	`<leeg>`
foreignOperation.traceId	f176a58de7fe249ea37ed4f5979da02b
foreignOperation.operationId	414514cf1d40d6b2

4. Log wijzigenPersoonsgegevens (log gemeente)

Attribuut	Waarde
operationId	414514cf1d40d6b2
operationName	wijzigenPersoonsgegevens
parentOperationId	`<leeg>`
traceId	f176a58de7fe249ea37ed4f5979da02b
startTime	2024-07-29 08:17:02.000
endTime	2024-07-29 08:17:02.000
statusCode	OK
resource.name	Balieapp
resource.version	1.0.5
receiver	`<leeg>`
attributeKey	dplCoreProcessingActivityId
attributeValue	19u2dd2a-0cb7-3541-9ae6-217a178fc9e6
attributeKey	dplCoreDataSubjectId
attributeValue	13j2ec27-0cc4-3541-9av6-219a178fcfe5
foreignOperation.traceId	`<leeg>`
foreignOperation.operationId	`<leeg>`

5. Log opvragenPersoonsgegevens (log BRP)

Attribuut	Waarde
operationId	7a95b6989d2b28c7
operationName	opvragenPersoonsgegevens
parentOperationId	`<leeg>`
traceId	f176a58de7fe249ea37ed4f5979da02b
startTime	2024-07-29 08:17:02.000
endTime	2024-07-29 08:17:02.000
statusCode	OK
resource.name	BRP
resource.version	2.0
receiver	`<leeg>`
attributeKey	dplCoreProcessingActivityId
attributeValue	0b1ff20a-3ecb-34bf-8cf5-e4cbacb046ab
attributeKey	dplCoreDataSubjectId
attributeValue	`<leeg>`
foreignOperation.traceId	c0a7a38d56f3f16a2163ca0071d3779a
foreignOperation.operationId	df524ee2a3fd5ddf

6. Log tonenNAWGegevens (log gemeente)

Attribuut	Waarde
operationId	df524ee2a3fd5ddf
operationName	tonenNAWGegevens
parentOperationId	`<leeg>`
traceId	c0a7a38d56f3f16a2163ca0071d3779a
startTime	2024-07-29 10:17:02.010
endTime	2024-07-29 10:17:02.039
statusCode	OK
resource.name	Balieapp
resource.version	1.0.5
receiver	27fdey98605etc48
attributeKey	dplCoreProcessingActivityId
attributeValue	12c21c2a-0875-3543-9b16-21ja179fcf16
attributeKey	dplCoreDataSubjectId
attributeValue	13j2ec27-0cc4-3541-9av6-219a178fcfe5
foreignOperation.traceId	`<leeg>`
foreignOperation.operationId	`<leeg>`

De relatie met de doelstellingen die gesteld zijn in de standaard Logboek dataverwerkingen worden, op basis van dit voorbeeld, als volgt concreet gerealiseerd:

het wegschrijven van logs van dataverwerkingen: In dit voorbeeld is het de Baliemedewerker die via een Balieapplicatie de gegevens van een Betrokkene kan bekijken en wijzigen. Deze acties zijn gegevensverwerkingen en worden gelogd bij zowel de Balieapplicatie als bij het BRP-systeem.
het aan elkaar relateren van logs van dataverwerkingen: Er zijn in dit voorbeeld twee applicaties nodig om het totaal aan gevraagde informatie te kunnen tonen aan de betrokkene. Beide applicaties hebben een logboek voor verwerkte gegevens. Om een totaalbeeld van de gelogde gegevens te kunnen construeren, is een relatie tussen de logs nodig. In dit voorbeeld wordt de koppeling gelegd door het operationId en traceId (gemeentelogboek) te linken aan het foreignOperationId en foreignTraceId (BRP-logboek).
het aan elkaar relateren van dataverwerkingen over de grenzen van systemen: Naast het koppelen van logs van diverse applicaties, wordt ook een koppeling gelegd met het Register van verwerkingsactiviteiten. Dit gebeurt per applicatie op basis van het ProcessingActivityId (register) te koppelen aan dplCoreProcessingActivityId (logboek). De diverse registers hebben geen directe koppeling met elkaar.

Standaard Logverwerkingen: paragraaf 3.3.1 Gedrag

De applicatie MOET een Trace starten voor iedere Dataverwerking waarvan nog geen Trace bekend is. Bij elke start van een verwerking wordt een traceId aangemaakt. Bijvoorbeeld: in het voorbeeld komt er een bericht binnen bij de Balieapplicatie van de gemeente (tonenNAWGegevens). Er wordt direct een traceId aangemaakt.
De applicatie MOET voor iedere Dataverwerking een logregel wegschrijven in een Logboek. Log Sampling is niet toegestaan. Een dataverwerking wordt opgeslagen als deze volledig is afgerond. In het voorbeeld is te zien dat een logregel wordt geschreven op het moment dat de vraag- en het antwoordbericht zijn afgerond.
De applicatie MOET bijhouden of een Dataverwerking geslaagd of mislukt is en dit per Dataverwerking als status meegeven aan het Logboek. Bij elke logregel in het voorbeeld staat de statusCode vermeld (‘OK’).
Als een Dataverwerking meerdere Betrokkenen heeft dan MOET de applicatie voor iedere betrokkene een aparte logregel wegschrijven. Een logregel kan naar 0 of 1 betrokkenen verwijzen. In het voorbeeld gaat het om één betrokkene (dplCoreDataSubjectId), er wordt steeds één logregel aangemaakt.
Als een applicatie aangeroepen kan worden vanuit een andere applicatie MOET de applicatie Trace Context metadata accepteren bij een dergelijke aanroepen deze metadata kunnen omzetten naar een foreign_operation bericht. Bij een externe verwerking (bijvoorbeeld opvragenPersoonsgegevens) geeft de Balieapplicatie de traceId en OperationId mee aan het BRP-systeem. Het BRP-systeem registreert de traceId en operationId beide als ‘foreignOperation’.

Deze case beschrijft de samenstelling van een huishouding op een bepaald adres. De beschrijving is functioneel zo eenvoudig mogelijk, een burger komt aan de balie en er is geen sprake van wijzigingen in de huishouding.

Het beschreven proces is een voorbeeld, het werkelijke proces kan anders verlopen.
Het proces is een ‘happy flow’, dit betekent dat validaties en eventuele foutsituaties in dit voorbeeld niet in ogenschouw worden genomen.
Autorisatieprocessen zijn in dit voorbeeld niet meegenomen.
Een Loggingsregel wordt toegevoegd aan het logboek per geheel afgeronde transactie. Er wordt dus geen aparte logregel aangemaakt per ontvangen of verstuurd bericht.
Een aantal gegevens staan nog ter discussie (vanuit juridisch oogpunt). Voor de volledigheid worden een aantal gegevens in dit voorbeeld meegenomen. Het betreft de gegevens:
- resource/name/version
- receiver
- dataSubject
Het is optioneel om het BSN (dplCoreDataSubjectId) te versleutelen ten behoeve van extra gegevensbeveiliging. In dit voorbeeld wordt versleuteling van gegevens toegepast.

Schematisch ziet dit proces er als volgt uit:

De Baliemedewerker voert adres van de burger in.
De Browser vraagt om persoonsgegevens bij de gemeentelijke Balieapplicatie.
De gemeentelijke Balieapplicatie vraag persoonsgegevens bij het BRP-systeem.
Het BRP systeem stuurt gevraagde gegevens naar de gemeentelijke Balieapplicatie en logt de aanvraag.
De gemeentelijke Balieapplicatie stuurt de gegevens naar de Browser en worden getoond aan de Baliemedewerker. De aanvraag wordt gelogd door de Balieapplicatie.

Schematisch ziet dit proces er als volgt uit:

De volgende gegevens worden gelogd in de diverse logmomenten:

1. Log opvragenPersoonsgegevens (log BRP) persoon 1:

Attribuut	Waarde
operationId	7a22eb38-bca6-463f-9955-54ab040287cb
operationName	opvragenPersoonsgegevens
parentOperationId	`<leeg>`
traceId	c6adf4df949d03c662b53e95debdc411
startTime	2024-07-29 08:16:49.000
endTime	2024-07-29 08:16:49.000
statusCode	OK
resource.name	BRP
resource.version	2.0
receiver	`<leeg>`
attributeKey	dplCoreProcessingActivityId
attributeValue	12f2ec2a-0cc4-3541-9ae6-219a178fcfe4
foreignOperation.traceId	bc9126aaae813fd491ee10bf870db292
foreignOperation.operationId	b2e339a595246e01
BSN 1	`<leeg>`
attributeKey	dplCoreDataSubjectId
attributeValue	ddj2ey299-0cf4-3541-9ar6-21ia178fcfrr
operationId	r2e3229059BG246e01
parentOperationId	7a22eb38-bca6-463f-9955-54ab040287cb

2. Log opvragenPersoonsgegevens (log BRP) persoon 2:

Attribuut	Waarde
operationId	7a22eb38-bca6-463f-9955-54ab040287cb
operationName	opvragenPersoonsgegevens
parentOperationId	`<leeg>`
traceId	c6adf4df949d03c662b53e95debdc411
startTime	2024-07-29 08:16:49.000
endTime	2024-07-29 08:16:49.000
statusCode	OK
resource.name	BRP
resource.version	2.0
receiver	`<leeg>`
attributeKey	dplCoreProcessingActivityId
attributeValue	12f2ec2a-0cc4-3541-9ae6-219a178fcfe4
foreignOperation.traceId	bc9126aaae813fd491ee10bf870db292
foreignOperation.operationId	b2e339a595246e01
BSN 2	`<leeg>`
attributeKey	dplCoreDataSubjectId
attributeValue	f4j2ey299-3er4-3aa41-9ar6-21ia178fc3tyy
operationId	9as5y3t-3ca7-463f-wwt9a5-54ab0402rft
parentOperationId	7a22eb38-bca6-463f-9955-54ab040287cb

3. Log tonenNAWGegevens (log gemeente) persoon 1:

Attribuut	Waarde
operationId	b2e339a595246e01
operationName	tonenNAWGegevens
parentOperationId	`<leeg>`
traceId	bc9126aaae813fd491ee10bf870db292
startTime	2024-07-29 10:16:49.690
endTime	2024-07-29 10:16:49.723
statusCode	OK
resource.name	Balieapp
resource.version	1.0.5
receiver	27fdey98605etc48
attributeKey	dplCoreProcessingActivityId
attributeValue	11x2ec2a-0774-3541-9b16-21ba179fcf15
BSN 1	`<leeg>`
attributeKey	dplCoreDataSubjectId
attributeValue	13j2ec27-0cc4-3541-9av6-219a178fcfe5
operationId	42f33gfa595246ert
parentOperationId	b2e339a595246e01

4. Log tonenNAWGegevens (log gemeente) persoon 2:

Attribuut	Waarde
operationId	b2e339a595246e01
operationName	tonenNAWGegevens
parentOperationId	`<leeg>`
traceId	bc9126aaae813fd491ee10bf870db292
startTime	2024-07-29 10:16:49.690
endTime	2024-07-29 10:16:49.723
statusCode	OK
resource.name	Balieapp
resource.version	1.0.5
receiver	27fdey98605etc48
attributeKey	dplCoreProcessingActivityId
attributeValue	11x2ec2a-0774-3541-9b16-21ba179fcf15
BSN 2	`<leeg>`
attributeKey	dplCoreDataSubjectId
attributeValue	342ec27-aa41-dav6-219a178f5ty6
operationId	aef53rfa59e240ert
parentOperationId	b2e339a595246e01

De relatie met de doelstellingen die gesteld zijn in de standaard Logboek dataverwerkingen worden, op basis van dit voorbeeld, als volgt concreet gerealiseerd:

het wegschrijven van logs van dataverwerkingen: In dit voorbeeld is het de Baliemedewerker die via een Balieapplicatie de gegevens van een Betrokkene kan bekijken. Deze acties zijn dataverwerkingen en worden gelogd bij zowel de Balieapplicatie als bij het BRP-systeem.
het aan elkaar relateren van logs van dataverwerkingen: Er zijn in dit voorbeeld twee applicaties nodig om het totaal aan gevraagde informatie te kunnen tonen aan de betrokkene. Beide applicaties hebben een logboek voor verwerkte gegevens. Om een totaalbeeld van de gelogde gegevens te kunnen construeren, is een relatie tussen de logs nodig. In dit voorbeeld wordt de koppeling gelegd door het operationId en traceId (gemeentelogboek) te linken aan het foreignOperationId en foreignTraceId (BRP-logboek). De aanroep van de gemeente-applicatie naar het BRP betreft één opvraag op basis van één adres, één operationId en één traceId. Het resultaat is meervoudig en moeten naar dezelfde operationId en traceId leiden van de gemeente-applicatie. Het onderscheid zit in de verschillende BSN’s van de personen die via een parentOperationiD gekoppeld zijn.
het aan elkaar relateren van dataverwerkingen over de grenzen van systemen: Naast het koppelen van logs van diverse applicaties, wordt ook een koppeling gelegd met het Register van verwerkingsactiviteiten. Dit gebeurt per applicatie op basis van het ProcessingActivityId (register) te koppelen aan dplCoreProcessingActivityId (logboek). De diverse registers hebben geen directe koppeling met elkaar.

Standaard Logverwerkingen: paragraaf 3.3.1 Gedrag

De applicatie MOET een Trace starten voor iedere Dataverwerking waarvan nog geen Trace bekend is. Bij elke start van een verwerking wordt een traceId aangemaakt. Bijvoorbeeld: in het voorbeeld komt er een bericht binnen bij de Balieapplicatie van de gemeente (tonenNAWGegevens). Er wordt direct een traceId aangemaakt.
De applicatie MOET voor iedere Dataverwerking een logregel wegschrijven in een Logboek. Log Sampling is niet toegestaan. Een dataverwerking wordt opgeslagen als deze volledig is afgerond. In het voorbeeld is te zien dat logregels worden geschreven op het moment dat de vraag- en het antwoordbericht zijn afgerond.
De applicatie MOET bijhouden of een Dataverwerking geslaagd of mislukt is en dit per Dataverwerking als status meegeven aan het Logboek. Bij elke logregel in het voorbeeld staat de statusCode vermeld (‘OK’).
Als een Dataverwerking meerdere Betrokkenen heeft dan MOET de applicatie voor iedere betrokkene een aparte logregel wegschrijven. Een logregel kan naar 0 of 1 betrokkenen verwijzen. In het voorbeeld gaat het om twee betrokkenen (dplCoreDataSubjectId), er wordt één logregel aangemaakt per BSN.
Als een applicatie aangeroepen kan worden vanuit een andere applicatie MOET de applicatie Trace Context metadata accepteren bij een dergelijke aanroepen deze metadata kunnen omzetten naar een foreign_operation bericht. Bij een externe verwerking (bijvoorbeeld opvragenPersoonsgegevens) geeft de Balieapplicatie de traceId en OperationId mee aan het BRP-systeem. Het BRP-systeem registreert de traceId en operationId beide als ‘foreignOperation’.

Dit project biedt een overzicht van gegevensverwerkingen binnen de overheid, waaronder het Register van de verwerkingsactiviteiten (RvvA). Dit register documenteert hoe gegevens worden verwerkt, waarschijnlijk ter ondersteuning van transparantie en naleving van de Algemene Verordening Gegevensbescherming (AVG).

Je kunt de voorbeeldapplicatie van het logboek en de specifieke RvvA-sectie hier bekijken:

Algemene inleiding - Logboek dataverwerkingen

Logius Praktijkrichtlijn Werkversie 13 december 2024

Samenvatting

Verwijzingen

Status van dit document

1. Conformiteit

2. Inleiding

2.1 Aanleiding en context van Logboek dataverwerkingen

2.1.1 Standaard Logboek dataverwerkingen

2.2 Scope van de Standaard Logboek dataverwerkingen

2.2.1 In scope van deze standaard

2.2.2 Buiten scope van deze standaard

2.3 Totstandkoming van de standaard

2.3.1 aanleiding en achtergrond

2.3.2 Interdisciplinaire aanpak

2.3.3 Beheer en doorontwikkeling

3. FAQ

3.1 Vragen

3.1.1 Wat is het doel van de standaard Logboek Dataverwerking?

3.1.2 Wie kan de standaard Logboek Dataverwerking gebruiken?

3.1.3 Is de standaard Logboek Dataverwerking alleen bedoeld voor de verwerking van persoonsgegevens?

3.1.4 Is in de standaard Logboek Dataverwerking opgenomen hoe logging plaatsvinden ten aanzien van beveiligingsincidenten (denk ook aan technische systeemactiviteiten en toegangsbeheer)?

3.1.5 Wie is eigenaar en beheerder van de standaard Logboek Dataverwerking?

3.1.6 Is mijn organisatie verplicht de standaard Logboek Dataverwerking te implementeren?

3.1.7 Wat is de relatie van Audit Log met de standaard Logboek Dataverwerking?

3.1.8 Zijn er dingen die je moet aanpassen aan je Audit Log als je de standaard Logboek Dataverwerking implementeert?

3.1.9 Kan je de standaard Logboek Dataverwerking implementeren als je een cloud (SaaS) applicatie gebruikt?

3.1.10 Is de performance van de standaard Logboek Dataverwerking getest? / Zal de standaard Logboek Dataverwerking de performance van mijn applicaties beperken?

3.1.11 Hoe werken het Register van verwerkingsactiviteiten (RvvA) en het Logboek Dataverwerkingen samen?

3.1.12 Moet ik mijn RvvA aanpassen als ik deze standaard Logboek Dataverwerking implementeer?

3.1.13 Mijn organisatie heeft geen RvvA API. (Hoe) Kan ik dan nog steeds de standaard Logboek Dataverwerking implementeren?

3.1.14 Hoe gedetailleerd moet mijn RvvA zijn om de standaard Logboek Dataverwerking te implementeren? / Heeft de detailniveau van mijn RvvA invloed op de werking van deze standaard?

3.1.15 Wat gebeurt er als ik mijn RvvA wil wijzigen na de implementatie van de Logboek Dataverwerkingenstandaard?

4. Architectuur

4.1 Context

4.1.1 Bedrijfsarchitectuur

4.1.2 Informatie­architectuur (Information systems architecture)

4.1.3 Technische architectuur (Technical architecture)

4.1.3.1 Netwerken en slimme apparaten

4.1.4 Software architectuur

4.1.4.1 Platformen voor dagelijkse exploitatie en huisvesting

4.1.4.2 Aspectgebieden

4.1.5 Relaties GDI architectuurprincipes en de standaard

4.2 De relatie tussen logboekelementen, waarom eigenlijk?

4.2.1 Welke relatiegegevens moeten er dan worden opgeslagen per Logregel?

4.2.2 Het logboek en het Register van Verwerkingsactiviteiten

4.2.3 TraceId als grootste gemene deler

4.2.4 Relatie tussen (sub)Operations

4.2.5 Voorbeeld van een traceringsconstructie

4.2.6 Situatieschets

4.2.7 Procesgang

4.2.8 traceId

4.2.9 OperationId

4.2.10 Totaalbeeld

4.3 Canoniek Gegevensmodel

4.3.1 attribute

4.3.2 dplCoreDataSubjectId

4.3.3 dataSubjectCategories

4.3.4 dplCoreProcessingActivityId

4.3.5 endTime

4.3.6 envisagedTimeLimit

4.3.7 foreignOperation.entity

4.3.8 foreignOperation.operationId

4.3.9 LegalBasis

4.3.10 LegalBasisComment

4.3.11 operationId

4.3.12 operationName

4.3.13 parentDplCoreProcessingActivityId

4.3.14 parentOperationId

4.3.15 personalDataCategories

4.3.16 purpose

4.3.17 recipientsCategories

4.3.18 resource.attribute

4.3.19 resource.name

4.3.20 resource.version

4.3.21 startTime

4.3.22 statusCode

4.3.23 traceId

5. Besluitenlijst

5.1 Logregels bevatten alleen wat nodig is voor verantwoording door verantwoordelijke

Logius Praktijkrichtlijn
Werkversie 13 december 2024

4.1.2 Informatiearchitectuur (Information systems architecture)