Release: logboek-dataverwerkingen_Inleiding

api/logboek_inleiding/0.8.1/LICENSE

@@ -0,0 +1,17 @@
+The W3C SOFTWARE NOTICE AND LICENSE (W3C)
+
+https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document
+
+This work is being provided by the copyright holders under the following license. By obtaining and/or copying this work, you (the licensee) agree that you have read, understood, and will comply with the following terms and conditions.
+
+Permission to copy, modify, and distribute this work, with or without modification, for any purpose and without fee or royalty is hereby granted, provided that you include the following on ALL copies of the work or portions thereof, including modifications:
+1. The full text of this NOTICE in a location viewable to users of the redistributed or derivative work.
+2. Any pre-existing intellectual property disclaimers, notices, or terms and conditions. If none exist, the W3C Software and Document Short Notice (https://www.w3.org/Consortium/Legal/2015/copyright-software-short-notice.html) should be included.
+3. Notice of any changes or modifications, through a copyright statement on the new code or document such as "This software or document includes material copied from or derived from [title and URI of the W3C document]. Copyright © [YEAR] W3C® (MIT, ERCIM, Keio, Beihang)."
+
+
+THIS WORK IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SOFTWARE OR DOCUMENT WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
+
+COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE SOFTWARE OR DOCUMENT.
+
+The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to the work without specific, written prior permission. Title to copyright in this work will at all times remain with copyright holders.

api/logboek_inleiding/0.8.1/docs/besluiten/00-introductie.md

@@ -0,0 +1,6 @@
+<!-- markdownlint-disable first-line-heading -->
+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.
+
+Een aantal besluiten en overweging hebben relatie met het [Juridische Beleidskader](https://logius-standaarden.github.io/publicatie/api/logboek_juridisch/)

api/logboek_inleiding/0.8.1/docs/besluiten/0000-gebruik-van-adr.md

@@ -0,0 +1,22 @@
+# Gebruik van ADR
+
+- Status: draft
+- Datum:
+
+
+## Context en probleemstelling
+
+{ Beschrijf de context en de probleemstelling }
+
+
+## Besluit
+
+{ Beschrijf het genomen besluit }
+
+
+## Gevolgen
+
+{ Wat zijn de gevolgen na het nemen van dit besluit }
+
+
+## Meer informatie

api/logboek_inleiding/0.8.1/docs/besluiten/README.md

@@ -0,0 +1,8 @@
+# Besluiten
+
+In deze directory staan alle besluiten. Het formaat is op basis van [Markdown Any Decision Records](https://adr.github.io/madr/).
+
+
+## Nieuw besluit
+
+Gebruik het bestand [`template.md`](template.md) om een nieuw besluit te maken.

api/logboek_inleiding/0.8.1/docs/besluiten/template.md

@@ -0,0 +1,29 @@
+# { Titel }
+
+- Status: { draft | proposed | rejected | accepted | deprecated | superseded by [ADR-0042](0042-asterisk.md) }
+- Datum: { YYYY-MM-DD wanneer het besluit voor het laatst is aangepast }
+
+
+## Context en probleemstelling
+
+{ Beschrijf de context en de probleemstelling }
+
+
+## Besluit
+
+{ Beschrijf het genomen besluit }
+
+
+## Gevolgen
+
+{ Wat zijn de gevolgen na het nemen van dit besluit }
+
+
+<!-- Optioneel -->
+## Meer informatie
+
+{ Eventuele verwijzingen naar andere bronnen of websites }
+
+- [Website](https://example.com)
+- [Ander document](https://example.com)
+- ...

api/logboek_inleiding/0.8.1/docs/besluiten/xxxx-bewaartermijnen-worden-in-profiel-vastgelegd.md

@@ -0,0 +1,26 @@
+# Bewaartermijnen worden in het Profiel vastgelegd
+
+- Status: draft
+- Datum: 2024-05-23
+
+
+## Context en probleemstelling
+
+Logregels 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 Logregels.
+
+Anders dan bij gegevens over rechtsfeiten zullen Logregels 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 Logregels 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 voor bewaartermijnen vast te leggen in een Profiel.
+
+
+## Besluit
+
+Bewaartermijnen worden in het Profiel vastgelegd.
+
+
+## Gevolgen
+
+- In de Logregel liggen geen gegevens vast over bewaartermijnen.
+- Vanuit een beheercomponent (een applicatie die functionaliteit biedt voor beheren van logboek. Is een kwestie van implementatie en valt buiten scope van deze standaard) kunnen Logregels worden verwijderd door te kijken naar de datum van de Logregel in relatie tot de bewaartermijn die de organisatie hanteert voor Logregels. Deze bewaartermijn kan gezamenlijk zijn afgesproken en ligt dan vast in het Profiel.

api/logboek_inleiding/0.8.1/docs/besluiten/xxxx-geen-gebruikers-in-logregels.md

@@ -0,0 +1,40 @@
+# Geen gegevens over gebruikers in logregels
+
+- Status: draft
+- Datum: 2024-05-23
+
+
+## Context en probleemstelling
+
+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 (Een log file die activiteiten van gebruikers, uitzonderingen en informatiebeveiligingsgebeurtenissen vastgelegd. Dit is o.a. vanuit BIO verplicht) onder een andere Verantwoordelijke valt dan de Dataverwerking die op dat moment door de gebruiker wordt uitgevoerd. Bijvoorbeeld:
+
+- Een Dataverwerking wordt door een gebruiker bij een [Verwerker](https://logius-standaarden.github.io/logboek-dataverwerkingen/#dfn-verwerkers) uitgevoerd
+- De Dataverwerking valt onder verantwoordelijkheid van de [Verantwoordelijke](https://logius-standaarden.github.io/logboek-dataverwerkingen/#dfn-verantwoordelijke), namelijk de organisatie die de Verwerker heeft ingehuurd
+- De Audit Log is een aparte Dataverwerking die valt onder verantwoordelijkheid van de Verwerker, in de rol van Verantwoordelijke over de eigen bedrijfsvoering.
+
+Het is daarom zuiverder om een andere oplossing te kiezen, namelijk:
+
+- Betrokkenheid van gebruiker wordt vastgelegd in een Audit Log (buiten scope van deze standaard)
+- In het Audit Log kan eventueel een relatie worden gelegd met het Processing ID dat ook in het Logboek Dataverwerkingen wordt gebruikt
+- Iedere keer dat in het Audit Log gegevens over een gebruiker worden vastgelegd, moet tevens een Dataverwerking worden gelogd in het Logboek Dataverwerkingen.
+
+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.
+
+
+## Besluit
+
+In logregels worden geen identificerende gegevens over gebruikers van de Applicaties vastgelegd.
+
+
+## Gevolgen
+
+- In gevallen dat het nodig is te achterhalen welke gebruiker een specifieke Dataverwerking heeft uitgevoerd, moet dit worden achterhaald door de Dataverwerking te koppelen aan het Audit Log (buiten scope van de standaard).
+- Het koppelen van Dataverwerking aan Audit Log is mogelijk door in Audit Logs hetzelfde Processing ID op te nemen als in de logregel die in het Logboek Dataverwerkingen wordt opgenomen.

api/logboek_inleiding/0.8.1/docs/besluiten/xxxx-geen-interface-voor-verwijderen-logs.md

@@ -0,0 +1,24 @@
+# Standaard beschrijft geen interface voor verwijderen van logs
+
+- Status: draft
+- Datum: 2024-05-24
+
+
+## Context en probleemstelling
+
+Logregels moeten op enig moment worden vernietigd. Moet er een interface in de standaard worden gedefinieerd voor het verwijderen van vastgelegde Logregels?
+
+De wijze waarop Logregels 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 Logregels 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.
+
+
+## Besluit
+
+- De standaard beschrijft geen interface voor het wijzigen of verwijderen van Logregels
+
+
+## Gevolgen
+
+- Iedere organisatie kan een bij de eigen implementatie passende oplossing kiezen voor het verwijderen van Logregels
+- Het wijzigen van Logregels is in principe ongewenst maar kan op soortgelijke manier opgelost worden

api/logboek_inleiding/0.8.1/docs/besluiten/xxxx-log-sampling-is-niet-toegestaan.md

@@ -0,0 +1,22 @@
+# Log Sampling is niet toegestaan
+
+- Status: proposed
+- Datum: 2024-06-20
+
+
+## Context en probleemstelling
+
+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.
+
+
+## Besluit
+
+Log Sampling is niet toegestaan.
+
+
+## Gevolgen
+
+- Iedere logregel wordt weggeschreven in het LogBoek Dataverwerkingen
+- Wanneer een techniek voor loggen wordt toegepast waarbij Log Sampling is ingericht, moet ervoor worden gewaakt dat dit niet geldt voor de logregels die beschreven worden in deze standaard.

api/logboek_inleiding/0.8.1/docs/besluiten/xxxx-logregels-bevatten-alleen-wat-nodig-is-voor-verantwoording-door-verantwoordelijke.md

@@ -0,0 +1,27 @@
+# Logregels bevatten alleen wat nodig is voor verantwoording door verantwoordelijke
+
+- Status: draft
+- Datum: 2024-06-24
+
+
+## Context en probleemstelling
+
+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](https://logius-standaarden.github.io/logboek-dataverwerkingen/#dfn-dataverwerkingen) kan  de neiging ontstaan om informatie uit andere organisaties vast te leggen in de logregels.
+
+Hierdoor kom je (juridisch gezien) al snel in lastig vaarwater. Er worden dan zaken vastgelegd die niet noodzakelijk zijn voor het verantwoorden van het handelen. Het is namelijk mogelijk om een compleet beeld te krijgen door de informatie te laten in de organisatie waar een dataverwerking is uitgevoerd. Vanuit het oogpunt van dataminimalisatie is dit een betere oplossing.
+
+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](https://datatracker.ietf.org/doc/html/rfc3986) te volgen naar Logregels 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.
+
+
+## Besluit
+
+Logregels bevatten alleen wat nodig is voor verantwoording door de Verantwoordelijke.
+
+
+## Gevolgen
+
+- In logregels wordt alleen een identifier vastgelegd van gerelateerde Dataverwerkingen in een andere context (bijv. een andere organisatie), geen inhoudelijke informatie
+- Voor een analyse, bijvoorbeeld in het kader van een audit of uitoefening inzagerecht, is het nodig om op dat moment de URI's naar logs in andere organisaties te volgen
+

api/logboek_inleiding/0.8.1/docs/besluiten/xxxx-logregels-bevatten-geen-gegevens-die-al-vastliggen-in-een-register.md

@@ -0,0 +1,73 @@
+# Logregels bevatten geen gegevens die al vastliggen in een [Register](https://logius-standaarden.github.io/logboek-dataverwerkingen/#dfn-registers)
+
+- Status: proposed
+- Datum: 2024-02-01
+
+## Context en probleemstelling
+
+Om logs zo begrijpelijk mogelijk te maken is het aantrekkelijk om de benodigde informatie redundant weg te schrijven in elk logrecord, zodat er geen afhankelijkheid bestaat van andere bronnen.
+
+Dit heeft nadelen, zoals:
+
+- Wanneer de statische gegevens (zoals bewaartermijn, verantwoordelijke, etc.) wijzigen, zou dit moeten worden aangepast in alle Logregels. Dat verhoudt zich slecht tot het 'inmutable' (onveranderbaar) zijn van deze Logregels.
+- De grote vrijheid in alle clients om invulling te geven aan deze gegevens leidt er vrijwel zeker toe dat verdere divergentie optreedt. Dit heeft o.a. tot gevolg dat het lastig wordt om te rapporteren uit de logs
+- De API voor het wegschrijven van logs wordt ingewikkeld en relatief traag voor het wegschrijven van records
+- We niet voldoen aan alle uitgangspunten die horen bij dataminimalisatie
+
+In de gewenste situatie:
+
+- staan alle statische gegevens in het Register van de Verwerkingsactiviteiten (RvVA), en bevatten Logregels verwijzingen naar dat Register. Specifiek gaat dit om de resources ['verwerkingsactiviteiten'](https://logius-standaarden.github.io/logboek-dataverwerkingen/#dfn-verwerkingsactiviteiten) en 'organisaties'.
+- kan bij het configureren van clients in de RvVA-API worden opgezocht welke organisaties en verwerkingsactiviten van toepassing zijn
+- kunnen wijzigingen in verwerkingsactiviteiten worden doorgevoerd zonder dat Logregels gewijzigd behoeven te worden
+
+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ïmplementeerd 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 bewaartermijnen en een eenduidige omgang met vertrouwelijkheid is het ook eenvoudiger om eenduidige te communiceren naar de [Betrokkene](https://logius-standaarden.github.io/logboek-dataverwerkingen/#dfn-betrokkenen). 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.
+
+## Besluit
+
+Logregels bevatten geen informatie over Verwerkingsactiviteiten en Verantwoordelijkheden die al vastliggen in een Register
+
+## Gevolgen
+
+- In de standaard Logboek Dataverwerkingen is het nodig om ook de benodigde interface op de RvVA te standaardiseren. Dit is nodig om de logs geautomatiseerd en realtime te kunnen interpreteren: zonder een gestandaardiseerde manier om informatie over verwerkingsactiviteiten op te vragen kan men aan logregels niet zien of het verwerkingen, handelingen of acties betreft.
+
+Met de volgende sequentie diagrammen wordt in beeld gebracht wat de gevolgen zijn voor de diverse flows in het gebruik van de standaard.
+
+### Loggen van een verwerking
+
+Het wegschrijven van een verwerking in de log-API is uiterst simpel:
+
+```mermaid
+sequenceDiagram
+    participant A as Applicatie
+    participant L as Logboek
+    Note over A: Dataverwerking in Applicatie
+    A->>+L: Schrijf logregel in Logboek
+    L-->>-A: ack
+```
+
+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.
+
+### Tonen van een verwerking
+
+Om verwerkingen op een significante manier te tonen aan bijvoorbeeld een Betrokkene, is het noodzakelijk 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.
+
+```mermaid
+sequenceDiagram
+    participant F as Inzage App
+    participant L as Logboek
+    participant R as Register
+    Note over F, R: Betrokkene vraagt om inzage
+    F->>+L: Vraag Logregels van Betrokkene
+    Activate F
+    L-->>-F: Logregels
+    F->>+R: Vraag Verwerkingsactiviteiten bij Logregels
+    R-->>-F: verwerkingsactiviteiten
+    F-->>F: Combineeer
+    Deactivate F
+```