Release: logboek-dataverwerkingen_Inleiding

api/logboek_algemeen/0.1.0/docs/besluiten/xxxx-bewaartermijnen-worden-in-profiel-vastgelegd.md

@@ -6,11 +6,11 @@
 
 ## Context en probleemstelling
 
-Logrecords moeten op enig moment worden verwijderd. Wanneer?
+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 logrecords.
+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 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.
+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.
 

api/logboek_algemeen/0.1.0/docs/besluiten/xxxx-geen-interface-voor-verwijderen-logs.md

@@ -6,19 +6,19 @@
 
 ## Context en probleemstelling
 
-Logrecords moeten op enig moment worden vernietigd. Moet er een interface in de standaard worden gedefinieerd voor het verwijderen van vastgelegde logrecords?
+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 logrecords worden weggeschreven is sterk afhankelijk van de keuzes die een organisatie maakt bij de implementatie van de standaard.
+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 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.
+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 logrecords
+- 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 logrecords
-- Het wijzigen van logrecords is in principe ongewenst maar kan op soortgelijke manier opgelost worden
+- 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_algemeen/0.1.0/docs/besluiten/xxxx-logregels-bevatten-alleen-wat-nodig-is-voor-verantwoording-door-verantwoordelijke.md

@@ -10,7 +10,7 @@ Vanuit de wens om zoveel mogelijk context vast te leggen om zo een compleet beel
 
 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](https://datatracker.ietf.org/doc/html/rfc3986) te volgen naar logrecords in andere organisaties.
+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.
 

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

@@ -9,16 +9,16 @@ Om logs zo begrijpelijk mogelijk te maken is het aantrekkelijk om de benodigde i
 
 Dit heeft nadelen, zoals:
 
-- Wanneer de statische gegevens (zoals bewaartermijn, verantwoordelijke, etc.) wijzigen, zou dit moeten worden aangepast in alle logrecords. Dat verhoudt zich slecht tot het 'inmutable' (onveranderbaar) zijn van deze logrecords.
+- 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 logrecords verwijzingen naar dat Register. Specifiek gaat dit om de resources ['verwerkingsactiviteiten'](https://logius-standaarden.github.io/logboek-dataverwerkingen/#dfn-verwerkingsactiviteiten) en 'organisaties'.
+- 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 logrecords gewijzigd behoeven te worden
+- 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.
 
@@ -63,10 +63,10 @@ sequenceDiagram
     participant L as Logboek
     participant R as Register
     Note over F, R: Betrokkene vraagt om inzage
-    F->>+L: Vraag logrecords van Betrokkene
+    F->>+L: Vraag Logregels van Betrokkene
     Activate F
-    L-->>-F: logrecords
-    F->>+R: Vraag Verwerkingsactiviteiten bij logrecords
+    L-->>-F: Logregels
+    F->>+R: Vraag Verwerkingsactiviteiten bij Logregels
     R-->>-F: verwerkingsactiviteiten
     F-->>F: Combineeer
     Deactivate F

api/logboek_algemeen/0.1.0/docs/besluiten/xxxx-vertrouwelijkheid-wordt-vastgelegd-per-verwerkingsactiviteit.md

@@ -29,9 +29,9 @@ Pogingen om het geschetste probleem op te lossen door op logrecord-niveau vast t
 
 
 - Vertrouwelijkheid vastleggen per logrecord betekent dat deze vertrouwelijkheid ook moet kunnen worden opgeheven
-- Logrecords zijn dan niet langer 'immutable' tenzij ingewikkelde constructies worden gekozen waarbij een logrecord logisch wordt vervangen door een nieuw record toe te voegen
+- Logregels zijn dan niet langer 'immutable' tenzij ingewikkelde constructies worden gekozen waarbij een logrecord logisch wordt vervangen door een nieuw record toe te voegen
 - Er zou een interface gedefinieerd moeten worden voor het wijzigen van de status 'vertrouwelijkheid'
-- Vertrouwelijkheid van een handeling aan het einde van een proces zou gevolgen kunnen hebben voor reeds vastgelegde logrecords
+- Vertrouwelijkheid van een handeling aan het einde van een proces zou gevolgen kunnen hebben voor reeds vastgelegde Logregels
 
 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.
 
@@ -43,7 +43,7 @@ Vertrouwelijkheid wordt vastgelegd per Verwerkingsactiviteit
 
 ## Gevolgen
 
-- Vertrouwelijkheid wordt niet vastgelegd in logrecords
+- Vertrouwelijkheid wordt niet vastgelegd in Logregels
 - Vertrouwelijkheid wordt per logrecord afgeleid uit wat over vertrouwelijkheid is vastgelegd bij de bijbehorende Verwerkingsactiviteit
 - Vertrouwelijkheid wordt NIET uitgewisseld tussen organisaties
 - Wanneer een verwerking niet langer vertrouwelijk is, bijvoorbeeld na verjaring, dan volgt dit uit gegevens die vastliggen in het Register (bijvoorbeeld status vertrouwelijkheid, duur vertrouwelijkheid) en wat vastligt in een logrecord (verwerkingsactiviteit_id en datum)

api/logboek_algemeen/0.1.0/docs/besluiten/xxxx-verwijzingen-naar-registers-zijn-zo-los-mogelijk.md

@@ -6,7 +6,7 @@
 
 ## Context en probleemstelling
 
-In de logrecords staat zo min mogelijk inhoudelijke informatie [[[ADR]]]. Informatie over verwerkingsactiviteiten ligt vast in specifieke registers.
+In de Logregels staat zo min mogelijk inhoudelijke informatie [[[ADR]]]. Informatie over verwerkingsactiviteiten ligt vast in specifieke registers.
 
 - Er kunnen meerdere van deze Registers zijn
 - Deze kunnen ook van andere organisaties zijn

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

@@ -6,11 +6,11 @@
 
 ## Context en probleemstelling
 
-Logrecords moeten op enig moment worden verwijderd. Wanneer?
+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 logrecords.
+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 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.
+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.
 

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

@@ -6,19 +6,19 @@
 
 ## Context en probleemstelling
 
-Logrecords moeten op enig moment worden vernietigd. Moet er een interface in de standaard worden gedefinieerd voor het verwijderen van vastgelegde logrecords?
+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 logrecords worden weggeschreven is sterk afhankelijk van de keuzes die een organisatie maakt bij de implementatie van de standaard.
+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 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.
+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 logrecords
+- 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 logrecords
-- Het wijzigen van logrecords is in principe ongewenst maar kan op soortgelijke manier opgelost worden
+- 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_algemeen/docs/besluiten/xxxx-logregels-bevatten-alleen-wat-nodig-is-voor-verantwoording-door-verantwoordelijke.md

@@ -10,7 +10,7 @@ Vanuit de wens om zoveel mogelijk context vast te leggen om zo een compleet beel
 
 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](https://datatracker.ietf.org/doc/html/rfc3986) te volgen naar logrecords in andere organisaties.
+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.
 

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

@@ -9,16 +9,16 @@ Om logs zo begrijpelijk mogelijk te maken is het aantrekkelijk om de benodigde i
 
 Dit heeft nadelen, zoals:
 
-- Wanneer de statische gegevens (zoals bewaartermijn, verantwoordelijke, etc.) wijzigen, zou dit moeten worden aangepast in alle logrecords. Dat verhoudt zich slecht tot het 'inmutable' (onveranderbaar) zijn van deze logrecords.
+- 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 logrecords verwijzingen naar dat Register. Specifiek gaat dit om de resources ['verwerkingsactiviteiten'](https://logius-standaarden.github.io/logboek-dataverwerkingen/#dfn-verwerkingsactiviteiten) en 'organisaties'.
+- 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 logrecords gewijzigd behoeven te worden
+- 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.
 
@@ -63,10 +63,10 @@ sequenceDiagram
     participant L as Logboek
     participant R as Register
     Note over F, R: Betrokkene vraagt om inzage
-    F->>+L: Vraag logrecords van Betrokkene
+    F->>+L: Vraag Logregels van Betrokkene
     Activate F
-    L-->>-F: logrecords
-    F->>+R: Vraag Verwerkingsactiviteiten bij logrecords
+    L-->>-F: Logregels
+    F->>+R: Vraag Verwerkingsactiviteiten bij Logregels
     R-->>-F: verwerkingsactiviteiten
     F-->>F: Combineeer
     Deactivate F