The EU's Privacy by Default 2.0

Last December, a draft of the new European e-Privacy rules leaked. It contained a number of interesting insights in the ways the EU will regulate privacy in electronic networks. The new e-Privacy law will supplement the General Data Protection Regulation (GDPR), which was enacted last May and which will enter into application on May 25, 2018.

From Directive to Regulation

Apart from re-shaping existing rules on spam, cookies and location-based services, the most important change is that the Directive will become a Regulation. I fully agree with this change. Internet-based services do not stop at the border. Services of the 4th Industrial Revolution will be powered by the cloud. E.g., self-driving cars will heavily rely on cloud connections. You can't have a different law relating to how your car communicates with the cloud each time you cross a border. Therefore, a clear and fully-harmonized legal framework across the EU is needed to facilitate the uptake of internet-connected products. This includes the rules on e-Privacy.

Hardware manufacturers and retail also covered
The second most important proposal in the draft e-Privacy Regulation is article 10, which reads:

"The settings of all the component of the terminal equipment placed on the market shall be configured to, by default, prevent third parties from storing information, processing information already stored in the terminal equipment and preventing the use by third parties of the equipment's processing capabilities."

By using the wording "placed on the market", this provision is targeted at the retail sector as well as the manufacturers of internet-connected products, such as smart TV's, smart energy meters, smart watches, smartphones, connected cars, computers, smart Barbies, and smart consumer products collectively known as 'IoT devices'.

The draft GDPR contained a similar provision, which required producers of devices to comply with the Data Protection by Design requirement. That provision was subsequently deleted, as it did not make sense in the context of the other provisions of the GDPR. The provision of the e-Privacy Regulation complements art. 25 GDPR.

Nevertheless, personal information collected by the device manufacturers themselves is already covered by the privacy-by-design & default requirements of the GDPR, as they are the controllers of the data processing. So, the settings of smart devices must be configured to ensure the rights of the consumers and to ensure the processing meets the requirements of the GDPR. But the e-Privacy Regulation will require those manufacturers to also configure those devices to prevent third parties from processing user information without the user's choice to do so. This is a duty-of-care requirement on the part of the manufacturer and retailer, which art. 10 translates into a prohibition to sell products in the EU which do not meet this requirement.

Obviously, the retail and wholesale sector in the EU will be covered by this provision. But as most devices are manufactured outside Europe and the settings of the pre-installed software would have to be taken care of already in the factory, this provision will also cover non-European manufacturers of electronic devices. Their products may not be shipped to the EU without the proper privacy and security settings.

EU to set the standard?
Depending on whether those factories choose to produce their products for regional demand or not, by requiring that no products are placed on the market that do not meet the privacy by default requirement, the EU may effectively set the standard for a more secure range of consumer products across the world. Of course, the requirement does not (primarily) cover the hardware itself, but mainly the software pre-installed on the devices, up to the embedded software in the chips used in the device. Ergo, chip manufacturers may be required to ensure that only secure chips are used. On the other hand, device manufacturers, including EMS, ODM and OEM manufacturers, will be required to install software pre-configured to protect user privacy. This pertains to the operating systems used as well as to the apps pre-installed on the device. For example, pre-installed apps and browers should all be installed with Do-Not-Track (DNT) enabled by default. All this under the direction of the companies under whose brand the product is sold. But the ultimate responsibility for compliance with this rule lies with the (web)shop selling the device.

It should be noted that the wording of article 10 limits the requirement to the import and retail phase. There is no legal obligation in the e-Privacy Regulation to keep supporting the device and its software on privacy and security once it has been sold. Ergo, keeping the device free from malware and patching the software will remain the responsibility of the user.

Note that the rule does not give the consumer a reasonable expectation of security nor a warranty that the device is secure at the moment of purchase, as the moment that the product was 'placed on the market' may lie weeks, months - or in some cases even years - before the moment of purchase. So, the faster the retailer moves his inventory, the more likely it is that the product is (still) secure. But nevertheless, this new rule, if enacted, would be a major step forward to ensure that end-user products will be secure.

Enforcement
Although the e-Privacy Regulation will, for the most part, be enforced by privacy and data protection authorities, the enforcement of article 10 would be the primary responsibility of customs (preventing non-compliant products from being imported) and product safety and consumer protection authorities (preventing non-compliant products from being sold).

This requires thorough and up-to-date knowledge of privacy and information security at those agencies; knowledge that they currently are not required to have. The same is true for the procurement departments of retail stores and webshops. The level of knowledge about privacy and information security with those agencies and retailers, or lack thereof, may proof to be the Achilles' Heel of this proposal.

Privacy Outlook 2017

.

Nog 500 dagen !!

2017 wordt vooral het jaar van de voorbereiding op de komst van de Algemene Verordening Gegevensbescherming (AVG). De AVG, ook wel bij zijn Engelse naam GDPR genoemd, is afgelopen jaar van kracht geworden en de overgangstermijn loopt af op 25 mei 2018. Was je nog niet begonnen met het invoeren van de AVG in je organisatie, dan wordt het nu toch wel hoog tijd. Je organisatie heeft nog ongeveer 500 dagen om compliant te worden.

Dat lijkt veel, maar het is voorbij voordat je het weet.

Aan de slag dus!

Regel een budget !

Begin niet met het lukraak implementeren van de AVG. Volg een vooraf vastgesteld plan en beschouw het als een project van meer dan 1 jaar. Dat begint met het regelen van een budget. Heeft jouw organisatie een budgetcyclus van een kalenderjaar, dan ben je eigenlijk nu al te laat. Dan wordt het in 2017 alleen pleisters plakken en verschuift de bulk van je AVG-complianceproject waarschijnlijk naar 2018. Dan wordt het wel heel krap om nog op tijd AVG-compliant te worden. Zorg dan in ieder geval voor een noodbudget om de grootste risico's al in 2017 te kunnen afdekken.

Wees bij het vaststellen van het budget vooral niet te zuinig. Heeft jouw organisatie privacy de afgelopen jaren laten versloffen, dan moet je in 2017 namelijk ook nog eens een inhaalslag maken. Met boetes in het vooruitzicht tot 20 miljoen of 4% van de jaaromzet van de onderneming kan het de moeite waard zijn om in 2017 flink in privacy te investeren. Uiteraard hoort daar ook nog een jaarlijks (onderhouds)budget bij.

Waar beginnen?

Er zijn verschillende scenario's om AVG-compliance aan te vliegen.

Startscenario 1: DPO benoemen

Sommige organisaties gaan nu hard op zoek naar een Data Protection Officer (DPO), in het Nederlands: Functionaris voor de Gegevensbescherming (FG). Ooit ben ik bij Philips op die manier begonnen toen de Wbp werd ingevoerd; weggekaapt bij wat nu de Autoriteit Persoonsgegevens (AP) is. Maar bedenk wel: gekwalificeerde DPO's zijn uiterst schaars. En dus niet goedkoop. Aan de andere kant bieden steeds meer nieuwkomers zich nu aan als DPO, soms met DPO-certificaat en al (voor wat dat waard is).

Maar het privacyvak vereist een hoop competenties in één DPO. Grondige wetskennis in relatie tot de bedrijfsvoering/sector is één. Toezichts-, advies- en communicatievaardigheden is twee. En idealiter ook enig gevoel voor een of meer van de volgende vakgebieden: marktstrategie, sectorkennis, privacy-by-design, informatiebeveiliging, kennis van de door de organisatie gebruikte technologie en risicomanagement. En de DPO moet ook nog eens de persoonlijkheid hebben om als het nodig is met gezag met zijn/haar vuist op tafel te kunnen slaan.

Nog daargelaten dat een goede DPO een boel meters moet hebben gemaakt voordat hij/zij dit vakgebied een beetje in de vingers heeft en dat de DPO slechts voor een beperkt aantal organisaties verplicht is (zie art. 37 AVG), schuilt in zo'n overhaaste benoeming ook het gevaar dat compliance met de AVG door de organisatie primair als het probleem van de DPO wordt gezien (quod non). De DPO is weliswaar een belangrijke drijvende kracht achter de handhaving van het privacybeleid van de organisatie, maar linksom of rechtsom blijft AVG-compliance in eerste instantie het probleem van de directie. Voor je het weet wordt de DPO of FG dus een vorm van window dressing en als het niet goed gaat waarschijnlijk ook de Kop van Jut. Wellicht dat het (lukraak) benoemen van een DPO dus niet de meest aangewezen manier is om een begin te maken met AVG-compliance....

Dit neemt overigens niet weg dat het voorhanden hebben van een DPO, intern of extern, een grote toegevoegde waarde kan hebben voor het waarborgen van AVG-compliance.

Startscenario 2: Risico's inventariseren

Een andere aanpak voor het aanvliegen van AVG-compliance is die van de risico-inventarisatie. De risk-based approach die in de AVG zit, gaat uit van de risico's voor de betrokkenen, zoals klanten, werknemers, burgers, patiënten en dergelijke (privacyrisico's). Voor die aanpak zal je echter eerst moeten inventariseren welke persoonsgegevens je eigenlijk in huis hebt en in welke processen (lees: voor welke doelen) ze worden gebruikt. En om dat goed uit te voeren, moet je eigenlijk eerst alle persoonsgegevens in je organisatie in kaart brengen (data mapping). Dat is weer wat teveel gevraagd, zeker als je nog maar 500 dagen de tijd hebt om compliant worden.

Je zal dus vooraf al een beperking willen aanbrengen in je risico-inventarisatie en focussen op de belangrijkste risico's. De vraag is dan welke criteria je daarvoor wilt gebruiken; met andere woorden, wélke risico's wil je eigenlijk in eerste instantie gaan afdekken?

• Sommige organisaties willen geen risico's lopen in hun business-kritische systemen. Dat kán een hele goede benadering zijn; je weet dan dat áls de AP langskomt, niet gelijk je hele bedrijf stilligt (business continuity risico).
• Andere organisaties willen naar de betrokkenen of hun vertegenwoordigers uitstralen dat het bij hen qua privacy wel goed zit. Zij willen dus als eerste aan de slag met hun belangrijkste klanten- en/of HR-processen. Bijkomend voordeel is dat hoe eerder die processen compliant zijn met de AVG, hoe kleiner de kans dat over die processen wordt geklaagd (brand damage risico). Voor overheidsorganisaties vertaalt zich dit in politieke risico's.
• Een - vooralsnog - kleine groep organisaties vliegt de AVG top-down aan. Zij willen eerst het privacymanagementkader neerzetten om van daaruit de AVG-compliance in hun processen op een volwassen manier te beheersen. Op zich niet zo gek gedacht als je bedenkt dat de AVG van organisaties eist dat ze "aantoonbaar" compliant zijn met de wet (art. 24 AVG). Dat vereist een relatief hoog maturity-niveau in privacycompliancemanagement (minstens 'defined', liefst 'managed'). Deze organisaties verkleinen daarmee de kans dat ze tegen een boete aanlopen wegens ernstig verwijtbare nalatigheid (accountability risico).
• En dan heb je nog organisaties die niet (als eerste) tegen een boete willen aanlopen of als uitgangspunt hebben om sowieso compliant te zijn. Veelal aangestuurd door de juridische afdeling wordt door die organisaties vaak ingezoomd op de belangrijkste compliance-verplichtingen, al dan niet in relatie tot de speerpunten van het handhavingsbeleid van de AP en jurisprudentie (boete-risico).

Welk criterium (of een combinatie ervan) je ook wilt gebruiken, realiseer je dat 100% compliance niet bestaat.... zeker niet in het privacyrecht. Bovendien is een heleboel nog onduidelijk, omdat de interpretatie van de AVG van de gezamenlijke Europese toezichthouders nog niet beschikbaar is. Maak er dus een langetermijnproject van. Wees daarbij helder en duidelijk naar de organisatie en je stakeholders: "Dit doen we in 2017, dat doen we in 2018 en de rest komt wel in 2019/2020".

Jouw AVG-project

Splits je project dus op in behapbare deelprojecten.

Start met wat jouw organisatie belangrijk vindt.

Data Protection Impact Assessments

Sommige bedrijven storten zich halsoverkop op het uitvoeren van Data Protection Impact Assessments (DPIA's, art. 35 AVG). Maar als je dat op alle processen zou doen, weet je twee dingen zeker: het AVG-project gaat binnen de kortste keren over het budget heen én het komt niet vóór 25 mei 2018 af. DPIA's zijn alleen verplicht voor de gegevensverwerkingen die "waarschijnlijk een hoog risico voor de rechten en vrijheden van natuurlijke personen" vormen. Het is dus helemaal niet nodig om overal een DPIA op te doen (zou ook veel te duur zijn), al kan het - ook vanuit maatschappelijk verantwoord ondernemen - verstandig zijn om de groep van processen waar je DPIA's op uitvoert iets ruimer te nemen dan de AVG voorschrijft.

Privacy Quick Scans
Beter is dus om zogeheten Privacy Quick Scans te doen op je (selectie van) gegevensverwerkingen c.q. bedrijfsprocessen. Zo'n Privacy Quick Scan (PQS) is goedkoop en snel, omdat je inzoomt op de vraag of er sprake is van mogelijke hoge risico's, zonder heel diep op die risico's in te gaan. Door PQS-en uit te voeren, weet je snel op welke processen je wél een DPIA moet uitvoeren (dubbel werk voorkom je door de resultaten van de PQS te gebruiken voor je DPIA). De overige processen hebben waarschijnlijk geen hoge risico's. En dus is dat 'gewoon' compliancewerk dat je eventueel kan uitstellen tot 2018 (of nog later).

Bijkomend voordeel van een PQS is dat je met niet al teveel extra werk ook snel zicht krijgt op de 'red flags' qua AVG-compliance (die moeten sowieso in 2017) en de stand van zaken van het maturity niveau van het privacymanagement in je organisatie. 

Data mapping
Maar om zo'n PQS uit te voeren moet je wel met aan zekerheid grenzende waarschijnlijkheid weten welke persoonsgegevens je eigenlijk is huis hebt. Een goede manier om dat te doen is een data mapping exercitie. Daarvoor bestaat tegenwoordig ook software. Je kan dus overwegen om zo'n licentie aan te schaffen. Groot voordeel daarvan is dat je gelijk voldoet aan je artikel 30-verplichting om een register van gegevensverwerkingen bij te houden.

Elementen AVG-project

Een beetje AVG-complianceproject kent dus de volgende elementen:

1. Het in kaart brengen van de (belangrijkste) gegevensverwerkingen en het inrichten van het artikel 30-register;
2. Het uitvoeren van Privacy Quick Scans op de (geselecteerde) gegevensverwerkingen om de risico's in kaart te brengen;
3. Het uitvoeren van Data Protection Impact Assessments op de verwerkingen met 'waarschijnlijk hoge risico's en het volledig documenteren van deze verwerkingen;
4. Het implementeren van proces-gerelateerde (aanpassings)maatregelen op het gebied van privacy-by-design/default, informatiebeveiliging, verwerkersovereenkomsten, internationaal gegevensverkeer, privacyverklaringen en bewaartermijnen;
5. Het implementeren van beleid en procedures op het gebied van privacymanagement, zoals privacytraining, privacy risk management (PQS/DPIA/audit), inkoop/outsourcing, toegang tot privacyexpertise (aanstelling DPO/FG en/of inhuren externe ondersteuning) en omgang met datalekken.

Veel organisaties zullen deze stappen in de volgorde 1 - 5 uitvoeren. Vooral als zij de AVG-compliance aanvliegen vanuit business continuity risico's, brand damage risico's of boeterisico's.

Zo'n AVG-project zou er dan als volgt uit kunnen zien:

• Q1 2017: Instellen privacy project organisatie. Data mapping en optuigen artikel 30 register.
• Q2/Q3 2017: Uitvoeren Privacy Quick Scans en DPIA's.
• Q3 2017 - Q1 2018: Implementatie procesmaatregelen op hoge-risico systemen en aanpakken 'red flags' privacycompliance. Start van het privacy management programma.
• Q2 2018 - 2020: Compliant maken van lage-risico verwerkingen, verhogen maturity niveau privacymanagement.
• Vanaf 2019: Onderhoud privacycompliance (aanpassen van processen, maatregelen en documenten aan de laatste inzichten en herziening/audit eerder uitgevoerde DPIA's).

Voor organisaties die liever eerst hun privacymanagement op orde willen brengen (accountability risico's), zou de tijdslijn van hun AVG-project er als volgt uit kunnen zien:

• Q1 2017: Definiëren van de organisatie-brede privacybeleidskaders en instellen van privacycompliance organisatie.
• Q2 2017: Data mapping en inrichten art. 30-register.
• Q3 2017: Uitvoeren Privacy Quick Scans en DPIA's.
• Q4 2017 - Q1 2018: Implementatie procesmaatregelen op hoge-risico verwerkingen.
• Q2 2018 - 2020: Compliant maken van lage-risico verwerkingen en aanpak 'red flags' privacycompliance, verhogen maturity niveau privacymanagement.
• Vanaf 2019: Onderhoud privacycompliance (aanpassen van processen, maatregelen en documenten aan de laatste inzichten en herziening/audit eerder uitgevoerde DPIA's).

Hoe eerder je met je project begint, hoe groter de kans dat je op 25 mei 2018 de belangrijkste risico's hebt afgedekt.

En wat brengt 2017 verder nog?

Traditioneel geef ik u in de jaarlijkse Privacy Outlook ook een overzicht van de veranderingen in de wet- en regelgeving die er aan zitten te komen. Bij deze dus.

Uitvoeringswet AVG

Een belangrijke aanvulling op de AVG wordt gevormd door de nationale uitvoeringswetten. Voor Nederland is dat de Uitvoeringswet AVG (UAVG). Het voorstel is in december 2016 in consultatie gegaan en zal naar verwachting in de loop van de eerste helft 2017 naar de Tweede Kamer worden gestuurd.

De UAVG regelt een aantal zaken, waarbij de wetgever uitgaat van een - waar mogelijk - beleidsneutrale invoering van de AVG. Met andere woorden, waar het kan, volgt de UAVG zoveel mogelijk de Wet bescherming persoonsgegevens (Wbp). Het gaat onder andere om:

• De instelling en de bevoegdheden van de Autoriteit Persoonsgegevens.
• De Nederlandse invulling van een aantal onderwerpen die de AVG aan de nationale wetgever voorbehoudt, zoals de beperking van het gebruik van het BSN-nummer en de leeftijdsgrens voor toestemming voor gegevens van kinderen (het voorstel in de UAVG is 16 jaar); en
• De verwerking van bijzondere gegevens zoals ras/etniciteit en gezondheidsgegevens in specifieke gevallen á la art. 17 - 22 Wbp.

Voorstel herziening e-Privacy Richtlijn

In het kielzog van de AVG wordt ook de e-Privacy Richtlijn 2002/58 herzien. Die richtlijn bevat nu onder meer de regels rondom het gebruik van cookies, spam en location-based services en is in Nederland uitgewerkt in hoofdstuk 11 van de Telecommunicatiewet.

In december lekte al een ontwerp van het voorstel uit. Daaruit bleek dat ook deze wet net als de AVG - terecht - een verordening wordt; één en dezelfde wet voor hele Europa dus. Naast de genoemde onderwerpen, die hier en daar worden aangescherpt of verduidelijkt, bevat het ontwerp van de e-Privacy Verordening ook uitbreidingen. Zo gaan ook internetcommunicatiediensten als Skype en WhatsApp onder de werking van de e-Privacy Verordening vallen.

Maar de opmerkelijkste uitbreiding is die artikel 10: het privacy-by-default vereiste gaat ook gelden voor slimme apparaten, zoals smart-TV's en Internet-of-Things apparaten. De regel komt erop neer dat de Europese Commissie een verbod voorstelt op het 'op de markt brengen' van slimme apparaten die niet aan deze eis voldoen. Dit en dit is onder de e-Privacy Verordening dus uit den boze. Deze nieuwe eis raakt primair de elektronicabranche (retail, groothandel, import) en in hun kielzog de - vaak buitenlandse - producenten van de apparatuur. Dat wordt nog een fikse kluif voor de douane en de NWVA !

Eerste boetes?

Bij zijn aantreden zei de nieuwe voorzitter van de AP, Aleid Wolfsen, dat de boetes er aan zitten te komen. Bij de AP zijn in 2016 een kleine 5500 meldingen van een datalek binnengekomen. Daarvan zijn een aantal door de AP in onderzoek genomen. En daarvan zullen waarschijnlijk weer een aantal in aanmerking komen voor een boete.

Omdat de AP in haar boetebeleidsregels werkt met boetecategorieën voor het niet nakomen van de beveiligingsverplichting (categorie II: minimaal 150.000 euro, maximaal 500.000 euro), waarbij sprake kan zijn van zowel boeteverhogende als boeteverlagende omstandigheden, is het dus nog even afwachten wat de gemiddelde hoogte zal zijn van een boete voor een datalek.

Maar daarnaast kan de AP natuurlijk ook een boete uitdelen voor andere overtredingen van de Wbp. Het maximum is ook in 2017 nog 820.000 euro (of 10% van de jaaromzet van de rechtspersoon als 820.000 euro niet passend zou zijn).

Kortom, ook 2017 wordt weer een spannend privacyjaar!

Een goed Big Data plan heeft geen toestemming nodig

Deze week stond het nieuws bol van de 'Big Data'-plannen van ING om data-analyses te gaan uitvoeren op de betalingsgegevens van hun klanten om zo de klant te voorzien van mogelijk interessante aanbiedingen van bedrijven. ING haastte zich te benadrukken dat die analyse alleen met de uitdrukkelijke toestemming van de klant zou gebeuren ('opt-in'). Ook het College Bescherming Persoonsgegevens (CBP) benadrukte in zijn eerste reactie dat de plannen van ING uitsluitend toelaatbaar waren als de klant toestemming had gegeven voor de analyses. Je zou dus zeggen dat het met de plannen van ING wel goed zit. Als de klant toestemming geeft, mag het. Einde discussie! Iedereen tevreden.

Of toch niet.....? Uit de vele negatieve reacties, zowel in de pers als op social media, bleek dat veel mensen niet gediend waren van de plannen van de ING. Je zou kunnen zeggen: "Waar zeuren die mensen over? Als ze niet mee willen doen, dan geven ze toch gewoon geen toestemming?" In die visie is toestemming een panacee; een toverwoord dat in een klap alles goed maakt. Die visie is fundamenteel onjuist.

Artikel 8 van de Wet Bescherming Persoonsgegevens (WBP) bevat 'rechtvaardigingsgronden'. Een rechtvaardigingsgrond vormt niet alleen de juridische basis onder je verwerking, maar bevat ook de maatschappelijk-ethische argumenten voor je verwerking. Artikel 8 WBP bevat zes van die rechtvaardigingsgronden: toestemming, uitvoering van een contractuele verplichting, uitvoering van een wettelijke plicht, bescherming van de vitale belangen van de betrokkene, de uitvoering van een publieke taak en het gerechtvaardigd belang van het bedrijf of van een derde. Hoewel toestemming als eerste in het rijtje staat, weten doorgewinterde privacy-professionals dat toestemming eigenlijk alleen bedoeld is voor zaken die je op geen van de vijf andere gronden kan rechtvaardigen. Een laatste redmiddel dus.

Maar daar komt, zeker bij Big Data, ook een ander principe van bescherming van persoonsgegevens om de hoek kijken: de doelbinding. Dat beginsel zegt dat je de persoonsgegevens alleen voor andere dingen mag gebruiken als die andere dingen verenigbaar zijn met het doel waarvoor die gegevens zijn verzameld. Daarbij spelen de redelijke verwachtingen van de klant een belangrijke rol. Doe je dingen die de klant redelijkerwijs niet van jou zou kunnen verwachten, dan doorkruisen jouw plannen waarschijnlijk het doelbindingsbeginsel. Dat soort plannen kan je alleen rechtvaardigen met de toestemming van de klant.

Toestemming is een juridische oplossing. Het creëert een papieren schijnwerkelijkheid dat het wel goed zit met de verwerking van de persoonsgegevens. Toestemming is dan vooral een afweer tegen claims dat het niet goed zit met de verwerking. Maar juist als er geen andere (lees: betere) rechtvaardigingsgrond is voor je Big Data plan, ontbeert zo'n plan intrinsieke voordelen, zowel voor de consument als voor het bedrijf. En in de perceptie van de klant is het belang van het bedrijf dan al snel groter dan het belang voor de consument. De klant ziet zich niet meer als klant, maar als melkkoe en verliest het vertrouwen in het bedrijf. Ethici spreken in zo'n geval over het ontbreken van een equal distribution of benefits and burdens. Een bedrijf moet zich bij de verwerking van persoonsgegevens dus altijd afvragen wat er voor de klant in zit. Zeker als het kennelijke doel is om het nut te vergroten. En dat is heel vaak het geval als je het over de verwerking van klantgegevens voor Big Data doeleinden hebt.

Regels voor bescherming van persoonsgegevens zijn in essentie niets anders dan een mechanisme om belangen tegen elkaar af te wegen. Enerzijds zijn daar de (fundamentele) belangen van de klant: privacy, reputatie, veiligheid, non-discriminatie, rechtvaardige behandeling, autonomie, identiteit en menselijke waardigheid. Deze belangen zijn meestal gediend bij het niet of zo beperkt mogelijk verwerken van persoonsgegevens. En als het dan toch gebeurt, met alle noodzakelijke waarborgen daaromheen. Aan de andere kant staan de veiligheid van derden (de staat, het bedrijf, andere mensen, etc), de handhaving van regels en maatschappelijke normen, het kunnen stellen van vertrouwen in mensen en het maximeren van nut. Tot dat laatste behoort ook het nut voor de klant zelf (denk aan personalisatie van diensten en het doen van aanbiedingen op basis van Big Data analyses). En dat is nu precies waar bedrijven goed in zouden moeten zijn: hun klanten zo'n goed aanbod doen, dat vrijwel alle klanten vinden dat de waarde/nut ervan opweegt tegen het stukje privacy dat ze daarmee inleveren.

Zo zouden bedrijven ook naar hun Big Data plannen moeten kijken: "Is mijn Big Data plan met klantgegevens zo goed, dat klanten er geen nee tegen willen zeggen?" Dit vereist echter een grote mate van transparantie over wat je als bedrijf eigenlijk wil gaan doen met de klantgegevens. Het bedrijf moet daarbij alles op tafel leggen, open en eerlijk. En dan niet alleen aangeven hoe de (privacy)belangen van de klant juridisch worden beschermd, maar ook welke feitelijke beschermingsmaatregelen zijn genomen (bijv. anonimisering) en wat de voor- en nadelen van de Big Data-verwerking zijn voor de klant. En dat mogen geen loze praatjes zijn (window dressing), maar echte maatregelen en echte voordelen.

Als je dus goed hebt nagedacht over je Big Data plannen, de nodige maatregelen hebt genomen om de belangen van de klant te beschermen en open en eerlijk communiceert over de voor- en nadelen voor de klant, dan heb je in principe voldaan aan de eisen van het gerechtvaardigd belang zoals vereist door artikel 8 sub f WBP. En daarmee is je verwerking behoorlijk en zorgvuldig en in overeenstemming met de wet, de hoofdregel van de WBP. Voldoe je niet aan die eisen en heb je dus toestemming van de klant nodig, zou het dan niet beter zijn om dan maar helemaal van je Big Data plan af te zien?

Een 'gerechtvaardigd belang'-aanbod aan de klant moet immers veel beter zijn dan een 'opt-in'-aanbod, omdat de default-positie ín dat geval is dat zijn gegevens worden verwerkt tenzij hij daar bezwaar tegen maakt ('opt-out'). Dat vereist, zoals gezegd, een rechtvaardiging die intrinsiek is gelegen in het plan zelf en voor de klant als zodanig herkenbaar is. Door toestemming te vragen zeg je dus eigenlijk tegen de klant: "Mijn plan voor de verwerking van jouw persoonsgegevens is niet in jouw belang". Dat is een boodschap die geen enkel bedrijf wil communiceren naar zijn klanten.

Holland Privacy Outlook 2014

By popular demand, please find below an English version of my earlier blogpost on what 2014 holds in store for privacy compliance in The Netherlands, based on the legislative and enforcement trends in The Hague and Brussels.

2014 is set to become the year for privacy and data protection in The Netherlands. A number of legislative proposals in The Hague and Brussels will significantly change the way businesses operating in The Netherlands have to comply with privacy and data protection laws. Some details still need to be worked out, but one thing is clear: in 2014, businesses operating in Holland need to get serious about privacy and data protection.

First order of business in 2014 is to seriously step up the maturity level of the organization's privacy compliance. The plans in The Hague and Brussels do no longer tolerate low levels of privacy compliance. The new name of the game is data lifecycle compliance management. This requires significant more resources and attention dedicated to privacy and data protection, as personal data need to be protection during their entire lifecycle and mere 'legal compliance' is no longer tolerated.



Privacy Maturity Path to 2015

Here are 6 trends you need to watch this year in order to stay on the right side of privacy compliance:

1. The Dutch Data Protection Authority Gets Power To Fine

The Dutch Cabinet has recently approved a bill which gives the Dutch Data Protection Authority (CBP) the power to fine businesses for violating the Dutch Personal Data Protection Act (WBP). These administrative fines may equal 6th category criminal fines (since January 1st: 810.000 Euro). The fines can be issued for any violation of the WBP. In theory this may lead to cumulative fines (!).

But it may get worse. State-Secretary Teeven, responsible for the WBP, has suggested in Parliament in November that he was about to send a bill to the Cabinet which would contain turn-over related fines. Probably he was referring to another bill which is currently pending in Parliament, which allows for fines of 10% of the annual turn-over if a fine of 810.000 euro would not be fair. It is therefore highly likely that this possibility is included in the CBP fining powers bill.

The bill is expected to become law on January 1, 2015. This would give businesses only 1 year to address their non-compliances to avoid fines next year.

2. Data Breach Notification Law Introduced

Also currently pending in Parliament is a bill requiring data breaches to be notified to the CBP and the data subject. Data breaches must be notified regardless of the amount of personal data breached. The only exceptions are: 1) where the data were encrypted or otherwise made unintelligible to unauthorized users, and 2) where the data breach is a 'trifle'. We don't know yet how the CBP will interpret this last exception, but one may expect that personal data of a more sensitive nature, such special data and financial data, will not qualify under the exception. It is important to note that data breaches which occur at the data processor's side must be notified by the controller. Processor contracts must contain language which require processors to notify controllers of data breaches.

Also this bill is expected to become law on January 1, 2015. Businesses should therefore use 2014 to review their security practices as well as their processor contracts and to take a close look at their internal security incident reporting procedures.

3. Safe Harbor and Cloud

In the wake of the Snowden-scandal, the European Commission has taken a close look at the Safe Harbor Agreement and has proposed a number of changes. The US have until the summer to implement these changes. If they don't agree, the European Commission may choose to terminate the Agreement.

The problem is that Safe Harbor is widely used to allow data transfers from the EU to the US via cloud services. If the Safe Harbor Agreement is terminated, European cloud customers will need to look for alternatives. One alternative may be to enter into modelcontracts with the US cloud provider, but these may be difficult to implement in cloud environments. Another way (favored by the European Parliament) may be to use a European cloud service, where the privacy rights of European citizens are respected.

CIO's and legal counsel should therefore use the first half of 2014 to take a close look at their organization's cloud strategy and prepare a back-up plan in case Safe Harbor is terminated this summer.

4. EU Data Protection Regulation

The EU Data Protection Regulation, which is supposed to replace the WBP in 2016, has hit some political trouble, which has caused a delay (most likely until 2015). Although details may change, there is high-level agreement on several key-elements of the Regulation, such as more responsibilities for the controller (especially with regard to compliance management), more rights for the data subject (especially on the internet), requirements for privacy-by-design and privacy impact assessments on new information systems and changes to business processes, steep turn-over related fines (up to 5% according to the Parliament) and restrictions on sharing data with foreign governments.

Given the significant impact of the Regulation on the business, it would be sound policy to start preparing an implementation plan in 2014, as the implementation period of 2 years after adoption of the Regulation will most likely be too short for most companies to review each and every data processing operation and data processor.

5. 2014: The Year of the DPO ?

I predict that 2014 will be the year where many organisations in The Netherlands, government bodies and businesses alike, will start looking for a Data Protection Officer (DPO) or even a Chief Privacy Officer (CPO, a DPO at executive level). This would allow such DPO/CPO to start preparing the implementation of the Regulation as well as to fix the most urgent non-compliances before the new fining power of the CBP and the data breach notification law come into force next year.

However, there are not many experienced DPO's around in The Netherlands, let alone experienced CPO's, since most businesses treat privacy compliance as a legal matter, leaving much of the work to law firms. On the other hand, appointing an existing employee as DPO may also not be a good thing, since such employee would need to be thoroughly trained first in order to acquire the required competencies of a DPO. In such case, 2014 would be wasted. It is therefore good to know that DPO's may also be hired externally (as a service). Not only would this provide some flexibility (DPO's have protected employment status in The Netherlands and cannot be fired without the court's approval), but it also ensures high-level expertise where time to bring the organization into compliance is limited. In the meantime, the in-house privacy lead may be trained to become a DPO.

6. Cookie law enforcement

The Dutch cookie law (art. 11.7a Telecommunications Act) is also likely to be changed this year. A bill is currently being prepared, which would exempt cookies with low privacy risks, such as first party analytics cookies, from the information and consent requirements. Also this bill is expected to become law on January 1, 2015.

On the other hand, I wouldn't be surprised if the Consumer and Market Authority (ACM), which enforces the Telecommunications Act, would step up its enforcement efforts with regard to the cookie law. Until now, the ACM has given priority to the information requirement by giving warning to websites, but could very well also start enforcing the consent requirement in 2014.

But also the CBP may enforce the cookie law, as a particular element of the Dutch cookie law is that cookies which track users over multiple websites are considered personal data (unless the party which places the cookie can demonstrate otherwise). In 2013, the CBP has already shown concerns about the implementation of the cookie law, especially with regard to the way consent is obtained. Also, the CBP has expressed concerns in cases where analytics cookies are placed by third party analytics providers, such as Google Analytics. In such case, the CBP requires an agreement similar to a processor agreement to be put in place between the website owner and the analytics service provider. So, I would also not be surprised if also the CBP would step up its enforcement actions in 2014 with regard to the cookie law.

I wish you a happy and data-breach-free 2014 !!
For more info or support, I can be contacted via www.privasense.eu

Privacy Outlook 2014

2014 belooft hét jaar te worden voor privacycompliance. Er staan grote veranderingen op stapel. Hoe een en ander er precies gaat uitzien, weten we nog niet, maar één ding staat vast: in 2014 moeten organisaties serieus met privacy en bescherming van persoonsgegevens aan de slag.

Privacy zou in 2014 wel eens veel meer het domein van managers, informatiebeveiligers en compliance officers kunnen (moeten?) worden en minder van (bedrijfs)juristen. Nog steeds ligt bij het merendeel van de bedrijven en organisaties de kennis over en aandacht voor privacycompliance bij de juridische afdeling (die het al dan niet uitbesteedt aan een advocatenkantoor). Die doet de nodige meldingen bij het CBP, maakt een paar bewerkersovereenkomsten met leveranciers, geeft juridisch advies bij een nieuw project of de aanschaf van een nieuw systeem en kijkt er daarna niet meer naar om. Privacycompliance overstijgt bij deze organisaties vaak nauwelijks het niveau van 'repeatable'. Bedrijven en organisaties die zich hierin herkennen doen er goed aan om dit beleid in 2014 eens drastisch tegen het licht te houden.
Repeatable is no longer an option!

Het nieuwe adagium is 'data lifecycle compliance management'. En daar hoort minimaal het niveau 'managed' bij. De plannen voor 2014/2015 in Den Haag en Brussel maken dat bescherming van persoonsgegevens voortdurende aandacht nodig heeft; van wieg tot graf dus.



Privacy Maturity Pad naar 2015

Daarom de zes belangrijkste aandachtspunten voor 2014 op het gebied van privacycompliance en bescherming van persoonsgegevens op een rijtje:

1. Boetebevoegdheid CBP

Hoewel de details van het wetsvoorstel dat het kabinet onlangs naar de Raad van State stuurde nog niet precies bekend zijn, staat al wel vast dat het CBP een algemene bestuurlijke boetebevoegdheid gaat krijgen voor overtredingen van de WBP. Het gaat dan niet meer alleen om het niet naleven van de meldplicht ex artikel 27 WBP (nu maximaal 4500 euro), maar om alle overtredingen van de WBP. Naar verluidt haakt het wetsvoorstel aan bij het boetemaximum van categorie 6 van het Wetboek van Strafrecht (per 1 januari 2014: 810.000 euro), de hoogst mogelijke boete. Let wel: per overtreding! Het ongericht verzamelen van persoonsgegevens plus het bovenmatig verstekken ervan én een slechte beveiliging zou in theorie dus zomaar een boete van 2,4 miljoen euro (!) kunnen opleveren.

Maar dat is wellicht nog niet alles. Staatssecretaris Teeven (Veiligheid en Justitie), verantwoordelijk voor de WBP, had het onlangs in de Tweede Kamer tijdens de begrotingsbehandeling over omzetgerelateerde boetes voor overtredingen van de WBP, daarmee mogelijk refererend aan het Wetsvoorstel Verruiming Mogelijkheden Bestrijding Financieel-Economische Criminaliteit waarmee het boetemaximum in het Wetboek van Strafrecht voor bedrijven wordt verhoogd naar 10% van de jaaromzet als categorie 6 geen passende bestraffing biedt. Dat wetsvoorstel is in juli 2013 naar de Tweede Kamer is gestuurd. 810.000 euro is een serieus boetemaximum, waarmee het CBP vergelijkbare boetes kan uitdelen als de Engelse toezichthouder (500.000 pond). Maar met omzetgerelateerde boetes zou het CBP pas echt slagtanden krijgen.

Als het vaste inwerkingtredingsschema voor nieuwe wetgeving wordt aangehouden, gaat de boetebevoegdheid in op 1 januari 2015. Dat zou betekenen dat bedrijven, overheden en instellingen nog maar een jaar hebben om hun gegevenshuishouding op orde te brengen om zo boetes te ontlopen. En dat jaar is voorbij voor je het weet.
 

2. Meldplicht datalekken

In de Tweede Kamer ligt momenteel het wetsvoorstel meldplicht datalekken. Een datalek moet worden gemeld bij het CBP en bij de betrokkenen, tenzij er sprake is van een 'bagatel'. Hoewel we nog niet precies weten hoe het CBP met de bagatelregeling zal omgaan, mag men er van uitgaan dat datalekken waarbij persoonsgegevens met een hoge mate van gevoeligheid zijn betrokken, altijd gemeld moeten worden. Je moet dan bijvoorbeeld denken aan bijzondere gegevens ex artikel 16 WBP (medische gegevens, etniciteitsgegevens, strafrechtelijke gegevens, etc), financiële gegevens zoals creditcardinformatie en rekeninggegevens, burgerservicenummers en inloggegevens op websites en sociale media, maar ook aan camerabeelden of gegevens uit personeelsvolgsystemen.

Het maakt voor de meldplicht overigens niet uit hoeveel data is gelekt. Zelfs een klein datalek moet gemeld worden als de gegevens gevoelig zijn. Datalekken waarbij gevoelige persoonsgegevens zijn betrokken hoeven alleen dan niet gemeld te worden als ze zijn versleuteld of anderszins onbegrijpelijk zijn gemaakt voor onbevoegden.

Het niet melden van een datalek kan worden beboet met maximaal 810.000 euro (het boetemaximum van 450.000 euro in het huidige voorstel wordt door het onder punt 1 genoemde wetsvoorstel verhoogd). Ook dit wetsvoorstel treedt naar verwachting in werking op 1 januari 2015. En dus doen organisaties er goed aan om niet alleen hun beveiligingsmaatregelen in 2014 nog eens kritisch tegen het licht te houden, maar ook om hun bewerkerscontracten te herzien (een datalek bij de bewerker moet door de verantwoordelijke worden gemeld) en hun interne procedure voor het rapporteren en adresseren van datalekken af te stoffen, bij te werken en te testen.

3. Cloud en Safe Harbor

De rel rond de NSA na de openbaarmakingen van klokkenluider Edward Snowden hebben de gemoederen in Europa het afgelopen jaar flink bezig gehouden. Door deze rel zijn doorgiften van persoonsgegevens van Europa naar de Verenigde Staten in een kwaad daglicht komen te staan. En dan vooral de gegevensdoorgiften op basis van het Safe Harbor Akkoord, het doorgifteverdrag tussen de EU en de VS. In Brussel vindt men dat de VS wel heel liberaal omgaan met de zogeheten 'national security exception' van dat verdrag. Brussel heeft bij monde van Eurocommissaris Reding (Justitie en Binnenlandse Zaken) dan ook geëist dat het Safe Harbor Akkoord in 2014 wordt aangepast. Uiterlijk zomer 2014 moeten de VS aan Brussel laten weten of zij zich kunnen vinden in de voorstellen van de Europese Commissie om het Safe Harbor Akkoord aan te passen.

Problematisch is echter dat Safe Harbor een van de belangrijkste grondslagen is voor de doorgiften van persoonsgegevens in cloud-omgevingen. Opzegging van het Safe Harbor Akkoord zou niet alleen de Amerikaanse cloud industrie hard treffen, maar ook hun Europese klanten. Deze laatsten zijn immers verantwoordelijk voor de doorgiften naar de VS via de cloud. Zij zouden dan dus op zoek moeten naar alternatieven. Zij moeten ofwel een andere juridische basis zoeken (bijvoorbeeld modelcontracten, hoewel dat lastig kan zijn in cloud-omgevingen), ofwel op zoek gaan naar een andere (lees: Europese) cloudleverancier. Dat laatste zou Brussel overigens niet erg vinden. In het Europese Parlement gaan stemmen op om de verwerking van persoonsgegevens in de cloud aan banden te leggen, tenzij er sprake is van een Europese cloud waar de rechten van de Europese burgers gewaarborgd zijn. Ook Eurocommissaris Kroes (Digitale Maatschappij) heeft zich voorstander betoond van zo'n Europese aanbieder.

Als de VS de Europeanen niet tegemoet willen komen, dan kan er zomaar een heus digitaal handelsconflict ontstaan, met alle gevolgen van dien.... CIO's doen er dus goed aan om in de eerste helft van 2014 hun cloudstrategie eens kritisch tegen het licht te houden en een back-up plan te hebben klaarliggen voor het geval in de zomer de stekker uit Safe Harbor wordt getrokken.
 

4. Europese Verordening Bescherming Persoonsgegevens

De onderhandelingen over een nieuwe Europese Verordening Bescherming Persoonsgegevens, die vanaf 2016 de WBP moet gaan vervangen, naderen hun eindfase. Er liggen nog wel een paar politieke knopen op tafel die lastig door te hakken zijn en het is twijfelachtig of dat gaat lukken vóór de Europese Verkiezingen in juni. Maar over de grote lijnen is men het in Brussel wel eens: meer verantwoordelijkheid voor bedrijven en instellingen (vooral op het gebied van privacymanagement), meer rechten voor consument (vooral op internet), verplichte privacy-by-design en privacy impact assessments bij de introductie van nieuwe systemen en veranderingen in bedrijfsprocessen, omzetgerelateerde boetes (als het aan het Parlement ligt tot zelfs 5% van de wereldwijde jaaromzet of 100 miljoen euro) en restricties aan de uitwisseling van persoonsgegevens met buitenlandse overheden.

Er wordt voorzien in een overgangstermijn van twee jaar. Dat lijkt lang, maar voor veel bedrijven en instellingen zal blijken dat die twee jaar veel te kort is om alle systemen, bedrijfsprocessen en bewerkers door te lichten en waar nodig aanpassingen door te voeren. In 2014 beginnen met een implementatieplan voor de Verordening is zeker geen overbodige luxe.
 

5. De Data Protection Officer (DPO)

Ik voorspel dat 2014 ook hét jaar van de DPO wordt. Veel bedrijven, overheden en andere instellingen gaan dit jaar op zoek naar een DPO. Of misschien wel naar een CPO (Chief Privacy Officer, een DPO op executive niveau). De DPO wordt voor alle overheden, instellingen in de gezondheidszorg en veel bedrijven verplicht als de Europese Verordening van kracht wordt. Maar als je als organisatie dan nog op zoek moet naar een DPO, ben je waarschijnlijk te laat. Niet alleen zijn goed gekwalificeerde DPO's uiterst dun gezaaid, de DPO is ook de spil van het privacycomplianceprogramma van de organisatie. En dat programma moet op poten staan als de Verordening in werking treedt.

Men doet er dus goed aan om de DPO of de CPO al in 2014 aan te stellen, zodat de organisatie op tijd klaar is voor de Europese Verordening. Ook kan hij/zij dit jaar gebruiken om alvast de ergste rotzooi op te ruimen voordat de wetsvoorstellen inzake de boetebevoegdheid van het CBP en de meldplicht datalekken in werking treden. Overigens is het goed om te weten dat de DPO ook extern mag worden ingehuurd. Enerzijds geeft dat flexibiliteit (een DPO heeft immers ontslagbescherming), anderzijds is men daarmee verzekerd van deskundigheid op hoog niveau. Vanwege het brede scala aan competenties die een DPO moet hebben gelet op zijn/haar wettelijke takenpakket, is het vaak niet verstandig om nog even snel een medewerker die al in dienst is tot DPO te bombarderen. Hij/zij moet immers nog worden opgeleid en dan is 2014 voorbij voordat zo'n DPO goed en wel in kaart heeft gebracht wat er allemaal moet gebeuren. Uiteraard kan zo iemand altijd al als "privacy lead" aan de slag en worden opgeleid tot een echte DPO.
 

6. Cookiewetgeving

Het lijkt erop dat in 2014 ook de cookiewet zal worden aangepast. Straks is er geen toestemming meer nodig voor analytics cookies (hoewel we nog even moeten afwachten of de ACM daar ook de cookies van marktleider Google Analytics onder laat vallen). Tegelijkertijd zou het mij niet verbazen als de ACM de handhaving van de cookiewet gaat opvoeren en de eerste boetes gaat uitdelen voor overtreding daarvan. Tot nu toe ging de ACM vooral voor de handhaving van de informatieplicht. In 2014 zou daar zomaar ook de handhaving van het toestemmingsvereiste bij kunnen komen.

En als we het CBP mogen geloven schort het daar nog vaak aan. Het CBP heeft tracking cookies hoog op haar prioriteitenlijstje staan. Deze worden immers geacht persoonsgegevens te zijn als zij het gedrag van de gebruiker over meerdere websites volgen. In 2013 heeft het CBP in een aantal zaken al wat piketpaaltjes geslagen. 2014 zou dus zomaar ook het jaar kunnen worden waarin de cookiewet serieus zal worden gehandhaafd.

 

Ik wens u een voorspoedig en datalek-vrij 2014 !!
Voor meer info over bovenstaande ben ik bereikbaar via www.privasense.nl.

Plannen Europees Parlement laten cookiewet onverlet

Op Emerce verscheen vandaag een bericht dat de plannen van het Europees Parlement inzake de nieuwe Europese Verordening Bescherming Persoonsgegevens de regels voor cookies zouden versoepelen. Dat is echter niet het geval.

Artikel 11.7a Telecommunicatiewet vereist nu dat voor het plaatsen en uitlezen van niet-functionele cookies toestemming wordt gevraagd en verkregen (opt-in). Minister Kamp werkt momenteel aan een aanpassing van de wet. Daarin wil Kamp beter uitleggen hoe die opt-in in de praktijk kan werken, zodat er geen behoefte meer is aan een 'cookiemuur' op websites. Daarmee moet de gebruikerservaring worden verbeterd.

Het is interessant om na te gaan of de nieuwe Verordening invloed heeft op de plannen van minister Kamp. Hieronder een analyse.

Voorstel Europese Commissie
Vorig jaar januari presenteerde de Europese Commissie een voorstel voor een Europese Verordening ter bescherming van persoonsgegevens. Deze Verordening zal naar verwachting volgend jaar de Wet bescherming persoonsgegevens (WBP) gaan vervangen. Omdat de Telecommunicatiewet verwijst naar de WBP als het gaat om toestemming, is het dus de vraag of de Verordening invloed heeft op de Telecommunicatiewet (cookies, spam, etc). De voor cookies relevante bepalingen in de Verordening zijn artikel 4 (definities) en artikel 20 (profiling).

Toestemming wordt door de Europese Commissie gedefinieerd als: (Artikel 4(8)) "elke vrije, specifieke, op informatie berustende en uitdrukkelijke wilsuiting, door middel van hetzij een verklaring hetzij een ondubbelzinnige actieve handeling aanvaardt dat hem betreffende persoonsgegevens worden verwerkt" (onderstreping JT). Artikel 8 sub a WBP spreekt nu nog van "ondubbelzinnige toestemming". Daarmee lijkt de eis van de Verordening strenger te zijn dan die van de WBP. Echter, Overweging 25 van de Verordening laat echter zien dat de soep niet zo heet gegeten wordt en dat er in het begrip 'expliciet' wel enige rek zit. Wat in ieder geval duidelijk is, is dat 'stilzitten' niet voldoende is; de betrokkene moet wel iets doen of verklaren waaruit zijn wil blijkt (zie ook de Opinie van de Artikel 29 Werkgroep inzake toestemming). Deze zienswijze is recentelijk nog nader gespecificeerd voor toestemming voor cookies.

De plannen van minister Kamp inzake een nadere uitleg van het toestemmingsbegrip in artikel 11.7a Telecommunicatiewet sluiten aan bij deze zienswijzen van de Artikel 29 Werkgroep. Dit betekent dat toestemming voor cookies kan worden verkregen door een handeling van de gebruiker (bijv. het aanklikken van een link op de website), mits hij eerst op een duidelijke wijze van informatie over het gebruik van cookies is voorzien (bijv. via een banner).

Daarnaast stelt de Commissie voor om profiling te verbieden, tenzij daarvoor toestemming was verkregen, de profiling nodig was voor de nakoming van een contract met de betrokkene of nodig was voor de nakoming van een wettelijke plicht. Daarmee leek profiling met behulp van cookies te worden beperkt, zeker als toestemming "expliciet" moest zijn. Dat was echter niet zo, zoals hiervoor al is geconcludeerd.

Voorstellen Europees Parlement
Allereerst breidt het Europees Parlement de reikwijde van de Verordening uit naar identifiers zoals IP-adressen, cookies of RFID-tags in de OV-chipkaart (zie Overweging 24). Daarmee gaan de regels voor toestemming en profiling ook gelden voor dit soort gegevens.

Daarnaast introduceert het EP een nieuwe categorie gegevens, waarvoor de toepassing van sommige onderdelen van de Verordening onder omstandigheden is uitgezonderd, te weten pseudoniemen. Pseudoniemen zijn gegevens die kunnen worden gekoppeld aan een niet nader te identificeren persoon zonder het gebruik van additionele informatie, zoals 'echte' persoonsgegevens als naam, adres, etc. Hieronder kunnen ook cookies worden verstaan.

Het Europees Parlement stelt voorts voor om het voorstel van de Europese Commissie om profiling aan strengere regels te onderwerpen wat af te zwakken. In de visie van het Europees Parlement is profiling in het algemeen toe te staan (categorie 1), mits de gebruiker duidelijk geïnformeerd is en het recht van bezwaar heeft (opt-out). Echter, als de profiling significante effecten heeft op de belangen, rechten of vrijheden van de betrokkene, mag profiling alleen plaatsvinden als de betrokkene daarvoor toestemming heeft gegeven, of als de profiling nodig is voor de nakoming van een wettelijke plicht of overeenkomst met de betrokkene (categorie 2). Ten slotte is profiling op basis van bijzondere gegevens (bijv. enticiteit, gezondheid) die leidt tot discriminatie verboden (categorie 3).

In Overweging 58a stelt het EP dat profiling die uitsluitend plaatsvindt met behulp van pseudoniemen geacht wordt geen significante effecten te hebben op de belangen, rechten en vrijheden van de betrokkene. Daarmee lijkt het EP dus te zeggen dat profiling met behulp van cookies onder de opt-out valt (categorie 1). Dat is echter niet het geval. Artikel 89 van de Verordening stelt namelijk dat de e-Privacy Richtlijn 2002/58/EG, waarop artikel 11.7a Telecommunicatiewet is gebaseerd, onverkort van kracht blijft. Daarmee blijft dus ook de verplichting om toestemming te vragen voor het plaatsen en uitlezen van cookies bestaan.

Kortom....
Profiling met behulp van cookies is in de plannen van het Europees Parlement toegestaan op grond van artikel 20 AVBP (categorie 1), maar kan alleen in de praktijk worden gebracht als de bezoeker van de website zijn/haar toestemming heeft gegeven op grond van art. 11.7a Telecommunicatiewet (opt-in). De Verordening heeft dus geen invloed op de cookieregels en er is dus zeker geen sprake van een versoepeling.

Er is echter wel één lichtpuntje.
De Commissie moet uiterlijk 2 jaar na de inwerkingtreding van de Verordening plannen presenteren om Richtlijn 2002/58 in overeenstemming te brengen met de Verordening, aldus artikel 89(2) van het EP-voorstel. Dat zou zomaar eens kunnen betekenen dat de opt-in voor cookies - gelet op Overweging 58a - alsnog wordt afgeschaft.

NB. Het Europese Parlement moet nog in onderhandeling met de Raad Van Ministers over een definitieve tekst van de Verordening. Deze zullen naar verwachting binnenkort starten en moeten uiterlijk volgend jaar april zijn afgerond, wil het Europees Parlement nog kunnen stemmen vóór de Europese verkiezingen.

Wetsvoorstel datalekken kan nog wel wat fine-tuning gebruiken.

Op 21 juni stuurde het Kabinet het wetsvoorstel meldplicht datalekken naar de Tweede Kamer. Daarmee wordt in overeenstemming met het regeerakkoord van het Kabinet Rutte II in de Wet bescherming persoonsgegevens een algemene meldplicht geïntroduceerd voor beveiligingslekken met persoonsgegevens (artikel 34a Wbp). Tot nu toe bestond een dergelijke plicht alleen voor de telecomsector.

Eerlijk gezegd rammelt de redactie van het wetsvoorstel aan alle kanten, en dan met name dat van artikel 34a, eerste lid (de meldingsplicht aan het CBP). Niet alleen is daardoor de kans groot dat dit wetsvoorstel in de praktijk anders uitpakt dan voorzien, ook zullen organisaties - publiek en privaat - niet altijd goed weten hoe zij met de meldplicht om moeten gaan. Als grote datalekken vanwege de redactie van de wet dan niet gemeld (hoeven te) worden, leidt dat tot onbegrip en irritatie bij betrokkenen, de media, de politiek en de toezichthouder. En dat heeft op zijn beurt weer vervelende gevolgen voor de verantwoordelijke die zich geconfronteerd ziet met onterechte kritiek en onnodige boetes.

Een paar kanttekeningen op een rijtje.

Meldplicht

Met de meldplicht en dan met name de meldplicht bij het CBP is nog het nodige mis. Het hele eerste lid van artikel 34a is voor verbetering vatbaar. Het eerste lid luidt thans:

1. De verantwoordelijke stelt het College onverwijld in kennis van een inbreuk op de beveiliging, bedoeld in artikel 13, waarvan redelijkerwijs kan worden aangenomen dat die leidt tot een aanmerkelijke kans op nadelige gevolgen voor de bescherming van persoonsgegevens die door hem worden verwerkt.

Lex certa beginsel

De Raad van State was in zijn advies over het wetsvoorstel met name kritisch over de onbepaaldheid van de meldplicht door het gebruik van vage termen zoals "redelijkerwijs", "aanmerkelijk" en "nadelig". Die kritiek richt zich vooral tot de formulering van de zogeheten 'bagatelregeling'. Terecht wil het Kabinet niet dat alle datalekken worden gemeld, maar alleen de serieuze datalekken. De gebruikte formulering leidt echter tot onzekerheid bij verantwoordelijken over de vraag wat nu precies is uitgezonderd. Met name omdat het CBP daarover een andere mening kan hebben, waardoor een verantwoordelijke zomaar tegen een boete van maximaal 450.000 euro kan oplopen wegens verschil van inzicht met het CBP. Dit is in strijd met het lex certa beginsel, het beginsel dat vereist dat vooraf duidelijk moet zijn wat precies strafbaar is. Volgens de Raad van State is het aan de wetgever om duidelijk te maken wat precies onder de strafbepaling valt, niet aan het CBP via het maken van beleidsregels.

In het kort komt het advies van de Raad van State erop neer dat de wetgever een duidelijke bagatelregeling zou moeten maken. Dat zou bijvoorbeeld kunnen via een Vrijstellingsbesluit Meldplicht Datalekken waarin kan worden aangegeven welke datalekken niet onder de meldplicht vallen. Zo'n Vrijstellingsbesluit ontbreekt echter evenals een delegatiebepaling terzake in artikel 34a. Terecht wijst de Raad van State erop dat de onbepaaldheid van de meldplicht er toe kan leiden dat de bagatelregeling zijn doel voorbijschiet: vanwege de onduidelijkheid worden waarschijnlijk meer datalekken gemeld dan nodig.

Hier wreekt zich overigens het feit dat het kabinet, anders dan bijvoorbeeld Duitsland en Amerika (waar het idee van een meldingsplicht voor datalekken vandaan komt), er voor kiest om in beginsel alle persoonsgegevens onder de meldplicht te brengen, niet alleen die paar categorieën persoonsgegevens die kunnen leiden tot identiteitsdiefstal, discriminatie of een andere hoge mate van gevoeligheid hebben, waarvoor een meldplicht uit oogpunt van administratieve lasten ook gerechtvaardigd zou zijn. Zo'n 'positieve lijst' geeft meer rechtszekerheid en is in de praktijk makkelijker te hanteren dan een bagatelregeling.

Definitie datalek

Het wetsvoorstel geeft helaas geen definitie van een datalek, maar geeft in artikel 34a, eerste lid, slechts een omschrijving van een datalek: een inbreuk op de beveiliging als bedoeld in artikel 13 Wbp. In die omschrijving zitten een aantal belangrijke knelpunten die er mede toe leiden dat een 'datalek' in de zin van artikel 34a aanzienlijk verschilt van wat men in het dagelijkse spraakgebruik verstaat onder een datalek.

Inbreuk

Ten eerste kan het zo zijn dat een verantwoordelijke in het geheel geen beveiligingsmaatregelen heeft genomen. In dat geval is er dus strikt genomen geen sprake van een 'inbreuk op de beveiliging', waardoor er dus ook geen verplichting om te melden ontstaat. Raar maar waar erkent de staatssecretaris dit probleem, maar doet hij dit af als "theoretisch", omdat een verantwoordelijke dit redelijkerwijs niet als een verweer zou kunnen aanvoeren als hij een boete krijgt wegens niet melden van het datalek. Ik waag dit te betwijfelen. Immers, een boete kan alleen worden opgelegd als er ten onrechte niet is gemeld. Daarvoor moet er dus eerst sprake zijn van een plicht tot melden. En die ontbreekt hier nu juist vanwege het gebruik van het woord "inbreuk". Een dergelijk verweer is dus misschien wel onredelijk, maar juridisch gezien volkomen juist en zal bij een rechter dus zeer zeker kunnen slagen als verweer tegen een boete voor niet melden. Beter is dus om het woord "inbreuk" in de omschrijving van een datalek te vermijden.

Passend

Het tweede probleem wordt gevormd door het aanhaken bij artikel 13 Wbp in de omschrijving van een datalek. Artikel 13 bepaalt immers dat beveiligingsmaatregelen "passend" moeten zijn. Daarmee wordt zowel een als een onder- als een bovengrens van beveiliging van persoonsgegevens aangegeven. Een verantwoordelijk moet minimaal de maatregelen nemen die voldoende zijn om de persoonsgegevens te beschermen (ondergrens), maar hoeft geen maatregelen nemen die boven de stand van de techniek uitgaan of die onevenredig duur zijn (bovengrens). Door de meldplicht datalekken aan te laten haken bij artikel 13 ontstaan twee afbakeningsproblemen:

1) Ondergrens

Wat als de maatregelen niet passend waren qua ondergrens, dus als er niet voldoende maatregelen waren genomen? Is er dan sprake van een inbreuk op "beveiliging als bedoeld in artikel 13"? Met andere woorden: kan een verantwoordelijke als verweer tegen een boete wegens niet melden van een datalek aanvoeren dat hij geen meldingsplicht had omdat de beveiliging niet "passend" was? De redactie van artikel 34a laat dat verweer mijns insziens wel toe. Artikel 13 omschrijft 'beveiliging' immers als "passende technische en organisatorische maatregelen...". Dus met het woord 'passend'. Als de beveiliging niet passend is, is er geen sprake van een inbreuk op de "beveiliging als bedoeld in artikel 13" en dus bestaat er ook geen plicht tot het melden van het datalek.

2) Bovengrens

Nog problematischer in het licht van de meldingsplicht is de ingebouwde bovengrens in artikel 13 Wbp. Zoals gezegd hoeft een verantwoordelijke geen beveiligingsmaatregelen te nemen die boven de stand van de techniek uitgaan of die onevenredig duur zijn. Dat betekent dat artikel 13 dus niet vereist dat persoonsgegevens 100% veilig worden verwerkt; ze hoeven alleen maar passend te zijn (zie ook de CBP Richtsnoeren Beveiliging). Met andere woorden, er bestaat een door de wet ingebouwde (theoretische) kans op een datalek dat de verantwoordelijke niet hoeft af te dekken. En als zo'n mogelijkheid wordt uitgebuit door bijvoorbeeld een hacker, dan is er wederom geen inbreuk op de "beveiliging als bedoeld in artikel 13" en dus ontbreekt ook hier de plicht tot melden. Maar als zo'n datalek publiek wordt (bijvoorbeeld via de media) zal het CBP al gauw staan te zwaaien met een boete wegens niet melden. En dan sta je als verantwoordelijke gelijk met 1-0 achter, hoewel je niets verkeerd hebt gedaan.

Nadelige gevolgen voor de bescherming van persoonsgegevens'

De meldplicht bij het CBP bestaat als er "een aanmerkelijke kans is op nadelige gevolgen voor de bescherming van persoonsgegevens". Volgens de Memorie van Toelichting dient de meldplicht bij het CBP ter ondersteuning van het toezicht door het CBP. Echter, het is volstrekt onduidelijk wat precies bedoeld wordt met "nadelige gevolgen voor de bescherming van persoonsgegevens".

Dit criterium uitleggen als "nadelige gevolgen voor compliance met de Wbp" is denk ik onjuist, omdat het hier moet gaan om de effectiviteit van de bescherming in de praktijk, niet om de juridische kwalificatie van die bescherming. Het ligt dus voor de hand om te kijken naar de praktische gevolgen voor de realisatie van de beginselen van dataprotectie, zoals doelbinding, transparantie en rechten van betrokkenen.

Kennelijk wordt er evenmin mee bedoeld: de gevolgen voor de beveiliging van persoonsgegevens. Immers, het datalek heeft al plaatsgevonden en dus is de inbreuk op beveiligingsmaatregelen (dan wel de afwezigheid ervan) geen 'gevolg', maar een oorzaak. Zelfs als de beveiliging wel onder het criterium zou vallen, zouden nadelige gevolgen bijna per definitie onwaarschijnlijk zijn. Het ligt immers voor de hand dat de verantwoordelijke de beveiliging als gevolg van het datalek zal aanscherpen. Omdat er meestal dus geen nadelige gevolgen voor de beveiliging te verwachten zijn, zal de meldplicht in de meeste gevallen dus ook niet zal bestaan. Het gevolg is dat het CBP als gevolg van het in artikel 34a lid 1 gehanteerde criterium juist niet in staat wordt gesteld toezicht uit te oefenen op de passendheid van de genomen beveiligingsmaatregelen.

Als we de gevolgen voor de beveiliging dus buiten beschouwing laten, moeten we dan kijken naar de bescherming van de persoonsgegevens bij de verantwoordelijke waar het datalek heeft plaatsgevonden of moeten we kijken naar de bescherming van de persoonsgegevens bij de partij die de inbreuk pleegde? Als het gaat om de bescherming van de gegevens bij de verantwoordelijke waar het datalek heeft plaatsgevonden, dan zal een datalek zelden of nooit nadelige gevolgen hebben voor de realisatie van andere beginselen van gegevensbescherming, tenzij het gaat om verlies van gegevens of een mogelijk wijziging van de persoonsgegevens als gevolg van ongeautoriseerde toegang. In dat geval is er mogelijk een nadelig gevolg voor de datakwaliteit.

In alle andere gevallen van ongeautoriseerde toegang heeft de verantwoordelijke veelal nog steeds controle over de verwerking en dus over de realisatie van de beginselen van gegevensbescherming. Het hangt er dus maar helemaal van af op welke wijze de ongeautoriseerde toegang plaatsvindt. Worden de gegevens verstrekt aan een onbevoegde derde of worden de gegevens na een hack ingezien, dan hoeft het niet altijd zo te zijn dat deze derde de gegevens ook kan wijzigen. Als hij dat inderdaad niet kan, dan is er dus geen sprake van een aanmerkelijke kans op nadelige gevolgen voor de bescherming van de persoonsgegevens. In dat geval zou er dus ook nooit sprake zijn van een meldingsplicht bij het CBP.

Kijken we echter naar de bescherming van persoonsgegevens bij degene die de inbreuk pleegde, dan zal het juist zeer waarschijnlijk zijn dat de bescherming van persoonsgegevens bij die partij onvoldoende is geborgd. Dat zou betekenen dat er altijd sprake zou zijn van een meldingplicht bij het CBP ongeacht de aard van de persoonsgegevens.

Kortom, het genoemde criterium voor de meldingsplicht bij het CBP klopt niet. Het zal ofwel (bijna) nooit leiden tot een melding of juist altijd. En dat verhoudt zich weer niet tot het uitgangspunt om een bagatelregeling op nemen. Beter zou zijn om niet het criterium "nadelige gevolgen voor de bescherming van persoonsgegevens" te gebruiken, maar "nadelige gevolgen voor de fundamentele rechten van de betrokkene, meer in het bijzonder zijn persoonlijke levenssfeer". Men moet dan denken aan belangen als: privacy, non-discriminatie, reputatie, autonomie, rechtvaardige behandeling en gelijkheid. Met andere woorden, bij een datalek is niet de bescherming van de persoonsgegevens zelf in het geding, maar de belangen van de betrokkene die met die bescherming worden gediend.

Verschillende criteria

Het criterium voor de meldplicht bij het CBP verschilt sterk van die bij de betrokkene. Zoals gezegd bestaat de meldplicht bij het CBP indien er "een aanmerkelijke kans is op nadelige gevolgen voor de bescherming van de persoonsgegevens". Daarentegen dient de betrokkene te worden geïnformeerd als "de inbreuk waarschijnlijk ongunstige gevolgen zal hebben voor diens persoonlijke levenssfeer."

Het verschil in de criteria is problematisch, met name voor de praktijk omdat er sprake is van twee verschillende bagatelregelingen. Ten eerste is er wellicht een verschil tussen "nadelige" en "ongunstige". Er is op zich geen reden voor dit verschil in terminologie. Ook kan het verschil in criteria leiden tot een situatie dat de betrokkene wel moet worden geïnformeerd, maar het CBP niet, en dat is onwenselijk. Het CBP zal zich in dat geval immers op het standpunt stellen dat het ook had moeten worden geïnformeerd en dan kan het een boete opleggen wegens het niet naleven van de meldingsplicht van het eerste lid.

Beter zou dus zijn om de criteria voor beide meldingsplichten gelijk te trekken, zodat een meldingsplicht bij het CBP ook leidt tot een meldingsplicht bij de betrokkene en omgekeerd. In dat geval zou overigens het zevende lid, dat bepaalt dat het CBP van de verantwoordelijke kan verlangen de betrokkenen alsnog te informeren, overbodig worden, omdat de inhoud van de bepaling dan volgtijdelijk onmogelijk is. En voor de duidelijkheid: het criterium voor het informeren van de betrokkene is wat mij betreft (bijna) goed. Het moet alleen niet beperkt worden tot "persoonlijke levenssfeer", maar alle fundamentele rechten van de betrokkene omvatten.

Onverwijld

Het CBP en de betrokkene moeten "onverwijld" worden geïnformeerd. Op zich zal een redelijke vertragingen in de melding zijn geoorloofd, bijvoorbeeld voor het doen van onderzoek. Maar het begrip 'onverwijld' betekent dat er een beginpunt in de tijd is vanaf wanneer onverwijld moet worden gemeld. Het wetsvoorstel verzuimt aan te geven waar dat startpunt ligt. Logisch is dat het startpunt ligt bij het tijdstip waarop de verantwoordelijke wetenschap krijgt van het datalek, bijvoorbeeld omdat hij dat zelf constateert of omdat hem dat wordt verteld. In ieder geval kan niet als startpunt dienen het tijdstip waarop het datalek zich voordoet. Dat zou immers betekenen dat het monitoringsbeleid van de verantwoordelijke ter discussie zou kunnen komen te staan in het bepalen van de onverwijldheid van de melding. Dat zou een extreem grote impact hebben op de inspanningen die verantwoordelijken doen in het monitoren van hun beveiliging.

Daarnaast is niet iedereen binnen de verantwoordelijke bevoegd tot het doen van de melding. Dat zou je ook niet moeten willen. Het gaat er dus om dat degene die belast is met de leiding of het beheer van het proces waarin de data worden verwerkt wetenschap krijgt van het datalek. Dat betekent dat er ruimte moet zijn voor interne rapportage (bijv. het melden van het verlies van een laptop door de medewerker bij de baas, of het melden van een datalek door de bewerker bij de accountmanager van se afdeling Inkoop die het op zijn beurt weer moet melden bij het management van de organisatie). Interne rapportege betekent dus altijd dat er enige vertraging ontstaat in de afhandeling van het datalek. Dit dient tot uiting te komen in de Memorie van Toelichting op het wetsvoorstel.

In kennis stellen

De verantwoordelijke dient het CBP en de betrokkene "in kennis te stellen" van het datalek. Die terminologie impliceert dat het CBP c.q. de betrokkene moet weten dat het datalek heeft plaatsgevonden.

Los van het feit dat het CBP in het weekend gesloten is en dus geen weet heeft van het datalek tot maandagochtend op zijn vroegst, is het ook zo dat de verantwoordelijke geen invloed kan uitoefenen op de werkzaamheden van het CBP. De betrokkene kan op vakantie zijn of er voor kiezen om de indoematie niet te lezen. Volstaan zou dus dienen te worden met een term die uitdrukt dat de informatie het CBP c.q. de betrokkene heeft bereikt. Daarvoor leent zich het meer neutralere "melden" (zie ook artikel 27 Wbp).

Versleuteling

Het zesde lid van artikel 34a bevat een uitzondering op de meldingsplicht aan de betrokkenen als er sprake is ban versleuting of als de gegevens anderszins onbegrijpelijk zijn gemaakt voor onbevoegden. Op zich is een dergelijk uitzondering toe te juichen. Maar het is niet logisch dat, zoals het thans ook in de VS is geregeld, de uitzondering zich niet ook uitstrekt tot de melding bij het CBP. Immers, als de gegevens zijn versleuteld, is een meldingsplicht bij het CBP een onnodige administratieve last.

Voorts kan er discussie onstaan over de versleuteling. Door voortschrijding van de techniek kan een bepaalde type versleuteling niet meer veilig zijn. Ook kan er slordig worden omgesprongen met de sleutel, bijvoorbeeld omdat deze mee ia gelekt. Daarom moet de versleuteling "passend" zijn, d.w.z. dat de versleuteling nog steeds de stand van de techniek moet omvatten én dat er sprake moet zijn van adequaat sleutelbeheer.

Echter, op de keper beschouwd is het zesde lid geheel overbodig in het licht van de meldingscriteria in het eerste en tweede lid. Immers, als de gegevens versleuteld zijn of op een andere manier onbegrijpelijk zijn gemaakt voor onbevoegden zal er altijd sprake zijn van een situatie waarin het datalek waarschijnlijk geen nadelige resp. ongunstige gevolgen zal hebben voor de bescherming van de persoonsgegevens resp. de persoonlijke levenssfeer van de betrokkene. Je hebt daarmee in het eerste resp. het tweede lid al geen meldingsplicht. De vrijstelling in het zesde lid is dus sympathiek maar overbodig. Beter zou zijn om het zesde lid ofwel als een "in ieder geval-bepaling" op te nemen in artikel 34a dan wel om het in de Memorie van Toelichting op te nemen als toelichting op de bagatelregeling.

Tekstvoorstel

De oplossing van voornoemde problemen zou zijn om aan artikel 1 Wbp een neutrale definitie van een datalek toe te voegen en de verplichting artikel 34a, eerste lid, te beperken tot alleen de verplichting tot het melden van een datalek. De bagatelregeling zou via een AMvB kunnen worden ingevuld. Artikel 34 zou dan, evenals artikel 29 Wbp voor wat betreft de meldingsplicht voor de verwerkingen zelf, de criteria moeten bevatten waaronder vrijstelling mogelijk is (even daargelaten het eerdere pleidooi voor een positieve lijst die uiteraard op dezelfde manier als een vrijstellingsregeling tot stand kan komen).

Een wetstekst die recht doet aan de voornoemde kritiek zou er dan als volgt uit kunnen zien:

Artikel 1

p. datalek: het verlies van, onbevoegde toegang tot of onbevoegd doen verkrijgen van persoonsgegevens.

Artikel 34a

1. De verantwoordelijke meldt een datalek onverwijld nadat hij van het datalek wetenschap heeft gekregen bij het CBP en de betrokkene.

2. Het eerste lid is niet van toepassing op verlies van persoonsgegevens waarbij uitsluitend persoonsgegevens zijn betrokken die op een passende manier zijn versleuteld of op een andere passende wijze onbegrijpelijk zijn gemaakt voor eenieder die onbevoegd is tot toegang tot of verkrijging van die persoonsgegevens.

3. Bij algemene maatregel van bestuur kan worden bepaald dat daarbij aan te geven datalekken die geen of waarschijnlijk geen ongunstige gevolgen hebben voor de fundamentele rechten van de betrokkene, in het bijzonder het recht op bescherming van  diens persoonlijke levenssfeer, zijn vrijgesteld van de meldingen als bedoeld in het eerste lid.

.....

Andere problemen

Bewerker

Naast de invoeging van artikel 34a wordt ook artikel 14 Wbp gewijzigd. Aan het derde lid wordt een onderdeel toegevoegd dat zegt dat de verantwoordelijke er zorg voor draagt dat de bewerker "de verplichtingen nakomt die op de verantwoordelijke rusten ten aanzien van de verplichting tot melding van een inbreuk op de beveiliging, bedoeld in artikel 13, waarvan redelijkerwijs kan worden aangenomen dat die leidt tot een aanmerkelijke kans op nadelige gevolgen voor de persoonsgegevens die door hem worden verwerkt".

Maar wat staat er nou eigenlijk in artikel 14 lid 3 sub c? Letterlijk genomen lijkt de nieuwe tekst te vereisen dat de bewerker de melding van een bij hem ontstaan datalek doet, niet de verantwoordelijke. Op zou daar niets mis mee zijn, omdat een datalek bij een bewerker de persoonsgegevens van meerdere verantwoordelijke kan betreffen. In plaats van dat iedere verantwoordelijke dan hetzelfde datalek meldt, wordt het datalek slechts 1x door de bewerker gemeld. Ook blijft de publiciteit rondom het datalek in principe beperkt tot de bewerker. Echter, uit de Memorie van Toelichting blijkt nergens dat het de bedoeling is dat de bewerker de melding doet. Bedoeld lijkt te worden dat de bewerker de nodige waarborgen biedt om er voor te zorgen dat de verantwoordelijke zijn meldingsplicht kan nakomen. Maar dat staat er niet. In dat geval zou de redactie voor artikel 14, derde lid, er namelijk als volgt uit zien: "de verantwoordelijke in staat stelt om zijn verplichting als bedoeld in artikel 34a na te komen". Op basis van deze tekst zouden verantwoordelijken en bewerkers dan nadere afspraken kunnen maken over hoe aan deze verplichting wordt voldaan.

Overigens zou nog beter zijn als de huidige contractspraktijk dat de bewerker verplicht is om datalekken te melden bij de verantwoordelijke tot wettelijke plicht zou worden verheven (zie ook artikel 31, tweede lid van het voorstel voor een Europese Verordening Bescherming Persoonsgegevens). Op die manier zou het de verantwoordelijke immers niet kunnen worden verweten dat hij een datalek niet gemeld heeft omdat de bewerker hem daarover niet heeft ingelicht. Aanpalend zou de boetebevoegdheid van het CBP in artikel 66 zich dan mede moeten uitstrekken tot die inlichtingenplicht.

Ten slotte zou het logisch zijn als ook de bewerker een overzicht zou bijhouden van de bij hem ontstane datalekken. Dit kan immers een impact hebben op de vraag of een verantwoordelijke met de betreffende bewerker in zee zou willen gaan.

En ach ja....., bij de splitsing van het wetsvoorstel is het woord 'gebruik' ten onrechte in de titel van het wetsvoorstel blijven staan.... Haastklus?