Is een data protection impact assessment (DPIA) ook verplicht voor interne systemen?
Heb jij een interessante vraag op het snijvlak van privacy, cybersecurity en recht? Stuur je vraag naar juridischevraag@security.nl. Elke week geeft ict-jurist Arnoud Engelfriet in deze rubriek antwoord.
Juridische vraag: Volgens de AVG zijn er een aantal criteria wanneer je een DPIA moet uitvoeren. Maar vallen interne systemen, zoals o.a. een DMS, e-mail, back-ups ed. ook onder deze 'plicht' ? Ik vraag dit omdat onze functionaris gegevensbescherming (FG) ook die systemen als "hoog risico" aanmerkt, wat enorme vertraging geeft.
Antwoord: Een DPIA of data protection impact assessment is een verplicht nummer voor verwerkingen van persoonsgegevens met waarschijnlijk een hoog risico voor de betrokken personen (artikel 35 AVG). Meestal gaat het dan om nieuwe technologieën, maar dat hoeft niet.
Om te bepalen of het risico hoog is, moet je volgens de AVG kijken naar "de aard, de omvang, de context en de doeleinden" van de verwerking. Er is geen expliciete uitzondering voor intern versus extern, wat dat ook zou mogen betekenen in de context van verwerken van persoonsgegevens.
De AP heeft een lijst gepubliceerd (pdf) van verwerkingen die in ieder geval eerst aan een DPIA onderworpen moeten worden. Hieronder valt onder meer heimelijk onderzoek van personeel door werkgevers, grootschalige fraudebestrijding (concreet: AI-analyse van je klantenbestand), grootschalig monitoren van personeel of klanten, stelselmatig monitoren van dataverkeer anders dan voor security, uitgebreid profileren en ga zo maar door.
Ik zie wel hoe een "intern" gebruik van persoonsgegevens onder deze kopjes kan vallen. De kern is voor mij wel dat het vrijwel altijd gaat om "grootschalig" gebruik. Dus één werknemer tijdelijk volgen vanwege een vermoeden van lekken van bedrijfsgeheimen zou geen DPIA vereisen.
Het uitrollen van een nieuw e-mailsysteem zou voor mij ook geen DPIA nodig hebben, maar wél als je er productiviteitsdingen in gaat toevoegen en daarmee werknemers monitort op hun effectiviteit. Een nieuwe procedure voor backups van bedrijfsdata lijkt me op zich ook niet hoog risico, met back-ups ging je sowieso al om alsof het goud was.
Arnoud Engelfriet is Ict-jurist, gespecialiseerd in internetrecht waar hij zich al sinds 1993 mee bezighoudt. Hij werkt als partner bij juridisch adviesbureau ICTRecht. Zijn site Ius mentis is één van de meest uitgebreide sites van Nederland over internetrecht, techniek en intellectueel eigendom. Hij schreef twee boeken, De wet op internet en Security: Deskundig en praktisch juridisch advies.
Je kan eens kijken op https://www.privacy-friendly.nl/dpia. Daar staat een gratis en open DPIA model dat in een eerste stap bepaalt of de rest van de DPIA verplicht is of niet.
Voor zover ik de GDPR ken staat nergens dat een DPIA alle mogelijke gebruikte technologie moet evalueren. De mogelijkheid dat een telco zou kunnen meeluisteren is expliciet uitgesloten voor een verwerkersovereenkomst.
https://edpb.europa.eu/sites/edpb/files/consultation/edpb_guidelines_202007_controllerprocessor_en.pdf zie noot 66 74 80.
Aangezien uitval ook een datalek is kun je de energievoorziening ook bij de dpia betrekken en nog wat meer.
Dat is schuivende veranderende scope lijkt me niet de bedoeling en is onwerkbaar.
https://www.cip-overheid.nl/media/1552/202010-format-pre-scan-pia-cip-v20-definitief.docx
Het tool is van CIP-overheid.nl en bevat openbare hulpmiddelen primair voor gebruik binnen de NL overheid, maar ook heel goed bruikbaar daarbuiten.
Voor mij wel, als expert. Heel veel (de meerderheid) van mail servers en bivjbehorende DNS zijn verkeerd geconfigureerd of onvoldoende veilig. Bijvoorbeeld fall-back zonder STARTTLS, dat is nogal een blunder wanneer dat open staat en email voor persoonlijke gegevens worden gebruikt. Anders dan men denkt/hoopt, is er bijna altijd sprake van persoonlijke gegevens in mail systemen.
Ik kwam laatst nog een zelf beheerde MX server tegen bij een bedrijf dat veiligheidssystemen maakt dat STARTTLS maar uit had gezet (op Exchange). NTLM stond wel aan. Op mijn waarschuwing krijg ik natuurlijk geen reactie, want dat is kritiek en daar kunnen ze niet mee omgaan.
Voor mij wel, als expert. Heel veel (de meerderheid) van mail servers en bivjbehorende DNS zijn verkeerd geconfigureerd of onvoldoende veilig. Bijvoorbeeld fall-back zonder STARTTLS, dat is nogal een blunder wanneer dat open staat en email voor persoonlijke gegevens worden gebruikt. Anders dan men denkt/hoopt, is er bijna altijd sprake van persoonlijke gegevens in mail systemen.
Ik kwam laatst nog een zelf beheerde MX server tegen bij een bedrijf dat veiligheidssystemen maakt dat STARTTLS maar uit had gezet (op Exchange). NTLM stond wel aan. Op mijn waarschuwing krijg ik natuurlijk geen reactie, want dat is kritiek en daar kunnen ze niet mee omgaan.
Dan nog is daar geen nieuwe DPIA nodig. Wat je daar moet doen is een pentest (en uiteraard de verbeteringen die daaruit voortkomen). Vanuit de pentestresultaten zou je eventueel een aanpassing kunnen doen op je risicoanalyse (of uberhaupt doen als je dat nog niet gedaan hebt). Een verandering van emailsysteem verandert namelijk niks in het informatieverwerkingsproces. E-mail is e-mail. Een DPIA voer je uit op een proces, niet op een systeem. Omdat het proces niet verandert, is een nieuwe DPIA dus niet nodig.
Voor mij wel, als expert. Heel veel (de meerderheid) van mail servers en bivjbehorende DNS zijn verkeerd geconfigureerd of onvoldoende veilig. Bijvoorbeeld fall-back zonder STARTTLS, dat is nogal een blunder wanneer dat open staat en email voor persoonlijke gegevens worden gebruikt. Anders dan men denkt/hoopt, is er bijna altijd sprake van persoonlijke gegevens in mail systemen.
Ik kwam laatst nog een zelf beheerde MX server tegen bij een bedrijf dat veiligheidssystemen maakt dat STARTTLS maar uit had gezet (op Exchange). NTLM stond wel aan. Op mijn waarschuwing krijg ik natuurlijk geen reactie, want dat is kritiek en daar kunnen ze niet mee omgaan.
Dan nog is daar geen nieuwe DPIA nodig. Wat je daar moet doen is een pentest (en uiteraard de verbeteringen die daaruit voortkomen). Vanuit de pentestresultaten zou je eventueel een aanpassing kunnen doen op je risicoanalyse (of uberhaupt doen als je dat nog niet gedaan hebt). Een verandering van emailsysteem verandert namelijk niks in het informatieverwerkingsproces. E-mail is e-mail. Een DPIA voer je uit op een proces, niet op een systeem. Omdat het proces niet verandert, is een nieuwe DPIA dus niet nodig.
Ik zou ook denken pen-test, maar ook DPIA, maar om een andere reden.
Veel van je medewerkers zullen toch persoonlijk via zo een systeem mailen. Dus heel veel (strikt) vertrouwelijke informatie zit juist in een e-mailsysteem. Je wilt ook weten hoe beheerders daarmee omgaan. Of de procedures daar de data van de medewerkers wel beschermd.
Het is een kwestie van geduld, toch ieder beheerder van een systeem met de privacy-offiicer l...t. :)
Voor mij wel, als expert. Heel veel (de meerderheid) van mail servers en bivjbehorende DNS zijn verkeerd geconfigureerd of onvoldoende veilig. Bijvoorbeeld fall-back zonder STARTTLS, dat is nogal een blunder wanneer dat open staat en email voor persoonlijke gegevens worden gebruikt. Anders dan men denkt/hoopt, is er bijna altijd sprake van persoonlijke gegevens in mail systemen.
Ik kwam laatst nog een zelf beheerde MX server tegen bij een bedrijf dat veiligheidssystemen maakt dat STARTTLS maar uit had gezet (op Exchange). NTLM stond wel aan. Op mijn waarschuwing krijg ik natuurlijk geen reactie, want dat is kritiek en daar kunnen ze niet mee omgaan.
Dan nog is daar geen nieuwe DPIA nodig. Wat je daar moet doen is een pentest (en uiteraard de verbeteringen die daaruit voortkomen). Vanuit de pentestresultaten zou je eventueel een aanpassing kunnen doen op je risicoanalyse (of uberhaupt doen als je dat nog niet gedaan hebt). Een verandering van emailsysteem verandert namelijk niks in het informatieverwerkingsproces. E-mail is e-mail. Een DPIA voer je uit op een proces, niet op een systeem. Omdat het proces niet verandert, is een nieuwe DPIA dus niet nodig.
Een stukje papier zegt niets over de werkelijkheid. Dat is wat er tegenwoordig fout gaat, veel papieren compliancy, weinig actie. Als je een mail server draait die niet aan de eisen voldoet is er DUS iets fout en juist dan is er een DPIA nodig. Het is immers eerder niet begrepen.
En een pen test? Er is een audit nodig. Een pen test is hooguit een dubbele controle.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Cybersecurity Trainer / Full Stack Developer
Ben je toe aan een nieuwe job waarmee je het verschil maakt? Wil jij je security kennis graag delen en hands-on laten zien hoe cybersecurity in de praktijk echt werkt? Werk je net als wij graag samen met enthousiaste en gedreven collega's? Bij ons geen bureaucratie maar open communicatie en een werkomgeving gericht op samenwerking.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?