Risicoanalyse en de DPIA
Expertblogs
Al meerdere malen heb ik vernomen dat het voor sommige organisaties onduidelijk is hoe ze precies om moeten gaan met de vragen rondom de beveiliging van persoonsgegevens tijdens een Data Protection Impact Assessment (DPIA). Vaak verneem ik dat tijdens een DPIA inhoudelijke vragen over de beveiliging worden behandeld. Is de autorisatie goed geregeld? Wat wordt gedaan om malware en hackers tegen te gaan? Zijn de gegevens op de juiste manier versleuteld? Hoewel dit goede vragen zijn, horen ze naar mijn idee niet thuis in een DPIA. Ze behoren in een risicoanalyse voor informatiebeveiliging (vanaf nu ‘risicoanalyse’), wat iets heel anders is dan een DPIA. Slechts het resultaat van zo’n risicoanalyse neem je mee in een DPIA om de vraag of de persoonsgegevens voldoende zijn beveiligd, te kunnen beantwoorden.
Verschillen
Er zijn verschillende redenen om een risicoanalyse en een DPIA gescheiden te houden. Een belangrijke reden is dat een goede risicoanalyse al meer dan genoeg tijd kost. Door beveiligingsvragen inhoudelijk te bespreken tijdens een DPIA, krijgt artikel 32 waarschijnlijk onevenredig meer aandacht dan de andere AVG-artikelen, die net zo belangrijk zijn. Daarnaast is beveiliging meestal voor informatie in brede zin ingericht en niet specifiek voor persoonsgegevens. Dat maakt een risicoanalyse specifiek voor de beveiliging van persoonsgegevens niet efficiënt.
De andere belangrijke redenen zijn het verschil in denkwijze en manier van beoordeling die nodig zijn bij een risicoanalyse en een DPIA. Zo beoordeel je tijdens een DPIA de huidige of geplande situatie, terwijl je bij een risicoanalyse een inschatting maakt van een mogelijke situatie in de toekomst. Bij een risicoanalyse gaat om de beveiliging van bedrijfsinformatie, terwijl het bij een DPIA gaat om de rechten en vrijheden van de betrokkenen. In beide gevallen denk en werk je dus vanuit een heel ander perspectief. Het zou naar mijn idee goed zijn om de beveiliging van persoonsgegevens zodanig te kunnen samenvatten, zodat deze op dezelfde wijze kan worden beoordeeld als de overige onderwerpen die tijdens een DPIA aan bod komen. De manier om dat goed te kunnen doen, is door de risicoanalyse uit de DPIA te halen en deze apart uit te voeren.
Het gaat voor dit artikel te ver om alle verschillen inhoudelijk toe te lichten, maar voor de volledigheid staat hier onder een overzicht van de belangrijkste punten waarin de bescherming van persoonsgegevens (vanaf nu ‘gegevensbescherming’) en informatiebeveiliging, en daardoor dus ook de DPIA en de risicoanalyse, van elkaar verschillen.
| Gegevensbescherming | Informatiebeveiliging | |
|---|---|---|
| Normenkader: | AVG, UAVG | ISO 27k, NEN 7510, BIO |
| Naleving: | verplicht | pas toe of leg uit, keuze |
| Onderwerp: | rechten en vrijheden | veiligheid van bedrijfsinformatie |
| Doelgroep: | betrokkenen | eigen organisatie |
| Beoordeling: | respecteren van privacy / wet | inschatting kans x impact van incident |
| Moment: | nu of zoals gepland | mogelijke situatie in de toekomst |
| Risicoacceptatie: | zo laag mogelijk | goede afweging |
| Risicocommunicatie: | transparantie | vertrouwelijk |
De juiste aanpak
Voor een goede aanpak van risicoanalyses en DPIA’s, is de volgorde waarin je deze zaken uitvoert belangrijk.
De eerste stap is het verkrijgen van goed zicht op je eigen informatiehuishouding. Artikel 30 van de AVG vereist het hebben van een overzicht van alle verwerking van persoonsgegevens. Waarom jezelf beperken tot persoonsgegevens? Waarom geen overzicht van alle bedrijfsinformatie? Waarom wel een personeelsadministratie, een financieel overzicht, maar geen informatieoverzicht, terwijl organisaties net zo afhankelijk zijn van bedrijfsinformatie als van personeel en geld. Maak dus werk van informatiemanagement. Maak een overzicht van alle bedrijfsinformatie, waarbij je per informatieonderdeel aangeeft of het persoonsgegevens betreft en wat de classificatie is van die informatie in termen van beschikbaarheid, integriteit en vertrouwelijkheid.
De volgende stap is het uitvoeren van een risicoanalyse. Kies de scope van de risicoanalyse, vraag bij informatiemanagement de metagegevens (classificatie van de informatie, naam verantwoordelijk manager, naam betrokken systemen, et cetera) over de betreffende informatie op en voer de analyse uit. De inhoud van de gegevens is daarbij niet relevant. Persoonsgegevens zijn dan gewoon ‘vertrouwelijke gegevens’. Is recentelijk al een risicoanalyse uitgevoerd waarvan de resultaten nog steeds bruikbaar zijn, dan gebruik je die natuurlijk. Wat ik dus niet wil zeggen is dat een DPIA een nieuwe risicoanalyse vereist.
Pas na de risicoanalyse is de DPIA aan de beurt. Het is belangrijk dat er daarbij een evenwichtige verdeling is tussen de onderwerpen die besproken moeten worden. De beveiliging van persoonsgegevens is slechts een van de onderwerpen. Gebruik daarvoor de resultaten uit de risicoanalyse. Realiseer je dat een datalek in de basis een inbreuk is op de beveiliging en niet per se op de gegevensbescherming. Dat laatste is afhankelijk van de mate van beveiliging, wat los staat van of er een incident heeft plaats gevonden of niet.
Een gangbare aanpak is dat risicoanalyses alleen worden uitgevoerd als er sprake is van een hoog risico. Ook artikel 35 van de AVG stelt dat een DPIA alleen nodig is als een verwerking ‘waarschijnlijk een hoog risico inhoudt’. Zelf ben ik van mening dat het altijd verstandig is om goed na te denken voordat je iets doet. Voer dus altijd een risicoanalyse en een DPIA uit, ongeacht het risico. De tijd die het kost haal je waarschijnlijk in met de incidenten die je ermee voorkomt.
Voorbij de grenzen
Informatiebeveiligers gaan niet over informationele privacy en de AVG en privacy professionals gaan niet over informatiebeveiliging. Echter, de vakgebieden gegevensbescherming en informatiebeveiliging, en ook informatiemanagement, zijn niet volledig op zichzelf staande vakgebieden. Ze hebben onderlinge raakvlakken. Om die reden ben ik in dit artikel over de grenzen van mijn eigen vakgebied gegaan. Ik ben er namelijk van overtuigd dat waar we ons in de toekomst op moeten richten om de afzonderlijke vakgebieden tot een succes te kunnen maken, is betere samenwerking. Dus, mochten jullie het nog niet doen, informatiebeveiligers, privacy professionals en informatiemanagers, ga eens regelmatig met elkaar om tafel zitten.
Hugo Leisink
Meer weblogberichten
Reactie toevoegen
U kunt hier een reactie plaatsen. Ongepaste reacties worden niet geplaatst. Uw reactie mag maximaal 2000 karakters tellen.
Reacties
-
Dag Hugo,
Een verhelderend stuk waar het het onderscheid aangaat tussen gegevensbescherming en informatiebeveiliging. Ook de terminologie helpt. En, de overweging om altijd een DPIA te doen maak ik ook.
Waar je me nog niet helemaal overtuigt, maar ik heb daarin nog niet zo veel ervaring, is het onderscheid tussen risicoanalyse als onderdeel van de informatiebeveiliging en de DPIA. Zoals ik het begrijp en positioneer is een DPIA een risicoanalyse. Nu introduceer je de de DPIA als ander instrument en dat kan ook weer extra compliceren. Waarom de DPIA niet ook benoemen als risicoanalyse specifiek voor gegevensbescherming? En daar dan aan toevoegen dat je bij deze risicoanalyse kan leunen op eerdere voor informatiebeveiliging?
vr. groet, Hugo -
Bedankt, wat een duidelijke uitleg!
-
Beste Hugo, allereerst vind ik het super dat je in je blogs je inzichten deelt met het publiek. De vraag is echter in relatie tot deze blog hoe jou advies vanuit je expert rol binnen het NCSC zich verhoudt tot de richtlijnen van het EDPB en de AP. Hoe goed bedoeld je adviezen zijn , de rol voor het NCSC ligt niet bij de uitleg en advisering rondom privacy aspecten. De tekst van artikel 35 GDPR is vrij helder over wanneer een DPIA wordt uitgevoerd en waar de impact analyse betrekking op heeft : Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data. Het gaat er niet om de privacy rechten te analyseren maar de impact te bestuderen van de voorgenomen verwerkingen van persoonsdata op de bescherming van de persoonsdata. De analyse dient bovendien altijd voorafgaand aan de voorgenomen verwerkingen plaats te vinden en dus niet op moment van de verwerkingen zelf. Om de impact op de bescherming te analyseren moet je een risico analyse uitvoeren. Dit alles gebeurd op exact dezelfde wijze als een informatie beveiligings risico inventarisatie. De DPIA hoef je niet altijd uit te voeren maar slechts indien voldaan is aan voorwaarden van art 35 lid 3 GDPR en op grond van de door de AP opgegeven lijst in welke gevallen de lidstaat een DPIA vereist acht ( art 35 lid 4 GDPR.) Alleen de verwerkingsverantwoordelijke heeft deze plicht tot het uitvoeren van dit assessment . De verwerker heeft deze plicht niet. Toepassingen van nieuwe technologie bijvoorbeeld door de verwerker verplichten tot contact met de Verwerkingsverantwoordelijke om dit assessment te laten uitvoeren. Ik lees een dergelijke benadering niet terug in je advies.
-
Beste Hugo, allereerst vind ik het super dat je in je blogs je inzichten deelt met het publiek. De vraag is echter in relatie tot deze blog hoe jou advies vanuit je expert rol binnen het NCSC zich verhoudt tot de richtlijnen van het EDPB en de AP. Hoe goed bedoeld je adviezen zijn , de rol voor het NCSC ligt niet bij de uitleg en advisering rondom privacy aspecten. De tekst van artikel 35 GDPR is vrij helder over wanneer een DPIA wordt uitgevoerd en waar de impact analyse betrekking op heeft : Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data. Het gaat er niet om de privacy rechten te analyseren maar de impact te bestuderen van de voorgenomen verwerkingen van persoonsdata op de bescherming van de persoonsdata. De analyse dient bovendien altijd voorafgaand aan de voorgenomen verwerkingen plaats te vinden en dus niet op moment van de verwerkingen zelf. Om de impact op de bescherming te analyseren moet je een risico analyse uitvoeren. Dit alles gebeurd op exact dezelfde wijze als een informatie beveiligings risico inventarisatie. De DPIA hoef je niet altijd uit te voeren maar slechts indien voldaan is aan voorwaarden van art 35 lid 3 GDPR en op grond van de door de AP opgegeven lijst in welke gevallen de lidstaat een DPIA vereist acht ( art 35 lid 4 GDPR.) Alleen de verwerkingsverantwoordelijke heeft deze plicht tot het uitvoeren van dit assessment . De verwerker heeft deze plicht niet. Toepassingen van nieuwe technologie bijvoorbeeld door de verwerker verplichten tot contact met de Verwerkingsverantwoordelijke om dit assessment Geblazen uitvoeren. Ik lees een dergelijke benadering niet terug in je advies.
-
Een mooie samenvatting en uiteenzetting van de onderwerpen met een passende afsluiting die in mijn optiek goed aansluit op de praktijk. Thanks!