Logboek dataverwerkingen

Functioneel toepassingsgebied: De standaard Logboek Dataverwerkingen kan worden toegepast als data wordt verwerkt in overheidssystemen. 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 bezig houdt 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. Het standaardiseren van aanvullende functionaliteit wordt gedaan met behulp van extensies:

-- NB. De scope van onderstaande extensies is nog onderwerp van gesprek. --

• 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 meest basale variant 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 Manipulatiebestendigheid
  Deze extensie beschrijft hoe Logboeken zodanig kunnen worden ingericht dat manipulatie van de Logregels kan worden aangetoond, en hierover zinnige uitspraken kunnen worden gedaan wanneer de Logregels van meerdere organisaties aan elkaar worden gerelateerd.

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 persoonsgegevens 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 software component of groep van software componenten 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 Verwerkingsactiviteiten die voorkomen bij een Verantwoordelijke. Elke Verwerkingsactiveit heeft een unieke code waarmee de Verwerkingsactiviteit kan worden aangeduid. Deze code wordt gebruikt om logregels te relateren aan een Verwerkingsactiviteit.

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. Bijvoorbeeld: het toevoegen van een Verwerkingsactiviteit of een Verantwoordelijke.

Voor alle Dataverwerkingen waarbij persoonsgegevens worden verwerkt is wettelijk geregeld dat de Verwerkingsactiviteiten moeten worden beschreven in het zogenaamde Register van Verwerkingsactiviteiten (AVG art. 30). Vanwege deze wettelijke plicht zal dit Register in veel organisaties beschikbaar zijn.

-- Uitwerken --

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 gegevens 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 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:

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: ID van de Betrokkene; versleuteld. Dit is bijvoorbeeld een BSN of Vreemdelingennummer waarmee wordt aangeduid welke persoon Betrokkene is bij de verwerking, gelet op de AVG.

De applicatie MOET een Trace starten voor iedere Dataverwerking waarvan nog geen Trace bekend is.

De applicatie MOET voor iedere Dataverwerking een logregel wegschrijven in een Logboek. Log Sampling is niet toegestaan.

De applicatie MOET bijhouden of een Dataverwerking geslaagd of mislukt is en dit per Dataverwerking als status meegeven aan het Logboek.

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.

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.

De Applicatie heeft geen voor deze standaard relevante interface. Voor het uitwisselen van de Trace wordt W3C Trace Context gebruikt.

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.