Samenhang PDC, UPL, zaaktypen en verwerkingsregister
Inhoud
1. Inleiding[bewerken]
Ter ondersteuning van gemeenten en ter standaardisatie van het gemeentelijke dienstverleningsaanbod zijn landelijk een aantal lijsten opgesteld waarin producten en diensten zijn gestandaardiseerd qua naamgeving en andere attributen. Voorbeelden van dergelijke standaardisatie lijsten zijn:
- De gemeentelijke producten en diensten catalogus (PDC),
- De landelijke Uniforme Productnamenlijst (UPL);
- De gemeentelijke zaaktypecatalogus (ZTC),
- Het gemeentelijke AVG verwerkingsregister, en
- Administratieve handelingen van bronapplicaties.
In dit document wordt de opbouw van de deze producten geschetst, wordt geduid hoe deze producten zich onderling tot elkaar verhouden en wordt geschetst hoe de lijsten zich verhouden tot de elementen van de gemeentelijke informatiearchitectuur.
1.1. Doel[bewerken]
Het doel van dit document is het beschrijven van de samenhang van de verschillende producten op het gebied van de standaardisatie van gemeentelijke producten en diensten. Door deze producten te verbinden aan elementen van de gemeentelijke informatiearchitectuur wordt de toegevoegde waarde van de producten vergroot. Het is dan bijvoorbeeld voor gemeenten mogelijk om analyses uit te voeren op wijzigingen die bijvoorbeeld vanuit wetswijzigingen worden doorgevoerd.
2. Producten en dienstencatalogus[bewerken]
Processen starten nooit spontaan, er is altijd een aanleiding voor. Bij processen die zich binnen overheidsorganisaties voltrekken, wordt die aanleiding vaak gevonden in wet- en regelgeving. De gemeente is beheerder van de openbare ruimte en dus verantwoordelijk voor het geven van toestemming voor het gebruik daarvan, bijvoorbeeld als er een evenement wordt georganiseerd. De gemeente is ook verantwoordelijk voor het registreren van haar bevolking en dient dus te worden geïnformeerd over de geboortes binnen de gemeentegrenzen. Uitkeringen worden, afhankelijk van de persoonlijke situatie, verstrekt door een gemeente of het UWV, et cetera. De verantwoordelijkheden, rechten en plichten omtrent al deze onderwerpen zijn door de overheid heel precies uitgewerkt in landelijke wetgeving en landelijke, regionale of lokale regelgeving. In de Producten- en Dienstencatalogi (PDC's) van overheidsorganisaties is deze wet- en regelgeving vertaald naar publiekrechtelijke producten en diensten die de overheidsorganisaties leveren. Zo zal de organisator van een evenement een vergunning moeten vragen aan de overheid. En moet voor elk pasgeboren kind een geboorteakte worden gevraagd bij de burgerlijke stand. Iemand die aanspraak wil maken op een financiële ondersteuning van de overheid, vraagt een uitkering aan.
Een producten en dienstencatalogus (PDC) is een product waarin gegevens over producten en diensten onderhouden kunnen worden en gepresenteerd kunnen worden aan burgers en bedrijven. De PDC wordt door gemeenten als onderdeel van de gemeentelijke website geleverd. De PDC biedt de mogelijkheid voor medewerkers van gemeenten om gegevens over beschikbare producten en diensten in te brengen en actueel te houden en biedt faciliteiten waarmee burgers en bedrijven geholpen worden om de door hen gewenste dienst af te nemen. Ondersteuning van afnemers kan bijvoorbeeld plaatsvinden via vraag-antwoord dialogen waarbij het te volgen pad dynamisch wordt bepaald, of door bij persoonlijke dienstverlening gebruik te maken van reeds bekende gegevens.
2.1. Doelgroep[bewerken]
De Producten en dienstencatalogus richt zich op burgers en bedrijven.
2.2. Inhoud[bewerken]
In de gemeentelijke PDC worden de producten en diensten vastgelegd die de gemeente aan burgers en bedrijven aanbiedt. Per product wordt een duidelijke omschrijving en beschrijving opgenomen die aan de gebruikers van de PDC duidelijk maken waar het product voor is bedoeld.
De producten en diensten worden (optioneel) door de gemeente aan corresponderende, of gerelateerde productnamen uit de UPL gekoppeld. Dit wordt gedaan om de producten in samenhang met producten van andere bestuurslagen vindbaar te maken via Samenwerkende Catalogi. Samenwerkende Catalogi is een virtuele catalogus waar alle aangesloten organisaties informatie over hun producten en diensten opslaan. Iedere aangesloten organisatie deelt op dezelfde manier informatie. Zo wordt het gemakkelijker om ook elkaars diensten aan gebruikers te laten zien. Handig voor bijvoorbeeld gemeenten en portalen die voor een doelgroep (ondernemers, studenten etc) bedoeld zijn.
Doorgaans zijn niet alle producten en diensten die gemeenten voortbrengen, terug te vinden in hun producten- en dienstencatalogus; gemeenten nemen enkel de producten en diensten op die vanuit de publiekrechtelijke taak van de gemeente geleverd worden, en nemen van die set van producten en diensten soms alleen die producten en diensten op die door individuele burgers, bedrijven of instellingen kunnen worden aangevraagd of gemeld. Hierdoor blijven in de Producten- en Dienstencatalogi verschillende groepen producten en diensten buiten beeld:
- Producten en diensten die de overheid proactief levert, zoals het voorinvullen van de belastingaangifte of het samenstellen en verstrekken van een pensioenoverzicht;
- En, in het verlengde daarvan, producten en diensten die de overheid aan de maatschappij - het collectief - levert, zoals het aanleggen en onderhouden van een weg of het versterken van een waterkering, maar ook het beboeten van een fout-parkeerder, het inspecteren van - de keuken in - een horecagelegenheid, het opsporenen beboeten van een illegale lozing van milieuverontreinigende stoffen;
- Tot slot leveren overheidsorganisaties vanuit hun privaatrechtelijke taak tal van producten en diensten aan de eigen - of een met de eigen organisatie samenwerkende - organisatie, zoals het inrichten van een werkplek, het vergoeden van declaraties, het verstrekken van adviezen, etc. Deze producten en diensten zijn niet gericht op burgers en bedrijven en komen dus niet voor in de gemeentelijke PDC.
2.3. Voorbeeld[bewerken]
Figuur 1 - Voorbeeld van de visualisatie van een PDC in de gemeentelijke website (Gemeente Alkmaar)
3. Uniforme Productnamenlijst[bewerken]
De Nederlandse overheid levert producten en diensten aan de samenleving: paspoorten, vergunningen, toeslagen, maar bijvoorbeeld ook informatie. Daarbij is een onderscheid te maken tussen burgers en bedrijven. De overheid bestaat uit een groot aantal organisaties die hun aanbod aan producten en diensten veelal op verschillende manieren aanbieden. Voor burgers en bedrijven is dat niet altijd handig: voor een enkele activiteit hebben zij soms verschillende producten van verschillende organisaties nodig. Het gebundeld en op maat aanbieden van producten en diensten, bijvoorbeeld wanneer iemand werkloos wordt of een restaurant wil beginnen, kan alleen als de overheidsorganisaties afspraken maken over de manier waarop ze hun producten en diensten aanbieden. Een complicerende factor is dat lokale of regionale overheden dezelfde producten verschillend kunnen benoemen en indelen.
De Uniforme Productnamenlijst (UPL) is een middel om met deze diversiteit om te gaan. De UPL is een onderdeel van de landelijke Samenwerkende Catalogi, de standaard voor uitwisseling van informatie over producten en diensten van de overheid. Het is een landelijk gestandaardiseerde lijst waarop namen voor publiekrechtelijke producten en diensten van alle overheden staan, ook voor gemeenten. Aan de autonomie van gemeenten wordt daarbij niet getornd: deze mogen zelf bepalen welke producten en diensten zij aanbieden en hoe ze die noemen en presenteren. Door de producten en diensten in de gemeentelijke productcatalogus (of op de website) te labelen met de eenduidige 'uniforme productnamen' is duidelijk waar het over gaat, en kunnen andere partijen (bijvoorbeeld websites als het Digitaal Ondernemersplein) burgers en ondernemers de informatie op maat en gebundeld voorschotelen. Hergebruik van productinformatie over organisaties heen wordt daardoor mogelijk.
3.1. Doelgroep[bewerken]
De Uniforme Productnamenlijst richt zich op burgers en bedrijven.
3.2. Inhoud[bewerken]
De UPL is onderdeel van het OWMS metadata raamwerk waarin wordt beschreven van welke kenmerken overheden hun informatie kunnen voorzien bij publicatie op internet. Het OWMS metadata raamwerk wordt beheerd door het Kennis- en Exploitatiecentrum Officiële Overheidspublicaties (KOOP) van BZK.
De productnamen op de UPL bevatten aantal kenmerken:
3.2.1. Basiskenmerken[bewerken]
- Label: de productnaam voor menselijk gebruik, bijvoorbeeld: antenneregister inzage
- URI: een unieke identificerende sleutel (ResourceIdentifier) voor machinegebruik, bijvoorbeeld: http://standaarden.overheid.nl/owms/terms/antenneregInz
- Einddatum (indien van toepassing): van toepassing bij productnamen die vervallen zijn of 'opgevolgd' zijn door een andere productnaam
- Opvolger (indien van toepassing): van toepassing bij productnamen die 'opgevolgd' zijn door een andere productnaam
3.2.2. Grondslagen[bewerken]
In de UPL komen sommige productnamen meerdere malen voor. Dit komt omdat deze productnamen meerdere grondslagen kennen. Zo kan het ook voorkomen dat in het overzicht van bijvoorbeeld de provinciale productnamen, gerefereerd wordt aan een gemeentelijke grondslag.
Bijvoorbeeld: in het kader van de handhaving kunnen de aanbieders gemeente, waterschap en provincie een aanschrijving laten uitgaan. Daarin wordt een overtreder gewaarschuwd dat hij maatregelen moet nemen om te voorkomen dat hem een dwangsom wordt opgelegd of dat bestuursdwang wordt toegepast. De productnaam (aanschrijving) is voor alle aanbieders gelijk, maar de grondslag is verschillend (Gemeentewet, Provinciewet of Waterschapswet). Die verschillende grondslagen worden echter bij alle aanbieders getoond.
- Grondslag: een identifier (URI) voor de wettelijke grondslag voor het product (niet getoond in onderstaande afbeelding);
- Grondslag label: de wettelijke grondslag voor het product, in tekst;
- Grondslag link: een link naar de wettelijke grondslag op www.wetten.nl conform de Juriconnect standaard.
3.2.3. Doelgroep[bewerken]
Met de kenmerken 'burger' en 'bedrijf' wordt een indicatie gegeven voor wie het betreffende product relevant zou kunnen zijn. Deze kenmerken maken het mogelijk om een nog specifiekere subset van productnamen te selecteren, bijvoorbeeld: alle gemeentelijke producten voor burgers.
- Burger: het product is van belang voor burgers;
- Bedrijf: het product is van belang voor bedrijven;
3.2.4. Relevantie voor specifieke bestuurslagen[bewerken]
- Relevantie: voor welk type organisaties is deze productnaam relevant? Dat kan zijn: gemeente, provincie, waterschap of Rijksoverheid.
3.2.5. Komt-Voor-Als en Categorie/Thema[bewerken]
- Alternatieve productnamen: hoe het product in de praktijk ook wel genoemd wordt (de zgn. 'Komt-Voor-Als-lijst');
- Categorie/Thema: indeling naar beleidsterrein volgens de Taxonomie Beleidsagenda (TBA)
3.3. Gebruik[bewerken]
Gemeenten kunnen gemeentelijke producten en diensten uit de PDC koppelen aan een of meer productnamen in de UPL. Deze koppeling kan worden gemaakt door bij de vastlegging van de gemeentelijke diensten in bijvoorbeeld een Content Management Systeem (CMS) bij de dienst als metagegeven de gerelateerde Uniforme Productnamen uit de UPL vast te leggen. Gemeenten geven vervolgens bij de publicatie van de gemeentelijke diensten naar Samenwerkende Catalogie in de metagegevens die worden gehanteerd per gemeentelijke dienst door welke Uniforme Productnamen uit de UPL worden implementeerd of zijn gerelateerd.
Via overheid.nl overheid.nl kunnen burgers zoeken naar diensten die door de overheid (Rijk, Provincies, Waterschappen, Gemeenten en overige organisaties) worden aangeboden.
3.4. Wijzigingsproces[bewerken]
Het aanbod van producten en diensten van de overheid verandert in de loop van de tijd, bijvoorbeeld als gevolg van wijziging van de wetgeving die meestal plaatsvindt op de vaste verandermomenten 1 januari en 1 juli. Overheden kunnen voorstellen voor nieuwe of ontbrekende productnamen, wijzigingen of andere opmerkingen aandragen door een mail te sturen naar samenwerkendecatalogi@logius.nl. Logius voert wijzigingen in de UPL vier keer per jaar door. Van alle mogelijke wijzigingen zal uiteindelijk bepaald moeten worden of de producten op de lijst worden toegevoegd, aangepast of verwijderd. Ook zal er een eenduidige productnaam gekozen moeten worden. Gezien de diversiteit van namen voor hetzelfde product bij verschillende overheidsorganisaties is het bepalen van één uniforme naam voor dat product een kwestie van afstemmen en besluiten nemen. Daar waar nodig stemt Logius af met koepelorganisaties en leveranciers van productcatalogi.
Bij het bepalen van nieuwe productnamen en het verwerken van wijzigingen gebruikt Logius de volgende uitgangspunten:
- Daar waar consensus bestaat over het granulariteitsniveau van producten en diensten wordt aangesloten bij hoe het product door organisaties wordt aangeboden;
- Daar waar geen consensus bestaat over het granulariteitsniveau hebben specifieke productnamen in principe de voorkeur boven generieke;
- Het wettelijk kader biedt vaak uitkomst. Op grond van het legaliteitsbeginsel zal er voor alle overheidsproducten waarvan verplicht gebruik gemaakt moet worden, een wettelijke grondslag moeten bestaan. In al die gevallen geeft de wet een definitie van producten en biedt zij een objectieve norm voor de meest gebruikelijke benaming. Verder kan ervan worden uitgegaan dat de meeste professionals een product bij zijn wettelijke benaming kennen;
- Voor gemeentelijke producten bieden de modelverordeningen van VNG vaak een vergelijkbare basis;
- Het wettelijk kader is in veel gevallen ook bepalend voor de fijnmazigheid of granulariteit: de productnaam dekt daarom vaak de lading van welke aspecten van het product of stappen in het proces er in een artikel worden geregeld. Regelt een artikel bijvoorbeeld slechts de inzage in een register, dan is de productnaam 'inzage' in dat register; regelt het artikel meer, dan wordt de naam van het register als productnaam gebruikt. Bijvoorbeeld:
- 'octrooiregister': artikel 19 Rijksoctrooiwet 1995 regelt dat er een register wordt bijgehouden, wie dat doet, hoe dat moet gebeuren en dat daaruit gegevens kunnen worden verstrekt. Niet expliciet dat het kan worden ingezien;
- voor het antenneregister worden inzage en registratie in aparte wetsartikelen geregeld en worden dus twee aparte productnamen gehanteerd;
3.5. Voorbeeld[bewerken]
Figuur 2 - Onderdeel van de inhoud van de landelijke UPL
4. Zaaktype catalogus[bewerken]
Om zaakgericht te kunnen werken is het van belang om uniforme afspraken over een zaak vast te leggen. Denk hierbij aan eigenschappen en kenmerken van een zaak maar ook soorten documenten en statussen. Deze afspraken, de specificaties van een zaaktype, worden vastgelegd per zaaktype en worden opgeslagen in de gemeentelijke zaaktypecatalogus, afgekort ZTC. Het doel van een zaaktype is om de behandelaar extra handvaten te geven over welke stappen hij of zij moeten doorlopen voor de zaakafhandeling, maar ook om de juiste informatie te borgen rondom een zaak. Dit draagt bij aan optimaal informatiemanagement en compliancy binnen een organisatie.
4.1. Doel[bewerken]
De eigenschappen van een zaaktype worden vastgelegd in een ZTC. In een ZTC worden onder andere de verschillende mogelijke statussen per zaaktype vastgelegd, maar ook welke documenten benodigd zijn en welke medewerkers betrokken moeten zijn voor de zaakafhandeling. Door VNG-Realisatie wordt de ZTC beschikbaar gesteld. Deze ZTC bevat de beschrijving van alle zaaktypen die binnen een organisatie of domein uitgevoerd worden, en vormt zo de blauwdruk voor de zaakdossiers. Functie van de ZTC is de parameters op te slaan die een zaaktype definiëren. De ZTC focust op een goede gestandaardiseerde structuur van de zaaktypecatalogus en niet op de concrete gestandaardiseerde zaaktypen. De ZTC is dus vooral een gestandaardiseerde zaaktypecatalogussjabloon.
4.2. Doelgroep[bewerken]
De ZTC richt zich op medewerkers van gemeenten.
4.3. Inhoud[bewerken]
Een ZTC bevat de beschrijving van de zaaktypen die binnen de gemeente uitgevoerd worden, en vormt zo de blauwdruk voor de zaakdossiers. Er staat bijvoorbeeld in beschreven hoe het zaaktype heet, welke resultaten er voor dat zaaktype zijn en wat de bewaartermijn is. Het opstellen van het ZTC gebeurt conform het Informatiemodel ZTC (ImZTC).
Een zaaktype binnen de ZTC omvat van zaaktypen onder andere:
- Zaakgegevens
- Statussen
- Doorlooptijden
- Betrokkenen
- Informatie over de samenstelling van het zaakdossier
- Kenmerken
- Behandelaars
- Resultaten
Schematisch ziet het ImZTC (versie 2.1) er als volgt uit:
4.4. Gebruik[bewerken]
De ZTC biedt een structuur voor het vastleggen van zaaktypen maar biedt geen invulling van de zaaktypen. Het vullen van een ZTC is de verantwoordelijkheid van gemeenten, de ZTC is een sjabloon die gemeenten kunnen gebruiken voor het vastleggen van hun gemeentelijke zaaktypen. Standaardisatie van de gemeentelijke zaaktypen is mogelijk maar is geen taak die VNG-Realisatie uitvoert.
Door VNG Realisatie is een handreiking ontwikkeld voor het tot stand brengen van een ZTC. Deze handreiking is te vinden op https://www.vngrealisatie.nl/sites/default/files/2018-03/20180321_Zaaktype_catalogus_zaakgericht_werken.pdf
5. Register van verwerkingsactiviteiten[bewerken]
De Algemene verordening gegevensbescherming (AVG) legt de verantwoordelijkheid bij gemeenten om aan te tonen dat aan de privacyregels wordt voldaan. In de AVG staat een aantal verplichte maatregelen genoemd waarmee aan de verantwoordingsplicht kan worden voldaan. Zo moeten gemeenten een register van verwerkingsactiviteiten (verwerkingsregister) bijhouden. In het verwerkingsregister wordt vastgelegd welke persoonsgegevens door de gemeente worden verwerkt, met welk doel en welke grondslag. In het verwerkingsregister dienen zowel de publieke als de privaatrechtelijke taken worden opgenomen.
5.1. Doel[bewerken]
Het doel van het verwerkingsregister is tweeledig. Ten eerste dwingt het organisaties om na te denken over de verwerkingen van persoonsgegevens en de noodzaak en wettelijke basis van deze verwerkingen. Daarnaast is het verwerkingsregister een belangrijk middel voor het bieden van transparantie naar de burger over de verwerking van persoonsgegevens door de gemeente. Burgers moeten het verwerkingsregister van de gemeente kunnen inzien en kunnen aan de hand van dit register ook de gemeente verzoeken om verantwoording af te leggen over de verwerkingen van hun persoonsgegevens. De toezichthouder (Autoriteit Persoonsgegevens) kan op verzoek inzage in het register vorderen om gemeenten te controleren.
5.2. Doelgroep[bewerken]
Het verwerkingsregister richt zich op medewerkers van gemeenten (FG en auditors), burgers en bedrijven en externe toezichthoudende instanties zoals de Autoriteit Persoonsgegevens.
5.3. Inhoud[bewerken]
De minimale attributen die per verwerkingsactiviteit in het verwerkingsregister moeten worden bijgehouden zijn met betrekking tot de verwerking van persoonsgegevens beschreven in de (AVG). Specifiek voor gemeenten is door de Informatiebeveigingsdienst (IBD) deze attributenset uitgebreid (Zie Handreiking verwerkingsregister gemeenten).
Het verwerkingsregister bevat de volgende, vanuit de AVG wettelijk verplichte, gegevens:
- De eindverantwoordelijke;
- De verwerkingsdoeleinden;
- De categorieën van betrokkenen;
- De categorieën van te verwerken persoonsgegevens;
- De categorieën van ontvangers;
- Doorgifte van aan derden;
- De bewaartermijnen;
- De technische en organisatorische beveiligingsmaatregelen.
Verschillende disciplines kijken op een andere manier naar de verwerkingen. De één vanuit een juridisch perspectief, de ander vanuit de functionaliteit van de applicaties. Met het oog op deze verschillende perspectieven heeft de IBD ervoor gekozen om een aantal (informatie)verplichtingen van de AVG direct beschikbaar te hebben in het register. Op deze manier is het register toegankelijk en begrijpelijk voor alle disciplines binnen de gemeente. Het betreft de volgende (ten opzichte van de AVG) extra attributen:
- Grondslag voor de verwerking en de daarbij horende toelichting - Een herkenningspunt voor de juristen van een gemeente is de grondslag van de verwerking. Op deze manier komt er één overzicht waarin alle grondslagen van de verwerkingen opgenomen zijn.
- Verwerker, verwerkersovereenkomst, en contactgegevens van de verwerkers - Dit geeft in een oogopslag inzicht in voor welke verwerkingen een verwerkersovereenkomst nodig is, en zo ja, of deze al is afgesloten. Dit is voor zowel de interne verantwoordelijke als de FG belangrijke informatie.
- Soort verwerking - De soort verwerking is toegevoegd om onderscheid te kunnen maken op welke manier de beslissing van de verwerking wordt gemaakt; geautomatiseerd of handmatig. Dit geeft inzicht in mogelijke extra maatregelen die nodig zijn voor de verwerking.
- Applicatie die de verwerking ondersteunt - Een herkenningspunt voor de interne verantwoordelijke van de verwerking of de invuller van het register, is de applicatie waarmee de gegevens verwerkt worden. Daarnaast wordt er in het register duidelijk voor welke applicatie er wel of niet een verwerkersovereenkomst afgesloten is.
- Herkomst van persoonsgegevens - De herkomst van de persoonsgegevens in de verwerking geeft aan op welke manier de betrokkene geïnformeerd dient te worden. Artikel 13 en 14 van de AVG lichten toe op welke manier de gemeente transparant moet zijn indien de gegevens van de betrokkene zelf of van derden zijn verkregen.
- Data protection impact assessment (DPIA) - Naar aanleiding van de motie-Franken heeft het kabinet bepaald dat bij de ontwikkeling van beleid en wetgeving waaruit gegevensverwerkingen voortvloeien, bij de bouw van ICT-systemen en de aanleg van grote databestanden een DPIA moet worden uitgevoerd. De AVG verplicht tot het voorafgaand uitvoeren van een DPIA voor gegevensverwerkingen met een hoog risico voor de rechten en vrijheden van natuurlijke personen. Daarvan wordt in elk geval geacht sprake te zijn als er sprake is van verwerkingen van persoonsgegevens met een hoog risico, zoals bij de inzet van nieuwe technieken of grootschalige gegevensverwerking - voorafgaand daarop - een DPIA uit te voeren. Doel ervan is om - aanvullend op de inrichting van bescherming van persoonsgegevens op grond van de reeds besproken beginselen, scherper zicht te krijgen op de feitelijk bij de verwerking of in de context spelende privacy risico's en daarmee - als correctiemechanisme - rekening te houden bij de uiteindelijke (ontwerp) en beveiligingsmaatregelen. Dit attribuut geeft inzicht op welke verwerkingen er een DPIA gedaan is en op welke verwerkingen er een nodig is. Dit is voor zowel voor de eindverantwoordelijke als de Functionaris Gegevensbescherming belangrijke informatie.
5.4. Scope[bewerken]
Voor wat betreft het vastlegen van verwerkingen van persoonsgegevens is de gemeente vanuit Artikel 30 van de AVG verplicht deze bij te houden en beschikbaar te stellen aan toezichthoudende autoriteit (de Autoriteit Persoonsgegevens). Het verwerkingsregister is echter niet gelimiteerd tot de registratie van enkel de verwerkingen die te maken hebben met persoonsgegevens. Ook verwerkingen van andere objecten kunnen in het verwerkingsregister worden opgenomen.
5.5. Gebruik[bewerken]
Het verwerkingsregister wordt op twee manier gebruikt. Het eerste gebruik is het openbaar maken van de inhoud van het register naar interne mederwerkers maar ook burgers en bedrijven. Door de verwerkingen van persoonsgegevens openbaar te maken wordt het inzicht van burgers en bedrijvenen ten aanzien van de doelen waarvoor gemeenten persoonsgegevens verwerken vergroot. Deze transparantie draagt bij aan het vertrouwen van burgers en bedrijven in de overheid. De tweede manier waarop het verwerkingsregister wordt gebruikt, is bij het loggen van uitgevoerde verwerkingen. Ieder gemeentelijk informatiesysteem heeft de verplichting om de verwerking van persoonsgegevens te loggen in audit logging. Op het moment dat een geautoriseerde eindgebruiker een functie van een informatiesysteem gebruikt zal dat systeem uit het verwerkingsregister de betreffende verwerking selecteren die wordt uitgevoerd en zal de metagegevens behorende bij die verwerking (zie voorgaande alinea) gecombineerd met de identificerende gegevens van het object wat wordt verwerkt (bijvoorbeeld een BSN in het geval van een verwerking van persoonsgevens) opnemen in de logging. Vanuit de audit logging kan de gemeente transparantie bieden over verwerkingen van gegevens naar burgers, bedrijven en bestuur.
6. Administratieve handelingen[bewerken]
Door informatiesystemen worden functies uitgevoerd waarmee gegevens ontstaan, worden gemuteerd of verwijderd. Deze functies worden “administratieve handelingen” genoemd. Een administratieve handeling van een informatiesysteem kent veelal een grondslag die is vastgelegd in (domein)wetgeving. Een voorbeeld van een administratieve handeling is de “verhuismelding” die vanuit het gemeentelijke GBA-systeem wordt geleverd. Deze administratieve handeling kent een grondslag die vastlegd is in de Wet basisregistratie personen (Art. 2.39).
Administratieve handelingen kennen een samenhang met het verwerkingsregister wat in het voorgaande hoofdstuk is beschreven. Iedere administratieve handeling kent een wettelijke grondslag en dient verbonden te zijn aan een van de verwerkingsactiviteiten van het verwerkingsregister. Het betreft hier zowel de privaat- als publiekrechtelijke administratieve handelingen die worden uitgevoerd. Het belang van het verbinden van de administratieve handelingen aan verwerkingsactiviteiten komt voort uit de transparantie en verantwoording die de gemeente moet kunnen afleggen over de verwerking van (persoons)gegevens. Enerzijds moet aan de burger een overzicht kunnen worden gegeven van de verwerkingen die op zijn of haar gegevens zijn uitgevoerd en anderzijds moeten de afhandeling van de verwerking worden vastgelegd. Het eerste doel, transparantie naar de burger over verwerkingen kan worden behaald door het aanleggen van een audit log (zie Logging van verwerking van gegevens). In een audit log worden metagegevens van de verwerkingsactiviteit vastgelegd zoals datum en tijd van de verwerking, verwerkte gegevenscategorien en grondslag van de verwerking. Het tweede doel, het kunnen verantwoorden van de afhandeling van de verwerking wordt behaald door het bijhouden van protocollering. In de protocollering van een informatiesysteem worden de inhoudelijke gegevens van een administratieve handeling bijgehouden en niet alleen metagegevens. In de protocollering worden dus inhoudelijke gegevens zoals een aktenummer waarop een administratieve handeling is gebaseerd bijgehouden.
Door het vastleggen van protocollering ontstaan nieuwe gegevensverzamelingen die persoonsgegevens kunnen bevatten (zoals naam van de behandelaar). Toegang tot de protocollering dient dus voorzien te worden van de privacywaarborgen die ook aan andere gegevensverzamelingen die persoonsgegevens bevatten.
Zowel de audit log als de protocollering worden door informatiesystemen bijgehouden. De eisen die aan de audit log worden gesteld zijn vastgelegd in de VNG Realisatie documentatie ten aanzien van logging4. De eisen die aan de protollering van informatiesystemen worden gesteld komen voort uit domeinwetgeving.
7. Samenhang van elementen[bewerken]
De in de voorgaande hoofdstukken beschreven producten op het gebied van gemeentelijke producten en diensten kennen allemaal bepaalde doelgroepen en doelen. Drie van de producten hebben een gemeenschappelijke basis: de grondslag. De grondslag van een product of dienst geeft aan wat het rechtmatige kader van handelen is. Dit kan bijvoorbeeld een wettelijke verplichting of toestemming van burger of ondernemer zijn. De inhoud van zowel de Uniforme productnamenlijst, de administratieve handelingen als het verwerkingsregister is (grotendeels) gebaseerd op grondslagen die betrekking hebben op wettelijke verplichtingen. Onderstaande tabel geeft een voorbeeld van een dienst die in zowel de UPL, het verwerkingsregister als de administratieve handelingen van de BRP is gedefinieerd.
| Uniforme productnamenlijst | Grondslag |
| geregistreerd partnerschap omzetting in huwelijk | Artikel 80g Burgerlijk Wetboek Boek 1 |
| Administratieve handelingen BRP (opgenomen in bijlage) | Grondslag |
| Omzetting geregistreerd partnerschap in huwelijk | Artikel 80g Burgerlijk Wetboek Boek 1 |
| Verwerkingsregister (zie als voorbeeld het register van verwerkingen van Amersfoort) | Grondslag |
| Omzetten partnerschap in huwelijk | art. 1: 80g BW artikel 6 |
Figuur 3 - Voorbeeld samenhang inhoud landelijk gestandaardiseerde lijsten
Bovenstaand overzicht geeft weer dat vanuit de wettelijke grondslag “Artikel 80g Burgerlijk Wetboek Boek” in zowel de uniforme productnamenlijst, de administratieve handelingen als het verwerkingsregister de dienst voor het omzetten van een geregistreerd partnerschap in een huwelijk is opgenomen. De wettelijke grondslag is het verbindende element tussen deze lijsten. Wat opvalt is dat hoewel de grondslag identiek is, en dezelfde dienst wordt bedoeld de omschrijving van de dienst in de verschillende lijsten verschilt.
7.1. Samenhang producten[bewerken]
Onderstaand figuur geeft een overzicht van de samenhang van de PDC, UPL, ZTC, administratieve handelingen en het verwerkingsregister.
Figuur 4 - Samenhang producten
In bovenstaand figuur is te zien dat een aantal producten en diensten zijn opgenomen zijn die vanuit de publiekrechtelijke taak van de gemeente voortkomen. Deze producten (PDC, UPL, ZTC en Samenwerkende Catalogi), richten zich op de dienstverlening aan burgers en bedrijven. Het verwerkingsregister en informatiesystemen van de gemeente richten zich naast de publiekrechtelijke taak ook op de privaatrechtelijke taak van de gemeente.
De PDC bevat de publiekrechtelijke diensten en producten die door gemeenten worden geleverd aan burgers en bedrijven. De PDC wordt als onderdeel van de gemeentelijke website ontsloten naar burgers en bedrijven. Per dienst of product wat wordt geleverd, wordt in de PDC een beschrijving van de dienst, en in sommige gevallen ook een e-formulier waarmee de dienst kan worden aangeroepen beschikbaar gesteld. Gemeenten zijn vrij om de namen voor producten en diensten in de PDC zelf te kiezen. De inhoud van de PDC van de gemeente wordt via een periodieke gegevensaanlevering aangeboden aan de GDI bouwsteen Samenwerkende Catalogi.
Gemeenten kunnen de producten en diensten uit de PDC relateren aan landelijk gestandaardiseerde productnamen, dit is echter nu niet verplicht. Deze productnamen zijn opgenomen in de Uniforme Productnamenlijst (UPL). De UPL bevat de productnamen die vanuit de publiekrechtelijke taak door de verschillende bestuurslagen (provincies, waterschappen, gemeenten en het Rijk) worden geleverd. Per productnaam is in de UPL opgenomen wat de wettelijke grondslag is. Door producten uit de gemeentelijke PDC's te verbinden met de productnamen uit de UPL wordt geborgd dat diensten die vergelijkbaar zijn, maar anders omschreven worden toch aan elkaar gerelateerd kunnen worden. Neem ter illustratie het voorbeeld waarbij een gemeente een dienst “Aangifte geboorte” biedt en een andere gemeente de dienst “Geboorteaangifte”. Door deze beide diensten te verbinden aan de productnaam geboorteaangifte uit de UPL zijn de diensten vergelijk- en vindbaar via Samenwerkende Catalogi.
Gemeenten kunnen de informatie uit Samenwerkende Catalogi gebruiken om een samenhangend aanbod van de dienstverlening van verschillende overheden te bieden aan burgers en bedrijven. Via aansluiting op Samenwerkende Catalogi kan een gemeente ook voldoen aan de verplichtingen van de Dienstenwet en de toekomstige Single Digital Gateway (SDG).
Nadat een burger of bedrijf een dienst of product aanvraagt wordt door de gemeente een zaak gestart. Deze zaak wordt ingericht conform de parameters die in de gemeentelijke zaaktypecatalogus zijn ingesteld. In de afhandeling van de zaak wordt gebruik gemaakt van de administratieve functies van gemeentelijke informatiesystemen. Deze administratieve functies zijn gerelateerd aan een verwerkingsactiviteit uit het verwerkingsregister.
7.2. Relatie producten en diensten met GEMMA procesmodel[bewerken]
De GEMMA procesarchitectuur biedt een basis voor het inrichten van bedrijfsprocessen bij gemeenten. De GEMMA procesarchitectuur richt zich op alle privaat-en publiekrechtelijke bedrijfsprocessen van de ambtelijke organisatie van de gemeente. In de procesarchitectuur worden de processen op verschillende niveaus beschouwd; een proces op een hoger niveau is dan samengesteld uit ("aggregeert") een of meerdere processen op een lager niveau. Het hoogste niveau dat in deze hiërarchie onderkend wordt, is het klant-tot-klant- ofwel bedrijfsproces. Onderstaande figuur toont de niveaus die onderkend worden.
Onderstaande tabel beschrijft de verschillende procesniveaus.
| Niveau | Definitie | Voorbeeld |
| Bedrijfsproces | Een bedrijfsproces (ook wel genoemd klant-tot-klantproces) is een onder verantwoordelijkheid van één organisatie (gemeente) uitgevoerde, geordende reeks deelprocessen, gerelateerd aan een interne of externe klant en gericht op het leveren van een dienst aan die klant.
Een bedrijfsproces heeft één eigenaar, die verantwoordlijk is voor alle aspecten van dat proces (ook de privacy en de beveiliging) |
Het proces "Behandelen vergunningaanvraag". |
| Deelproces | Een deelproces is een onder verantwoordelijkheid van één bedrijfsfunctie uitgevoerde, geordende reeks processtappen, gericht op het leveren van een deeldienst die een noodzakelijke of gewenste bijdrage levert aan een uiteindelijk aan de klant te leveren dienst. | Het deelproces "Intake vergunningaanvraag". |
| Processtap | Een processtap is een onder verantwoordelijkheid van één persoon (rol) handmatig of geautomatiseerd uitgevoerde, geordende reeks handelingen gericht op het bijdragen aan de levering van een deeldienst. | De processtap "Versturen ontvangstbevestiging". |
| Handeling | Kleinst mogelijke eenheid van werk, uitgevoerd door één persoon of machine op één plek op één moment. | De handeling "Opvragen adres uit de basisregistratie". |
Het aggregatieniveau van de verwerkingsactiviteiten die in het verwerkingsregister zijn opgenomen is vergelijkbaar met het aggregatieniveau van deelprocessen van de GEMMA procesarchitectuur. Gemeenten kunnen verwerkingen zoals die worden vastgelegd in het verwerkingsregister in hun architectuur koppelen aan deelprocessen. Een deelproces kan bijvoorbeeld Aangifte geboorte, Aangifte huwelijk of Aangifte overlijden zijn.
8. Aandachtspunten en verbetervoorstellen[bewerken]
Onderstaande paragrafen beschrijven een aantal aandachtspunten en verbetervoorstellen ten aanzien van de samenhang van de PDC, UPL, ZTC, verwerkingsregister en administratieve handelingen van informatiesystemen.
8.1. Verwijzingen naar wetgeving[bewerken]
De wettelijke grondslag is het verbindende element tussen deze lijsten. Wat opvalt is dat hoewel de wettelijke grondslag van veel producten identiek is, en dezelfde dienst wordt bedoeld de omschrijving van de verwijzing naar wetgeving in de verschillende lijsten verschilt.
Verbetervoorstel: Uniformeer de wijze waarop de verwijzing naar wetgeving wordt vastgelegd. Hanteer daartoe een link naar de wettelijke grondslag op www.wetten.nl conform de Juriconnect standaard.
8.2. Relatie informatiesystemen en het verwerkingsregister[bewerken]
Informatiesystemen bieden via applicatiefuncties administratieve handelingen die gegevens verwerken op basis van een bepaalde wettelijke grondslag. In het verwerkingsregister zijn de verschillende verwerkingsactiviteiten die door de gemeente worden uitgevoerd inclusief de wettelijke grondslag en overige relevante metagegevens vastgelegd. Op dit moment bestaat er geen verplichte koppeling tussen deze administratieve handelingen en het verwerkingsregister. Vanuit de implementatie van logging (zie Logging van verwerking van gegevens) van informatiesystemen is deze verplichte koppeling wel vereist.
- Verbetervoorstel: Beschrijf hoe de applicatiefuncties van informatiesystemen verplicht gekoppeld moeten worden aan de verwerkingsactiviteiten van het verwerkingsregister. Neem hierbij op welke metagegevens van verwerkingsactiviteiten door informatiesystemen in de audit logging moeten worden opgenomen.
8.3. Relatie verwerkingsregister en de UPL[bewerken]
Tussen het verwerkingsregister en de UPL ligt geen formele relatie. Voor wat betreft de publiekrechtelijke taken die voor alle gemeenten gelijk zijn dient een productnaam in de UPL opgenomen te worden en dient de relatie met het verwerkingsregister gelegd te worden. Het doel van de UPL is immers het standaardiseren van productnamen van publiekrechtelijke diensten die voor alle gemeenten gelden.
- Verbetervoorstel: Leg een relatie vanuit het verwerkingsregister met de corresponderende productnaam uit de UPL. Hanteer zoveel mogelijk de omschrijving van de productnaam als omschrijving van de verwerkingingsactiviteit;
- Verbetervoorstel: Stel de standaard inhoud van het verwerkingsregister ten aanzien van de publiekrechtelijke verwerkingsactiviteiten vast. Door de inhoud te standaardiseren worden gemeenten ontlast en wordt de doelbinding van gemeenten gebruiken gestandaardiseerd. Dit heeft als bijkomend voordeel dat verwerkingen tussen gemeenten onderling vergeleken kunnen worden;
- Verbetervoorstel: Sluit voor wat betreft de releases van de standaard inhoud van het verwerkingsregister aan bij de release frequentie van de UPL.
8.4. UPL als bronregistratie van publiekrechtelijke gemeentelijke diensten en producten[bewerken]
Zoals uit de voorgaande hoofdstukken blijkt heeft de UPL een centrale rol in niet alleen de samenhang van de verschillende componenten maar ook als een bronregistratie van de gemeentelijke producten en diensten. Iedere publiekrechtelijke dienst of product met een wettelijke grondslag die voortkomt uit landelijke wet- of regelgeving zou in de UPL voor moeten komen. De UPL is na aanvulling met ontbrekende producten en diensten de basis voor gemeentelijke publiekrechtelijke producet en diensten. Gemeentelijke producten die gemeentelijke diensten en producten definiëren (zoals het verwerkingsregister en de PDC) dienen een verwijzing op te nemen naar de UPL zodat kan worden geborgd dat richting burger en bedrijf de informatievoorziening samenhangend, correct en compleet is.
- Verbetervoorstel: Op diverse plekken worden nu gemeentelijke diensten en producten gedefinieerd. Hanteer de UPL als bron voor publiekrechtelijke verwerkingsactiviteiten van het verwerkingsregister voor wat betreft verwerkingsactiviteiten die vanuit de publiekrechtelijke taak van de gemeenten voortkomen en voor alle gemeenten gelden.
Verbetervoorstel: De huidige UPL is voor wat betreft de gemeentelijke productnamen van publiekrechtelijke taken niet compleet. Vul de bestaande UPL aan vanuit andere bronnen zoals de gemeentelijke verwerkingsregisters.
8.5. ZTC, ImZTC en voorbeeldcatalogus[bewerken]
De visie van VNG Realisatie ten aanzien van Zaaktypecatalogi evolueert. De nu vigerende visie is dat de ZTC eigenlijk alleen zaaktypen zou moeten bevatten die generiek zijn, en niet zoals nu het geval is specifiek voor een product. De huidige zaaktypen in de gemeentelijke ZTC's zijn gebaseerd op het product wat vanuit het zaaktype wordt opgeleverd. Hierdoor is vrijwel ieder zaaktype uniek en direct gerelateerd aan een proces. De gemeentelijke ZTC is daarmee inhoudelijk bijna een kopie van de PDC en bevat vele tientallen zo niet honderden zaaktypen. In de ontwikellende visie van VNG Realisatie zou een zaaktype moeten dienen ter standaardisatie van statussen van een type proces, de doorlooptijd(en), de respectievelijke rollen van betrokken partijen voor een bepaald type zaak, informatie over de samenstelling van het dossier en mogelijke resultaten. Uitwerking van die visie zou leiden tot een beperkt aantal standaard zaaktypen. Voorbeelden hiervan zijn 'Aanvragen', 'Meldingen' of 'Aangiften'.
- Verbetervoorstel: De doorlooptijd van een proces wordt nu conform het ImZTC bepaald op basis van het zaaktype. Dit betekent dat alle processen die op een zaaktype worden gebaseerd dezelfde doorlooptijd kennen. In de praktijk blijkt dit geen gelukkige keuze te zijn. De afhandeling van bijvoorbeeld de aangifte van de naamskeuze voor een kind is anders dan de afhandeling van de aangifte van een eerste inschrijving in Nederland. Doordat de doorlooptijden verschillen zouden verschillende zaaktypen gedefinieerd moeten worden wat de inrichting van de ZTC naar producten in de hand werkt. Pas het ImZTC op het punt van de doorlooptijden aan. Verplaats de doorlooptijd van zaaktype naar product;
- Verbetervoorstel: De referentieprocessen zijn slechts zeer beperkt uitgewerkt en de uitwerking is van jaren geleden (voor het ImZTC 2.x). Herijk de referentieprocessen en zorg ervoor dat ze passen op de visie van het ZTC.
8.6. PDC[bewerken]
Voor de gemeentelijke PDC is geen gestandaardiseerd informatiemodel gedefinieerd. Leveranciers hebben hierdoor de vrijheid om relaties naar bijvoorbeeld de UPL en PDC zelf te definiëren. Hierdoor is niet geborgd dat alle gemeentelijke PDCs voldoen aan de visie die door VNR-R wordt uitgedragen ten aanzien van de onderlinge relatie van PDC/ZTC/UPL en selectielijst. Ook is de inhoud van de gemeentelijke PDC's is niet gestandaardiseert, zelfs niet voor de producten die voor alle gemeenten gelijk zijn. Dit leidt tot verschillende beschrijvingen van identieke diensten bij gemeenten.
- Verbetervoorstel: Stel een gemeentelijk informatiemodel PDC (ImPDC) op wat als basis dient voor informatiesystemen die een PDC implementeren om hiermee te borgen dat de relaties tussen de verschillende producten op de juiste manier gelegd (kunnen) worden.
- Verbetervoorstel: Stel een standaard inhoud van de PDC op voor de diensten die voor alle gemeenten gelijk zijn.
8.7. Verwerkingsregister[bewerken]
Door VNG-R en de Informatie Beveiligingsdienst (IBD) zijn richtlijnen en templates opgeleverd ten aanzien van het opstellen en toepassen van een verwerkingsregister. De inhoud van het verwerkingsregister wordt door VNG-R/IBD niet geboden. Wel wordt verwezen naar diverse implementaties van verwerkingsregisters van gemeenten. Gemeenten zijn dus min of meer op zichzelf aangewezen voor het bepalen van de inhoud van het verwerkingsregister. Zoals eerder in dit document is geconcludeerd zou het verwerkingsregister ten aanzien van publiekrechtelijke verwerkingen die een wettelijke grondslag hebben en door alle gemeenten worden uitgevoerd synchroon moeten lopen met de UPL.
- Verbetervoorstel: Vul de UPL aan met de ontbrekende producten en diensten. Gebruik hiervoor als mogelijke bron de gemeentelijke verwerkingsregisters die nu in gebruik zijn. Pas het informatiemodel verwerkingsregister hierop aan;
- Verbetervoorstel: Stel de standaard inhoud van het Register van verwerkingsactiviteiten ten aanzien van de publiekrechtelijke verwerkingsactiviteiten vast. Door de inhoud te standaardiseren worden gemeenten ontlast en worden doelbindingen die door gemeenten worden gebruikt voor de publiekrechtelijke taken gestandaardiseerd. Dit heeft als bijkomend voordeel dat verwerkingen tussen gemeenten onderling vergeleken kunnen worden.
- Verbetervoorstel: Sluit voor wat betreft de releases van de standaard inhoud van het verwerkingsregister aan bij de release frequentie van de UPL.
8.8. Bedrijfsprocessen en het verwerkingsregister[bewerken]
De deelprocessen van de gemeente kunnen veelal worden gerelateerd aan een verwerkingsactiviteit uit het verwerkingsregister. Het bedrijfsproces Burgelijke stand diensten kan bijvoorbeeld gekoppeld worden aan de verwerkingsactiviteit Omzetten partnerschap in huwelijk. Doordat de verwerkingsactiviteiten uit het verwerkingsregister gekoppeld (kunnen) zijn aan één of meerdere productnamen uit de Uniform Productnamenlijst (UPL) is de koppeling tussen de UPL en bedrijfsprocessen te maken via het verwerkingsregister. Via deze relatie is het bedrijfsproces Burgelijke stand diensten gerelateerd aan de productnaam geregistreerd partnerschap omzetting in huwelijk uit de UPL.
- Verbetervoorstel: Koppel de verwerkingsactiviteiten uit het verwerkingsregister aan deelprocessen van de GEMMA bedrijfsarchitectuur. Pas het kennismodel GEMMA hier op aan;
- Verbetervoorstel: Breidt de GEMMA bedrijfsarchitectuur daar waar verwerkingsactiviteiten niet te koppelen zijn aan bedrijfsprocessen uit met nieuwe bedrijfsprocessen, en wellicht zelfs nieuwe bedrijfsfuncties.
Bijlage 1: BRP administratieve handelingen[bewerken]
Onderstaand overzicht geeft de administratieve handelingen weer zoals die in scope waren van de koppelvlakken van de Basisregistratie Personen dd. 14 juli 2017.
| 01 - Afstamming |
| Geboorte in Nederland |
| Geboorte in Nederland met erkenning op geboortedatum |
| Geboorte in Nederland met erkenning na geboortedatum |
| Erkenning |
| Vernietiging erkenning |
| Vaststelling ouderschap |
| Ontkenning ouderschap |
| Adoptie |
| Omzetting adoptie |
| Wijziging oudergegevens |
| Wijziging kindgegevens |
| Correctie geboorte |
| Correctie afstamming |
| Correctie oudergegevens |
| Correctie kindgegevens |
| 02 - Naam en Geslacht |
| Wijziging naam |
| Wijziging geslachtsaanduiding |
| Wijziging naamgebruik |
| Correctie naam |
| Correctie geslachtsaanduing |
| Correctie naamgebruik |
| 03 - Document, verzoek en mededeling |
| Wijziging verstrekkingsbeperking |
| Correctie verstrekkingsbeperking |
| Wijziging gezag |
| Correctie gezag |
| Wijziging curatele |
| Correctie curatele |
| Verwijdering gegevens na adoptie |
| Verwijdering kindgegevens na adoptie |
| Overschrijving geslacht en naam na geslachtswijziging |
| Overschrijving oudergegevens na geslachtswijziging |
| Overschrijving kindgegevens na geslachtswijziging |
| Overschrijving partnergegevens na geslachtswijziging |
| 04 - Huwelijk en Geregistreerd partnerschap |
| Voltrekking huwelijk in Nederland |
| Ontbinding huwelijk in Nederland |
| Voltrekking huwelijk in buitenland |
| Ontbinding huwelijk in buitenland |
| Aangaan geregistreerd partnerschap in Nederland |
| Beëindiging geregistreerd partnerschap in Nederland |
| Aangaan geregistreerd partnerschap in buitenland |
| Beëindiging geregistreerd partnerschap in buitenland |
| Omzetting geregistreerd partnerschap in huwelijk |
| Nietigverklaring huwelijk in Nederland |
| Nietigverklaring geregistreerd partnerschap in Nederland |
| Wijziging partnergegevens huwelijk |
| Wijziging partnergegevens geregistreerd partnerschap |
| Ongedaanmaking huwelijk |
| Ongedaanmaking geregistreerd partnerschap |
| Correctie huwelijk |
| Correctie geregistreerd partnerschap |
| Correctie partnergegevens huwelijk |
| Correctie partnergegevens geregistreerd partnerschap |
| 05 - Verblijf en adres |
| Constatering verblijf kind |
| Vestiging niet-ingeschrevene |
| Vestiging niet-ingezetene |
| Verhuizing binnengemeentelijk |
| Verhuizing intergemeentelijk |
| Wijziging gemeente infrastructureel |
| Wijziging gemeente infrastructureel bij overledene |
| Wijziging adres infrastructureel |
| Verhuizing naar buitenland |
| Correctie adres |
| Correctie migratie |
| Wijziging verblijfsrecht |
| Correctie verblijfsrecht |
| Wijziging bijzondere verblijfsrechtelijke positie |
| Correctie bijzondere verblijfsrechtelijke positie |
| 06 - Nationaliteit |
| Verkrijging Nederlandse nationaliteit |
| Verlies Nederlandse nationaliteit |
| Verkrijging vreemde nationaliteit |
| Verlies vreemde nationaliteit |
| Beëindiging bijhouding vreemde nationaliteit |
| Correctie nationaliteit |
| Wijziging indicatie nationaliteit |
| Correctie indicatie nationaliteit |
| 07 - Reisdocument |
| Verkrijging reisdocument |
| Onttrekking reisdocument |
| Signalering reisdocument |
| Correctie reisdocument |
| 09 - Overlijden |
| Overlijden in Nederland |
| Overlijden in buitenland |
| Correctie overlijden |
| 10 - Bijzondere bijhouding |
| Wijziging identificatienummers |
| Wijziging nummerverwijzing |
| Correctie nummerverwijzing |
| Wijziging buitenlands persoonsnummer |
| Correctie buitenlands persoonsnummer |
| Opschorting bijhouding persoonsgegevens reden foutief |
| Wijziging documentindicatie |
| Correctie documentindicatie |
| Correctie inschrijving |
| Correctie bijhouding |
| Correctie persoonskaart |
| 11 - Onderzoek |
| Aanvang onderzoek |
| Wijziging onderzoek |
| Registratie niet aangetroffen op adres |
| Beëindiging onderzoek |
| Correctie onderzoek |
| 13 - Verkiezingen |
| Wijziging uitsluiting kiesrecht |
| Wijziging deelname EU verkiezingen |
| Correctie kiesrecht |
| xx - Systeemhandelingen |
| Relateren |
| Ontrelateren |
Bijlage 2: Bronnen[bewerken]
- Toelichting op de Uniforme Productnamenlijst (UPL), 14 december 2018
- Gemeentelijk Gegevenslandschap - Register van verwerkingsactiviteiten v1.0, VNG Realisatie, 28 november 2018
- Gemeentelijk Gegevenslandschap - Logging van verwerking van gegevens v1.0, VNG Realisatie, 28 november 2018
- Protocollering, Ministerie van Binnenlandse Zaken en Koninkrijksrelaties, april 2015
- GEMMA ZTC2 - Begeleidend document, KING Gemeenten, 1 juli 2014