Dit document is ook beschikbaar in dit niet-normatieve formaat: PDF
Dit document valt onder de volgende licentie:
Creative Commons Attribution 4.0 International Public License
Dit is een werkversie die op elk moment kan worden gewijzigd, verwijderd of vervangen door andere documenten. Het is geen door het TO goedgekeurde consultatieversie.
Naast onderdelen die als niet-normatief gemarkeerd zijn, zijn ook alle diagrammen, voorbeelden, en noten in dit document niet-normatief. Verder is alles in dit document normatief.
De trefwoorden MOET en MOETEN in dit document moeten worden geïnterpreteerd als in BCP 14 [RFC2119] [RFC8174] als, en alleen als deze in hoofdletters zijn weergegeven, zoals hier getoond.
Dit document is onderdeel van een standaard voor het loggen van dataverwerkingen in de Nederlandse publieke sector. De governance van deze standaard wordt beschreven in het API-Standaarden beheermodel, gepubliceerd door Logius.
De overheid wil voor burgers en bedrijven zo transparant mogelijk zijn in de omgang met hun data. 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. Voor een optimale samenwerking over organisaties en bronnen heen is voor deze logging een algemene standaard nodig.
Transparantie en verantwoording naar burgers is één van de drijfveren voor ontwikkeling van deze logging standaard, maar geen onderdeel van de standaard. De standaard richt zich op vastlegging van de logging en deze eenduidige vastlegging maakt het mogelijk om, via een extensie, inzage mogelijk te maken.
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 | 1.0.0 | Logboek dataverwerkingen (werkversie) | logboek-dataverwerkingen |
| 2. De Algemene Inleiding | 1.0.0 | De Algemene Inleiding (werkversie) | logboek-dataverwerkingen-inleiding |
| 3. Het Juridische Beleidskader | 1.0.0 | Juridisch Beleidskader (werkversie) | logboek-dataverwerkingen-juridisch-beleidskader |
| 4. LDV Extensie Guideline | 1.0.0 | Guideline voor het schrijven van een extensie voor LDV (werkversie) | logboek-extensie-template |
Dit onderdeel is niet-normatief.
We moedigen gebruikers aan om meldingen of suggesties aan te maken via GitHub. Mocht dit niet mogelijk zijn, dan kunt u ook een e-mail sturen naar api@logius.nl.
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/
Hier gaat het om de extensie lezen op de standaard logboek dataverwerkingen: Een algemeen toepasbare standaard voor het lezen van gelogde overheidsdata. Deze standaard zal interoperabel kunnen werken met meerdere logging standaarden; Tenminste zal de standaard werken met de Logboek Dataverwerkingen standaard. De beschrijving van standaard zal gebeuren in de vorm van een extensie op de Logboek Dataverwerkingen standaard.
De standaard Logboek Dataverwerkingen beschrijft een manier om technisch interoperabele functionaliteit voor het loggen van dataverwerkingen te implementeren, door voor de volgende functionaliteit de interface en het gedrag voor te schrijven:
De extensie lezen breid deze uit met de mogelijkheid te kunnen lezen:
Per logboek MOET er één lezen API beschikbaar zijn. Deze geeft toegang tot alle dataverwerkingen die in dit logboek zijn opgeslagen. Indien de verwerkingsactiviteit over meerdere applicaties (met eigen logboeken) gaat, dienen alle lezen APIs bevraagd te worden om een compleet beeld van de verwerkingsactiviteit te krijgen. Wanneer er binnen één organisatie meerdere logboeken zijn dan MOETEN deze vanuit oogpunt van de extensie lezen gezien worden als aparte applicaties en voor elk logboek de lezen API implementeren.
De extensie voegt een extra attribuut toe aan dataverwerkingen bovenop de core standaard waarmee een aangeroepen externe organisatie (en bijbehorende lezen API) geidentificeerd kan worden.
Het bevragen van de lezen APIs begint altijd bij de applicatie waar de verwerkingsactiviteit gestart is. Vanuit de daar opgevraagde dataverwerkingen zijn dan de URLs van APIs te vinden die als volgende bevraagd moeten worden om een compleet beeld van de verwerkingsactiviteit te krijgen. Op deze manier kan iteratief een compleet beeld opgebouwd worden.
De lezen API kent één type resource Dataverwerkingen volgens de core standaard logboek dataverwerkingen oftewel ProcessingActivities in opentelemetry. Voor het bevragen van deze resource MOET tenminste een van de volgende parameters meegegeven worden:
Wanneer dit bij een request aan de server niet gebeurd, MOET de server antwoorden met een HTTP 400 Bad Request, die aangeeft dat hieraan niet voldaan is.
Wanneer geen query paramaters worden meegegeven, dan zou de server alle dataverwerkingen terug moeten geven. Het risico is dan groot dat zowel client als server dit niet aankunnen, alsmede dat er teveel gegevens worden gedeeld.
aanbeveling: Het is verstandig als de server ook bij het toepassen van query parameters een maximum stelt aan het aantal terug te geven dataverwerkingen.
De extensie lezen voegt één attribuut toe ten opzichte van de Core standaard. Het stelt in staat te verwijzen naar de volgende partij of applicatie in de keten waar verdere logging over een ketenproces te vinden is. Registreer bij iedere verwerking die een externe partij aanroept de URL van de lezen API waar je de verwerkingen van die partij kan opzoeken. Indien er geen sprake is van het aanroepen van een andere API, dan MOET dit attribuut niet toegevoegd worden. Wanneer er wel een volgende partij is maar deze de extensie lezen (nog) niet implementeert kan je in dit attribuut een URL die verwijst naar een pagina met contactgegevens opnemen. Dit attribuut MOET een specifieke waarde hebben ongeacht het gebruikte detailniveau.
| Veld | Type | Beschrijving |
|---|---|---|
| dpl.read.nextLogbookId | String | verwijzing naar de lezen API van de aan te roepen externe applicatie of partij. uri naar uniek identificeerbare API volgens extensie lezen |
De TraceID wordt voor organisatie overstijgende processen gevuld met de W3C TracecontextID en anders met een interne ID waarmee alle logging die bij één instantie van een proces hoort aan elkaar gerelateerd wordt. Deze usecase gaat ervanuit dat de TraceID bekend is en dat je alle bijbehorende logging op wil vragen.
De processingActivityID wordt gevuld met een verwijzing naar de verwerkingsactiviteit (verwerkingsregister bij core standaard of algoritmeregister i.h.g.v. objecten extensie) die uitgevoerd wordt. Je wil dan alle traceIDs terugkrijgen die voor deze verwerkingsactiviteit bekend zijn.
De dataSubjectId gevuld met een verwijzing naar de betrokkene van verwerkingen. Je wil dan alle traceIDs terugkrijgen die voor deze betrokkene bekend zijn. Het is hierbij aan te bevelen het gebruik van BSN en andere gevoelige personsgegevens in de logging te vermijden. Het waar mogelijk toepassen van pseudoniemen verminderd de kans op datalekken.
Hierbij wil je filters kunnen toepassen tenminste op start_time en/of end_time einde van de dataverwerkingen. We kiezen ervoor om in de interface de REST API Designrules te volgen voor het aangeven van tijd. Deze kent andere conventies dan Open Telemetry waarin tijdstippen volgens de core standaard van logboek dataverwerkingen wordt vastgelegd. De implementatie van de lezen API zal dus een vertaling moeten maken van het OTLP formaat naar het ADR formaat.
In de OAS specificatie staat geen authenticatie voor de lezen API gespecificeerd. Dit is bewust niet normatief neergezet om per implementatie de vrijheid te hebben dit binnen het domein waarin de standaard wordt geimplementeerd open te laten. Het is echter wel belangrijk om het endpoint goed te beveiligen. Dus zorg tenminste voor authenticatie van de client die de lezen API bevraagd en richt autorisatie regels in zodat een client alleen toegang krijgt tot loggingregels waar deze recht op heeft. In zijn algemeenheid biedt de module access control van het kennisplatform APIs hier goede handvaten voor. De referentie-implementatie van logboek dataverwerkingen geeft één specifiek voorbeeld voor hoe dit gedaan kan worden.
De logboek dataverwerking standaard is op 9 april 2026 in de PGDI vastgesteld. Deze standaard stelt overheden in staat om hun dataverwerkingen op een uniforme manier vast te leggen en te verantwoorden. Daarnaast maakt de standaard het mogelijk om deze verantwoordingen aan elkaar te relateren, zodat de keten van dataverwerkingen tussen organisaties volledig inzichtelijk wordt.
Een volgende stap is om ervoor te zorgen dat de gegevens die conform de standaard zijn opgeslagen worden opgehaald en daarmee ook getoond kunnen worden. Binnen het logboek dataverwerkingen is een logboek Dataverwerkingen Extensie Lezen gemaakt. Zo zorgen we ervoor dat de opgeslagen informatie toegankelijk wordt. Dit toegankelijk maken wordt gestandaardiseerd. Hiermee willen we bereiken, dat als iedereen dit op eenzelfde manier doet, we van elkaar snappen wat we zien en dat gegevensverwerkingen over organisatiegrenzen heen raadpleegbaar worden.
Met de leesextensie voor logboek dataverwerkingen wordt er bijgedragen aan een aantal maatschappelijke doelen:
Het beleids- en juridisch kader is geschreven voor organisaties die de standaard gaan implementeren. De standaard is voor organisaties generiek toe te passen en te gebruiken voor verschillende doeleinden die zij heeft. De organisatie kan hiermee inzicht geven in gegevens die zij verwerkt en daarmee gemakkelijker, eenduidiger en sneller reageren op informatieverzoeken. Deze informatieverzoeken kunnen van verschillende afzenders komen en kent daarmee verschillende doelgroepen, bijvoorbeeld:
Om zich te verantwoorden, is het soms nodig dat de overheid de logging die zij onder de Standaard Logboek Dataverwerkingen vastlegt, ook uitleesbaar maakt. Dit zodat zij transparant kunnen zijn over wat zij met data hebben gedaan.
Informatieverzoeken aan de overheid kunnen zijn gebaseerd op verschillende wettelijke kaders, waaronder onder andere de AVG, de Awb of de Woo.
Een overheidsorganisatie kan de vraag krijgen inzage te geven in persoonsgegevens in het kader van de rechten van betrokkene onder de [AVG]. De AVG regelt rechten met betrekking tot persoonsgegevens, namelijk in artikel 13 en in artikel 16voor rectificatie (van onjuiste gegevens). Het inzagerecht op grond van artikel 15 AVG omvat niet alleen het verstrekken van een kopie van persoonsgegevens (lid 3), maar ook het verstrekken van aanvullende contextinformatie als bedoeld in artikel 15, eerste lid, onder a tot en met h, AVG. Het enkel beschikbaar stellen van loggegevens is in beginsel niet voldoende om volledig aan dit recht te voldoen.
Daarnaast gelden procedurele vereisten op grond van artikel 12 AVG. Zo moet informatie in een transparante en begrijpelijke vorm worden verstrekt, dient in beginsel binnen één maand te worden gereageerd en moet bij een (gedeeltelijke) afwijzing worden gewezen op de openstaande rechtsmiddelen.
Zie voor een uitleg van deze informatieverplichtingen paragraaf "Informatieverplichtingen in de AVG" in het juridisch beleidskader van de normatieve standaard.
Een overheidsorganisatie kan gevraagd worden informatie aan te leveren in het kader van een onderzoek van een toezichthouder. Toezichthouders zijn personen die op grond van een wet belast zijn met het houden van toezicht op bepaalde wettelijke regels. Denk bijvoorbeeld aan ambtenaren van de arbeidsinspectie, of de belastinginspecteur.
Een toezichthouder kan verschillende soorten informatie vorderen onder de Awb, waaronder inlichtingen (art. 5:16 Awb) en inzage in zakelijke gegevens (art. 5:17 Awb). De informatie die aangeleverd moet worden, zal dus afhangen van het informatieverzoek en is niet beperkt tot enkel persoonsgegevens. Als een toezichthouder een informatieverzoek doet, heeft degene tot wie dat verzoek zich richt in beginsel verplicht een medewerkingsplicht (art. 5:20 lid 1 Awb).
Welke gegevens of bescheiden moeten worden aangeleverd is dus afhankelijk van het verzoek (of de vordering) van de betreffende toezichthouder. Wat een toezichthouder mag opvragen hangt ook af van de taak van de toezichthouder.
Ook een beroep op de Wet open overheid kan ervoor zorgen dat informatie gegeven moet worden. De Wet open overheid (Woo) regelt het recht van burgers om overheidsinformatie in te zien en de verplichtingen van bestuursorganen om zulke informatie beschikbaar te stellen (art. 1.1 en 2.1 - 2.5 Woo). Het uitgangspunt is dat informatie openbaar is, tenzij er een specifieke uitzondering geldt (art. 3.1 lid 1). Het doel is transparantie: burgers moeten inzicht kunnen krijgen in hoe besluiten tot stand komen en welke informatie een bestuursorgaan beheert.
De Woo geldt voor informatie die wordt beheerd door bestuursorganen (art. 2.2 - 2.4 Woo). Dit kan gaan om bijvoorbeeld beleidsdocumenten, besluitvorming, en gegevens die bestuursorganen gebruiken bij uitvoering van hun taken. Niet alle informatie hoeft openbaar te zijn; uitzonderingen zijn opgenomen in art. 5.1 Woo.
Zoals ook al geconcludeerd in de Standaard Logboek Dataverwerkingen, kan logging die wordt vastgelegd vele verschillende doelen dienen, zoals de invulling van specifieke informatieverschaffing aan burgers, of de verantwoording over de zorgvuldigheid van overheidshandelen.
Het is daarbij belangrijk onderscheid te maken tussen formele verzoeken in juridische zin en andere vormen van informatieverstrekking. Een formeel verzoek, zoals een verzoek op grond van
de AVG of de Woo, kwalificeert als een aanvraag in de zin van artikel 1:3, eerste lid, Awb, waartegen rechtsbescherming open staat.
Het enkel uitlezen van logging via een leesextensie of applicatie, zonder expliciet verzoek en zonder dat een besluit wordt genomen, kwalificeert in beginsel niet als een dergelijk formeel verzoek.
Met de toepassing van de Leesextensie, dient ook de manier van uitlezen van de gelogde dataverwerkingen op een standaardwijze plaats te vinden. De context en het doel waarvoor de gelogde dataverwerkingen uit te lezen zijn, is daarbij buiten scope (de wijze van uitlezen is "neutraal"). Het is aan de verantwoordelijke organisatie om te bepalen welke informatie zij, volgens welke verplichting, aan wie verstrekken. De standaard helpt om de gelogde dataverwerkingen inzichtelijk te maken: als organisatie maak je de keuze wat je aan wie laat zien.
Hieronder zijn een aantal uitgangspunten en principes benoemd. Voordat organisaties de leesextensie gaat implementeren, wordt aanbevolen om hier in de organisatie zelf naar te kijken.
{
"openapi": "3.0.2",
"info": {
"title": "LDV lezen API",
"description": "API voor het lezen van Logboek dataverwerkingen",
"version": "1.1.0",
"license": {
"name": "CC4",
"url": "https://github.com/Logius-standaarden/API-Design-Rules/blob/develop/LICENSE"
},
"contact": {
"name": "Standaard logboek dataverwerkingen extensie lezen",
"email": "api@logius.nl",
"url": "https://logius-standaarden.github.io/logboek-extensie-lezen/"
}
},
"servers": [
{
"url": "https://addyourserverhe.re/lezenapi/v1"
}
],
"tags": [
{
"name": "ProcessingActivities",
"description": "Alle API operaties die bij processingActivities horen."
}
],
"paths": {
"/processing-activities": {
"post": {
"operationId": "listProcessingActivitiesPost",
"description": "Alle dataverwerkingen ophalen",
"summary": "Alle dataverwerkingen ophalen",
"tags": ["ProcessingActivities"],
"requestBody": {
"$ref": "#/components/requestBodies/ProcessingActivityRequest"
},
"responses": {
"200": {
"$ref": "#/components/responses/ProcessingActivitiesResponse"
},
"400": {
"$ref": "#/components/responses/BadRequest"
},
"401": {
"$ref": "#/components/responses/Unauthorized"
}
}
}
}
},
"components": {
"requestBodies": {
"ProcessingActivityRequest": {
"required": true,
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/ProcessingActivityRequest"
}
}
}
}
},
"responses": {
"ProcessingActivitiesResponse": {
"description": "OK",
"headers": {
"API-Version": {
"$ref": "https://static.developer.overheid.nl/adr/components.yaml#/headers/API-Version"
}
},
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/ListProcessingActivities"
}
}
}
},
"BadRequest": {
"description": "Bad Request",
"headers": {
"API-Version": {
"$ref": "https://static.developer.overheid.nl/adr/components.yaml#/headers/API-Version"
}
},
"content": {
"application/problem+json": {
"schema": {
"$ref": "#/components/schemas/Nlgovproblem"
}
}
}
},
"Unauthorized": {
"description": "Unauthorized",
"headers": {
"API-Version": {
"$ref": "https://static.developer.overheid.nl/adr/components.yaml#/headers/API-Version"
}
},
"content": {
"application/problem+json": {
"schema": {
"$ref": "#/components/schemas/Nlgovproblem"
}
}
}
}
},
"schemas": {
"Nlgovproblem": {
"$ref": "./ProblemJson.schema.json"
},
"Attributes": {
"x-comment": "Dit is een verwijzing naar een schema met de attributen die je voor jouw implementatie nodig hebt, indien je enkel LDV core toepast dan volstaat een referentie naar https://schemas.don.projects.digilab.network/logboek-dataverwerkingen/attributes anders wordt aangeraden dit lokale bestand aan te passen",
"$ref": "./attributes.schema.json"
},
"ProcessingActivityRequest": {
"type": "object",
"allOf": [
{
"$ref": "#/components/schemas/Attributes"
},
{
"type": "object",
"properties": {
"traceId": {
"$ref": "#/components/schemas/TraceID"
},
"startTime": {
"$ref": "#/components/schemas/StartTime"
},
"endTime": {
"$ref": "#/components/schemas/EndTime"
}
}
}
],
"minProperties": 1,
"description": "Minimaal één moet gevuld zijn, zorg voor een zo exact mogelijke zoekopdracht"
},
"TraceID": {
"type": "string",
"format": "uuid",
"description": "Unieke identificerende code van Trace die Dataverwerking volgt",
"example": "ef4e77b9-b03b-585f-b613-5fcf8d8555fb",
"externalDocs": {
"description": "Definitie van Trace in de standaard logboek dataverwerkingen",
"url": "https://logius-standaarden.github.io/logboek-dataverwerkingen/#dfn-traces"
}
},
"StartTime": {
"type": "string",
"format": "date-time",
"description": "Tijdstip waarop de Actie gestart is, in RFC 3339 formaat",
"example": "2026-01-01T06:30:00.000Z",
"externalDocs": {
"description": "Definitie van start_time in de standaard logboek dataverwerkingen",
"url": "https://logius-standaarden.github.io/logboek-dataverwerkingen/#start_time"
}
},
"EndTime": {
"type": "string",
"format": "date-time",
"description": "Tijdstip waarop de Actie beëindigd is, in RFC 3339 formaat",
"example": "2026-01-01T06:30:00.000Z",
"externalDocs": {
"description": "Definitie van end_time in de standaard logboek dataverwerkingen",
"url": "https://logius-standaarden.github.io/logboek-dataverwerkingen/#end_time"
}
},
"ListProcessingActivities": {
"type": "object",
"required": ["processingActivities"],
"properties": {
"metadata": {
"$ref": "#/components/schemas/Metadata"
},
"processingActivities": {
"type": "array",
"items": {
"$ref": "#/components/schemas/ProcessingActivity"
}
}
}
},
"ProcessingActivity": {
"description": "Dataverwerking",
"type": "object",
"required": [
"traceId",
"spanId",
"status",
"name",
"startTime",
"endTime"
],
"properties": {
"traceId": {
"$ref": "#/components/schemas/TraceID"
},
"startTime": {
"$ref": "#/components/schemas/StartTime"
},
"endTime": {
"$ref": "#/components/schemas/EndTime"
},
"spanId": {
"type": "string",
"pattern": "^[0-9a-fA-F]{16}$",
"description": "Unieke identificerende code van Actie binnen de Dataverwerking",
"example": "beb0291b5162d850",
"externalDocs": {
"description": "Definitie van Actie in de standaard logboek dataverwerkingen",
"url": "http://gitdocumentatie.logius.nl/publicatie/logboek/dataverwerkingen/#span_id"
}
},
"status": {
"type": "string",
"description": "Status van de Actie",
"enum": ["Unset", "Ok", "Error"]
},
"name": {
"type": "string",
"description": "Naam van de specifieke Actie binnen de Dataverwerking",
"example": "verwerken van gegevens"
},
"parentSpanId": {
"type": "string",
"pattern": "^[0-9a-fA-F]{16}$",
"description": "Unieke identificerende code aanroepende Actie binnen huidige Trace",
"example": "beb0291b5162d850"
},
"resource": {
"description": "Een object met velden dat gebruikt wordt om een systeem, applicatie of component aan te duiden op een manier die binnen de organisatie gebruikelijk is. Denk hierbij aan velden als naam en versienummer van een applicatie, of een verwijzing naar een record in een CMDB",
"type": "object",
"properties": {
"attributes": {}
},
"externalDocs": {
"description": "Uitleg van CMDB volgens ITIL v3",
"url": "https://gitdocumentatie.logius.nl/publicatie/logboek/dataverwerkingen/#resource"
}
},
"attributes": {
"$ref": "#/components/schemas/Attributes"
}
}
},
"Metadata": {
"description": "Metadata van een Logboek",
"type": "object",
"required": ["logbookId", "organizationName"],
"properties": {
"logbookId": {
"type": "string",
"description": "Unieke identificerende code van het Logboek"
},
"organizationName": {
"type": "string",
"description": "Organisatie waartoe dit Logboek behoort"
}
}
}
}
}
}