Logboek dataverwerkingen

Functioneel toepassingsgebied: De standaard Logboek Dataverwerkingen kan worden toegepast als data wordt verwerkt in geautomatiseerde systemen. Uitgangspunt is de verantwoordingsplicht van de overheid over de uitvoering van haar taken en de wetten en kaders die daarbij horen.

Organisatorisch werkingsgebied: Nederlandse overheden (Rijk, provincies, gemeenten en waterschappen) en instellingen uit de (semi-) publieke sector.

De standaard heeft als doelgroep iedereen die zich bezighoudt met het implementeren van logging rond dataverwerkingen en beschrijft alleen wat relevant is voor de implementatie. Alle achterliggende overwegingen zijn te vinden in de Algemene inleiding en het Juridisch Beleidskader.

De standaard Logboek Dataverwerkingen specificeert de basis voor het loggen en aan elkaar relateren van Dataverwerkingen. Aanvullende functionaliteit wordt gestandaardiseerd in extensies:

• Extensie Betrokkenen
  Met deze extensie wordt meer precies uitgewerkt hoe de identiteit van een Betrokkene wordt gerelateerd aan een verwerking, zodat actief informeren of het faciliteren van inzageverzoeken gestandaardiseerd mogelijk wordt. Dit is een nadere uitwerking van wat in de kern van de standaard al mogelijk is rond vastlegging van de Betrokkene.

• Extensie Verwerkte Data
  Deze extensie specificeert een uniforme manier om verwerkte data in logregels op te nemen.

• Extensie Inzage
  Deze extensie heeft een afhankelijkheid van de extensies Betrokkenen en Verwerkte Data, en biedt een interface op de logs vanuit een bepaald perspectief.

• Extensie (geo)objecten
  Deze extensie specificeert hoe dataverwerkingen voor objecten kunnen worden vastgelegd en beheerd in een logboek.

In een profiel worden aanvullende beperkingen en verplichtingen vastgelegd over het gebruik van de standaard. Op deze manier kan een groep organisaties interoperabiliteit organiseren. Voorbeelden van aanvullende afspraken in een profiel zijn:

• De combinatie van extensies die gebruikt wordt
• Afspraken over specifieke aanvullende eisen (bijvoorbeeld over TLS configuratie)
• Afspraken over data-retentie
• De wijze waarop pseudonimisering van persoonsdata plaatsvindt

Een typische use case voor het gebruik van de standaard is een samenwerking tussen meerdere organisaties die interoperabiliteit willen bereiken bij het loggen van Dataverwerkingen, om zo op eenduidige manier te kunnen verantwoorden over de dataverwerking.

Een Applicatie is een softwarecomponent of groep van softwarecomponenten waarmee een Dataverwerking wordt uitgevoerd. Een Applicatie kan in allerlei vormen voorkomen. Voor de architectuur is niet relevant welke vorm de Applicatie heeft, het is slechts relevant dat dit de component is waar een Dataverwerking wordt uitgevoerd.

In een Applicatie is de context van de Dataverwerking bekend, zoals welke Verwerkingsactiviteit wordt uitgevoerd met de Dataverwerking. Het is dan ook de Applicatie die het loggen van de Dataverwerking initiëert.

Een Logboek is een Applicatie met een specifieke rol in de context van deze standaard. In het Logboek worden Dataverwerkingen gelogd.

Dataverwerkingen in het Logboek zelf worden niet gelogd in een Logboek Dataverwerkingen, dit zou een oneindige recursiviteit veroorzaken.

Een Register bevat statische informatie over Dataverwerkingen. Elk record in een Register heeft een unieke identificatiecode waarmee de Verwerkingsactiviteit kan worden aangeduid. Deze identificatiecode wordt gebruikt om vanuit een Logregel te linken naar aanvullende informatie in een Register.

Het Register kan een Applicatie zijn, in dat geval is het een Applicatie met een specifieke rol in de context van deze standaard. Eventueel kan het ook een Register in de vorm van een document zijn.

Dataverwerkingen in het Register worden gelogd in een Logboek Dataverwerkingen.

Voor alle Dataverwerkingen waarbij persoonsdata worden verwerkt is wettelijk geregeld dat de Verwerkingsactiviteiten moeten worden beschreven in het zogenaamde Register van Verwerkingsactiviteiten (AVG art. 30). Dit Register wordt verondersteld aanwezig te zijn in iedere organisatie die de standaard Logboek Dataverwerkingen toepast.

Verwerkingsactiviteiten waarin geen persoonsdata worden verwerkt staan niet verplicht in het Register van Verwerkingsactiviteiten. De standaard laat ruimte om dit op te lossen naar eigen voorkeur:

• In het bestaande Register ook Verwerkingsactiviteiten opnemen zonder persoonsdata, al is dit niet wettelijk verplicht
• Zelf een ander Register opzetten met gelijke interface maar specifiek voor Verwerkingsactiviteiten zonder persoonsdata

Het is daarnaast ook mogelijk om Registers te gebruiken met heel andere statische informatie die meer context geeft over een Logregel, bijv. informatie over de gebruikte beslisregels of van toepassing zijnde normen. Dit wordt niet verder uitgewerkt.

Voor een juiste toepassing van de standaard is het nodig om strict de grenzen aan te houden die passen bij de Verantwoording die een Verantwoordelijke af moet kunnen leggen. Het wordt AANBEVOLEN om alle Dataverwerkingen te loggen alsof zij persoonsdata bevatten, ook wanneer de Dataverwerking geen persoonsdata betreft. Dit omdat het wettelijk kader dat leidt tot verantwoordingsplicht breder is dan alleen de AVG. Logregels kunnen ook worden gebruikt voor bijvoorbeeld het verantwoorden welke data gebruikt zijn bij het nemen van een besluit.

Belangrijk uitgangspunt is dat een Verantwoordelijke alleen Logregels bijhoudt voor Dataverwerkingen die onder eigen verantwoordelijkheid plaatsvinden.

Een zogenaamde Verwerker die Dataverwerkingen uitvoert in opdracht van een Verantwoordelijke wordt in deze standaard beschouwd als deel van de Verantwoordelijke. Van welke Logboeken en Registers een Verwerker gebruik maakt is een implementatiekeuze.

Er wordt met de standaard geen inhoudelijke informatie over Dataverwerkingen uitgewisseld tussen Verantwoordelijken. Dit is niet nodig, aangezien iedere Verantwoordelijke alleen Logregels over eigen Dataverwerkingen vastlegt. De informatie die wordt uitgewisseld is beperkt tot zogenaamde Trace-informatie waarmee Logregels van de ene Verantwoordelijke gerelateerd kunnen worden aan Logregels bij de andere Verantwoordelijke.

De standaard specificeert een interface voor het wegschrijven van Logregels. Dit is het deel dat in alle organisaties hetzelfde moet zijn om interoperabel te zijn. Het beheren van een Logboek is vrij in te vullen per implementatie.

Dit betekent o.a. dat de standaard geen gedrag of interfaces specificeert voor:

• het verwijderen of muteren van Logregels
• het regelen van toegang tot het Logboek
• het regelen van duurzame toegankelijkheid
• het regelen van archivering en verwijdering van Logregels

In Logregels ligt geen informatie vast over welke specifieke medewerker van de Verantwoordelijke ofwel de gebruiker de Dataverwerking heeft uitgevoerd. Deze informatie hoort niet in het Logboek maar in een auditlog, en is daarmee buiten scope van de standaard. Wel is het mogelijk om vanuit auditlogs de relatie te leggen naar specifieke Logregels in het Logboek. (toevoegen link naar Algemene inleiding, besluit over gebruikers)

Deze transactie is geoptimaliseerd op eenvoud en snelheid, want deze heeft rechtstreeks invloed op de snelheid van Dataverwerkingen. Deze transactie moet schaalbaar zijn naar bijv. honderdduizenden transacties per seconde, o.a. omdat wanneer bij een enkele Dataverwerking meerdere Betrokkenen gerelateerd zijn, voor elk van deze Betrokkenen een logregel wordt weggeschreven.

Voor het op betekenisvolle manier tonen van informatie over Dataverwerkingen aan bijvoorbeeld een Betrokkene is het nodig om data op te vragen uit zowel het Logboek als het Register. 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.

Het Logboek MOET TLS afdwingen op connecties volgens de binnen de organisatie gangbare standaard.

Het Logboek MOET het wegschrijven van elke logregel bevestigen.

De interface MOET de volgende velden implementeren:

Het veld span_id is in implementaties voor logging.

Het veld status_code is een enumeratie die de volgende waarden kan bevatten:

• 0: STATUS_CODE_UNKNOWN:
• 1: STATUS_CODE_OK:
• 2: STATUS_CODE_ERROR:

Het veld foreign_operation is een message, opgebouwd uit de volgende velden:

Deze velden worden optioneel aangeboden door een aanroepende Applicatie, zie de specificatie van het gedrag van Applicaties.

Het veld resource is een bericht, opgebouwd uit het volgende veld:

• attributes: Lijst attributen in de vorm van KeyValue pairs. De organisatie kan deze lijst gebruiken om een systeem, applicatie of component aan te duiden op een manier die binnen de organisatie gebruikelijk is. Dit zijn bijvoorbeeld naam en versienummer van een applicatie, of een verwijzing naar een record in een CMDB.

Het veld attributes is een lijst van key-value pairs, in een namespace met prefix dpl. (data processing log). De volgende attributen zijn mogelijk in de namespace core:

• dpl.core.processing_activity_id: URI; Verwijzing naar Register met meer informatie over de Verwerkingsactiviteit
• dpl.core.data_subject_id: Unieke identificerende code van de Betrokkene; versleuteld. Hiermee wordt aangeduid welke persoon Betrokkene is bij de verwerking, gelet op de AVG.
• dpl.core.data_subject_id_type: Type van het veld data_subject_id. Dit is bijvoorbeeld BSN, Personeelsnummer of Vreemdelingennummer, of een URI naar een Register waar het veld meer precies wordt geduid.

Het gespecificeerde gedrag van Applicaties is erop gericht om de interface van het Logboek te gebruiken. Voor alle metadata geldt dat de specificatie te vinden is in de interface van het Logboek.

De Applicatie MOET een nieuwe Trace met een uniek trace_id starten voor iedere nieuwe Dataverwerking. In een Trace wordt de metadata bijgehouden die nodig is om de interface van een Logboek te gebruiken.

Een Dataverwerking kan uit meerdere acties bestaan. De applicatie MOET een voor iedere nieuwe actie een unieke span_id bijhouden. Iedere Trace heeft tenminste één span_id.

Wanneer een actie binnen een Applicatie is gestart door een andere actie, dan MOET de Applicatie de trace_id ongewijzigd overnemen en de span_id opnemen in een veld genaamd parent_span_id voor deze nieuwe actie.

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.

De Applicatie MOET voor iedere actie (span_id) een logregel wegschrijven via de interface van het Logboek.

De Applicatie MOET bijhouden of een actie geslaagd of mislukt is en dit per Dataverwerking als status (status_code) meegeven in de Logregel.

Als de Applicatie een verzoek van een andere Applicatie kan ontvangen, MOET de Applicatie metadata volgens de W3C Trace Context standaard kunnen verwerken en gebruiken in de eigen Trace(s). Metadata verkregen via W3C Trace Context MOET als foreign_operation worden opgenomen in de Logregel.

Als de Applicatie een verzoek aan een andere Applicatie kan versturen, MOET de Applicatie metadata volgens de W3C Trace Context standaard meegeven aan dit verzoek.

De Applicatie MAG NIET gebruik maken van Log Sampling.

Het Register MOET iedere relevante wijziging van een Verwerkingsactiviteit opslaan met een nieuwe identifier, zodat de dpl.core.processing_activity_id naar een eenduidige versie van de verwerkingsactiviteit verwijst.

Voor de werking van het Logboek is het niet nodig de Registers te ontsluiten met een API. Wel moeten de Verwerkingsactiviteiten die gebruikt worden in de logregels ook voorkomen in een register. Wanneer bij het raadplegen van de logregels geautomatiseerd context aan de logregels moet worden gegeven is een read-only interface op het Register nodig. Deze interface wordt hieronder gespecificeerd.

Nog uitwerken, REST API, Read-only OpenAPI 3 specificatie.

Op het laagste niveau wordt er enkel naar het Register verwezen. Dit betekent dat de Logregel enkel de referentie naar het register bevat. Hieruit kan worden opgemaakt welke potentiële data is verwerkt, maar hiermee kan niet worden herleid welke data is verwerkt op basis van enkel de Logregel. Dit kan wel op basis van de verwerkingsactiviteit ID.

Voorbeeld referentie: er is informatie over het bezit van een auto opgevraagd. Dit register bevat informatie zoals BSN, Adres, Kenteken, Lease-contract, APK gekeurd. Er wordt hier niet verder gespecificeerd welke categorieën van informatie zijn opgevraagd. De Logregel bevat dus "Bezit van auto opgevraagd uit RDW-register: verwerkingsactiviteit ID <<UUID>>"

Op dit niveau wordt er zowel naar het betreffende Register verwezen alsmede de specifieke categorieën van data die zijn verwerkt. Hieruit kan dus worden opgemaakt welke specifieke categorieën van data zijn verwerkt, maar kan er niet worden herleid wat de waarde van de data is tijdens het loggen.

Voorbeeld referentie: er is informatie over het bezit van een auto opgevraagd. Dit register bevat informatie zoals BSN, Adres, Kenteken, Lease-contract, APK gekeurd. De Dataverwerking betrof het BSN, Kenteken en APK gekeurd. Omdat de overige categorien niet werden gebruikt, zijn die ook niet gelogd. De Logregel bevat dus "Bezit van auto opgevraagd uit RDW-register: BSN, Kenteken, APK gekeurd, verwerkingsactiviteit ID <<UUID>>"

Op het hoogste niveau wordt alle data in de Logregel gezet. Dit betekent dat alle relevante categorieën uit het Register met bijbehorende concrete data worden gelogd. Op dit niveau kan de gehele Dataverwerking worden gereconstrueerd.

Voorbeeld referentie: er is informatie over het bezit van een auto opgevraagd. Dit register bevat informatie zoals BSN, Adres, Kenteken, Lease-contract, APK gekeurd. De Dataverwerking bevat de BSN, Kenteken en APK gekeurd met specifieke data. De Logregel bevat dus "Bezit van auto opgevraagd uit RDW-register: BSN 1234, Kenteken 1-ABC-23, APK gekeurd: ja, verwerkingsactiviteit ID <<UUID>>"