Dit document valt onder de volgende licentie:
Creative Commons Attribution 4.0 International Public License
-- volgt --
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.
Deze sectie geeft een introductie op de standaard. Sectie 2 beschrijft de architectuur van systemen die de standaard gebruiken. Sectie 3 beschrijft de interfaces en het gedrag van componenten die de standaard volgen in detail. Sectie 4 beschrijft een optionele extensie waarmee de interface van externe registers wordt gestandaardiseerd.
Sectie 5 is tijdelijk en geeft een lijst achterliggende besluiten bij de 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:
Door Dataverwerkingen te loggen volgens de standaard kunnen organisaties het datagebruik verantwoorden. De standaard is gericht op verantwoording van Dataverwerkingen door Nederlandse (overheids)organisaties, gelet op onder meer de Algemene Verordening Gegevensbescherming en de Algemene Wet Bestuursrecht.
-- volgt --
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 op link.
De volgende lijst beschrijft terminologie in de betekenis zoals deze wordt gebruikt in dit document.
Applicatie
Iedere softwaretoepassing waarmee dataverwerkingen worden uitgevoerd.
Betrokkene
Als persoonsgegevens worden verwerkt, wordt de persoon van wie de organisatie persoonsgegevens verwerkt de 'Betrokkene' genoemd. Dat is dus degene over wie de dataverwerking gaat. De Betrokkene is degene op wie een persoonsgegeven betrekking heeft en die daarmee geïdentificeerd kan worden. Als identificeerbaar wordt beschouwd een natuurlijke persoon die direct of indirect kan worden geïdentificeerd, met name aan de hand van een identificator zoals een naam, een identificatienummer, locatiegegevens, een online identificator of van een of meer elementen die kenmerkend zijn voor de fysieke, fysiologische, genetische, psychische, economische, culturele of sociale identiteit van die natuurlijke persoon [NORA: De Privacy Baseline/Persoonsgegevens en bijzondere persoonsgegevens]
Dataverwerking
Aansluitend bij de Algemene Verordening Gegevensbescherming (art. 4 lid 2), maar breder toegepast dan alleen persoonsgegevens, wordt voor deze standaard ‘elke bewerking of elk geheel van bewerkingen met betrekking tot gegevens, al dan niet uitgevoerd via geautomatiseerde procedures, 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’ opgevat als een dataverwerking.
Inzage
De Betrokkene heeft het recht om van de verwerkingsverantwoordelijke uitsluitsel te verkrijgen over het al dan niet verwerken van hem betreffende persoonsgegevens en, wanneer dat het geval is, om inzage te verkrijgen van die persoonsgegevens (AVG, art. 15, lid 1). Met Inzage doelen we op de handeling waarmee uitvoering wordt gegeven aan dat recht.
Logboek
Softwaretoepassing waarmee het log van Dataverwerkingen wordt bijgehouden.
Operatie
--nog definiëren--
Register
Register waarin statische gegevens over Verwerkingsactiviteiten worden geregistreerd en ter beschikking gesteld, zoals het Register van Verwerkingsactiviteiten uit AVG art. 30.
Trace
Concept waarmee bij elkaar behorende Dataverwerkingen binnen de grenzen van een systeem worden gegroepeerd.
Verwerkingsverantwoordelijke
Een natuurlijke persoon of rechtspersoon, een overheidsinstantie, een dienst of een ander orgaan die/dat, alleen of samen met anderen, het doel van en de middelen voor de verwerking van persoonsgegevens vaststelt (AVG art. 4, lid 7.)
Verwerkingsactiviteit
Verwerkingsactiviteiten zijn de activiteiten die een organisatie onderkent heeft als activiteiten waarbinnen Dataverwerkingen plaatsvinden.
Applicaties loggen metadata over Dataverwerkingen in een daarvoor ingerichte softwaretoepassing, het Logboek Dataverwerkingen. Elke Dataverwerking wordt apart gelogd. Dataverwerkingen binnen dezelfde context (bijvoorbeeld een organisatie of een verantwoordelijkheid binnen een organisatie) worden gegroepeerd met behulp van een Trace. Wanneer een Dataverwerkingen een andere Dataverwerking tot gevolg heeft worden de logregels van beide Dataverwerkingen aan elkaar gelinkt. Statische informatie over Dataverwerkingen kan worden opgezocht in Registers op basis van een verwijzing die in elke logregel wordt opgenomen.
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 het perspectief van de Betrokkene.
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:
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.
Deze sectie beschrijft de algemene architectuur voor het loggen van dataverwerkingen bij toepassing van deze standaard.
Op hoog abstractieniveau zijn voor het begrijpen van deze standaard de volgende componenten te onderscheiden:
Een Dataverwerking kan plaatsvinden over de grenzen van een verantwoordelijkheid. In dat geval roept een Applicatie van Verantwoordelijke A de Applicatie van Verantwoordelijke B aan. Denk bijvoorbeeld aan het bevragen of muteren van gegevens via een API.
Een Verantwoordelijke is bijvoorbeeld een organisatie, maar kan ook bestaan uit meerdere organisaties die allemaal onder dezelfde Verantwoordelijke werk uitvoeren. Denk daarbij aan Verwerkers in het kader van de AVG.
Iedere Verantwoordelijke kan een veelheid aan Applicaties gebruiken.
Applicaties schrijven logs over Dataverwerkingen weg in een Logboek. Logregels in het Logboek verwijzen naar nadere informatie in een Register. Iedere Verantwoordelijke houdt alleen logs bij over eigen Dataverwerkingen. Op basis van metadata die tussen Applicaties wordt uitgewisseld is het mogelijk om bij elkaar behorende logregels in meerdere Logboeken aan elkaar te relateren.
De standaard beschrijft de interfaces (in het diagram aangeduid met groene lijnen), en het gedrag van de componenten voor zover relevant om technisch interoperabel te worden.
De relatie tussen Logboek en Register heeft geen technische interface, wel moet een relatie gelegd kunnen worden tussen de logregels in het Logboek en de Verwerkingsactiviteiten in het Register.
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.
Deze sectie geeft de specificatie voor de te gebruiken protocollen en interfaces en het verwachte gedrag van de componenten.
De protocollen die worden gebruikt tussen applicatie en logboek en voor het uitvoeren van transacties tussen applicaties worden niet voorgeschreven in de standaard. Dit biedt de vrijheid om de standaard toe te voegen aan vrijwel iedere softwareoplossing.
Het is AANBEVOLEN om het OpenTelemetry Protocol (OTLP) te gebruiken in de interactie tussen Applicatie en Logboek.
OpenTelemetry is een open source framework voor het beheren, genereren, verzamelen en exporteren van telemetriegegevens. Door het gebruik van deze open standaard kunnen leverancierspecifieke integraties voorkomen worden.
Als gebruik wordt gemaakt van HTTP/1.1 [RFC9112] of HTTP/2 [RFC9113] voor het uitvoeren van dataverwerkingen in meerdere applicaties MOET gebruik worden gemaakt van de Trace Context specificatie voor het uitwisselen van context informatie.
Voor ieder Logboek waarin dataverwerkingen worden gelogd gelden de volgende specificaties voor gedrag en interface.
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:
| Veld | Type | optioneel | Omschrijving |
|---|---|---|---|
trace_id |
16 byte | verplicht | Uniek ID van Trace, een groep bij elkaar behorende Dataverwerkingen |
operation_id |
8 byte | verplicht | Uniek ID van de Dataverwerking |
status_code |
enum | verplicht | Status van de Dataverwerking |
name |
string | verplicht | Naam van de specifieke operatie binnen de Dataverwerking |
start_time |
timestamp (ms) | verplicht | Tijdstip waarop de Dataverwerking gestart is |
end_time |
timestamp (ms) | verplicht | Tijdstip waarop de Dataverwerking beëindigd is |
parent_operation_id |
8 byte | optioneel | ID van aanroepende Dataverwerking binnen de huidige Verwerkingsactiviteit |
foreign_operation |
message | optioneel | |
resource |
message | optioneel | |
attributes |
list | verplicht | Verplichte key-value pairs |
Het veld status_code is een enumeratie die de volgende waarden kan bevatten:
Het veld foreign_operation is een message, opgebouwd uit de volgende velden:
| Veld | Type | optioneel | Omschrijving |
|---|---|---|---|
trace_id |
16 byte | verplicht | Uniek ID van Trace bij externe partij |
operation_id |
8 byte | verplicht | Uniek ID van de Dataverwerking bij externe partij |
entity |
URI | verplicht | URI verwijzend naar externe partij |
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 verwerkingsactiviteitdpl.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.Voor iedere applicatie waarin dataverwerkingen plaatsvinden die gelogd moeten worden gelden de volgende specificaties voor het gedrag.
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.
Voor ieder register met statische gegevens over dataverwerkingen die gelogd moeten worden gelden de volgende specificaties voor het gedrag en de interface.
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.
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.
Dit onderdeel is niet normatief.
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 al snel in lastig vaarwater, juridisch gezien. Er worden dan zaken vastgelegd die niet noodzakelijk zijn voor het verantwoorden van het handelen. Bovendien is het mogelijk om een compleet beeld te krijgen door de informatie te laten in de organisatie waar een dataverwerking is uitgevoerd. Dit is dan ook beter om te doen, vanuit het oogpunt van dataminimalisatie.
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 logrecords 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.
Dit onderdeel is niet normatief.
Om te optimaliseren voor de het lezen en begrijpen van de logs is het denkbaar om de benodigde informatie redundant weg te schrijven in elk logrecord, zodat er geen afhankelijkheid bestaat van andere bronnen.
Dit heeft nadelen, zoals:
In de gewenste situatie:
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ïmplementeert 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 bewaartermijnenen 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
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.
Voor het op betekenisvolle manier tonen van verwerkingen aan bijvoorbeeld een Betrokkene is het dan nodig 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.
Logrecords 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 logrecords.
Anders dan bij gegevens over rechtsfeiten zullen logrecords 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 logrecords 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 voer bewaartermijnen vast te leggen in een Profiel.
Bewaartermijnen worden in het Profiel vastgelegd.
Dit onderdeel is niet normatief.
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 onder een andere Verantwoordelijke valt dan de Dataverwerking die op dat moment door de gebruiker wordt uitgevoerd. Bijvoorbeeld:
Het is daarom zuiverder om een andere oplossing te kiezen, namelijk:
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.
Dit onderdeel is niet normatief.
Logrecords moeten op enig moment worden vernietigd. Moet er een interface in de standaard worden gedefinieerd voor het verwijderen van vastgelegde logrecords?
De wijze waarop logrecords 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 logrecords 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.
Dit onderdeel is niet normatief.
Alle verwerkingen worden gelogd. Een deel van deze verwerkingen mag (moet!) bekend worden bij Betrokkenen, een deel niet. Hoe moet dit onderscheid geïmplementeerd worden?
Voorbeeld:
Voorbeeld:
Er zijn meerdere oplossingsrichtingen denkbaar. Wat is de gewenste oplossingsrichting, hoe wordt deze gespecificeerd?
Mogelijke oplossingsrichtingen:
Overwegingen:
Vertrouwelijke verwerkingen moeten meer strikt gescheiden moeten worden van niet-vertrouwelijke verwerkingen. Wanneer een bevraging zowel vertrouwelijk als niet-vetrouwelijk kan zijn (voorbeeld: het opvragen van eigenaargegevens van een voertuig) moeten twee gescheiden processen bestaan, waarbij de vertrouwelijke variant niet alleen apart wordt gelogd, maar in het geheel aan meer strikte regels wordt onderworpen, zoals eisen aan betrokken beheerders, classificatie van gegevens, etc.
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:
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
Dit onderdeel is niet normatief.
In de logrecords staat zo min mogelijk inhoudelijke informatie (ADR xxx). Informatie over verwerkingsactiviteiten ligt vast in specifieke registers.
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.
{ Wat zijn de gevolgen na het nemen van dit besluit }
Dit onderdeel is niet normatief.
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.
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 AANBEVOLEN en MOET 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.