Logboek Dataverwerkingen Extensie Lezen

Logius Praktijkrichtlijn
Werkversie

Deze versie:
https://logius-standaarden.github.io/logboek-extensie-lezen/
Laatst gepubliceerde versie:
https://logius-standaarden.github.io/logboek-extensie-lezen/
Laatste werkversie:
https://logius-standaarden.github.io/logboek-extensie-lezen/
Redacteurs:
Nil Barua (Logius)
Tim van der Lippe (Logius)
Auteurs:
Frank Terpstra (Geonovum)
Tim van der Lippe (Logius)
Henk Erik van der Hoek (Geonovum)
Doe mee:
GitHub Logius-standaarden/logboek-extensie-lezen
All issues
Dien een melding in
Revisiehistorie
Pull requests

Dit document is ook beschikbaar in dit niet-normatieve formaat: PDF


Status van dit document

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.

Conformiteit

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.

Abstract

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.

Context bij de standaard

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.

Verwijzingen

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

1. Feedback en Issues

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.

2. Naam en beschrijving

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.

2.1 Doel en nut

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:

3. Technische specificatie

3.1 Architectuur

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.

3.2 Werking lezen API

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.

Noot

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.

3.3 Toevoeging bij schrijven Logs

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

3.3.1 Query op basis van traceID

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.

3.3.2 Query op basis van processingActivityID

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.

3.3.3 Query op basis van dataSubjectId

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.

3.3.4 Query op starttijd/eindtijd

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.

3.4 Beveilingsoverwegingen (Security considerations)

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.

3.5 Todo

4. Gebruiksscenario's

4.1 Query voorbeelden

4.1.1 Voorbeeld query op basis van traceID

4.1.2 Voorbeeld query op basis van processingActivityID

4.1.3 Voorbeeld query op basis van dataSubjectId

4.1.4 Voorbeeld query op basis van start_time/end_time

4.2 voorbeeld loggen url lezen API externe partij

4.3 voorbeeld compleet beeld verwerkingsactiviteit krijgen door meerdere lezen APIs aan te roepen

5. Juridische Beleidskader

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.

5.1 Maatschappelijke doelen

Met de leesextensie voor logboek dataverwerkingen wordt er bijgedragen aan een aantal maatschappelijke doelen:

5.2 Toepassing van de extensie lezen

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:

5.3 Uitleesbaarheid van eenduidige logging ten behoeve van de uitvoering van informatieverplichtingen

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.

5.3.1 Aanleveren informatie n.a.v. AVG verplichtingen

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.

5.3.2 Aanleveren informatie bij toezicht

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.

5.3.3 Wet open overheid (Woo)

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.

5.3.4 Formele verzoeken in juridische zin versus andere vormen van informatieverstrekking

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.

5.4 Leidende principes van de Leesextensie bij implementatie

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.

5.4.1 Gegevens worden vastgelegd en uitleesbaar gemaakt

  1. Overheidsorganisaties die gebruik maken van de standaard Logboek dataverwerkingen inclusief de extensie lezen om de verwerking van data gestandaardiseerd zichtbaar te maken, zijn zelf verantwoordelijk voor implementatie en inrichting van de standaard, de logs en de informatie die erin te vinden is.
  2. Dataverwerkingen worden waar mogelijk gemakkelijk inzichtelijk gemaakt. Overheidsorganisaties maken een afweging over welke gegevens proactief inzichtelijk gemaakt kunnen worden en welke niet. Een organisatie kan daarmee ook bepalen welke informatieverzoeken in de regel worden toegekend en besluiten of deze informatie al proactief open kan worden gezet, al dan niet afgeschermd door authenticatie. Het is uiteindelijk aan de overheidsorganisatie zelf om te beoordelen welke informatie al vooraf inzichtelijk gemaakt wordt en welke naar aanleiding van een informatieverzoek (zoals de AVG of Woo) getoond wordt. Deze vorm van proactief beschikbaar maken van informatie moet worden onderscheiden van formele verzoekprocedures en vormt geen recht in de zin van artikel 15 AVG of in de zin van de Woo, maar kan deze mogelijk wel ondersteunen.
  3. Bij het tonen van informatie moet de organisatie rekening houden met zwaarder wegende algemene belangen (bijv. nationale/openbare veiligheid, opsporing van strafbare feiten) of zwaarder wegende belangen van betrokkene of rechten van anderen (bijv. bescherming persoon) waardoor bepaalde informatieverplichtingen niet gelden. Dit kan bijvoorbeeld door bij een verwerkingsactiviteit een vertrouwelijke en niet-vertrouwelijke variant op te nemen, waardoor het vanuit de logfile inzichtelijk is of er bij de betreffende verwerking rekening moet worden gehouden met zwaarder wegende belangen.
  4. De organisatie borgt dat de Leesextensie optimaal ingericht wordt ten behoeve van ondersteuning van het versterken van de informatiepositie van de burger, door proactief en waar mogelijk geautomatiseerd, de informatie die zij heeft te verschaffen.

5.4.2 Naleving en vertrouwen

  1. De extensie lezen dient zodanig ingericht te worden dat deze voldoet aan de vereisten die volgen uit regels ten aanzien van informatieveiligheid. De organisatie bepaalt vooraf de procedurele, procesmatige en technische waarborgen die nodig zijn om ervoor te zorgen dat de uitleesbaar gemaakte gegevens niet oneigenlijk worden gebruikt of misbruikt.
Noot
Hierbij geldt dat het voldoen aan eisen van informatieveiligheid onder de Cyberbeveiligingswet niet uitsluiten een technische aangelegenheid is. De verantwoordelijkheid voor passende beveiligingsmaatregelen ligt mede op bestuurlijk niveau.
  1. Publieke dienstverleners moeten erop kunnen vertrouwen dat informatie niet onjuist wordt gebruikt of wordt misbruikt:
    • De organisatie zorgt ervoor dat de beoogde toegang tot gegevens en de juiste werking van zijn systemen continu alsook achteraf te controleren is.
    • De organisatie verschaft alleen geautoriseerde afnemers toegang tot vertrouwelijke gegevens.
  2. Bij het inzichtelijk maken van een dataverwerking, dient een tijdsstempel getoond te worden. De getoonde gegevens zijn zoals ze golden ten tijde van de verwerking; ook als deze bijvoorbeeld na enkele maanden opnieuw wordt ingezien of verstrekt.

6. OpenAPI specificatie

{
"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"
}
}
}
}
}
}

A. Referenties

A.1 Normatieve referenties

[AVG]
Algemene Verordening Gegevensbescherming. Verordening (EU) 2016/679 van het Europees Parlement. April 27, 2016. URL: https://eur-lex.europa.eu/legal-content/NL/TXT/?uri=CELEX%3A32016R0679
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc2119/
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc8174/
Logius Praktijkrichtlijn - Werkversie