[23bb005645] Bijlage 11 behorende bij 23bb5665 - 2Privacyframework datagedreven werken DAP'R

In relatie tot de compliance aspecten overziet de business consultant het geheel en adviseert aan zowel manager DACC als compliance specialisten. 34

Ten behoeve van deze adviesfunctie beschikt OBI over een compliance officer, een privacyspecialist en een algoritme-expert. DACC staat voor Data & Analytics Competence Center, een multidisciplinaire team waarin IIFO en de clusters samenwerken om te voorzien in de informatiebehoefte van de clusters. Per cluster is er een separaat DACC, die met behulp van scrumteams informatieproducten ontwikkelen. 35

Datum

Pagina

mei 2023

25 van 41

2.3.9 Functioneel beheerder De functioneel beheerder van de applicaties binnen het DAP’R hebben een belangrijke uitvoerende rol bij het administreren van toegangsrechten. Zij zijn namelijk degenen die gebruikersrechten feitelijk invoeren, wijzigen en uiteindelijk weer verwijderen. 36 Ook rapporteren zij regelmatig aan de verschillende eigenaren van informatieproducten over de bestaande toegangsrechten tot hun informatieproducten, zodat de eigenaren kunnen beoordelen of de bestaande rechten correct zijn. 2.3.10 Informatie-analist / data-analist De informatie-analist en/of data-analist is degene die voorziet in de vertaling van de business behoefte in wensen voor dataoplossingen, de oplevering van data en de uitvoering van activiteiten m.b.t. privacy, security en informatiebeheer. Zij hebben dus een belangrijke ondersteunende rol bij het specificeren van het doel en de AVG-grondslag van het informatieproduct / de gebruiksverwerking, het vaststellen van welke (persoons)gegevens daarvoor nodig zijn, en het vaststellen van privacybevorderende maatregelen. Ook zijn zij betrokken bij de implementatie en documentatie van de maatregelen, nadat de (toekomstig) proceseigenaar van het informatieproduct die maatregelen – al dan niet met behulp van een DPIA – heeft vastgesteld.

2.3.11 BI-specialist / data engineer / data scientist / poweruser Dit zijn de medewerkers die zorgen voor het realiseren van informatieproducten c.q. het uitvoeren van analyses op datasets, en het technisch ontsluiten en prepareren van de benodigde data met behulp van de daarvoor beschikbare tooling – bijvoorbeeld applicaties als Cognos, Power BI en SAS Viya, programmeertalen als Pyhton en R, en ETL-tooling en ontwikkelomgevingen als Azure Databricks. Zij zorgen er dus voor dat (persoons)gegevens daadwerkelijk worden omgezet in de gewenste inzichten die een informatieproduct of analyse moet opleveren. Daarmee hebben zij een belangrijke rol bij het bepalen welke persoonsgegevens wel/niet nodig zijn, en dus het voldoen aan het beginsel van dataminimalisatie. Verder implementeren zij een belangrijk deel van de technische maatregelen voor het mitigeren van privacyrisico’s. Deze medewerkers werken voor een van de clusterspecifieke Data & Analytics Competence Centers, of in het geval van een poweruser (in het kader van self-service BI), elders binnen een cluster. Omdat zij bij het ontwikkelen en testen van het informatieproduct en het uitvoeren van analyses mogelijk met grote hoeveelheden persoonsgegevens werken, wordt van hen verwacht dat zij daar zeer zorgvuldig mee omgaan. Bovendien dienen de projectomgevingen waarin zij werken strikt van elkaar te zijn gescheiden.

Op die manier hebben alleen de medewerkers die daadwerkelijk zijn betrokken bij het realiseren van het betreffende informatieproduct of het uitvoeren van een bepaalde analyse toegang tot de gegevens die daarvoor nodig zijn. 2.3.12 Privacy compliancespecialist OBI ondersteunt de clusters ook door expertise te leveren op het gebied van privacy/compliancevraagstukken bij datagedreven werken. De privacy compliancespecialist verzorgt de voorfase van het DUB-proces, samen met de gegevensmakelaar, op basis waarvan de leden van het DUB gericht hun adviezen kunnen uitbrengen. Voorts onderhoudt de privacycompliance specialist de richtlijnen voor de compliance-aspecten van datagedreven werken, waaronder dit privacyframework, adviseert in concrete gevallen bij het realiseren van

36

Voor het concern Datawarehouse gebeurt dit door Wijzigingsbeheer van het team DWH van de afdeling OBI.

Datum

Pagina

mei 2023

26 van 41

nieuwe informatieproducten, ondersteunt bij het uitvoeren van DPIA’s, en houdt toezicht op de implementatie en effectiviteit van privacybevorderende maatregelen voor zowel de verkrijging als voor het (her)gebruik van de data. 2.3.13 Gegevensmakelaar De belangrijkste taak van een gegevensmakelaar is het bij elkaar brengen van de vraag naar en het aanbod van data. Een gegevensmakelaar heeft dan ook bij uitstek zicht op welke data beschikbaar is om tot de door de opdrachtgever/proceseigenaar gewenste inzichten te komen. Op basis van die kennis kan een gegevensmakelaar goed inschatten welke (persoons)gegevens nodig zijn om te verwerken in het informatieproduct, en wat de kwaliteit van de daarvoor benodigde data is. Ook speelt de gegevensmakelaar een belangrijke rol bij de totstandkoming van de gegevensleveringsovereenkomst tussen dataleverancier en afnemer. 2.3.14 DISO / adviseur informatiebeheer / algoritme-expert Deze functionarissen nemen – samen met de Privacy Officer – deel aan de Data Usage Board37 (DUB) hebben een belangrijke adviserende taak richting de (toekomstig) proceseigenaar, omdat zij hem/haar adviseren over de te implementeren maatregelen uit hoofde van de AVG (en andere privacyregelgeving), de BIO en de Archiefwet.

Ook adviseren zij waar van toepassing over de ethische aspecten van het informatieproduct, 38 zaken op het gebeid van datamanagement en het publiceren van data op grond van de Wet hergebruik overheidsinformatie. Dit doen de leden door vanuit hun expertise te adviseren over het te ontwikkelen informatieproduct. 2.3.15 Privacy Officer (PO) De privacy officer neemt deel aan het DUB proces en adviseert daarin over de AVG aspecten van een bepaald informatieproduct. Hij/zij adviseert de proceseigenaar, waar nodig in samenspraak met de PO van de bronhouder en de security officer over de te nemen maatregelen. Het DUB proces leidt tot eén integraal advies waarin de Privacy officer het advies opstelt met input van de andere experts in het DUB proces. Wanneer het DUB advies niet wordt overgenomen door de proceseigenaar kan de privacy officer of een ander lid van het DUB het advies voorleggen aan de FG, 2.3.16 Functionaris gegevensbescherming (FG) De rol van de FG is niet anders dan bij de verwerkingen van persoonsgegevens in de primaire processen van de gemeente: Wanneer het DUB proces tot een advies leidt waarmee de proceseigenaar/afnemer het oneens is kan de FG om advies worden gevraagd. Zodoende is de FG onderdeel van de escalatieladder.

Wanneer het DUB proces leidt tot een DPIA wordt de DPIA altijd voorgelegd aan de FG, voorzien van advies door de PO’er, waarna de FG een advies geeft. Tevens houdt de FG – als third line of defence – systeemtoezicht.

Interne auditor De interne auditfunctie vormt – samen met de FG – de derde linie in het three lines of defense-model dat de gemeente hanteert. Interne auditors van Concern Auditing kunnen onafhankelijk de governance-, risicomanagement- en interne beheersingsprocessen van een organisatie beoordelen en geven aanvullende zekerheid over de kwaliteit ervan. Ze

37 38

Zie hierover de paragraaf DUB-proces. In het bijzonder als de verwerking van gegevens plaatsvindt met behulp van een algoritme.

Datum

Pagina

mei 2023

27 van 41

beantwoorden dus de volgende vraag: bestuurt de 1e lijn (management) de organisatie toereikend en worden ze hierin voldoende ondersteund door de 2e lijn? Onderdeel van de governance is het controleren of de werkwijze en vastgestelde procedures ook daadwerkelijk worden gevolgd, en hierop te handhaven waar nodig. Daartoe zal de interne auditors (Concern Auditing) worden gevraagd een audit uit te voeren op de werking van dit kader in de praktijk. Daarnaast zal ook binnen OBI periodiek geëvalueerd worden, door een daarvoor aan te wijzen team. Waar nodig zal hoofd OBI opdracht geven de uitkomsten van audits en evaluaties door te voeren in het technische en organisatorische proces.

2.4 Procedures Er zijn vele procedures die een rol spelen bij het werken met (persoons)gegevens. Denk aan autorisatieprocedures, de procedure voor het faciliteren van de (AVG-)rechten van betrokkenen en het melden/afhandelen van datalekken. De meeste procedures hebben een generiek karakter, en kunnen ook op het datagedreven werken worden toegepast. 39 Er zijn echter ook enkele procedures die specifiek voor datagedreven werken van belang zijn, en een belangrijke rol hebben bij het voldoen aan wet- en regelgeving. De voornaamste daarvan is het DUB-proces, als vast onderdeel van de way of working voor data- & analyseprojecten. Deze way of working geeft handvatten voor het realiseren van een informatieproduct, van eerste idee tot en met de in beheername en doorontwikkeling.40 Maar ook als bij het realiseren of het doorontwikkelen van een informatieproduct niet volgens de way of working wordt gewerkt, is de proceseigenaar verplicht om advies te vragen aan de DUB. Daarnaast speelt het GLO-proces een belangrijke rol bij het borgen van afspraken over het (door)leveren van data en de kwaliteit daarvan, maar ook bij het vastleggen van wie proceseigenaar is van – en dus verantwoordelijk is voor – welk informatieproduct. 2.4.1 DUB-proces De Data Usage Board is een orgaan dat advies uitbrengt aan de toekomstige (proces)eigenaar van een te realiseren informatieproduct.

Dit advies ziet onder meer opde volgende aspecten: • • • • • • •

Nut, noodzaak, doel, grondslag, dataminimalisatie en alle andere AVG principes. de te implementeren maatregelen voor het beperken en beheersen van privacyrisico’s en informatiebeveiligingsrisico’s; de te hanteren bewaartermijn; de toepassing van de FAIR-principes (Findable, Accessable, Interoperable, Reusable) op de outputdata; het verhogen van de data kwaliteit en daarmee de waarde van de data bepalen of uitvoering van een DPIA vereist is voor dataverwerkingen (waaronder algoritmes) de ethische aspecten van het informatieproduct, met name bij de inzet van algoritmes, waarbij naast een DPIA een ethische toets (DEDA bij laag risico of IAMA bij hoog risico), wordt uitgevoerd.

De samenstelling van de DUB is deels afhankelijk van het te ontwikkelen informatieproduct:

39

Denk aan de procedures voor het bijwerken van het verwerkingsregister, het afsluiten van verwerkersovereenkomsten, het effectueren van de rechten van betrokkenen en het melden en afhandelen van potentiële datalekken. 40 @@ Link opnemen naar beschrijving way of working op procesplein

Datum

Pagina

mei 2023

28 van 41

•

•

Als ten behoeve van het informatieproduct persoonsgegevens zullen worden verwerkt, neemt de Privacy officer van het opdrachtgevende cluster of afdeling plaats in de DUB. Zo nodig ook de privacy officer van de bronhouder(s). Als de verwerking plaatsvindt met behulp van een algoritme, 41 neemt ook een algoritmeexpert deel aan het DUB.

Mede om te borgen dat privacy by design wordt toegepast, geeft de Data Usage Board twee keer advies over het te realiseren informatieproduct: • Een advies aan het begin van het project, voordat het project start met de daadwerkelijke ontwikkelactiviteiten. Dit advies heeft onder meer betrekking op het te dienen doel en mogelijke grondslagen voor de verwerking, te implementeren beveiligingsmaatregelen, te hanteren bewaartermijnen en of het nodig is om een DPIA 42 en/of een ethische toets uit te voeren. • Daarnaast vraagt de gegevensmakelaar die de DUB-bijeenkomst voorbereidt aan de Privacy Officer van het dataleverende cluster om schriftelijk advies uit te brengen. Dit advies heeft in het bijzonder betrekking op de verenigbaarheid van het gebruik van de brondata met de oorspronkelijke verwerkingsdoelen. • Een advies aan het einde van het project, voordat OBI of het cluster het informatieproduct in beheer neemt. In het tweede advies beoordeelt de DUB in hoeverre de geïmplementeerde maatregelen een effectieve bijdrage leveren aan het beperken en beheersen van risico’s en wordt een definitief Privacy advies gegeven. Zie voor de nadere beschrijving en uitwerking van het DUB-proces en de daarbij behorende formulieren Data Governance (data hergebruik/ processen).

2.4.2 Gegevensleveringsovereenkomsten (GLO’s) Een GLO is een overeenkomst tussen twee partijen binnen de gemeente die betrekking heeft op het leveren van data: de dataleverancier en de afnemer. In een GLO maken leverancier en afnemer afspraken over om welke gegevens het precies gaat, en over de beschikbaarheid en kwaliteit van de betreffende gegevens. Zie datacontracten (GLO en DTA) voor de beschrijving van het proces voor het afsluiten van GLO’s. Parallel aan het onderscheid in verantwoordelijkheden tussen de verkrijging en de diverse gebruikstoepassingen is er een GLO voor: • het ontsluiten van brongegevens en het bewaren daarvan in de opslaglaag van het DAP’R – de leverancier is dan de bronhouder, de afnemer is (het hoofd van) de afdeling OBI. • het beschikbaar stellen van gegevens vanuit de opslaglaag ten behoeve van een specifiek informatieproduct – de leverancier is in dat geval (het hoofd van) de afdeling OBI, en de afnemer is de proceseigenaar van het informatieproduct. Zoals in de vorige paragraaf vermeld, zal de afdeling OBI data alleen structureel ter beschikking stellen aan de afnemer als er een GLO tot stand is gekomen tussen beide partijen. Door ondertekening van de GLO geeft de afnemer tevens aan dat hij/zij de risico’s aanvaardt die voortvloeien uit het verwerken van de betreffende (persoons)gegevens.

41

Zoals bedoeld in de algoritmegovernance van de gemeente; zie @@ Onderdeel van dit framework is een aparte DPIA-template voor informatieproducten, opgenomen in annex III. Deze template beperkt zich tot de aspecten die voor ieder informatieproduct anders zijn, zoals doel, grondslag en benodigde persoonsgegevens. De aspecten van het gebruik van Cognos, Power BI en SAS Viya, die voor ieder informatieproduct hetzelfde zijn, zijn besproken in separate ‘generieke DPIA’s’. 42

Datum

Pagina

mei 2023

29 van 41

3 Levenscyclusbeheer Levenscyclusbeheer gaat over (de beheersprocessen rondom) het ontstaan, gebruiken, opslaan, wijzigen en uiteindelijk vernietigen van data en informatieproducten. Het beheren van de datalevenscyclus is een onderdeel van datamanagement. Het is niet de bedoeling dit onderwerp hier uit te werken; dit hoofdstuk gaat over de aspecten van de datalevenscyclus van belang voor het voldoen aan de AVG, de BIO en de Archiefwet bij het data gedreven werken met het DAP’R.

Figuur 1 De levencyclus van data volgens DAMA DMBOK Data- en informatieproducten die wij binnen de gemeente Rotterdam ontwikkelen, vallen onder de regels van de Archiefwet en bijbehorende lagere regelgeving. Deze regels zijn er om: - Transparant te maken hoe besluitvorming tot stand is gekomen en hoe de overheid heeft gehandeld (bijvoorbeeld voor de WOO); - Goede dienstverlening en bedrijfsvoering mogelijk te maken; - Bewijs van het handelen van de overheid te kunnen leveren, bijvoorbeeld bij bezwaar, beroep en geschillen. - Behoud van informatie voor (historisch) onderzoek. De Archiefwet, vertaald in de VNG Selectielijst, schrijft bewaartermijnen voor per proces en daar uit voortkomende informatie. Sommige categorieën informatie moeten we blijvend bewaren en binnen twintig jaar naar het Stadsarchief overgebrengen, andere moeten na een bewaartermijn vernietigd worden. Deze bewaartermijnen zijn een wettelijke grondslag om persoonsinformatie in de zin van de AVG verder te mogen verwerken. De Archiefwettelijke maatregelen zijn op twee manieren ondersteunend aan de AVG: - Door tijdig, volgens bewaartermijnen, te vernietigen, bewaren we persoonsgegevens niet onnodig lang (dataminimalisatie) en is helder voor alle betrokkenen hoe lang we hun gegevens bewaren.

Datum

Pagina

mei 2023

30 van 41

-

Transparantie richting burgers: door de data en documentatie over totstandkoming en werking van informatieproducten goed te bewaren, kunnen we betrokkenen makkelijk en betrouwbaar informeren over wat er met hun data is gebeurd en met welke data en algoritmen de gemeente een besluit heeft genomen. De reikwijdte van de Archiefwet gaat verder dan de AVG. De regels gelden ook voor nietpersoonsgegevens. Dit hoofdstuk beschrijft de werkwijze van levenscyclusbeheer by design. Maatregelen als functionaliteit in software, vastleggen van metadata en inrichting van het proces nemen we in het ontwerp mee. Hiermee lossen we niet het levenscyclusbeheer van bestaande informatieproducten en hun achterliggende data op. Dit vraagt om een eenmalige aanpak, waarbij we, bij ontbreken van metadata over bewaartermijnen, bestaande data en loggegevens gebruiken. Dit vraagt handwerk, met alle risico’s van dien. De datalevenscyclus (3.1) is verbonden met de levenscyclus van informatieproducten (3.2), omdat het doel en het bedrijfsproces van het informatieproduct in veel gevallen de bewaartermijn van de onderliggende data bepaalt.

3.1 Datalevenscyclus 3.1.1 Ontstaan en bewerken De meeste gegevens in het DAP’R, zijn afkomstig uit bronsystemen, en bestonden voordat we het op het DAP’R ontsloten. Als nieuwe gegevens ontstaan op het DAP’R, is het een verrijking van gegevens. Als dit een generiek karakter heeft, voegen we de nieuw ontstane data toe aan de opslaglaag, en zijn deze beschikbaar voor hergebruik. In dat geval is het creëren van de gegevens onderdeel van de verwerking, en moeten we de nieuwe gegevens classificeren en toevoegen aan de datacatalogus. Als de nieuwe data persoonsgegevens zijn, geldt dat we ze alleen creëren (en bewaren) als dat nodig is voor een of meer informatieproducten. Zolang dat het geval is, blijven zij bewaard in de opslaglaag, en passen we bewaartermijnen toe. Deze worden vastgesteld op basis van de VNG-selectielijst. Data die we uit bronsystemen halen, moeten we bewerken. Data matchen, transformeren, integreren, standaardiseren en anonimiseren we, afhankelijk van het gebruik en autorisaties. Sommige bewerkingen zijn zo tijdrovend, dat we het resultaat moet opslaan zodat we deze ‘snel’ kunnen leveren. Om te voldoen aan dataminimalisatie doen we dit alleen als dit nodig is voor de gewenste performance. De lineage van deze bewerkingen moet transparant zijn en getoond kunnen worden, zodat gebruikers kunnen inzien hoe de data is ontstaan vanuit de brondata.

De hierom opgeslagen data moeten we voorzien van een bewaartermijn en daarna vernietigen we ze. Bij BI is er een variant zonder tussenbewerkingen, namelijk Direct Query, dan is er geen tussentijdse gegevensopslag en wordt direct geput vanuit het Datawarehouse. 3.1.2 Gebruiken Het gebruik van gegevens vindt – in geval van Business Intelligence en Analytics – plaats door verwerking ervan in de diverse informatieproducten. De meeste privacy risico's doen zich voor wanneer een informatieproduct persoonsgegevens bevat. Daarom toetsen we ieder voorgenomen gebruik (en opslag) vooraf door de Data Usage Board op compliance met onder meer de AVG, de BIO en de Archiefwet. Voor ieder gebruik van gegevens voor een informatieproduct, moet separaat worden beoordeeld of het mag en zo ja, welke maatregelen daarvoor nodig zijn. De proceseigenaar voert een PRA uit en een DPIA als dat nodig is.

Datum

Pagina

mei 2023

31 van 41

Het gebruik van persoonsgegevens begint met het bepalen van het doel van het informatieproduct en AVG-grondslag. Vervolgens moet de proceseigenaar vaststellen welke persoonsgegevens nodig zijn om dat doel te bereiken (dataminimalisatie). Dit gebeurt door eerst te bepalen welke dataobjecten nodig zijn, en vervolgens per dataobject welke attributen. Alleen die objecten en attributen worden vanuit de opslaglaag beschikbaar gesteld voor dat specifieke informatieproduct. Dataminimalisatie is ook het beoordelen of we: • Gegevens uitsluitend geaggregeerd (geanonimiseerd indien daarna nog nodig); of • Gegevens gepseudonimiseerd of (deels) gemaskeerd tonen aan de gebruiker van het informatieproduct. Anonimiseren of pseudonimiseren van hergebruikte gegevens is niet strijdig met de Archiefwet, omdat het nog steeds mogelijk is te reconstrueren hoe besluiten met het informatieproduct genomen zijn. Dit geldt niet voor informatie die we creëren in het oorspronkelijk bronproces. Bijvoorbeeld het verstrekken van een vergunning of uitkering. Daar gaat het vaak om een individueel persoon, die herkenbaar moet zijn voor de behandeling van de zaak en latere reconstructie. Vervolgens stelt de proceseigenaar43 vast hoe lang de gegevens bewaard moeten blijven voor het doel. Dit is onderdeel van het gesprek in de Data Usage Board (DUB) en vindt plaats in de ontwerpfase (by design).

Zie hiervoor paragraaf 2.2.2. De cluster records manager44 neemt hieraan deel. Deze stelt met de proceseigenaar vast welk IBP-proces45 ondersteund wordt door het informatieproduct, of maakt een nieuw IBP-proces aan. Ieder IBP-proces is gekoppeld aan een categorie en vernietigingstermijn van de landelijke VNG Selectielijst. Zie verder onder 3.1.5 ‘Vernietigen’. Het is ook nodig in deze fase vast te stellen hoe ver je wilt terugkijken. Dan kun je in de software, of procesmatig de bewaartermijn starten. En tot slot welke specifieke toegangsrechten en overige beveiligingsmaatregelen we moeten toepassen. Een best practice is dat een informatieproduct de datum vermeldt van de onderliggende dataset, zodat de eindgebruiker weet hoe recent de gebruikte gegevens zijn. Welke gegevens precies worden aangeleverd voor een specifiek informatieproduct en wat daar de beschikbaarheids- en kwaliteitscriteria voor zijn, leggen we vast in een gegevensleveringsovereenkomst tussen bronhouder en OBI, en de (proces)eigenaar van het informatieproduct. Bij data van een externe partij stel je een Data Transfer Agreement (DTA) op. Zie hiervoor hoofdstuk 4 over Datamanagement.

3.1.3 Opslaan We slaan gegevens op in de opslaglaag van het DAP’R. Het kan zijn dat de opslag in verschillende databases en verschillende fysieke locaties plaatsvindt, op eigen dataservers, of bij een externe hostingpartij. Logisch gezien is er één opslaglaag. Welke gegevens zijn opgenomen in de opslaglaag, en wat hun betekenis en eigenschappen zijn, leggen we vast in de datacatalogus. De ‘opslaglaag’, is alleen voor het bewaren van gegevens, en het opbouwen van historie. Voordat we gegevens daadwerkelijk verwerken voor specifieke informatieproducten (zie hierna), laden we ze eerst in een aparte omgeving. Zo minimaliseren we het aantal medewerkers dat toegang heeft tot de opslaglaag. Zie hiervoor het hoofdstuk over Security (H4).

43

of namens hem de product owner van het informatieproduct Contact Procesmanagement Beheer Informatiehuishouding - RIO (rotterdam.nl) 45 Het Informatiebeheerplan (IBP) bevalt alle processen van de gemeente met bijbehorende informatieneerslag. Deze hebben een zogeheten P-nummer. Zie: Beleid, wetgeving en Informatiebeheerplan - RIO (rotterdam.nl) 44

Datum

Pagina

mei 2023

32 van 41

Het beginsel van dataminimalisatie betekent dat de gemeente alleen gegevens bewaart in de opslaglaag die daadwerkelijk nodig zijn voor één of meer informatieproducten. Met datalineage bepalen we welke dataobjecten we opslaan door bij te houden welke dataobjecten nodig zijn voor welke informatieproducten. Het exporteren van gegevens uit de opslaglaag en opslaan in excelsheets of PDF's mag alleen als dit niet strijdig is met de privacywetgeving, zoals vastgesteld in de DUB. Als dit nodig is voor het opleveren van een product, moeten we deze documenten in een beheerde omgeving opslaan, bij voorkeur DIVA. Zo waarborgen we de bewaartermijnen. 3.1.4 Wijzigen Het wijzigen van de op het DAP’R aanwezige gegevens vindt in de bronsystemen plaats. De gewijzigde gegevens komen vervolgens via het ontsluitingsproces in de opslaglaag terecht, waarbij de verouderde/gecorrigeerde gegevens als historie bewaard blijven tot hun bewaartermijn verstrijkt. Het recht op correctie heeft dus geen rechtstreekse impact op het DAP’R, en hoeven we geen maatregelen te treffen op het DAP’R. Het is van belang dat alleen een zeer beperkte groep ontwikkelaars toegang heeft tot het wijzigen van de business rules die de de bron naar de opslaglaag vertalen in het DAP’R.

3.1.5 Vernietigen Op grond van de Archiefwettelijke VNG Selectielijst voor gemeenten46 moet de gemeente per proces bepalen hoelang de daarin verwerkte gegevens bewaard moeten blijven. Zo moet de proceseigenaar ook voor ieder informatieproduct vaststellen wat de bewaartermijn is. Omdat een informatieproduct altijd een bedrijfsproces ondersteunt, is de bewaartermijn voor het informatieproduct gelijk aan de bewaartermijn van dat bedrijfsproces. Als een informatieproduct meerdere bedrijfsprocessen ondersteunt, geldt de langste termijn. Het informatieproduct dat het proces met kortste bewaartermijn ondersteunt, heeft dan geen toegang meer. Deze bewaartermijn geldt voor: • De definitie van het informatieproduct, oftewel de regels aan de hand waarvan de gegevens worden verwerkt en getoond aan de gebruiker; • Een eventueel ‘hardcopy’ rapport van het informatieproduct; • De data die in het informatieproduct worden verwerkt NB: de bewaartermijn van de data wordt dus niet afgeleid van de bron van de data. De definitie kan simpelweg worden gearchiveerd in de daarvoor beschikbaar gestelde infrastructuur (bij voorkeur een register van definities), terwijl de data wordt bewaard in de opslaglaag van het DAP’R. Daartoe moet eerst worden vastgesteld welke dataobjecten precies nodig zijn voor dat informatieproduct, om vervolgens per dataobject de bewaartermijn te bepalen:

46

Selectielijst 2020 vastgesteld | VNG

Datum

Pagina

mei 2023

33 van 41

Als een dataobject in meerdere informatieproducten wordt verwerkt – zoals bij dataobject D het geval is – geldt de langste termijn. Een dataobject is op zijn beurt opgebouwd uit een of meerdere tabellen. Als op bovenstaande manier per dataobject de bewaartermijn is bepaald, moet die vervolgens worden toegepast op alle onderliggende tabellen:

Het toepassen van bewaartermijnen op de onderliggende tabellen, gebeurt door voor ieder record binnen een tabel te bepalen wanneer de bewaartermijn begint. Na het verstrijken van deze termijn, wordt het record definitief verwijderd uit de opslaglaag. Wanneer de bewaartermijn begint, wordt bepaald aan de hand van business rules. Voor ieder informatieproduct wordt per dataobject de business rule bepaald. Omdat een dataobject in meerdere informatieproducten verwerkt kan worden (zoals dataobject D in het voorbeeld hierboven), leidt dit mogelijk tot meerdere business rules voor ieder dataobject in de

Datum

Pagina

mei 2023

34 van 41

opslaglaag. In dat geval wordt de business rule toegepast die tot de langste bewaartermijn leidt. In sommige gevallen is een dataobject niet opgebouwd uit tabellen, maar uit andere soorten bestanden. Het gaat dan bijvoorbeeld om afbeeldingen en documenten. Dit soort bestanden bevatten geen records zoals tabellen die hebben. Bewaartermijnen kunnen dan ook niet op recordniveau worden bepaald, maar zullen in plaats daarvan op bestands-niveau worden toegepast. Naast dat voor de in dataobjecten aanwezige gegevens bewaartermijnen gelden, geldt dat ook voor de dataobjecten. Zoals in paragraaf gezegd, bevat de opslaglaag van het DAP’R alleen dataobjecten nodig voor een of meer informatieproducten. Dat betekent dat, als een informatieproduct komt te vervallen, moet worden bekeken of de daarin gebruikte dataobjecten nog nodig zijn voor andere informatieproducten. Als dat niet het geval is, dan start de bewaartermijn voor het dataobject als geheel: • Het ontsluiten van brongegevens voor dit dataobject wordt gestopt; • Dan gaat de bewaartermijn in; • Na afloop van de bewaartermijn wordt het gehele dataobject, inclusief alle onderliggende tabellen/bestanden, verwijderd.47 • Eventuele ruwe gegevens, tijdelijk ingeladen gegevens in analysetools, de inhoud van de datamart worden als dubbele gegevens beschouwd en kunnen meteen na het afsluiten van het informatieproduct worden vernietigd.

De laatste twee worden periodiek ververst, waarbij de oude (kopie)gegevens worden overschreven. • Tijdens de levensduur van het informatieproduct moeten periodiek data die buiten de scope van de historie vallen worden opgeschoond/op bewaartermijn afgesteld, handmatig, of softwarematig. De boven beschreven werkwijze is gebaseerd op de VNG Selectielijst 2020 en de Handreiking48. Het is raadzaam om een discussie op landelijk/VNG niveau te starten over de vraag tot op welk detailniveau de data van een informatieproduct bewaard moeten blijven gedurende de periode dat het informatieproduct in gebruik is, plus de bewaartermijn. Dit vanuit oogpunt van dataminimalisatie op grond van de AVG. In 2023 zal de huidige selectielijst geëvalueerd worden en zal dit punt vanuit Rotterdam ingebracht worden. Daarbij moet worden afgewogen of het bewaren van alle data die ten grondslag liggen aan een informatieproduct niet in tegenspraak is met het principe van dataminimalisatie uit de AVG. Dataminimalisatie houdt in dat bij het verzamelen en verwerken van persoonsgegevens niet meer gegevens mogen worden gebruikt dan nodig is om het doel waarvoor ze gebruikt zullen worden te bereiken. Het langdurig bewaren van grote hoeveelheden data met persoonsgegevens leidt echter tot privacyrisico's. Door beveiligingsincidenten kunnen data bijvoorbeeld in handen komen van of zichtbaar worden voor onbevoegden.

Hier gaat het echter om het bewaren van gegevens die al getoetst zijn in het licht van dataminimalisatie. Zij zouden anders niet voor het informatieproduct gebruikt mogen worden. In ieder geval geldt: als er wettelijke termijnen zijn, dan moet de organisatie die in acht nemen. Dit in het belang van de reconstrueerbaarheid van besluitvorming. Om die risico's zo klein mogelijk te houden worden de data in een zo vroeg mogelijk stadium gepseudonimiseerd en waar mogelijk

47

Als op grond van de Archiefwet de betreffende gegevens niet voor vernietiging in aanmerking komen, dan worden het dataobject direct verwijderd van het DAP’R, en de onderliggende gegevens ondergebracht in de archiefbewaarplaats van de gemeente. 48 handreiking-gebruik-selectielijst_20200506.pdf (vng.nl) par, 5.17

Datum

Pagina

mei 2023

35 van 41

geanonimiseerd. Naast de beveiligingsmaatregelen die in H4 worden besproken worden privacyrisico's op die manier zo klein mogelijk gehouden..

3.2 Levenscyclus van informatieproducten 3.2.1 Ontstaan Informatieproducten worden ontwikkeld en getest door de BI-teams van de afdeling OBI, en door BI-specialisten binnen de clusters (self-service BI). Hierbij kan het nodig zijn met persoonsgegevens te werken. Als dat het geval is, is er sprake van een verwerking van persoonsgegevens, en is de AVG van toepassing. Dat betekent dat de gemeente het ontwikkelen en testen van informatieproducten moet voorzien van de benodigde waarborgen, en dat de eigenaar van het ontwikkel- en testproces daarvoor verantwoordelijk is. Het proces waar het hier om gaat, is de way of working voor data- en analyseprojecten – zie ook de inleiding van hoofdstuk 0. De proceseigenaar is het hoofd van de afdeling OBI. Om bij het ontwikkelen en testen van informatieproducten privacyrisico's te beperken, nemen we de volgende maatregelen: • We gebruiken als regel gepseudonimiseerde of geanonimiseerde persoonsgegevens, waarbij uitzonderingen getoetst moeten worden door de DUB. • Bijzondere gegevens (gegevens over gezondheid, religie, etniciteit, ed.) worden geanonimiseerd. Waar mogelijk vooraf, en altijd na afronding van het informatieproduct. Ook hier worden uitzonderingen getoetst in de DUB.

• We bewaren de gegevens in een aparte projectomgeving; alleen de medewerkers die zijn betrokken bij de ontwikkel- en testwerkzaamheden voor dat specifieke informatieproduct hebben toegang tot deze projectomgeving. • Na afloop van het project zorgt de projectleider ervoor dat de gegevens uit de projectomgeving voorzien worden van een bewaartermijn, waar mogelijk direct gepseudonimiseerd of geanonimiseerd worden en na afloop daarvan worden verwijderd. Projectdocumentatie wordt gearchiveerd in DIVA. • Regelmatig controleert de functioneel beheerder welke projectomgevingen bestaan, en of zij nog in gebruik zijn. Zo niet, dan zorgt de eindverantwoordelijke voor de ontwikkelen testwerkzaamheden ervoor dat de niet meer in gebruik zijnde omgevingen worden verwijderd. • De bewaartermijn voor data in ontwikkel- en testomgevingen is 5 jaar (cat. 19.1 VNG Selectielijst). Als het informatieproduct klaar is om in productie/beheer te nemen, werken we de datalineage en de benodigde registers bij. Dit is een cyclisch proces dat zich bij iedere wijziging herhaalt. Afhankelijk van het informatieproduct kan het gaan om het register informatieproducten, het verwerkingsregister en het algoritmeregister.

In die fase is ook de het IBP-proces vastgesteld en daarmee de bewaartermijn, de technische en procesmatige maatregelen voor inregelen en toepassen van de bewaartermijn zijn getroffen en eventuele restrisico's zijn geaccordeerd. De afspraken worden na advies van de Data Usage Board vastgelegd in een GLO. 3.2.2 Gebruiken Waarvoor en door wie een informatieproduct precies wordt gebruikt, is aan de proceseigenaar/afnemer om te bepalen. In zijn algemeenheid is daar slechts over te zeggen dat het gebruik in lijn moet zijn met het vooraf vastgestelde doel van het informatieproduct. De proceseigenaar informeert de gebruikers die toegang hebben over dit doel, en over het feit dat zij het informatieproduct niet voor andere doelen mogen gebruiken.

Datum

Pagina

mei 2023

36 van 41

De proceseigenaar bepaalt ook met wie buiten de gemeente het informatieproduct wordt gedeeld. Ook daar is het beginsel van doelbinding op van toepassing: het extern delen moet noodzakelijk zijn om het doel van het informatieproduct te realiseren. 3.2.3 Opslaan Nadat het informatieproduct is samengesteld, is het technisch mogelijk om het op te slaan buiten de applicatie waarin het informatieproduct is samengesteld, bijvoorbeeld in pdf-formaat. Alhoewel het wenselijk kan zijn dat gebruikers dat kunnen, kleven daar ook privacy- en andere compliancerisico's aan, voor zover het informatieproduct persoonsgegevens bevat. Die nadelen zijn: • Het is lastiger om te borgen dat het informatieproduct niet voor andere doelen wordt gebruikt, omdat er geen zicht meer is op wie op welk moment toegang had tot de gegevens. • Het is lastiger om aan het beginsel van opslagbeperking en de Archiefwet te voldoen, omdat er geen zicht is op waar het informatieproduct wordt opgeslagen. • Het is lastiger om gevolg te geven aan de rechten van betrokkenen – in het bijzonder het recht op verwijdering – omdat er geen zicht is op waar het informatieproduct wordt opgeslagen. • Het is lastiger om te borgen dat blijvend wordt voldaan aan de BIO als er geen zicht is op waar het informatieproduct wordt opgeslagen, en wie er op die plaats toegang hebben tot de daarin besloten gegevens.

Het aan de proceseigenaar gebruiksverwerking om te besluiten of het opslaan door gebruikers is toegelaten. Voor informatieproducten die persoonsgegevens bevatten dient deze keuze expliciet te worden gemaakt en onderbouwd worden gedocumenteerd. De Data Usage Board zal hierover worden geïnformeerd, zodat de leden daar advies over uit kunnen brengen aan de (toekomstig) proceseigenaar. 3.2.4 Wijzigen Net als de totstandkoming van nieuwe informatieproducten, loopt het wijzigen ervan volgens de gebruikelijke change- en releasemanagementprocessen van OBI en de DACC’s. Voor grote wijzigingen kan de Way of Working voor data- & analyseprojecten worden gebruikt, waarin ook het DUB-advies, addendum op het GLO en het uitvoeren van een eventuele DPIA als belangrijke privacy waarborgen deel van uitmaken. Mocht de wijziging daar aanleiding toe geven, dan dienen (waar van toepassing) het register informatieproducten, de datalineage, het verwerkingsregister en het algoritmeregister te worden bijgewerkt. 3.2.5 Verwijderen Ook informatieproducten komen aan het einde van hun levenscyclus.

Niet alleen om systeemcapaciteit te sparen, maar ook vanuit compliance perspectief is het nodig om het informatieproduct te verwijderen, of over te brengen naar het Stadsarchief (wanneer het blijvend bewaard moet worden).49 Om aan de Archiefwet te voldoen, moet de definitie van het informatieproduct worden gearchiveerd in DIVA volgens de geldende bewaartermijn. De data die nodig zijn om het informatieproduct later nogmaals te kunnen samenstellen, worden bewaard in de opslaglaag van het DAP’R, totdat zij conform de bewaartermijn vernietigd moeten worden, of overgebracht naar het Stadsarchief.

49

Zo is het samenstellen van een informatieproduct dat niet meer in gebruik is, strijdig met de AVG, omdat er onnodig persoonsgegevens worden verwerkt.

Datum

Pagina

mei 2023

37 van 41

Om te signaleren welke informatieproducten voor verwijdering in aanmerking komen, moet er, procesmatig en/of geautomatiseerd, een overzicht bijgehouden worden, met een instelbaar signaleringsmechanisme wanneer informatieproducten langer dan bijvoorbeeld een jaar niet gebruikt zijn. De ‘niet gebruik’-meldingen worden gedeeld met de betreffende proceseigenaars van de daarop vermelde informatieproducten, zodat zij op basis van het overzicht kunnen aangeven welke informatieproducten kunnen komen te vervallen. Zodra een eigenaar aangeeft dat een informatieproduct kan vervallen, wordt het op de bewaartermijn afgesteld, zoals hierboven beschreven. Het verladen van gegevens vanuit de opslaglaag voor het betreffende informatieproduct stopt, en er wordt beoordeeld of de onderliggende dataobjecten ook voor archivering/verwijdering in aanmerking komen. Tot slot dienen (waar van toepassing) het register informatieproducten, het GLO-register, de Gegevenscatalogus, de datalineage, het verwerkingsregister en het algoritmeregister te worden bijgewerkt. Er is functionaliteit nodig om het vervallen van bewaartermijnen te signaleren, te controleren of de data nog door andere informatieproducten wordt gebruikt en zo niet, de vernietiging, of overbrenging te effectueren.

Datum

Pagina

mei 2023

38 van 41

4 Security Dit hoofdstuk beschrijft op hoofdlijnen welke keuzes zijn gemaakt met betrekking tot de inrichting van informatiebeveiliging binnen het DAP’R. Het gaat daarbij specifiek om de volgende applicaties: • het concern Datawarehouse • het Datake • IBM Cognos • Microsoft Power BI • SAS Viya • Azure Databricks, Azure Synapse en Azure Machine Learning Al deze applicaties zijn geclassificeerd op Basisbeveiligingsniveau (BBN) 2+. Uitgangspunt voor de hierna volgende beschrijving is dan ook dat alle controls 50 behorend bij dit BBN niveau zijn geïmplementeerd, of nog zullen worden geïmplementeerd, om volledig aan de Baseline Informatiebeveiliging Overheid BIO) te voldoen. Voor een meer gedetailleerde beschrijving van geïmplementeerde en te implementeren controls wordt verwezen naar de zelfassessments behorende bij deze applicaties.

4.1 Prioritering maatregelen Er is een risicoanalyse uitgevoerd door de DISO BCO, welke een aantal hoofdrisico’s heeft gedefinieerd. Dit zijn de volgende risico’s: • Toegang tot data • Misbruik van data • Leveranciersmanagement • Assurance dienstverlening OBI • Gebruik Shadow IT Als gevolg van deze risico’s zijn er een aantal hoofdmaatregelen geadviseerd: • Adequate toegangsbeveiliging • Loggen van gebruikersactiviteiten • Afspraken met externe leveranciers • Programmatuurgerichte maatregelen • Mensgerichte maatregelen Het is uiteindelijk van belang dat alle BIO controls worden geïmplementeerd, maar hoofdzakelijk dient er een focus te liggen op het vijftal geadviseerde hoofdmaatregelen. De controls zullen zoveel mogelijk worden geïmplementeerd met relevante risico’s in het achterhoofd.

50

In AVG-termen: technische en organisatorische maatregelen

Datum

Pagina

mei 2023

39 van 41

4.2 Toegangsbeveiliging Een van de grootste risico’s is ongeautoriseerde toegang tot data. Dit kan zowel van buitenaf als binnenaf gebeuren. Om ongeautoriseerde toegang door medewerkers te voorkomen is het de bedoeling dat toegangsbeveiliging zo goed mogelijk is ingericht. Een aantal maatregelen dient getroffen te worden. 4.2.1 Reguliere accounts • Bepaal waar en op welke wijze functiescheiding wordt toegepast, zodat gebruikers alleen informatie kunnen inzien en verwerken die ze nodig hebben voor het uitoefenen van hun taak. Dit is het principe van least privilege. o Pas functiescheiding toe op medewerkers die gegevens inladen en medewerkers die gegevens gebruiken. Dit zijn verschillende belangen die zoveel mogelijk gescheiden dienen te blijven. • Het verlenen van toegangsrechten dan wel functieprofielen binnen de tools en opslagfaciliteiten wordt uitsluitend verleend na autorisatie door een bevoegde functionaris die staat genoteerd in een mandaatregister. o Zorg dat het toewijzen van rechten via een traceerbaar proces verloopt, bijvoorbeeld via SARA. Zorg ook dat er met profielen wordt gewerkt, vermijd het kopiëren van rechten van andere gebruikers naar een nieuwe gebruiker. o Het verlenen van toegangsrechten gaat met behulp van een autorisatiematrix. Voor ieder proces/applicatie dient er een autorisatiematrix te zijn.

Deze autorisatiematrix bevat minimaal welke rollen er aanwezig zijn en welke rechten deze rollen hebben. Er wordt gewerkt met rollen/functies, er vindt geen toegang plaats zonder toewijzing van een rol. • Er is een formele registratie- en afmeldprocedure voor het beheren van gebruikersidentificaties. o Handelingen en afwegingen in het proces dienen opgeschreven te zijn. • Toegangsrechten van gebruikers behoren bij beëindiging van dienstverband te worden verwijderd en bij wijzigingen behoren ze te worden aangepast. • Alle uitgegeven toegangsrechten worden minimaal eenmaal per halfjaar beoordeeld. De eigenaren van de tools en opslagfaciliteiten horen deze beoordeling uit te (laten) voeren. o Functioneel Beheer ondersteunt in dit proces door het te initiëren, voortgang te bewaken etc. Daadwerkelijke controle dient plaats te vinden door verantwoordelijk managers. Toegangsbeveiliging is veelal een menselijk proces, er kunnen dus fouten insluipen. Het is daarom aan te raden zoveel mogelijk van de toegangsbeveiliging te automatiseren. Denk hierbij bijvoorbeeld aan het automatisch verlopen van toegangsrechten.

4.2.2 Beheeraccounts Maatregelen: • De uitgegeven speciale bevoegdheden worden minimaal ieder kwartaal beoordeeld. • Alleen bevoegd personeel heeft toegang tot systeemhulpmiddelen, zoals beheertools. o Zorg dat aantallen beheerders zoveel mogelijk beperkt zijn, maar wel met oog voor een praktisch werkbare situatie. Het is niet aan te raden slechts één beheerder aan te stellen voor een applicatie.

Datum

Pagina

mei 2023

40 van 41

4.3 Loggen gebruikersactiviteiten Maatregelen: • De logregels bevatten minimaal de gebeurtenis; de benodigde informatie die nodig is om het incident met hoge mate van zekerheid te herleiden tot een natuurlijk persoon; het gebruikte apparaat; het resultaat van de handeling; een datum en tijdstip van de gebeurtenis. Log ook het gebruik van systeemhulpmiddelen, zoals beheertools. • Bepaal de bewaarperiode van de logging. Binnen deze periode is de beschikbaarheid van de loginformatie gewaarborgd. o Bij logging van systeemhulpmiddelen betreft dit minimaal een halfjaar. o De gelogde informatie omtrent een (vermoedelijk) beveiligingsincident wordt minimaal drie jaar bewaard. • Zorg dat toegang tot logging beperkt is, en waar mogelijk onmogelijk te manipuleren is. Indien logging wordt getransporteerd naar een andere applicatie, zorg dat dit zo veilig mogelijk gebeurt.

4.4 Afspraken met externe leveranciers Maatregelen: • Zorg ervoor dat de leveranciers voldoen aan het programma van eisen (PvE) van de gemeente Rotterdam. De eisen rondom informatiebeveiliging uit het PvE zijn in bijlage B te vinden. • Blijf periodiek monitoren of leveranciers blijvend aan de eisen voldoen. Dit kan bijvoorbeeld door het beoordelen van verklaringen, rapportages en andere teksten. • Een ISAE3402 verklaring of SOC2 verklaringen hebben de voorkeur boven certificeringen zoals ISO27001.

4.5 Programmatuurgerichte maatregelen Maatregelen: • Toegang gebeurt altijd op basis van tweefactor-/ multifactorauthenticatie. Dit geldt dus voor alle toegang, waaronder gebruikers- beheerders- service- en machine-to-machine accounts. • Initiële/ geresette wachtwoorden hebben een maximale geldigheidsduur van een werkdag en moeten bij het eerste gebruik worden gewijzigd. • Wachtwoorden voldoen aan complexiteitseisen. Ze hebben minimaal een wachtwoordlengte van 10 posities en bestaan uit minstens een getal, letter en teken (@#! etc.)

4.6 Governance Governance van informatiebeveiliging bij DAP’R volgt het algemene informatiebeveiligingsbeleid van de gemeente Rotterdam.

Datum

Pagina

mei 2023

41 van 41