Cookie-instellingen

Deze website gebruikt Cookies.

Meer informatie over het gebruik van cookies en gegevensverwerking vindt u onder onze cookie- en privacy-policy .

U kunt hieronder uw cookie-instellingen kiezen en accepteren:

AVG-compliance voor gemeenten: twee uitdagingen om NU op te pakken

Organisaties, waaronder ook gemeenten, worden steeds vaker geconfronteerd met uitdagingen op het gebied van gegevensbeheer en toegangsautorisatie. In deze tijd, waar digitale gegevens een cruciale rol spelen, is het essentieel om aandacht te besteden aan twee fundamentele aspecten: het adequaat opschonen van gegevens en het differentiëren van toegangsrechten tot deze gegevens. Gaat u hiermee op de juiste manier aan de slag, inclusief een goed projectplan en een degelijk tijdpad, dan is de kans op berisping door de Autoriteit Persoonsgegeven een stuk kleiner.


Door: Steven Louisse, senior consultant bij Solviteers Advies & Implementatie

blog-avg-compliance-voor-gemeenten-twee-uitdagingen-om-nu-op-te-pakken

Uitdaging 1: Opruimen die gegevens

Het verwijderen van oude gegevens is een complexe uitdaging waar op alle vlakken goed over nagedacht moet worden. Wat doet u bijvoorbeeld met de oude aanvraaggegevens voor bijzondere bijstand van een cliënt die nu nog steeds een lopende uitkering heeft – soms wel 30 jaar? Want u moet kunnen blijven aantonen hoe dat ooit zo gekomen is. En hoe zit het met de eisen van de archiefwet en de noden van de bedrijfsvoering? Al dit soort vragen en vooral hun antwoorden moeten eerst goed in kaart worden gebracht.


Vervolgens het verwijderen zelf. De functionaliteit applicaties, waar de meerderheid van gemeenten mee werkt, is op dit gebied nog volop in ontwikkeling. Binnen sommige applicaties moet u een stuk of 20 bewerkingen of runs doorlopen voordat alle gegevens echt uit de database zijn verwijderd. Dit wilt u uiteraard vooraf goed getest hebben, zodat u echt alleen de gegevens verwijdert die u voor ogen had en niet té veel weggooit. En dan zijn er nog de ‘speciaaltjes’ waar de standaard-interface (nog) niet aan kan voldoen. Een voorbeeld: als er op dit moment een verzoek tot vergetelheid zou binnenkomen, dan is het via de interface niet mogelijk om de cliënt te verwijderen. Dan moet u met (maatwerk) scripts gaan werken, die natuurlijk eerst wel geschreven moeten worden. Dit alles betekent: eerst een plan maken en daarna goed testen of het verwijderen in de applicatie of via scripts goed heeft gewerkt. Omdat het om grote hoeveelheden data gaat, is een data analist nodig om het overzicht te houden en de resultaten aan te tonen.


Zijn we er dan? Nee. Allereerst is het waarschijnlijk dat het opschonen ondanks alles tóch niet helemaal lukt. U moet in dat geval aan kunnen tonen dat de applicatie hier niet in voorziet en dat u de leverancier er om heeft gevraagd. Maar dat lost het probleem zelf natuurlijk niet op. Bovendien blijft de ‘opruimplicht’ bestaan en blijven de gegevens zich ophopen.


Uitdaging 2: Autorisering en logging

Het draait hier om het belangrijke AVG-begrip ‘autorisering’: ervoor zorgen dat alleen diegene bij bepaalde gegevens mag die hier ook toe geautoriseerd is. Dat lijkt simpel en logisch, maar is bepaald nog niet naar de AVG-norm bij veel gemeenten. Autorisaties zijn nu vooral gericht op fraudebestrijding, maar niet conform de AVG ingericht. Zo kan een gemiddelde KCC medewerker vaak alles inzien van een cliënt, tot fraudemeldingen aan toe. In veel gevallen is dit niet toegestaan uit het oogpunt van privacy.


Zoals wij de AVG interpreteren is het functie- of taakprofiel van de medewerker leidend voor de raadpleegrechten in applicaties: Role Based Access. Het is als een cijferslot waar men alleen vanuit de juiste rol de code van krijgt. Om dat in te kunnen regelen, moet u eerst inzichtelijk krijgen wat een functiegroep wel en niet mag inzien. Steeds is de vraag: welke gegevens van een cliënt heeft de medewerker nodig om zijn functie of taak naar behoren uit te voeren? Role Based Access maakt gebruik van het invullen van een autorisatiematrix. Hieronder ziet u welke stappen nodig zijn om tot een goede autorisatiematrix te komen. Vervolgens kan de autorisatie in het systeem worden ingevoerd. Een meeste applicaties van de gemeente hebben hiervoor goede mogelijkheden.


Een goede autorisatiematrix maken én gebruiken: 11 stappen

  1. Inventarisatie applicaties, ruimtes en apparatuur
  2. Inventarisatie gebruikersgroepen
  3. Per gebruikersgroep bepalen welke applicatie
  4. Per gebruikersgroep bepalen welke rechten
  5. Rechten groeperen in bepaalde rollen
  6. Speciale rechten bepalen per applicatie en functiescheidingen
  7. Opstellen autorisatiematrix
  8. Controleren & vaststellen autorisatiematrix
  9. Toepassen vastgestelde autorisaties
  10. Inrichten periodieke controle (bijv. 1x per kwartaal)
  11. Reviewen matrix (bijv. 1x per jaar)


Soms zijn er situaties waarin de matrix niet heeft voorzien. Een simpel voorbeeld: een lid van het crisisteam die het integrale klantbeeld inziet naar aanleiding van dreigende huisuitzetting. De gemeentelijke organisatie en de hulpverlening aan burgers moeten kunnen blijven draaien en daarvoor is het belangrijk om een zekere flexibiliteit in te bouwen. Maar dan wél gekoppeld aan ‘logging’, dus bijhouden wie wat heeft ingezien. Als er dan problemen zijn, kan precies worden bekeken wat er aan de hand was. De meeste gemeenten hebben een licentie aangeschaft waarin de logging wordt weggeschreven in een platte tabel op de database. Daar zijn prima rapportages op te maken met een overzicht van de toekende autorisaties.


patrick

Meer weten over onze diensten?

Patrick, onze accountmanager, helpt je graag verder. Je kunt hem mailen of bellen.


E-mail: p.boonman@solviteers.nl | Telefoonnummer: 06 42 93 97 28