ACTUALITEITEN PRIVACY DEEL II SPREKER MR. IR. J.M. VAN ESSEN. ADVOCAAT NAUTADUTILH N.V. 17 APRIL 2013 15:00 – 17:15 UUR
WWW.AVDRWEBINARS.NL WEBINAR 0274
W E B I N A R S
H O O G L E R A R E N
De Academie voor de Rechtspraktijk heeft onder de naam Magna Charta Webinars 30 hoogleraren bereid gevonden webinars te verzorgen op de verschillende rechtsgebieden.
Prof. mr. B.J. van Ettekoven, senior rechter Rechtbank Utrecht en hoogleraar Bestuursrecht Universiteit van Amsterdam Prof. mr. dr. I.N. Tzankova, bijzonder hoogleraar Comparative mass litigation Universiteit van Tilburg, advocaat BarentsKrans N.V. en mr. C.M. Verhage, advocaat BarentsKrans N.V. Prof. mr. G.T.M.J. Raaijmakers, hoogleraar Ondernemings- en Effectenrecht Vrije Universiteit Amsterdam, advocaat NautaDutilh N.V. Prof. mr. F.T. Oldenhuis, universitair hoofddocent aan de vakgroep Privaatrecht en Notarieel Recht van de Rijksuniversiteit Groningen Prof. mr. F.W.J.M. Schols, hoogleraar Privaatrecht, in het bijzonder notarieel recht, Radboud Universiteit Nijmegen, estate planner Prof. dr. M.B.M. Loos, hoogleraar Privaatrecht Universiteit van Amsterdam Prof. mr. J.G.J. Rinkes, hoogleraar Privaatrecht Open Universiteit, bijzonder hoogleraar Europees Consumentenrecht Universiteit Maastricht, raadsheer-plaatsvervanger Hof Arnhem, rechter-plaatsvervanger Rechtbank Rotterdam, adviseur Paulussen advocaten Prof. mr. M.M. van Rossum, hoofd Wetenschappelijk Bureau Deterink Advocaten en Notarissen, bijzonder hoogleraar Privaatrecht Open Universiteit Heerlen Prof. mr. M.E. Koppenol-Laforce, hoogleraar Faculteit Rechtsgeleerdheid, Instituut voor Privaatrecht, Ondernemingsrecht, Universiteit Leiden, advocaat Houthoff Buruma Prof. mr. drs. M.L. Hendrikse, bijzonder hoogleraar Handelsrecht en Verzekeringsrecht Open Universiteit (JPR advocatenleerstoel), directeur UvA Amsterdam Centre for Insurance Studies (ACIS), opleidingsdirecteur Master Verzekeringskunde UvA Amsterdam Business School, universitair hoofddocent Privaatrecht Universiteit van Amsterdam, rechterplaatsvervanger Rechtbank Utrecht, lid geschillencommissie Kifid (verzekeringskamer) Prof. mr. G.C.C. Lewin, bijzonder hoogleraar Bijzondere aspecten van het Privaatrecht Universiteit van Amsterdam, raadsheer Hof Amsterdam Prof. mr. CH. E.F.M. Gielen, hoogleraar Intellectueel Eigendomsrecht Universiteit van Groningen, advocaat NautaDutilh N.V. Prof. mr. A.H.N. Stollenwerck, hoogleraar Notarieel en Fiscaal Recht Vrije Universiteit Amsterdam, raadsheerplaatsvervanger Hof Den Bosch Prof. mr. C.A. Schwarz, hoogleraar Handels- en Ondernemingsrecht Universiteit Maastricht Prof. mr. J.M. Hebly, hoogleraar Bouw- en Aanbestedingsrecht Universiteit Leiden, advocaat Houthoff Buruma Prof. mr. G.K. Sluiter, hoogleraar Internationaal Strafrecht Universiteit van Amsterdam, advocaat Bรถhler Advocaten Prof. mr. M.W. Scheltema, hoogleraar Enforcement issues in Private Law Erasmus Universiteit Rotterdam, advocaat Pels Rijcken & Droogleever Fortuijn N.V. Prof. mr. P. Vlaardingerbroek, hoogleraar Familie- en Personenrecht Universiteit Tilburg, raadsheer-plaatsvervanger Hof Den Bosch, rechter-plaatsvervanger Rechtbank Rotterdam Prof. W.H. van Boom, hoogleraar Privaatrecht Erasmus School of Law, Erasmus Universiteit Rotterdam Prof. mr. dr. G.J. Zwenne, professor Faculteit Rechtsgeleerdheid, Instituut voor Metajuridica, eLaw@Leiden, Universiteit Leiden, advocaat Bird & Bird LLP Prof. dr. S. Perrick, bijzonder hoogleraar Universiteit van Amsterdam, advocaat Spinath & Wakkie Prof. dr. K.F. Haak, hoogleraar Handelsrecht Erasmus Universiteit Rotterdam, rechter-plaatsvervanger Hof Arnhem Prof. W.D. Kolkman, hoogleraar Privaatrecht Rijksuniversiteit Groningen, raadsheer-plaatsvervanger Hof Arnhem Prof. mr. dr. M.G.C.M. Peeters, bijzonder hoogleraar Derivatenrecht Universiteit van Amsterdam, advocaat NautaDutilh N.V. Prof. mr. E.P.M. Vermeulen, hoogleraar Business & Financial Law Universiteit van Tilburg Prof. mr. dr. W. Burgerhart, hoogleraar Rijksuniversiteit Groningen, estate planner Prof. mr. dr. M. Heemskerk, bijzonder hoogleraar Pensioenrecht Radboud Universiteiten Nijmegen, advocaat Onno F. Blom Advocaten Prof. dr. H.B. Winter, bijzonder hoogleraar Toezicht Rijksuniversiteit Groningen Prof. mr. B. Barentsen, bijzonder hoogleraar Albeda leerstoel Universiteiten Leiden Prof. mr. dr. R.F.H. Mertens, bijzonder hoogleraar Zakelijke Rechten Open Universiteit Heerlen, advocaat Paulussen Advocaten
Klik hier voor meer informatie
Magna Charta is onderdeel van de Academie voor de Rechtspraktijk Postbus 13346
|
3507 LH Utrecht
|
T 030 - 220 10 70
E info@magnacharta.nl
|
F 030 - 220 53 27
Inhoudsopgave Mr. Ir. J.M. van Essen Richtsnoeren en overige informatie CBP Melden verwerking persoonsgegevens
p. 497
Zienswijze inzake de toepassing van de Wet bescherming persoonsgegevens bij een overeenkomst met betrekking tot cloud computing diensten van een Amerikaanse leverancier
p. 498
Wbp naslag
p. 509
Opinion 05/2012 on Cloud Computing
p. 510
Opinion 8/2010 on applicable law
p. 537
Opinion 1/2010 on the concept of ‘controller’ and ‘processor’
p. 571
Opionon 4/2007 on the concept of personal data
p. 606
Opinion 04/2012 on Cookie Consent Exemption
p. 670
Relevante sites Informatiebladen CBP over diverse onderwerpen http://cbpweb.nl/Pages/ind_publ_inf.aspx Website gericht op burgers www.mijnprivacy.nl OPTA informatie www.spamklacht.nl http://www.opta.nl/nl/actueel/alle-publicaties/publicatie/?id=3715 http://www.opta.nl/nl/wat-doet-opta/toezichtsgebieden/telemarketing/ Reclamecodecommissie http://www.reclamecode.nl/nrc/pagina.asp?paginaID=0&deel=2 NVP sollicitatiecode http://www.nvp-plaza.nl/site/nl/kennis.phtml?p=sollicitatiecode
Melden verwerking persoonsgegevens Als u persoonsgegevens verwerkt, moet u dit in een aantal gevallen melden bij het College bescherming persoonsgegevens (CBP). Heeft uw organisatie een Functionaris voor de gegevensbescherming (FG), dan doet u een melding bij de FG. U hoeft een verwerking van persoonsgegevens niet te melden als deze is vrijgesteld van melding. U dient als verantwoordelijke zelf te beslissen of u een verwerking van persoonsgegevens moet melden. Het CBP kan u hierover niet verder adviseren. Als u twijfelt, raadt het CBP u aan om de verwerking te melden. Het blijft uw verantwoordelijkheid om de melding op een juiste en volledige wijze te doen en om u te houden aan de overige bepalingen van de Wet bescherming persoonsgegevens (Wbp). De informatie op deze pagina helpt u bij de beoordeling of u wel of niet moet melden. Ook leest u hier hoe u een melding doet. Meer informatie over melden en de meldingsprocedure vindt u onder Vraag en antwoord.
497
Zienswijze inzake de toepassing van de Wet bescherming persoonsgegevens bij een overeenkomst met betrekking tot cloud computing diensten van een Amerikaanse leverancier Inleiding
Op 20 febru ari 2012 (ged ateerd 25 januari 2012) ontving het College bescherm ing p ersoonsgegevens (CBP) een verzoek van SURFm arket (d estijd s nog SURFd iensten geheten) om 1 een zienswijze. Parallel aan d e beantwoord ing van d it verzoek w erkte het CBP sam en m et d e and ere Europese p rivacy-toezichthoud ers, verenigd in d e Groep gegevensbescherming artikel 29 (WP29), aan een gezam enlijk stand p u nt over clou d com pu ting in relatie tot d e bescherming van p ersoonsgegevens. Deze laatste activiteit heeft geresu lteerd in een ad vies d at op 1 ju li 2012 d oor 2 d e plenaire vergad ering van WP29 w erd aangenomen. Med e omd at het CBP in d eze zienswijze aan w ild e sluiten op het Eu rop ese stand p u nt heeft d e beantw oord ing van het verzoek langer ged u urd d an gebruikelijk is. H et CBP heeft hierover tu ssentijd s contact gehad m et SURFm arket. In het verzoek geeft SURFm arket aan in besp reking te zijn m et een Eu rop ese vestiging van een 3 Am erikaanse leverancier over het gratis aanbied en van een aantal cloud -d iensten, en d at in d eze besp rekingen 'verschillen [zijn] gerezen over d e interp retatie van d e Eu rop ese Privacyrichtlijn 95/ 46/ EG' en d e im plem entatie d aarvan in d e Wet bescherming p ersoonsgegevens (Wbp ). SURFm arket geeft d aarbij aan d at d oor d e verschillen in interp retatie 'het gevaar kan ontstaan d at d e beveiliging en bescherming van p ersoonsgegevens van zeer vele p ersonen tekort schiet. SURFm arket kan m et haar d ienstverlening potentieel nam elijk hond erd d u izend en m ed ew erkers en stu d enten voorzien van d e [clou d -d iensten].' SURFm arket wijst er op d at er ook bijzond ere p ersoonsgegevens w ord en verw erkt. SURFm arket legt het CBP – kort sam engevat – d e volgend e vragen voor: 1. Biedt de zelfcertificering door de Amerikaanse leverancier bij het Safe Harbor Framework voldoende waarborgen voor de doorgifte van persoonsgegevens aan de Verenigde Staten (VS)? 2. Biedt de standaard Statement on Auditing Standards no. 70 (SAS 70) voldoende zekerheid over de beveiliging van de verwerkte persoonsgegevens of zijn de standaarden International Standard for Assurance Engagements (ISAE) 3402 en Statement on Standards for Attestation Engagements (SSAE) 16 daartoe beter toegerust? 3. Volstaat de zelfcertificering van de Amerikaanse leverancier bij het Safe Harbor Framework om te waarborgen dat sub-bewerkers die door de leverancier worden ingeschakeld voldoen aan een vergelijkbaar passend beschermingsniveau?
SURFmarket maakt deel uit van SURF, de samenwerkingsorganisatie voor het hoger onderwijs en onderzoek waarbinnen de Nederlandse universiteiten, hogescholen en onderzoeksinstellingen nationaal en internationaal gezamenlijk investeren in ICTinnovatie. SURF bestaat uit een aantal organisaties met een eigen werkterrein, te weten: SURF, SURFnet, SURFmarket, SURFshare en binnenkort SURFsara. SURFmarket sluit sinds 1991 overeenkomsten met aanbieders van software en wetenschappelijke informatiebronnen ten behoeve van medewerkers en studenten in het hoger onderwijs en wetenschappelijk onderzoek in Nederland. Zie < http://www.surfmarket.nl/Over/Paginas/Samenwerking.aspx >. 2 Bij het uitbrengen van deze zienswijze was dit advies uitsluitend nog beschikbaar in het Engels: Opinion 05/2012 on Cloud Computing van 1 juli 2012, < http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2012/wp196_en.pdf >. 3 Bij de aangeboden cloud-diensten gaat het onder meer om e-mail, agendabeheer, groepsdiscussies en relatiebeheer. 1
498
BLAD
1
H et vervolg van d eze ziensw ijze geeft antw oord op d e d rie vragen d ie SURFm arket heeft voorgelegd aan het CBP. Met d e beantw oord ing w il het CBP een zo groot m ogelijke groep v an aanbied ers en afnem ers d u id elijkheid bied en over d e kw esties d ie in d e vragen van SURFm arket aan d e ord e kom en. De vragen w ord en d aarom in m eer algem ene zin beantw oord . De beantw oord ing gaat u it van een in N ed erland gevestigd e verantw oord elijke d ie, voor een verw erking van persoonsgegevens w aarop d e Wet bescherming p ersoonsgegevens (Wbp ) van toep assing is, gebru ik maakt van d e cloud com p uting d iensten van een leverancier d ie gevestigd is in d e Verenigd e Staten (VS).
Juridisch kader
Relevant voor d e beantw oord ing van d e gesteld e vragen zijn d e artikelen 13 (beveiliging), 14 (het inschakelen van bew erkers), 15 (toezicht d oor d e verantw oord elijke) en d e artikelen 76 en 77 (internationale d oorgifte) van d e Wbp . Bij d e beantw oord ing van d e vragen in het vervolg van d eze ziensw ijze word en d eze artikelen nad er besp roken. H et Safe Harbor Framework, d at in tw ee van d e gesteld e vragen w ord t genoemd , heeft tot d oel om d e d oorgifte van p ersoonsgegevens vanu it d e Europese Unie (EU) / d e Eu ropese Economische Ru imte (EER) naar d e VS te vergemakkelijken zond er d aarbij afbreuk te d oen aan d e bescherming van d e p ersoonsgegevens. H et gaat om een vorm van zelfcertificering, w aarbij organisaties zich verp lichten om een aantal princip es op h et gebied van d e gegevensbescherming na te leven (d e Safe Harbor Principles of Veilige H aven Beginselen ). Bij d e beantw oord ing van d e betreffend e vragen w ord t nad er ingegaan op d e relevante inhou d elijke asp ecten van het Safe Harbor Framework. WP29, een sam enw erkingsverband van Europ ese toezichthoud ers op d e gegevensbescherm ing, heeft op 1 ju li 2012 een ad vies aangenom en over clou d com pu ting in relatie tot d e bescherming 4 van p ersoonsgegevens. Deze zienswijze is m ed e gebaseerd op d it ad vies. Verd er heeft het CBP 5 bij het op stellen van d eze ziensw ijze kennis genom en van d e eerd ere uitspraken van d e Noorse 6 en d e Deense toezichthoud ers over clou d comp uting.
Doorgifte van persoonsgegevens in de cloud
Biedt de zelfcertificering door de A merikaanse leverancier bij het Safe Harbor Framework voldoende waarborgen voor de doorgifte van persoonsgegevens aan de V S? Alvorens tot beantw oord ing van bovengenoem d e vraag over te gaan w ord en ond erstaand eerst d e eisen w eergegeven d ie d e Wbp en d e Safe Harbor Principles stellen aan d oorgifte in het algem een. Ook word t d aarbij ingegaan op w at het ad vies van WP 29 d aarover overweegt. De artikelen 76 en 77 Wbp regelen d e d oorgifte van p ersoonsgegevens naar land en bu iten d e EU/ EER. Doorgifte is een vorm van gegevensverw erking. Persoonsgegevens m ogen in beginsel slechts naar land en bu iten d e EU/ EER w ord en d oorgegeven ind ien d at land een â&#x20AC;&#x2DC;p assend beschermingsniveau â&#x20AC;&#x2122; kent. Ind ien een p assend beschermingsniveau ontbreekt geld t in beginsel een d oorgifteverbod en m ogen p ersoonsgegevens alleen aan land en bu iten d e EU/ EER word en d oorgegeven op grond van een van d e in artikel 77 Wbp genoem d e (w ettelijke) u itzond eringen, zoals d e uitd rukkelijke toestemm ing van een betrokkene, voor d e nood zakelijke uitvoering van een overeenkom st of op grond van een vergu nning van d e m inister van Veiligheid en Ju stitie. Steed s m oet ook vold aan zijn aan d e algem ene vereisten van d e Wbp. WP29, Opinion 05/2012 on Cloud Computing van 1 juli 2012. Uitspraak van de Noorse toezichthouder: Will not let Norvegian enterprises use Google Apps, < http://www.datatilsynet.no/English/Publications/Will-not-let-Norwegian-enterprises-of-Google-Apps/ > 6 Uitspraak van de Deense toezichthouder: Processing of sensitive personal data in a cloud solution, < http://www.datatilsynet.dk/english/processing-of-sensitive-personal-data-in-a-cloud-solution/ > 4 5
499
BLAD
2
De VS w ord en niet aangem erkt als een land m et een ‘p assend beschermingsniveau ’ omd at er geen algem ene w etgeving voor d e bescherming van p ersoonsgegevens bestaat. Ter bevord ering van d e hand elsrelaties tu ssen d e VS en d e EU en zond er afbreu k te w illen d oen aan het beschermingsniveau van p ersoonsgegevens, is d aarom in 2000 het VS-EU Safe Harbor Framework tot stand gekom en, d at d oor d e Europ ese Commissie bij beschikking is aangem erkt als ‘p assend 7 beschermingsniveau ’. H et Safe Harbor Framework is een vorm van zelfregu lering d oor bed rijven. Voor zelfcertificering m oet een organisatie d ie tot d e Veilige H aven toe wil tred en, zich aanm eld en bij het ministerie van H and el van d e VS en in het op enbaar verklaren d at zij d e Veilige H aven Beginselen zullen naleven. Aan d e aanm eld ing w ord en overigens verschillend e eisen gesteld in d e beschikking, zoals d e beschrijving en pu blicatie van een privacybeleid . Alleen voor d ie organisaties d ie zich verplicht hebben tot naleving van d e zogenaamd e Veilige Haven Beginselen (Safe Harbor Principles) geld t d at er sp rake is van een p assend beschermingsniveau . De verklaring van naleving van d e Veilige Haven Beginselen op zichzelf garand eert niet d at d e bed rijven d aaraan in d e praktijk ook uitvoering geven. H et ad vies van WP29 m erkt hierover het volgend e op : “The Working Party considers that companies exporting data should not merely rely on the statement of the data importer claiming that he has a Safe Harbor certification. On the contrary, the company exporting data should obtain evidence that the Safe Harbor selfcertifications exists and request evidence demonstrating that their principles are complied with. This is important especially with regard to the information provided to data subjects affected by the data processing.”8 Van d e verantw oord elijke voor d e d oorgifte word t in een clou d comp uting context ald u s verw acht d at hij niet alleen verifieert of d e zelfcertificering bestaat m aar ook d at hij verzoekt om bew ijs w aaruit blijkt d at d e Veilige Haven Beginselen d oor d e im p orteu r van d e p ersoonsgegevens ook d aad w erkelijk w ord en nageleefd . De Veilige H aven Beginselen, op basis w aarvan d e zelfcertificering p laatsvind t, zijn 9 geform u leerd op een hoog abstractieniveau . Als hand reiking bij d e interp retatie heeft d e 10 Am erikaanse overheid een aantal Frequently A sked Questions (FAQ's) gep ubliceerd . Over d e relatie tu ssen d e Veilige Haven Beginselen en d e bijbehorend e FAQ's enerzijd s, en d e richtlijn 95/ 46/ EG and erzijd s, bepaalt d e Europ ese Commissie in artikel 2 van d e eerd er genoemd e beschikking het volgend e: "Deze beschikking heeft alleen betrekking op de gepastheid van de bescherming die in de Verenigde Staten overeenkomstig de volgens de FAQ's ten uitvoer gelegde beginselen wordt geboden […] en laat de toepassing van andere bepalingen van die richtlijn de op de verwerking van persoonsgegevens in de lidstaten betrekking hebben […] onverlet." N aleving van d e Safe Harbor Principles betekent d u s u itslu itend d at d oorgifte van p ersoonsgegevens naar d e VS p laats kan vind en, en garand eert niet d at d e verw erking van d e p ersoonsgegevens in d e VS vold oet aan alle eisen uit d e richtlijn 95/ 46/ EG. Evenmin is 2000/520/EC Commission Decision of 26 July 2000, L 215, 25/08/2000, p. 0007-0047. Zie ook: < http://export.gov/safeharbor/ >. 7
WP 29, Opinion 05/2012 on Cloud Computing van 1 juli 2012, § 3.5.1, pagina 17. Safe Harbor Privacy Principles, issued by the U.S. Department of Commerce on July 21, 2000, < http://export.gov/safeharbor/eu/eg_main_018475.asp > 10 U.S.-EU Safe Harbor Framework Documents: C. Frequently Asked Questions, < http://export.gov/safeharbor/eu/eg_main_018493.asp > 8 9
500
BLAD
3
gegarand eerd d at d e verwerking in d e VS vold oet aan alle eisen u it d e van toep assing zijnd e nationale w et waarin d e richtlijn 95/ 46/ EG is geïm plem enteerd . De verantw oord elijke blijft ook bij verw erking d oor een bew erker, en ook bij verw erking in d e cloud , verantw oord elijk voor d e naleving van d eze w et. Bij het slu iten van d e overeenkom st zal d e verantw oord elijke zich d aarom ervan m oeten vergew issen d at alle van toepassin g zijnd e w ettelijke bep alingen zijn afged ekt, en zal hij eventueel aanvullend e afsp raken in d e overeenkom st op moeten nem en. Een ond erw erp d at in d it verband sp ecifiek om aand acht vraagt is d e beveiliging van d e verw erkte p ersoonsgegevens. WP29 stelt hierover het volgend e: “Finally, the Working Party considers that the Safe Harbor principles by themselves may also not guarantee the data exporter the necessary means to ensure that appropriate security measures have been applied by the cloud provider in the US, as may be required by national legislations based on the Directive 95/46/EC. In terms of data security cloud computing raises several cloud-specific security risks, such as loss of governance, insecure or incomplete data deletion, insufficient audit trails or isolation failures, which are not sufficiently addressed by the existing Safe Harbor principles on data security. Additional safeguards for data security may thus be deployed; such as by incorporating the expertise and resources of third parties that are capable of assessing the adequacy of cloud providers through different auditing, standardization and certification schemes. For these reasons it might be advisable to complement the commitment of the data importer to the Safe Harbor with additional safeguards taking into account the specific nature of the cloud.” 11 N aleving van d e Safe Harbor Principles bied t op zichzelf d u s geen zekerheid d at d e in d e cloud verw erkte p ersoonsgegevens vold oend e w ord en beveiligd , en het zal nod ig zijn om d aarover in 12 d e bewerkersovereenkomst aanvu llend e afspraken te m aken. Resu merend kan het volgend e w ord en gesteld over d e w aarborgen d ie zelfcertificering bij het Safe Harbor Framework bied t voor d e d oorgifte van persoonsgegevens aan d e VS, en ku nnen d e volgend e aand achtsp u nten w ord en aangereikt: 1. De verklaring van naleving van de Safe Harbor Principles garandeert op zichzelf niet dat de organisatie deze in de praktijk ook daadwerkelijk naleeft. De verantwoordelijke zal zich ervan moeten vergewissen dat de zelfcertificering bestaat en dat deze in de praktijk daadwerkelijk wordt nageleefd. 2. Ook als de Safe Harbor Principles aantoonbaar worden nageleefd, betekent dit uitsluitend dat de doorgifte van persoonsgegevens naar de VS plaats kan vinden en niet dat de verwerking in de VS voldoet aan alle eisen uit de richtlijn 95/46/EG. Evenmin is gegarandeerd dat de verwerking in de VS voldoet aan alle eisen uit de van toepassing zijnde nationale wet waarin de richtlijn 95/46/EG is geïmplementeerd. De verantwoordelijke blijft ook bij verwerking door een bewerker, en ook bij verwerking in de cloud, verantwoordelijk voor de naleving van deze wet. Bij het sluiten van de overeenkomst zal de verantwoordelijke zich daarom ervan moeten vergewissen dat alle van toepassing zijnde wettelijke bepalingen zijn afgedekt, en zal hij eventueel aanvullende afspraken in de overeenkomst op moeten nemen. 3. Een onderwerp dat in dit verband specifiek om aandacht vraagt is de beveiliging van de verwerkte persoonsgegevens. Naleving van de Safe Harbor Principles biedt op zichzelf geen WP 29, Opinion 05/2012 on Cloud Computing van 1 juli 2012, § 3.5.1, pagina 18. ENISA, een Europese organisatie die zich bezig houdt met informatiebeveiliging, heeft een handreiking over dit onderwerp gepubliceerd. ENISA, Procure secure: A guide to monitoring of security service levels in cloud contracts, < http://www.enisa.europa.eu/activities/application-security/cloud-computing/procure-secure-a-guide-to-monitoring-ofsecurity-service-levels-in-cloud-contracts > 11 12
501
BLAD
4
zekerheid dat de in de cloud verwerkte persoonsgegevens voldoende worden beveiligd, en het zal nodig zijn om daarover in de bewerkersovereenkomst aanvullende afspraken te maken.
Beveiliging van persoonsgegevens in de cloud
Biedt de standaard Statement on A uditing Standards no. 70 (SA S 70) voldoende zekerheid over de beveiliging van de verwerkte persoonsgegevens of zijn de standaarden International Standard for A ssurance Engagements (ISA E) 3402 en Statement on Standards for A ttestation Engagements (SSA E) 16 daartoe beter toegerust? De stand aard s d ie in d e vraag w ord en genoemd bevatten richtlijnen voor het afgeven van een zogenaamd e 'third party med ed eling' (TPM). Een TPM is een verklaring van een onafhankelijke externe d esku nd ige, w aarin d eze een oord eel geeft over d e m aatregelen d ie een bew erker heeft getroffen. De TPM w ord t op gesteld in opd racht van d e bew erker, en w ord t verstrekt aan d e verantw oord elijken d ie gebruik m aken van d iens d iensten. H et d oel van het verstrekken van een TPM is om d e verantw oord elijken inzicht te bied en in d e getroffen m aatregelen, zond er d at ied ere verantw oord elijke d aar zelf ond erzoek naar hoeft te (laten) d oen. Voor het op stellen van TPM's bestaat een aantal breed geaccepteerd e stand aard en . De belangrijkste d aarvan zijn d e d rie stand aard en d ie in d e vraag w ord en genoemd : SAS70, ISAE 3402 en SSAE 16. In N ed erland w ord t vooral ISAE 3402 toegepast. SSAE 16 is sterk gebaseerd op ISAE 3402, m aar heeft op p u nten een uitw erking gekregen d ie p ast binnen d e Am erikaanse regelgeving. Beid e stand aard s vervangen d e inm id d els vervallen SAS70. Binnen zow el ISAE 3402 als SSAE 16 w ord t d e basis voor d e TPM gevorm d d oor een beschrijving d oor d e bew erker van d e m aatregelen d ie voor d e d oelgroep van d e TPM relevant zijn. De externe d esku nd ige toetst d eze beschrijving ond er m eer op volled igheid en stelt vervolgens vast of d e bew erker d e beschreven m aatregelen d aad w erkelijk heeft getroffen. Afhankelijk van het typ e TPM d oet d e externe d esku nd ige een uitsp raak over d e aan w ezigheid van d e beschreven m aatregelen op een bep aald e d atum (typ e 1) of ged u rend e een bep aald e p eriod e (typ e 2). Alvorens over te gaan tot d e beantw oord ing van d e gesteld e vraag, w ord en ond erstaand eerst kort d e eisen w eergegeven d ie d e Wbp stelt aan d e beveiliging van p ersoonsgegevens bij verw erking d oor een bewerker. Deze eisen zijn van toep assing op ied ere vorm van verw erking d oor een bew erker, ook als d e verw erking plaatsvind t in d e clou d . De kern van d eze eisen is op genom en in artikel 14 Wbp . Daarnaast zijn ook d e artikelen 12 en 13 Wbp van toepassing op d e verw erking d oor een bew erker. Artikel 14 Wbp schrijft voor d at d e verantw oord elijke, als hij p ersoonsgegevens laat verw erken d oor een bew erker, m oet zorgen d at d e bew erker vold oend e technische en organisatorische beveiligingsm aatregelen treft. De verantwoord elijke m oet toezien op naleving van d ie 13 m aatregelen. De afspraken d ie d e verantw oord elijke m et d e bew erker maakt over d e bescherming en d e beveiliging van p ersoonsgegevens m oeten schriftelijk of in een and ere, 14 gelijkwaard ige vorm w ord en vastgelegd . Artikel 13 Wbp schrijft voor d at d e verantw oord elijke p assend e technische en organisatorische m aatregelen m oet treffen om d e p ersoonsgegevens d ie hij verw erkt te beveiligen tegen verlies en onrechtm atige verw erking. Bij verwerking d oor een bew erker m oet d e verantw oord elijke zorgen d at d e bew erker d e verp lichtingen nakom t d ie ingevolge artikel 13 op d e verantw oord elijke 15 ru sten. Artikel 14 lid 1 Wbp. Artikel 14 lid 2 Wbp: ‘De uitvoering van verwerkingen door een bewerker wordt geregeld in een overeenkomst of krachtens een andere rechtshandeling waardoor een verbintenis ontstaat tussen de bewerker en de verantwoordelijke’. Artikel 14 lid 5 Wbp: ‘Met het oog op het bewaren van het bewijs worden de onderdelen van de overeenkomst of de rechtshandeling die betrekking hebben op de bescherming van persoonsgegevens, alsmede de beveiligingsmaatregelen als bedoeld in artikel 13 schriftelijk of in een andere, gelijkwaardige vorm vastgelegd’. 15 Artikel 14 lid 3 onderdeel b Wbp. 13 14
502
BLAD
5
Artikel 12 Wbp schrijft voor d at d e bew erker, d iens p ersoneel en and eren d ie ond er zijn gezag vallen, p ersoonsgegevens u itslu itend mogen verwerken in opd racht van d e verantw oord elijke. 16 De verantwoord elijke m oet toezien op naleving van d eze verp lichting. Verd er legt artikel 12 aan d e bewerker, d iens p ersoneel en and eren d ie ond er zijn gezag vallen, een geheim houd ingsplicht op met betrekking tot d e p ersoonsgegevens d ie zij verw erken. Een TPM kan voor d e verantw oord elijke een m id d el zijn om vast te stellen of d e bewerker d e nood zakelijke organisatorische en technische beveiligingsm aatregelen d aad w erkelijk getroffen heeft. Aand achtsp u nten d aarbij zijn: 1. De standaard SAS 70 wordt niet meer gebruikt. De standaarden ISAE 3402 en SSAE 16, die SAS 70 vervangen, zijn onderling min of meer vergelijkbaar. Beide standaarden zien op de wijze waarop de onafhankelijke externe deskundige zijn onderzoek uitvoert en daarover rapporteert, en niet op de maatregelen die worden beoordeeld. 2. Voor de verantwoordelijke is het vooral van belang welke maatregelen in de TPM worden betrokken, en of een uitspraak wordt gedaan over de aanwezigheid van de beschreven maatregelen op een bepaalde datum (type 1) of gedurende een bepaalde periode (type 2). Hiaten in de TPM, bijvoorbeeld waar het gaat om technische beveiligingsmaatregelen die specifiek zijn voor verwerking in de cloud,17 zullen via aanvullende rapportages moeten worden ingevuld.
Verwerking door sub-bewerkers in de cloud
V olstaat de zelfcertificering van de A merikaanse leverancier bij het Safe Harbor Framework om te waarborgen dat sub-bewerkers die door de aanbieder worden ingeschakeld voldoen aan een vergelijkbaar passend beschermingsniveau? Bew erkers van persoonsgegevens ku nnen bij d e verw erking van p ersoonsgegevens sub bew erkers inschakelen. Een cloud -d ienstverlener d ie ap plicaties aan zijn afnem ers ter beschikking stelt, kan bijvoorbeeld voor d e fysieke op slag van d e verw erkte p ersoonsgegevens gebru ik maken van d e d iensten van een sub-bewerker. Alvorens over te gaan tot d e beantw oord ing van d e gesteld e vraag, w ord t ond erstaand eerst kort d e eisen w eergegeven uit d e Wbp en u it d e Safe Harbor Principles d ie betrekking hebben op het inschakelen van sub-bew erkers bij d e verw erking van p ersoonsgegevens. Bij d e beantw oord ing van d e voorgaand e vraag zijn d e eisen besp roken d ie d e artikelen 12, 13 en 14 van d e Wbp stellen aan d e beveiliging van p ersoonsgegevens bij verwerking d oor een bew erker. Deze eisen zijn integraal van toepassing als d e bew erker d e p ersoonsgegevens laat verw erken d oor een of m eer su b-bew erkers. Uitgangsp unt blijft d at d e verantw oord elijke verantw oord elijk is voor alles wat er m et d e p ersoonsgegevens gebeurt, en u it d eze verantwoord elijkheid vloeit voort d at p ersoonsgegevens alleen maar d oor een su b-bew erker ku nnen w ord en verw erkt als d e verantw oord elijke d aar u itd rukkelijk m ee heeft ingestem d . Ind ien d e verantw oord elijke d aarvoor in d e bew erkersovereenkom st u itd rukkelijk ruimte heeft gegeven m ag d e bew erker â&#x20AC;&#x201C; m et behou d van zijn volle aansprakelijkheid voor d e naleving van zijn overeenkom st m et d e verantw oord elijke â&#x20AC;&#x201C; d elen van d e verw erking u itbested en aan sub-bew erkers. De bew erker d ient d an w el contractueel verzekerd te hebben d at d e sub-bew erker zich eveneens richt naar d e instru cties van
Artikel 14 lid 3 onderdeel a Wbp. Zie voor meer informatie ENISA, Procure secure: A guide to monitoring of security service levels in cloud contracts, URL: http://www.enisa.europa.eu/activities/application-security/cloud-computing/procure-secure-a-guide-to-monitoring-of-securityservice-levels-in-cloud-contracts 16 17
503
BLAD
6
d e verantw oord elijke, tot geheim houd ing verplicht is en d e nod ige beveiligingsm aatregelen ten 18 op zichte van d e gegevensverw erking neem t. De Safe Harbor Principles stellen in het beginsel 'verd ere d oorgifte' d e volgend e eisen aan het inschakelen van (sub)bewerkers: "Wanneer [een organisatie] informatie wil doorgeven aan een derde die als haar vertegenwoordiger optreedt19, mag dit indien zij zich er eerst van vergewist dat deze derde de Veiligehavenbeginselen onderschrijft, dan wel de richtlijn of een andere vaststelling van gepastheid op hem van toepassing is, of indien zij een schriftelijke overeenkomst met deze derde aangaat waarin zij eist dat deze derde ten minste dezelfde bescherming van de persoonlijke levenssfeer biedt als de betreffende Veiligehavenbeginselen bieden. Indien de organisatie aan deze eisen voldoet, zal zij niet aansprakelijk worden gehouden (tenzij door de organisatie anders wordt overeengekomen) indien een derde partij waaraan de informatie is doorgegeven, deze verwerkt op een manier die strijdig is met eventuele restricties of verklaringen, tenzij de organisatie wist of had moeten weten dat de derde partij de informatie op een dergelijke manier zou verwerken, maar geen redelijke maatregelen heeft genomen om deze verwerking te voorkomen of stop te zetten." Over het inschakelen van su b-bew erkers bij d e verw erking van p ersoonsgegevens in d e cloud stelt WP29 het volgend e: "If processors subcontract services out to sub-processors, they are obliged to make this information available to the client, detailing the type of service subcontracted, the characteristics of current or potential subcontractors and guarantees that these entities offer to the provider of cloud computing services to comply with Directive 95/46/EC. All the relevant obligations must therefore apply also to the sub-processors through contracts between the cloud provider and subcontractor reflecting the stipulations of the contract between cloud client and cloud provider. [â&#x20AC;Ś] In the view of the WP29, the processor can subcontract its activities only on the basis of the consent of the controller, which may be generally given at the beginning of the service with a clear duty for the processor to inform the controller of any intended changes concerning the addition or replacement of subcontractors with the controller retaining at all times the possibility to object to such changes or to terminate the contract. There should be a clear obligation of the cloud provider to name all the subcontractors commissioned. In addition, a contract should be signed between cloud provider and subcontractor reflecting the stipulations of the contract between cloud client and cloud provider." 20 WP29 benad rukt d at, ook in situ aties m et m eerd ere (su b)bew erkers, d e verantw oord elijkhed en m et betrekking tot d e naleving van d e w ettelijke voorschriften held er m oeten w ord en belegd en d at d e verantw oord elijke eind verantw oord elijk blijft: "In such scenarios, the obligations and responsibilities deriving from data protection legislation should be set out clearly and not dispersed throughout the chain of outsourcing or subcontracting, in order to ensure effective control over and allocate clear responsibility for processing activities." 21 Resu merend kan w ord en gesteld d at zelfcertificering bij het Safe Harbor Framework om d e volgend e red enen niet volstaat om te w aarborgen d at (su b-) bew erkers vold oen aan een Memorie van Toelichting Wbp bij artikel 1 onder e. In de Safe Harbor Principles wordt de rol van (sub)bewerker omschreven als 'een derde die optreedt als vertegenwoordiger van een organisatie om uit haar naam en in haar opdracht een of meer taken uit te voeren'. 20 WP 29, Opinion 05/2012 on Cloud Computing van 1 juli 2012, § 3.3.2, pagina 9. 21 WP 29, Opinion 05/2012 on Cloud Computing van 1 juli 2012, § 3.3.2, pagina 9. 18 19
504
BLAD
7
vergelijkbaar p assend beschermingsniveau , en ku nnen d e volgend e aand achtsp u nten word en aangereikt: 1. Het beginsel 'verdere doorgifte' uit de Veilige Haven Beginselen staat verwerking door een (sub-) bewerker onder bepaalde voorwaarden toe: de (sub-) bewerker moet bijvoorbeeld zelf ook de Veilige Haven Beginselen onderschrijven. 2. De beperkingen van de waarborgen die de zelfcertificering biedt bij verwerking door een (sub-) bewerker zijn analoog aan wat eerder in deze zienswijze werd aangegeven. Een organisatie die de Safe Harbor Principles onderschrijft is niet verplicht om vast te stellen of een (sub-) bewerker de gestelde voorwaarden in de praktijk daadwerkelijk naleeft. Daarbij komt dat, ook als de (sub-) bewerker de gestelde voorwaarden daadwerkelijk naleeft, er nog geen garantie is dat de verwerking door de (sub-) bewerker daarmee eveneens voldoet aan alle eisen uit de Europese richtlijn 95/46/EG of uit de nationale wet waarin deze richtlijn is geïmplementeerd. 3. De eisen die de Wbp stelt aan de verwerking door sub-bewerkers gaan verder dan de eisen uit de Safe Harbor Principles. De Wbp staat de inzet van sub-bewerkers uitsluitend toe als de verantwoordelijke daar in de bewerkersovereenkomst uitdrukkelijk ruimte voor biedt, en de bewerker dient contractueel verzekerd te hebben dat de sub-bewerker zich eveneens richt naar de instructies van de verantwoordelijke, tot geheimhouding verplicht is en de nodige beveiligingsmaatregelen ten opzichte van de gegevensverwerking neemt. 4. Ook bij inzet van meerdere (sub-) bewerkers blijft de verantwoordelijke volledig verantwoordelijk voor de naleving van de Wbp. 5. In relatie met de voorgaande vraag kan nog worden opgemerkt dat TPM's kunnen worden afgegeven met medeneming of met uitsluiting van de maatregelen die door sub-bewerkers worden getroffen ('inclusive' of 'carve-out'). Als gebruik wordt gemaakt van TPM's moet de verantwoordelijke in de bewerkersovereenkomst vastleggen of de maatregelen door subbewerkers wel of niet worden meegenomen.
Slotbeschouwing
H et CBP heeft in d eze ziensw ijze d e voorgelegd e vragen in algem ene zin beantw oord . Daarbij is u itgegaan van een verw erking van p ersoonsgegevens w aarop d e Wbp van toep assing is, m et een in N ed erland gevestigd e verantw oord elijke d ie clou d com pu ting d iensten afneem t van een in d e VS gevestigd e bew erker d ie d e Safe Harbor Principles ond erschrijft. Kenm erkend voor clou d com pu ting is echter d at d e gegevensverw erking in potentie plaats kan vind en op servers d ie in d e hele w ereld ku nnen staan. H et ad vies van WP 29 m erkt d aarover het volgend e op : “However, cloud computing is most frequently based on a complete lack of any stable location of data within the cloud provider’s network. Data can be in one data centre at 2pm and on the other side of the world at 4pm. The cloud client is therefore rarely in a position to be able to know in real time where the data are located or stored or transferred. In this context, the traditional legal instruments providing a framework to regulate data transfers to non-EU third countries not providing adequate protection, have limitations.” 22
22
WP 29, Opinion 05/2012 on Cloud Computing van 1 juli 2012, § 3.5, pagina 17.
505
BLAD
8
WP 29 voegt d aaraan toe: “Adequacy findings, including Safe Harbor, are limited in respect of the geographical scope, and therefore do not cover all transfers within the cloud.” 23 Verd er zal er binnen een cloud -context vaak sp rake zijn van m eerd ere (sub-) bew erkers en zelfs van m eerd ere verantw oord elijken. Uitgangsp unt blijft, zoals eerd er aangegeven, d at d e verantw oord elijke ook bij verw erking van persoonsgegevens in d e cloud , eind verantwoord elijk is voor d e naleving van d e Wbp . Om invulling te geven aan zijn verantw oord elijkheid voor naleving van d e Wbp , zal d e verantw oord elijke ten eerste een risicoanalyse u it moeten voeren om vast te stellen of, en ond er w elke voorw aard en, er in zijn sp ecifieke situ atie gebru ik kan word en gem aakt van cloud comp u ting. Dit w as ook een belangrijke conclu sie in het ad vies v an WP 29: "A key conclusion of this Opinion is that businesses and administrations wishing to use cloud computing should conduct, as a first step, a comprehensive and thorough risk analysis. All cloud providers offering services in the EEA should provide the cloud client with all the information necessary to rightly assess the pros and cons of adopting such a service. Security, transparency and legal certainty for the clients should be key drivers behind the offer of cloud computing services." 24 De risicoanalyse geeft niet alleen inzicht in d e risico's, m aar ook in d e aanvu llend e m aatregelen d ie m oeten w ord en getroffen om te w aarborgen d at d e betreffend e verw erking van p ersoonsgegevens in d e clou d vold oet aan d e Wbp . Ten tw eed e zal d e verantw oord elijke moeten kiezen voor een cloud -d ienstverlener d ie vold oend e w aarborgen bied t, en zal hij d e nood zakelijke afsp raken m oeten vastleggen in het bew erkerscontract. WP 29 d oet hierover d e volgend e globale aanbevelingen: "In terms of the recommendations contained in this Opinion, a cloud client's responsibilities as a controller is highlighted and it is thus recommended that the client should select a cloud provider that guarantees compliance with EU data protection legislation. […] any contract between the cloud client and cloud provider should afford sufficient guarantees in terms of technical and organizational measures. Also of significance is the recommendation that the cloud client should verify whether the cloud provider can guarantee the lawfulness of any cross-border international data transfers." 25 Een aand achtsp u nt is d e aansp rakelijkheid voor eventu ele inbreu ken op d e bescherming van d e p ersoonlijke levenssfeer. Artikel 49 Wbp stelt d e verantw oord elijke aansp rakelijk voor d e schad e of het nad eel d at voortvloeit uit niet-naleving van d e Wbp , en stelt d e bew erker aansp rakelijk voor d e schad e of het nad eel voor zover ontstaan d oor zijn w erkzaam heid . Het is nood zakelijk om d eze aansp rakelijkheid te concretiseren in het bew erkerscontract, en op voorhand d u id elijk vast te stellen w elke natuu rlijke of rechtsp ersoon in w elke gevallen en in w elke mate aansp rakelijk is. Tot slot wijst het CBP op het voornem en van d e regering om d e zogenoemd e 'bred e m eld plicht' voor d atalekken in het leven te roep en. Voor aanbied ers van op enbare elektronische comm u nicatied iensten is een d ergelijke m eld plicht nu al op genomen in artikel 11.3a van d e Telecomm u nicatiew et (d e zogenoemd e 'sm alle meld p licht'). De bred e m eld p licht richt zich tot d e
WP 29, Opinion 05/2012 on Cloud Computing van 1 juli 2012, § 3.5.1, pagina 17. WP 29, Opinion 05/2012 on Cloud Computing van 1 juli 2012, Executive summary, pagina 2. 25 WP 29, Opinion 05/2012 on Cloud Computing van 1 juli 2012, Executive summary, pagina 2. 23 24
506
BLAD
9
verantw oord elijke. Bij verw erking d oor een bew erker d raagt d e verantw oord elijke zorg d at d e bew erker 'd e verplichtingen nakom t d ie op d e verantw oord elijke ru sten ten aanzien van d e verplichting tot m eld ing van [d atalekken]'. De afspraken d ie d e verantw oord elijke m et d e bew erker m aakt over d e nakom ing m et d e m eld plicht m oeten schriftelijk of in een and ere, gelijkwaard ige vorm w ord en 26 vastgelegd . De eisen u it het w etsvoorstel zijn integraal van toepassing op verw erking van p ersoonsgegevens in d e clou d en op verw erking d oor sub -bew erkers. H et verd ient aanbeveling om hier bij het afslu iten van overeenkom sten m et aanbied ers van clou d -d iensten nu reed s rekening m ee te houd en.
26 Wijziging van de Wet bescherming persoonsgegevens voor verruiming gebruik camerabeelden en invoering van meldplicht bij datalekken < http://www.rijksoverheid.nl/documenten-en-publicaties/kamerstukken/2011/12/20/wijziging-van-de-wet-beschermingpersoonsgegevens-voor-verruiming-gebruik-camerabeelden-en-invoering-van-meldplicht-bij-datalekken.html >; Memorie van Toelichting Wijziging van de Wet bescherming persoonsgegevens < http://www.rijksoverheid.nl/documenten-en-publicaties/kamerstukken/2011/12/20/memorie-van-toelichting-wijziging-vande-wet-bescherming-persoonsgegevens.html >.
507
BLAD
10
508
BLAD
11
Wbp-naslag Wbp-naslag is een naslagwerk waarin de bepalingen van de Wet bescherming persoonsgegevens (Wbp) nader zijn toegelicht. Deze toelichting bestaat uit passages van de parlementaire geschiedenis van de Wbp en samenvattingen van relevante openbare uitspraken. De uitspraken zijn zowel van het CBP als van rechterlijke instanties. Niet alle uitspraken zijn opgenomen in het naslagwerk. Het betreft een selectie. Disclaimer De informatie in Wbp-naslag is met de grootst mogelijke zorg samengesteld. Desondanks kan het voorkomen dat er onvolkomenheden in de informatie zitten. Het CBP kan niet instaan voor de juistheid, volledigheid en actualiteit van de geboden informatie. U kunt aan de informatie in het naslagwerk, zoals die wordt weergegeven, geen rechten ontlenen. Als u zekerheid wilt hebben over regelgeving moet u de originele teksten raadplegen, zoals ze bijvoorbeeld in het Staatsblad worden gepubliceerd. Het CBP aanvaardt geen aansprakelijkheid voor schade die verband houdt met het gebruik van Wbp-naslag of met de tijdelijke onmogelijkheid om Wbp-naslag te raadplegen. Het CBP aanvaardt geen aansprakelijkheid en geen enkele verantwoordelijkheid voor de inhoud, het gebruik of de beschikbaarheid van websites waarnaar wordt verwezen. Het gebruik van dergelijke links is voor eigen risico. De informatie op dergelijke websites is door het CBP niet nader beoordeeld op juistheid, redelijkheid, actualiteit of volledigheid. Het CBP behoudt zich het recht voor de in Wbp-naslag aangeboden informatie, te allen tijde te wijzigen zonder hiervan nadere aankondiging te doen.
509
ARTICLE 29 DATA PROTECTION WORKING PARTY
01037/12/EN WP 196
Opinion 05/2012 on Cloud Computing
Adopted July 1st 2012
This Working Party was set up under Article 29 of Directive 95/46/EC. It is an independent European advisory body on data 1 protection and privacy. Its tasks are described in Article 30 of Directive 95/46/EC and Article 15 of Directive 2002/58/EC. The secretariat is provided by Directorate C (Fundamental Rights and Union Citizenship) of the European Commission, Directorate General Justice, B-1049 Brussels, Belgium, Office No MO-59 02/013. Website: http://ec.europa.eu/justice/data-protection/index_en.htm 510
Executive Summary
In this Opinion the Article 29 Working Party analyses all relevant issues for cloud computing service providers operating in the European Economic Area (EEA) and their clients specifying all applicable principles from the EU Data Protection Directive (95/46/EC) and the e-privacy Directive 2002/58/EC (as revised by 2009/136/EC) where relevant. Despite the acknowledged benefits of cloud computing in both economic and societal terms, this Opinion outlines how the wide scale deployment of cloud computing services can trigger a number of data protection risks, mainly a lack of control over personal data as well as insufficient information with regard to how, where and by whom the data is being processed/sub-processed. These risks need to be carefully assessed by public bodies and private enterprises when they are considering engaging the services of a cloud provider. This Opinion examines issues associated with the sharing of resources with other parties, the lack of transparency of an outsourcing chain consisting of multiple processors and subcontractors, the unavailability of a common global data portability framework and uncertainty with regard to the admissibility of the transfer of personal data to cloud providers established outside of the EEA. Similarly, a lack of transparency in terms of the information a controller is able to provide to a data subject on how their personal data is processed is highlighted in the opinion as matter of serious concern. Data subjects must1 be informed who processes their data for what purposes and to be able to exercise the rights afforded to them in this respect. A key conclusion of this Opinion is that businesses and administrations wishing to use cloud computing should conduct, as a first step, a comprehensive and thorough risk analysis. All cloud providers offering services in the EEA should provide the cloud client with all the information necessary to rightly assess the pros and cons of adopting such a service. Security, transparency and legal certainty for the clients should be key drivers behind the offer of cloud computing services. In terms of the recommendations contained in this Opinion, a cloud clientâ&#x20AC;&#x2122;s responsibilities as a controller is highlighted and it is thus recommended that the client should select a cloud provider that guarantees compliance with EU data protection legislation. Appropriate contractual safeguards are addressed in the opinion with the requirement that any contract between the cloud client and cloud provider should afford sufficient guarantees in terms of technical and organizational measures. Also of significance is the recommendation that the cloud client should verify whether the cloud provider can guarantee the lawfulness of any cross-border international data transfers. Like any evolutionary process, the rise of cloud computing as a global technological paradigm represents a challenge. This Opinion, as it stands, can be deemed to be an important step in defining the tasks to be assumed in this regard by the data protection community in the upcoming years. 1
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in Request for Comments 2119. The document is available at http://www.ietf.org/rfc/rfc2119.txt. However, for readability, these words do not appear in all uppercase letters in this specification. 511
2
Table of Contents
Executive Summary ............................................................................................................... 2 1. Introduction ............................................................................................................................ 4 2. Data protection risks of cloud computing .............................................................................. 5 3. Legal framework .................................................................................................................... 6 3.1 Data protection framework............................................................................................... 6 3.2 Applicable law.................................................................................................................. 7 3.3 Duties and responsibilities of different players................................................................ 7 3.3.1 Cloud client and cloud provider ................................................................................ 7 3.3.2 Subcontractors........................................................................................................... 9 3.4 Data protection requirements in the client-provider relationship................................... 10 3.4.1 Compliance with basic principles ........................................................................... 10 3.4.1.1 Transparency ........................................................................................................ 10 3.4.1.2 Purpose specification and limitation .................................................................... 11 3.4.1.3 Erasure of data...................................................................................................... 11 3.4.2 Contractual safeguards of the “controller”-“processor” relationship(s) ................. 12 3.4.3 Technical and organisational measures of data protection and data security ......... 14 3.4.3.1 Availability........................................................................................................... 14 3.4.3.2 Integrity ................................................................................................................ 15 3.4.3.3 Confidentiality...................................................................................................... 15 3.4.3.4 Transparency ........................................................................................................ 15 3.4.3.5 Isolation (purpose limitation) ............................................................................... 15 3.4.3.5 Intervenability ...................................................................................................... 16 3.4.3.6 Portability ............................................................................................................. 16 3.4.4.7 Accountability ...................................................................................................... 16 3.5 International transfers..................................................................................................... 17 3.5.1 Safe Harbor and adequate countries........................................................................ 17 3.5.2 Exemptions.............................................................................................................. 18 3.5.3 Standard contractual clauses ................................................................................... 18 3.5.4 BCR: towards a global approach............................................................................. 19 4. Conclusions and recommendations...................................................................................... 19 4.1 Guidelines for clients and providers of cloud computing services ................................ 20 4.2 Third Party Data Protection Certifications..................................................................... 22 4.3 Recommendations: Future Developments ..................................................................... 22 ANNEX.................................................................................................................................... 25 a) Rollout models ................................................................................................................. 25 b) Service provision models................................................................................................. 25
512
3
1. Introduction For some, cloud computing is one of the biggest technological revolutions to emerge in recent times. For others, it is just the natural evolution of a set of technologies aimed to achieve the long awaited dream of utility computing. In any case, large numbers of stakeholders have put cloud computing to the fore in the development of their technological strategies. Cloud computing consists of a set of technologies and service models that focus on the Internet-based use and delivery of IT applications, processing capability, storage and memory space. Cloud computing can generate important economic benefits, because on-demand resources can be configured, expanded and accessed on the Internet quite easily. Next to economic benefits, cloud computing may also bring security benefits; enterprises, especially small-to-medium sized ones, may acquire, at a marginal cost, top-class technologies, which would otherwise be out of their budget range. There is a wide gamut of services offered by cloud providers ranging from virtual processing systems (which replace and/or work alongside conventional servers under the direct control of the controller) to services supporting application development and advanced hosting, up to web-based software solutions that can replace applications conventionally installed on the personal computers of end-users. This includes text processing applications, agendas and calendars, filing systems for online document storage and outsourced email solutions. Some of the most commonly used definitions for these different types of services are contained in the Annex to this Opinion. In this Opinion the Article 29 Working Party (hereinafter: WP 29) analyses the applicable law and obligations for controllers in the European Economic Area (hereinafter: EEA) and for cloud service providers with clients in the EEA. This opinion focuses on the situation, where the relationship is assumed to be a controller-processor relationship, with the customer qualifying as controller and the cloud provider qualifying as processor. In cases where the cloud provider acts as a controller as well, they have to meet additional requirements. As a consequence, a precondition for relying on cloud computing arrangements is for the controller to perform an adequate risk assessment exercise, including the locations of the servers where the data are processed and the consideration of risks and benefits from a data protection perspective, pursuant to the criteria outlined in the paragraphs below. This Opinion specifies the applicable principles for both controllers and processors from the general data protection directive (95/46/EC), such as purpose specification and limitation, erasure of data and technical and organizational measures. The opinion provides guidance on the security-requirements, both as a structural and a procedural safeguard. Special emphasis is laid on the contractual arrangements that should regulate the relationship between a controller and a processor in this connection. The classic goals of data security are availability, integrity and confidentiality. However, data protection is not limited to data security and therefore these goals are complemented with the specific data protection goals of transparency, isolation, intervenability and portability to substantiate the individualâ&#x20AC;&#x2122;s right to data protection as enshrined in Article 8 of the EU Charter of Fundamental rights. With regard to transfers of personal data outside of the EEA, instruments such as the standard contractual clauses adopted by the European Commission, adequacy-findings and a possible future processor-BCR are analysed, as well as data protection risks arising from international law enforcement requests.
513
4
This Opinion concludes with recommendations for cloud clients as controllers, cloud providers as processors and for the European Commission with regard to future changes in the European data protection framework. The Berlin International Working Group on Data Protection in Telecommunications adopted the Sopot Memorandum 2 in April 2012. This memorandum examines privacy and data protection issues in cloud computing and emphasizes that cloud computing must not lead to a lowering of data protection standards as compared to conventional data processing.
2. Data protection risks of cloud computing As this Opinion focuses on personal data processing operations deploying cloud computing services, only the specific risks related to this context are considered.3 The majority of these risks fall within two broad categories namely lack of control over the data, and insufficient information regarding the processing operation itself (absence of transparency). Specific cloud computing risks considered in this opinion include: Lack of control By committing personal data to the systems managed by a cloud provider, cloud clients may no longer be in exclusive control of this data and cannot deploy the technical and organisational measures necessary to ensure the availability, integrity, confidentiality, transparency, isolation4, intervenability and portability of the data. This lack of control may manifest itself in the following manner: o Lack of availability due to lack of interoperability (vendor lock-in): If the cloud provider relies on proprietary technology it may prove difficult for a cloud client to shift data and documents between different cloud-based systems (data portability) or to exchange information with entities that use cloud services managed by different providers (interoperability). o Lack of integrity caused by the sharing of resources: A cloud is made up of shared systems and infrastructures. Cloud providers process personal data emanating from a wide range of sources in terms of data subjects and organisations and it is a possibility that conflicting interests and/or different objectives might arise. o Lack of confidentiality in terms of law enforcement requests made directly to a cloud provider: personal data being processed in the cloud may be subject to law enforcement requests from law enforcement agencies of the EU Member States and of third countries. There is a risk that personal data could be disclosed to (foreign) law enforcement agencies without a valid EU legal basis and thus a breach of EU data protection law would occur. o Lack of intervenability due to the complexity and dynamics of the outsourcing chain: The cloud service offered by one provider might be produced by combining services from a range of other providers, which may be dynamically added or removed during the duration of the client’s contract. 2 3
4
http://datenschutz-berlin.de/attachments/873/Sopot_Memorandum_Cloud_Computing.pdf In addition to the risks related to personal data processed “in the cloud” explicitly mentioned in this opinion, all risks related to the outsourcing of the processing of personal data must also be taken into account. In Germany the broader concept of “unlinkability” has been introduced. Cf. footnote 24 below. 514
5
o Lack of intervenability (data subjectsâ&#x20AC;&#x2122; rights): A cloud provider may not provide the necessary measures and tools to assist the controller to manage the data in terms of, e.g., access, deletion or correction of data. o Lack of isolation: A cloud provider may use its physical control over data from different clients to link personal data. If administrators are facilitated with sufficiently privileged access rights (high-risk roles), they could link information from different clients. Lack of information on processing (transparency) Insufficient information about a cloud serviceâ&#x20AC;&#x2122;s processing operations poses a risk to controllers as well as to data subjects because they might not be aware of potential threats and risks and thus cannot take measures they deem appropriate. Some potential threats may arise from the controller not knowing that o Chain processing is taking place involving multiple processors and subcontractors. o Personal data are processed in different geographic locations within the EEA. This impacts directly on the law applicable to any data protection disputes which may arise between user and provider. o Personal data is transferred to third countries outside the EEA. Third countries may not provide an adequate level of data protection and transfers may not be safeguarded by appropriate measures (e.g., standard contractual clauses or binding corporate rules) and thus may be illegal. It is a requirement that data subjects whose personal data are processed in the cloud are informed as to the identity of the data controller and the purpose of the processing (an existing requirement for all controllers under Data Protection Directive 95/46/EC). Given the potential complexity of processing chains in a cloud computing environment, in order to guarantee fair processing in respect of the data subject (Article 10 of Directive 95/46/EC), controllers should also as a matter of good practice provide further information relating to the (sub-)processors providing the cloud services.
3. Legal framework 3.1 Data protection framework The relevant legal framework is the Data Protection Directive 95/46/EC. This Directive applies in every case where personal data are being processed as a result of the use of cloud computing services. The e-privacy Directive 2002/58/EC (as revised by 2009/136/EC) applies to the processing of personal data in connection with the provision of publicly available electronic communications services in public communications networks (telecom operators) and thus is relevant if such services are provided by means of a cloud solution5.
5
Directive 2002/58/CE on e-privacy (as amended by Directive 2009/136/CE): Directive 2002/58/EC on privacy in telecommunications applies to providers of electronic communication services made available to the public, and requires them to ensure compliance with obligations relating to the secrecy of communications and personal data protection, as well as rights and obligations with regard to electronic communications networks and services. In cases where cloud computing providers act as providers of a publicly-available electronic communication service they will be subject to this regulation. 515
6
3.2 Applicable law The criteria for establishing the applicability of legislation are contained in Article 4 of Directive 95/46/EC, which refers to the law applying to controllers 6 with one or more establishments within the EEA and also to the law applying to controllers who are outside the EEA but use equipment located within the EEA to process personal data. The Article 29 Working Party has analyzed this issue in its Opinion 8/2010 on applicable law7. In the first case, the factor that triggers the application of EU law to the controller is the location of his or her establishment and the activities it carries out, according to Article 4.1.a) of the Directive, with the type of cloud service model being irrelevant. The applicable legislation is the law of the country in which the controller contracting the cloud computing services is established, rather than the place in which the cloud computing providers are located. Should the controller be established in various Member States, processing the data as part of its activities in these countries, the applicable law shall be that of each of the Member States in which this processing occurs. Article 4.1.c) 8 refers to how data protection legislation applies to controllers who are not established in the EEA but use automated or non-automated equipment located in the territory of the Member State, except where these are used only for purposes of transit. This means that if a cloud client is established outside the EEA, but commissions a cloud provider located in the EEA, then the provider exports the data protection legislation to the client.
3.3 Duties and responsibilities of different players As previously indicated, cloud computing involves a range of different players. It is important to assess and clarify the role of each of these players in order to establish their specific obligations with regard to current data protection legislation. It should be recalled that the WP29 pointed out in its opinion 1/2010 on the concepts of “controller” and “processor” that “the first and foremost role of the concept of controller is to determine who shall be responsible for compliance with data protection rules, and how data subjects can exercise the rights in practice. In other words: to allocate responsibility.” These two general criteria responsible for compliance and allocation of responsibility should be borne in mind by the parties involved throughout the analysis in question. 3.3.1 Cloud client and cloud provider The cloud client determines the ultimate purpose of the processing and decides on the outsourcing of this processing and the delegation of all or part of the processing activities to an external organisation. The cloud client therefore acts as a data controller. The Directive defines a controller as "the natural or legal person, public authority, agency or any other body that alone or jointly with others determines the purposes and means of the processing of 6
7 8
The concept of the controller can be found in Article 2.h) of the Directive and was analysed by the Article 29 WG in its Opinion 1/2010 on the concepts of controllers and processors. http://ec.europa.eu/justice/policies/privacy/docs/wpdocs/2010/wp179_en.pdf Article 4(1)c states that the legislation of a Member State shall be applicable when "the controller is not established in Community territory and, for purposes of processing personal data, makes use of equipment, automated or otherwise, situated in the territory of said Member State, unless such equipment is used only for purposes of transit through the territory of the Community". 516
7
personal data”. The cloud client, as controller, must accept responsibility for abiding by data protection legislation and is responsible and subject to all the legal duties that are addressed in Directive 95/46/EC. The cloud client may task the cloud provider with choosing the methods and the technical or organisational measures to be used to achieve the purposes of the controller. The cloud provider is the entity that provides the cloud computing services in the various forms discussed above. When the cloud provider supplies the means and the platform, acting on behalf of the cloud client, the cloud provider is considered as a data processor i.e., according to Directive 95/46/EC “the natural or legal person, public authority, agency or any other body that alone or jointly with others, processes personal data on behalf of the controller”.910 As stated in the Opinion 1/2010, some criteria11 can be used for assessing controllership of the processing. As a matter of fact, there may be situations in which a provider of cloud services may be considered either as a joint controller or as a controller in their own right depending on concrete circumstances. For instance, this could be the case where the provider processes data for its own purposes. It should be emphasized that even in complex data processing environments, where different controllers play a role in processing personal data, compliance with data protection rules and responsibilities for possible breach of these rules must be clearly allocated, in order to avoid that the protection of personal data is reduced or that a "negative conflict of competence" and gaps arise whereby some obligations or rights stemming from the Directive are not ensured by any of the parties. In the current cloud computing scenario, clients of cloud computing services may not have room for manoeuvre in negotiating the contractual terms of use of the cloud services as standardised offers are a feature of many cloud computing services. Nevertheless, it is ultimately the client who decides on the allocation of part or the totality of processing operations to cloud services for specific purposes; the cloud provider’s role will be that of a contractor vis-à-vis the client, which is the key point in this case. As stated in the Article 29 Working Party Opinion 1/201012 on the concepts of controller and processor, “the imbalance in the contractual power of a small controller with respect to large service providers should not be considered as a justification for the controller to accept clauses and terms of contracts which are not in compliance with data protection law”. For this reason, the controller must choose a cloud provider that guarantees compliance with data protection legislation. Special emphasis must be placed on the features of the applicable contracts – these must include a set of standardised data protection safeguards including those outlined by the WP in paragraph 3.4.3 (Technical and Organisational Measures) and in paragraph 3.5 (cross-border data flows) – as well as on additional mechanisms that can prove suitable for facilitating due diligence and accountability (such as independent third-party audits and certifications of a provider’s services – see paragraph 4.2). 9 10
11 12
This opinion focuses only on the regular controller – processor relationship. The cloud computing environment can also be used by natural persons (users) to carry out exclusively personal or domestic activities. In such a case, it is to be analysed thoroughly whether the so called household exception applies which exempts users from qualifying as controller. However, this issue is beyond the scope of this opinion. e.g. Level of instructions, monitoring by the cloud client, expertise of the parties Opinion 1/2010 on the concepts of "controller" and "processor" http://ec.europa.eu/justice/policies/privacy/docs/wpdocs/2010/wp169_en.pdf 517
8
Cloud providers (as processors) have a duty to ensure confidentiality. Directive 95/46 EC states that: “Any persons acting under the authority of the controller or of the processor, including the processors themselves, who have access to personal data must not process them except on instructions from the controller, unless he is required to do so by law.” Access to data by the cloud provider during its provision of services is also fundamentally governed by the requirement to comply with the provisions of Article 17 of the Directive – see section 3.4.2. Processors must take into account the type of cloud in question (public, private, community or hybrid / IaaS, SaaS or PaaS [see Annex a) Rollout models - b) Service Provision Models]) and the type of service contracted by the client. Processors are responsible for adopting security measures in line with those in EU legislation as applied in the controller’s and the processor’s jurisdictions. Processors must also support and assist the controller in complying with (exercised) data subjects’ rights. 3.3.2 Subcontractors Cloud computing services may entail the involvement of a number of contracted parties who act as processors. It is also common for processors to subcontract additional sub-processors which then gain access to personal data. If processors subcontract services out to subprocessors, they are obliged to make this information available to the client, detailing the type of service subcontracted, the characteristics of current or potential sub-contractors and guarantees that these entities offer to the provider of cloud computing services to comply with Directive 95/46/EC. All the relevant obligations must therefore apply also to the sub-processors through contracts between the cloud provider and subcontractor reflecting the stipulations of the contract between cloud client and cloud provider. In its Opinion 1/2010 on the concepts of "controller" and "processor", the Article 29 Working Party referred to the multiplicity of processors in cases in which processors may have a direct relationship with the controller or operate as subcontractors where the processors outsource part of the processing work they had been tasked with. “Nothing in the Directive prevents that on account of organisational requirements, several entities may be designated as processors or (sub-)processors also by subdividing the relevant tasks. However, all of them are to abide by the instructions given by the controller in carrying out the processing.”13. In such scenarios, the obligations and responsibilities deriving from data protection legislation should be set out clearly and not dispersed throughout the chain of outsourcing or subcontracting, in order to ensure effective control over and allocate clear responsibility for processing activities. A possible model of assurances that can be used to clarify the duties and obligations of processors when they subcontract data processing was first introduced by the Commission Decision of 5 February 2010 on the standard contractual clauses for the transfer of personal data to processors established in third countries14. In this model sub-processing is permitted only with the prior written consent of the controller and with a written agreement imposing the same obligations on the sub-processor as are imposed on the processor. Where the subprocessor fails to fulfil its data protection obligations under such written agreement the 13
14
Cf. WP169, p. 29, Opinion 1/2010 on the concepts of "controller" (http://ec.europa.eu/justice/policies/privacy/docs/wpdocs/2010/wp169_en.pdf) See FAQ II.5 of WP176. 518
and
"processor"
9
processor shall remain fully liable to the controller for the performance of the sub-processorâ&#x20AC;&#x2122;s obligations under such agreement. A provision of this kind could be used in any contractual clauses between a controller and a cloud service provider, where the latter intends to provide services through subcontracting, to assure required guarantees for the sub-processing. A similar solution regarding assurances in the course of sub-processing has been proposed recently by the Commission in the proposal for a General Data Protection Regulation15. The acts of a processor must be governed by a contract or other legal act binding the processor to the controller and stipulating in particular that, among other requirements, the processor shall enlist another processor only with the prior permission of the controller (Article 26(2) of the proposal). In the view of the WP29, the processor can subcontract its activities only on the basis of the consent of the controller, which may be generally given at the beginning of the service16 with a clear duty for the processor to inform the controller of any intended changes concerning the addition or replacement of subcontractors with the controller retaining at all times the possibility to object to such changes or to terminate the contract. There should be a clear obligation of the cloud provider to name all the subcontractors commissioned. In addition, a contract should be signed between cloud provider and subcontractor reflecting the stipulations of the contract between cloud client and cloud provider. The controller should be able to avail of contractual recourse possibilities in case of breaches of contracts caused by the subprocessors. This could be arranged by ensuring that the processor is directly liable toward the controller for any breaches caused by any sub-processors he has enlisted, or through the creation of third party beneficiary right for the benefit of the controller in the contracts signed between the processor and the sub-processors or by the fact that those contracts will be signed on behalf of the data controller, making this later a party to the contract.
3.4 Data protection requirements in the client-provider relationship 3.4.1 Compliance with basic principles The lawfulness of the processing of personal data in the cloud depends on the adherence to basic principles of EU data protection law: Namely, transparency vis-Ă -vis the data subject is to be guaranteed, the principle of purpose specification and limitation must be complied with and personal data must be erased as soon as their retention is not necessary any more. Moreover, appropriate technical and organisational measures must be implemented to ensure an adequate level of data protection and data security. 3.4.1.1 Transparency Transparency is of key importance for a fair and legitimate processing of personal data. Directive 95/46/EC obliges the cloud client to provide a data subject from whom data relating to himself are collected with information on his identity and the purpose of the processing. The cloud client should also provide any further information such as on the recipients or categories of recipients of the data, which can also include processors and sub-processors in
15
16
Proposal for a Regualtion of the European Parliament and of the Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data, 25.1.2012. See FAQ II, 1) of WP176, adopted on 12 July 2010. 519
10
so far as such further information is necessary to guarantee fair processing in respect of the data subject (cf. Article 10 of the Directive)17. Transparency must also be ensured in the relationship(s) between cloud client, cloud provider and subcontractors (if any). The cloud client is only capable of assessing the lawfulness of the processing of personal data in the cloud if the provider informs the client about all relevant issues. A controller contemplating engaging a cloud provider should carefully check the cloud providerâ&#x20AC;&#x2122;s terms and conditions and assess them from a data protection point of view. Transparency in the cloud means it is necessary for the cloud client to be made aware of all subcontractors contributing to the provision of the respective cloud service as well as of the locations of all data centres personal data may be processed at.18 If the provision of the service requires the installation of software on the cloud clientâ&#x20AC;&#x2122;s systems (e.g., browser plug-ins), the cloud provider should as a matter of good practice inform the client about this circumstance and in particular about its implications from a data protection and data security point of view. Vice versa, the cloud client should raise this matter ex ante, if it is not addressed sufficiently by the cloud provider. 3.4.1.2 Purpose specification and limitation The principle of purpose specification and limitation requires that personal data must be collected for specified, explicit and legitimate purposes and not further processed in a way incompatible with those purposes (cf. Article 6(b) of Directive 95/46/EC). The cloud client must determine the purpose(s) of the processing prior to the collection of personal data from the data subject and inform the data subject thereof. The cloud client must not process personal data for other purposes that are not compatible with the original ones. Moreover, it must be ensured that personal data are not (illegally) processed for further purposes by the cloud provider or one of his subcontractors. As a typical cloud scenario may easily involve a larger number of subcontractors, the risk of processing of personal data for further, incompatible purposes must therefore be assessed as being quite high. To minimise this risk, the contract between cloud provider and cloud client should include technical and organisational measures to mitigate this risk and provide assurances for the logging and auditing of relevant processing operations on personal data that are performed by employees of the cloud provider or the subcontractors.19 Penalties should be imposed in the contract against the provider or subcontractor if data protection legislation is breached. 3.4.1.3 Erasure of data According to Article 6(e) of Directive 95/46/EC, personal data must be kept in a form which permits the identification of data subjects for no longer than is necessary for the purposes for which the data were collected or for which they are further processed. Personal data that are not necessary any more must be erased or truly anonymised. If this data cannot be erased due to legal retention rules (e.g., tax regulations), access to this personal data should be blocked. It
17
18
19
A corresponding duty to inform the data subject exists when data that have not been obtained from the data subject himself, but from different sources are recorded or disclosed to a third party (cf. Article 11). Only then he will be able to assess whether personal data may be transferred to a so-called third country outside of the European Economic Area (EEA) which does not ensure an adequate level of protection within the meaning of Directive 95/46/EC. Cf. also section 3.4.6 below. Cf. section 3.4.3 below. 520
11
is the cloud client’s responsibility to ensure that personal data are erased as soon as they are not necessary in the aforementioned sense any more20. The principle of erasure of data applies to personal data regardless of whether they are stored on hard drives or on other storage media (e.g., backup tapes). Since personal data may be kept redundantly on different servers at different locations, it must be ensured that each instance of them is erased irretrievably (i.e., previous versions, temporary files and even file fragments are to be deleted as well). Cloud clients must be aware of the fact that log data21 facilitating auditability of, e.g., storage, modifications or erasure of data may also qualify as personal data relating to the person who initiated the respective processing operation.22 Secure erasure of personal data requires that either the storage media to be destroyed or demagnetised or the stored personal data is deleted effectively through overwriting. For the overwriting of personal data, special software tools that overwrite data multiple times in accordance with a recognised specification should be used. The cloud client should make sure that the cloud provider ensures secure erasure in the abovementioned sense and that the contract between the provider and the client contains clear provision for the erasure of personal data23. The same holds true for contracts between cloud providers and subcontractors. 3.4.2 Contractual safeguards of the “controller”-“processor” relationship(s) Where controllers decide to contract cloud computing services, they are required to choose a processor providing sufficient guarantees in respect of the technical security measures and organizational measures governing the processing to be carried out, and must ensure compliance with those measures (Article 17(2) of Directive 95/46/EC). Furthermore, they are legally obliged to sign a formal contract with the cloud service provider, as stated in Article 17(3) of Directive 95/46/EC. This article establishes the requirement for there to be a contract or other binding legal act to govern the relationship between the controller and the processor. For the purposes of keeping proof, the parts of the contract or the legal act relating to data protection and the requirements relating to the technical and organizational measures shall be in writing or in another equivalent form. The contract must at a minimum establish the fact, in particular, that the processor is to follow the instructions of the controller and that the processor must implement technical and organizational measures to adequately protect personal data. To ensure legal certainty the contract should also set forth the following issues: 1. Details on the (extent and modalities of the) client’s instructions to be issued to the provider, with particular regard to the applicable SLAs (which should be objective and measurable) and the relevant penalties (financial or otherwise including the ability to sue the provider in case of non-compliance). 2. Specification of security measures that the cloud provider must comply with, depending on the risks represented by the processing and the nature of the data to be 20
21 22
23
Erasure of data is an issue both throughout the duration of a cloud computing contract and upon its termination. It is also relevant in case of substitution or withdrawal of a subcontractor. Remarks on logging requirements are provided below at 4.3.4.2. This means that reasonable retention periods for log files are to be defined and that processes safeguarding the timely erasure or anonymisation of these data are to be in place. Cf. section 3.4.3 below. 521
12
protected. It is of great importance that concrete technical and organizational measures are specified such as those outlined in paragraph 3.4.3 below. This is without prejudice to the application of more stringent measures, if any, that may be envisaged under the client’s national law. 3. Subject and time frame of the cloud service to be provided by the cloud provider, extent, manner and purpose of the processing of personal data by the cloud provider as well as the types of personal data processed. 4. Specification of the conditions for returning the (personal) data or destroying the data once the service is concluded. Furthermore, it must be ensured that personal data are erased securely at the request of the cloud client. 5. Inclusion of a confidentiality clause, binding both upon the cloud provider and any of its employees who may be able to access the data. Only authorized persons can have access to data. 6. Obligation on the provider’s part to support the client in facilitating exercise of data subjects’ rights to access, correct or delete their data. 7. The contract should expressly establish that the cloud provider may not communicate the data to third parties, even for preservation purposes unless it is provided for in the contract that there will be subcontractors. The contract should specify that subprocessors may only be commissioned on the basis of a consent that can be generally given by the controller in line with a clear duty for the processor to inform the controller of any intended changes in this regard with the controller retaining at all times the possibility to object to such changes or to terminate the contract. There should be a clear obligation of the cloud provider to name all the subcontractors commissioned (e.g., in a public digital register). It must be ensured that contracts between cloud provider and subcontractor reflect the stipulations of the contract between cloud client and cloud provider (i.e. that sub-processors are subject to the same contractual duties than the cloud provider). In particular, it must be guaranteed that both cloud provider and all subcontractors shall act only on instructions from the cloud client. As explained in the chapter on sub-processing the chain of liability should be clearly set in the contract. It should set out the obligation on the part of the processor to frame international transfers, for instance by signing contracts with subprocessors, based on the 2010/87/EU standard contractual clauses. 8. Clarification of the responsibilities of the cloud provider to notify the cloud client in the event of any data breach which affects the cloud client’s data. 9. Obligation of the cloud provider to provide a list of locations in which the data may be processed. 10. The controller’s rights to monitor and the cloud provider’s corresponding obligations to cooperate. 11. It should be contractually fixed that the cloud provider must inform the client about relevant changes concerning the respective cloud service such as the implementation of additional functions. 12. The contract should provide for logging and auditing of relevant processing operations on personal data that are performed by the cloud provider or the subcontractors. 13. Notification of cloud client about any legally binding request for disclosure of the personal data by a law enforcement authority unless otherwise prohibited, such as a
522
13
prohibition under criminal law to preserve the confidentiality of a law enforcement investigation. 14. A general obligation on the providerâ&#x20AC;&#x2122;s part to give assurance that its internal organisation and data processing arrangements (and those of its sub-processors, if any) are compliant with the applicable national and international legal requirements and standards. In the event of infringement by the controller, any person suffering damages as a result of unlawful processing shall have the right to receive compensation from the controller for the damages caused. Should the processors use the data for any other purpose, or communicate them or use them in a way that breaches the contract, they shall also be considered to be controllers, and shall be held liable for the infringements in which they were personally involved. It should be noted that, in many cases, cloud service providers offer standard services and contracts to be signed by controllers, which set forth a standard format for processing personal data. This imbalance in the contractual power of a small controller with respect to large service providers should not be considered as justification for the controllers to accept clauses and terms of contracts which are not in compliance with data protection law. 3.4.3 Technical and organisational measures of data protection and data security Article 17(2) of Directive 95/46/EC puts full responsibility on cloud clients (acting as data controllers) to choose cloud providers that implement adequate technical and organisational security measures to protect personal data and to be able to demonstrate accountability. In addition to the core security objectives of availability, confidentiality and integrity, attention must also be drawn to the complementary data protection goals of transparency (see 3.4.1.1 above), isolation 24 , intervenability, accountability and portability. This section highlights these central data protection goals, without prejudice to other complementary security oriented risk analysis25. 3.4.3.1 Availability Providing availability means ensuring timely and reliable access to personal data. One severe threat to availability in the cloud is accidental loss of network connectivity between the client and the provider or of server performance caused by malicious actions such as (Distributed) Denial of Service (DoS)26 attacks. Other availability risks include accidental hardware failures both on the network and in the cloud processing and data storage systems, power failures and other infrastructure problems. Data controllers should check whether the cloud provider has adopted reasonable measures to cope with the risk of disruptions, such as backup internet network links, redundant storage and effective data backup mechanisms.
24
25
26
In Germany the broader concept of â&#x20AC;&#x153;unlinkabilityâ&#x20AC;? has been introduced into legislation and is promoted by the Conference of Data Protection Commissioners. Cf. e.g. ENISA at http://www.enisa.europa.eu/activities/risk-management/files/deliverables/cloudcomputing-risk-assessment A DoS attack is a coordinated attempt to make a computer or network resource unavailable to its authorised users, either temporarily or indefinitely (e.g., by means of a large number of attacking systems paralysing their target with a multitude of external communication requests). 523
14
3.4.3.2 Integrity Integrity may be defined as the property that data is authentic and has not been maliciously or accidentally altered during processing, storage or transmission. The notion of integrity can be extended to IT systems and requires that the processing of personal data on these systems remains unaltered. Detecting alterations to personal data can be achieved by cryptographic authentication mechanisms such as message authentication codes or signatures. Interference with the integrity of IT systems in the cloud can be prevented or detected by means of intrusion detection / prevention systems (IPS / IDS). This is particularly important in the type of open network environments in which clouds usually operate. 3.4.3.3 Confidentiality In a cloud environment, encryption may significantly contribute to the confidentiality of personal data if implemented correctly, although it does not render personal data irreversibly anonymous27. Encryption of personal data should be used in all cases when “in transit” and when available to data “at rest”.28 In some cases (e.g., an IaaS storage service) a cloud client may not rely on an encryption solution offered by the cloud provider, but may choose to encrypt personal data prior to sending them to the cloud. Encrypting data at rest requires particular attention to cryptographic key management as data security then ultimately depends on the confidentiality of the encryption keys. Communications between cloud provider and client as well as between data centres should be encrypted. Remote administration of the cloud platform should only take place via a secure communication channel. If a client plans to not only store, but also further process personal data in the cloud (e.g., searching databases for records), he must bear in mind that encryption cannot be maintained during processing of the data (except of very specific computations). Further technical measures aiming at ensuring confidentiality include authorization mechanisms and strong authentication (e.g. two-factor authentication). Contractual clauses should also impose confidentiality obligations on employees of cloud clients, cloud providers and subcontractors. 3.4.3.4 Transparency Technical and organisational measures must support transparency to allow review, cf. 3.4.1.1. 3.4.3.5 Isolation (purpose limitation) In cloud infrastructures, resources such as storage, memory and networks are shared among many tenants. This creates new risks for data to be disclosed and processed for illegitimate purposes. The protection goal “isolation” is meant to address this issue and contribute to guarantying that data is not used beyond its initial purpose (Article 6(b) of Dir 95/46/EC) and to maintain confidentiality and integrity.29 27
28
29
Directive 95/46/EC - Recital 26: “(...); whereas the principles of protection shall not apply to data rendered anonymous in such a way that the data subject is no longer identifiable; (...)”. I n the same line, the technical data fragmentation processes that may be used in the framework of the provision of CC services will not lead to irreversible anonymisation and thus does not imply that data protection obligations do not apply. This holds true in particular for data controllers who plan to transfer sensitive data in the meaning of Article 8 of Directive 95/46/EC (e.g., health data) to the cloud or who are subject to specific legal obligations of professional secrecy. Cf. 3.4.1.2. 524
15
Achieving isolation first requires adequate governance of the rights and roles for accessing personal data, which is reviewed on a regular basis. The implementation of roles with excessive privileges should be avoided (e.g., no user or administrator should be authorised to access the entire cloud). More generally, administrators and users must only be able to access the information that is necessary for their legitimate purposes (least privilege principle). Secondly, isolation also depends on technical measures such as the hardening of hypervisors and proper management of shared resources if virtual machines are used to share physical resources between different cloud customers. . 3.4.3.5 Intervenability Directive 95/46/EC gives the data subject the rights of access, rectification, erasure, blocking and objection (cf. Article 12 and 14). The cloud client must verify that the cloud provider does not impose technical and organisational obstacles to these requirements, including in cases when data is further processed by subcontractors. The contract between the client and the provider should stipulate that the cloud provider is obliged to support the client in facilitating exercise of data subjectsâ&#x20AC;&#x2122; rights and to ensure that the same holds true for his relation to any subcontractor.30 3.4.3.6 Portability Currently, most cloud providers do not make use of standard data formats and service interfaces facilitating interoperability and portability between different cloud providers. If a cloud client decides to migrate from one cloud provider to another, this lack of interoperability may result in the impossibility or at least difficulties to transfer the clientâ&#x20AC;&#x2122;s (personal) data to the new cloud provider (so-called vendor lock-in). The same holds true for services that the client developed on a platform offered by the original cloud provider (PaaS). The cloud client should check whether and how the provider guarantees the portability of data and services prior to ordering a cloud service.31 3.4.4.7 Accountability In IT accountability can be defined as the ability to establish what an entity did at a certain point in time in the past and how. In the field of data protection it often takes a broader meaning and describes the ability of parties to demonstrate that they took appropriate steps to ensure that data protection principles have been implemented. IT accountability is particularly important in order to investigate personal data breaches, where cloud clients, providers and sub-processor may each bear a degree of operational responsibility. The ability for the cloud platform to provide reliable monitoring and comprehensive logging mechanisms is of paramount importance in this regard. Moreover, cloud providers should provide documentary evidence of appropriate and effective measures that deliver the outcomes of the data protection principles outlined in the previous sections. Procedures to ensure the identification of all data processing operations, to respond to access requests, the allocation of resources including the designation of data protection 30
31
Cf. section 3.4.5 No. 7 above. The provider may even be instructed to answer requests on behalf of the client. Preferably, the provider should make use of standardised or open data formats and interfaces. In any event, contractual clauses stipulating assured formats, preservation of logical relations and any costs accruing from the migration to another cloud provider should be agreed on. 525
16
officers who are responsible for the organisation of data protection compliance, or independent certification procedures are examples of such measures. In addition, data controllers should ensure that they are prepared to demonstrate the setting up of the necessary measures to the competent supervisory authority upon request.32
3.5 International transfers Article 25 and 26 of the Directive 95/46/EC provide for free flow of personal data to countries located outside the EEA only if that country or the recipient provides an adequate level of data protection. Otherwise specific safeguards must be put in place by the controller and its co-controllers and/or processors. However, cloud computing is most frequently based on a complete lack of any stable location of data within the cloud providerâ&#x20AC;&#x2122;s network. Data can be in one data centre at 2pm and on the other side of the world at 4pm. The cloud client is therefore rarely in a position to be able to know in real time where the data are located or stored or transferred. In this context, the traditional legal instruments providing a framework to regulate data transfers to non-EU third countries not providing adequate protection, have limitations. 3.5.1 Safe Harbor and adequate countries Adequacy findings, including Safe Harbor, are limited in respect of the geographical scope, and therefore do not cover all transfers within the Cloud. Transfers to US organizations adhering to the principles can take place lawfully under EU law since the recipient organizations are deemed to provide an adequate level of protection to the transferred data. However, in the view of the Working Party, sole self-certification with Safe Harbor may not be deemed sufficient in the absence of robust enforcement of data protection principles in the cloud environment. In addition, Article 17 of the EU directive requires a contract to be signed from a controller to a processor for processing purposes, which is confirmed in FAQ 10 of the EU-US Safe Harbor Framework documents. This contract is not subject to prior authorization from the European DPAs. Such contract specifies the processing to be carried out and any measures necessary to ensure that the data are kept secure. Different national legislations and DPAs may have additional requirements. The Working Party considers that companies exporting data should not merely rely on the statement of the data importer claiming that he has a Safe Harbor certification. On the contrary, the company exporting data should obtain evidence that the Safe Harbor selfcertifications exists and request evidence demonstrating that their principles are complied with. This is important especially with regard to the information provided to data subjects affected by the data processing33, 34. The Working Party also considers that cloud client must verify if the standard contracts composed by cloud providers are compliant with national requirements regarding contractual data processing. National legislation may require sub-processing to be defined in the contract, 32
33
34
The Working Party provided detailed remarks on the topic of accountability in its Opinion 3/2010 on the principle of accountability http://ec.europa.eu/justice/policies/privacy/docs/wpdocs/2010/wp173_en.pdf. See German DPA: http://www.datenschutzberlin.de/attachments/710/Resolution_DuesseldorfCircle_28_04_2010EN.pdf. For requirements regarding contracting sub-processors, see 3.3.2.
526
17
which includes the locations and other data on sub-processors, and traceability of the data. Normally the cloud providers do not offer the client such information â&#x20AC;&#x201C; their commitment to the Safe Harbor cannot substitute for the lack of the above guarantees when required by the national legislation. In such cases the exporter is encouraged to use other legal instruments available, such as standard contractual clauses or BCR. Finally, the Working Party considers that the Safe Harbor principles by themselves may also not guarantee the data exporter the necessary means to ensure that appropriate security measures have been applied by the cloud provider in the US, as may be required by national legislations based on the Directive 95/46/EC35. In terms of data security cloud computing raises several cloud-specific security risks, such as loss of governance, insecure or incomplete data deletion, insufficient audit trails or isolation failures 36 , which are not sufficiently addressed by the existing Safe Harbor principles on data security37. Additional safeguards for data security may thus be deployed; such as by incorporating the expertise and resources of third parties that are capable of assessing the adequacy of cloud providers through different auditing, standardization and certification schemes38. For these reasons it might be advisable to complement the commitment of the data importer to the Safe Harbor with additional safeguards taking into account the specific nature of the cloud. 3.5.2 Exemptions The exemptions provided by article 26 of the EU Directive 95/46 enable data exporters to transfer data out of the EU without providing additional guarantees. However, WP29 has adopted an opinion in which it considered that exemptions shall apply only where transfers are neither recurrent, nor massive or structural.39 Based on such interpretations, it is almost impossible to rely on exemptions in the context of cloud computing. 3.5.3 Standard contractual clauses Standard contractual clauses as adopted by the EU Commission for the purpose of framing international data transfers between two controllers or one controller and a processor are based on a bilateral approach. When the cloud provider is considered to be the processor, model clauses 2010/87/EC are an instrument that can be used between the processor and the controller as a basis for the cloud computing environment to offer adequate safeguards in the context of international transfers. In addition to the standard contractual clauses, the Working Party considers that cloud providers could offer customers provisions that build on their pragmatic experiences as long as they do not contradict, directly or indirectly the standard contractual clauses approved by
35
36
37
38 39
See an opinion by the Danish DPA: http://www.datatilsynet.dk/english/processing-of-sensitive-personaldata-in-a-cloud-solution. Described in detail in ENISA paper Cloud Computing: Benefits, Risks and Recommendations for Information Security at: https://www.enisa.europa.eu/activities/risk-management/files/deliverables/cloudcomputing-risk-assessment. â&#x20AC;&#x153;Organizations must take reasonable precautions to protect personal information from loss, misuse and unauthorized access, disclosure, alteration and destruction.â&#x20AC;? See section 4.2 below. Working Document 12/1998: Transfers of personal data to third countries: Applying Articles 25 and 26 of the EU data protection directive, Adopted by the Working Party on 24 July 1998 (http://ec.europa.eu/justice/policies/privacy/docs/wpdocs/1998/wp12_en.pdf). 527
18
the Commission or prejudice fundamental rights or freedoms of the data subjects 40 . Nevertheless, the companies may not amend or change the standard contractual clauses without implying that the clauses will no longer be "standard"41. When the cloud provider acting as processor is established in the EU, the situation might be more complex since the model clauses applies, in general, only to the transfer of data from a EU controller to a non EU processor (see recital 23 of the Commission decision on the model Clauses 2010/87/EU and WP 176). As regards the contractual relationship between the non EU processor and the sub-processors, a written agreement which imposes the same obligations on the subprocessor as are imposed on the processor in the Model clauses should be put in place. 3.5.4 BCR: towards a global approach BCR constitute a code of conduct for companies which transfer data within their group. Such solution will be provided also for the context of cloud computing when the provider is a processor. Indeed, WP29 is currently working on BCRs for processors which will allow the transfer within the group for the benefit of the controllers without requiring the signature of contracts between processor and subprocessors per client.42 Such BCR for processors would enable the providerâ&#x20AC;&#x2122;s client to entrust their personal data to the processor while being assured that the data transferred within the providerâ&#x20AC;&#x2122;s business scope would receive an adequate level of protection.
4. Conclusions and recommendations Businesses and administrations wishing to use cloud computing should conduct, as a first step, a comprehensive and thorough risk analysis. This analysis must address the risks related to processing of data in the cloud (lack of control and insufficient information â&#x20AC;&#x201C; see section 2 above) by having regard to the type of data processed in the cloud.43 Special attention should also be paid to assessing the legal risks regarding data protection, which concern mainly security obligations and international transfers. The processing of sensitive data via cloud computing raises additional concerns. Therefore without prejudice to national laws such processing requires additional safeguards.44 The conclusions below are meant to provide a checklist for data protection compliance by cloud clients and cloud providers based on the current legal framework; some recommendations are also provided with a view to future developments in the regulatory framework at EU level and beyond.
40
41
42
43
44
See FAQ IV B1.9 9, Can companies include the standard contractual clauses in a wider contract and add specific clauses? published by the EC on http://ec.europa.eu/justice/policies/privacy/docs/international_transfers_faq/international_transfers_faq.pdf See FAQ IV B1.10, Can Companies amend and change the standard contractual clauses approved by the Commission? See Working Document 02/2012 setting up a table with the elements and principles to be found in Processor Binding Corporate Rules, adopted on 6th June 2012: http://ec.europa.eu/justice/data-protection/article29/documentation/opinion-recommendation/files/2012/wp195_en.pdf ENISA provides a list of the risks that must be taken into consideration http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-risk-assessment See Sopot Memorandum, cf. footnote 2 above. 528
19
4.1 Guidelines for clients and providers of cloud computing services -
Controller-processor relationship: This Opinion focuses on the client-provider relationship as controller-processor relationship; (see paragraph 3.3.1); Nevertheless based on concrete circumstances situations may exist where the cloud provider acts as a controller as well, e.g. when the provider re-processes some personal data for its own purposes. In such a case, the cloud provider has full (joint) responsibility for the processing and must fulfil all legal obligations that are stipulated by Directives 95/46/EC and 2002/58/EC (if applicable);
-
Cloud clientâ&#x20AC;&#x2122;s responsibility as a controller: The client as the controller must accept responsibility for abiding by data protection legislation and is subject to all the legal obligations mentioned in Directive 95/46/EC and 2002/58/EC, where applicable, in particular vis-Ă -vis data subjects (see 3.3.1). The client should select a cloud provider that guarantees compliance with EU data protection legislation as reflected by the appropriate contractual safeguards summed up below;
-
Subcontracting safeguards: Provisions for subcontractors should be provided for in any contract between the cloud provider and cloud clients. The contract should specify that sub-processors may only be commissioned on the basis of a consent that can be generally given by the controller in line with a clear duty for the processor to inform the controller of any intended changes in this regard with the controller retaining at all times the possibility to object to such changes or to terminate the contract. There should be a clear obligation of the cloud provider to name all the subcontractors commissioned. The cloud provider should sign a contract with each subcontractor reflecting the stipulations of his contract with the cloud client; the client should ensure that it has contractual recourse possibilities in case of contractual breaches by the providerâ&#x20AC;&#x2122;s sub-contractors (see 3.3.2);
-
Compliance with fundamental data protection principles: o Transparency (see 3.4.1.1): cloud providers should inform cloud clients about all (data protection) relevant aspects of their services during contract negotiations; in particular, clients should be informed about all subcontractors contributing to the provision of the respective cloud service and all locations in which data may be stored or processed by the cloud provider and/or its subcontractors (notably, if some or all locations are outside of the European Economic Area (EEA)); the client should be provided with meaningful information about technical and organisational measures implemented by the provider; the client should as a matter of good practice inform data subjects about the cloud provider and all subcontractors (if any) as well as about locations in which data may be stored or processed by the cloud provider and/or its subcontractors; o Purpose specification and limitation (3.4.1.2): the client should ensure compliance with purpose specification and limitation principles and ensure that no data is processed for further purposes by the provider or any subcontractors. Commitments in this respect should be captured in the appropriate contractual measures (including technical and organisational safeguards); o Data retention (3.4.1.3): the client is responsible for ensuring that personal data are erased (by the provider and any subcontractors) from wherever they are stored as soon as they are no longer necessary for the specific purposes; secure
529
20
erasure mechanisms (destruction, demagnetisation, overwriting) should be provided for contractually; -
Contractual safeguards (see 3.4.2, 3.4.3 and 3.5): o In general: the contract with the provider (and the ones to be stipulated between provider and sub-contractors) should afford sufficient guarantees in terms of technical security and organizational measures (under Article 17(2) of the directive) and should be in writing or in another equivalent form. The contract should detail the client’s instructions to the provider including subject and time frame of the service, objective and measurable service levels and the relevant penalties (financial or otherwise); it should specify the security measures to be complied with as a function of the risks of the processing and the nature of the data, in line with the requirements made below and subject to more stringent measures as envisaged under the client’s national law; if cloud providers aim at making use of standard contractual terms, they should ensure that these terms comply with data protection requirements (see 3.4.2); in particular technical and organisational measures that have been implemented by the provider should be specified in the respective terms; o Access to data: only authorised persons should have access to the data; a confidentiality clause should be included in the contract vis-à-vis the provider and its employees; o Disclosure of data to third parties: this should be regulated only via the contract, which should include an obligation for the provider to name all its sub-contractors – e.g. in a public digital register – and ensure access to information for the client of any changes in order to enable him to object to those changes or terminate the contract; the contract should also require the provider to notify any legally binding request for disclosure of the personal data by a law enforcement authority, unless such disclosure is otherwise prohibited; the client should warrant that the provider will reject any nonlegally binding requests for disclosure; o Obligations to co-operate: client should ensure that the provider is obliged to co-operate with regard to the client’s right to monitor processing operations, facilitate the exercise of data subjects’ rights to access/correct/erase their data, and (where applicable) notify the cloud client of any data breaches affecting client’s data; o Cross-border data transfers: The cloud client should verify if the cloud provider can guarantee lawfulness of cross-border data transfers and limit the transfers to countries chosen by the client, if possible. Transfers of data to non-adequate third countries require specific safeguards via the use of Safe Harbor arrangements, standard contractual clauses (SCC) or binding corporate rules (BCR) as appropriate; the use of SCC for processors (under Commission’s decision 2010/87/EC) requires certain adaptations to the cloud environment (to prevent having separate per-client contracts between a provider and its subprocessors) which might imply the need for prior authorisation from the competent DPA; a list of the locations in which the service may be provided should be included in the contract; o Logging and auditing of processing: the client should request logging of processing operations performed by the provider and its sub-contractors; the client should be empowered to audit such processing operations, however 530
21
third-party audits chosen by the controller and certification may also be acceptable providing full transparency is guaranteed (e.g. by providing for the possibility to obtain a copy of a third-party audit certificate or a copy of the audit report verifying certification); o Technical and organisational measures: these should be aimed at remedying the risks entailed by lack of control and lack of information that feature most prominently in the cloud computing environment. The former include measures aimed at ensuring availability, integrity, confidentiality, isolation, intervenability and portability as defined in the paper whilst the latter focus on transparency (see 3.4.3 for full details).
4.2 Third Party Data Protection Certifications •
Independent verification or certification by a reputable third party can be a credible means for cloud providers to demonstrate their compliance with their obligations as specified in this Opinion. Such certification would, as a minimum, indicate that data protection controls have been subject to audit or review against a recognised standard meeting the requirements set out in this Opinion by a reputable third party organisation.45 In the context of cloud computing, potential customers should look to see whether cloud services providers can provide a copy of this third party audit certificate or indeed a copy of the audit report verifying the certification including with respect to the requirements set out in this Opinion.
•
Individual audits of data hosted in a multi-party, virtualised server environment may be impractical technically and can in some instances serve to increase risks to those physical and logical network security controls in place. In such cases, a relevant third party audit chosen by the controller may be deemed to satisfy in lieu of an individual controller’s right to audit.
•
The adoption of privacy-specific standards and certifications is central to the establishment of a trustworthy relationship between cloud providers, controllers and data subjects.
•
These standards and certifications should address technical measures (such as localisation of data or encryption) as well as processes within cloud providers’ organisation that guarantee data protection (such as access control policies, access control or backups).
4.3 Recommendations: Future Developments The WP is fully aware that the complexities of cloud computing cannot be addressed completely via the safeguards and solutions outlined in this Opinion, which provide, however, a sound basis for securing the processing of personal data that EEA-based clients submit to cloud providers. This section is meant to highlight some issues that need to be tackled in the short to medium term to enhance the safeguards in place, assisting the cloud industry in terms of the issues highlighted whilst ensuring respect for the fundamental rights to privacy and data protection.
45
Such standards would include those issued by the International Standards Organisation, the International Auditing and Assurance Standards Board and the Auditing Standards Board of the American Institute of Certified Public Accountants in so far as these organisations provide standards that meet the requirements set out in this opinion. 531
22
-
Better balancing of responsibilities between controller and processor: The WP welcomes the provisions contained in Article 26 of the Commission’s proposals (Draft EU General Data Protection Regulation) that are aimed at making processors more accountable towards controllers by assisting them in ensuring compliance in particular with security and related obligations. Article 30 of the proposal introduces a legal obligation for the processor to implement appropriate technical and organisational measures. The draft proposals clarify that a processor failing to comply with the controller’s instructions qualifies as a controller and is subject to specific joint controllership rules. The Article 29 Working party considers that this proposal goes in the right direction to remedy the unbalance that is often a feature in the cloud computing environment, where the client (especially if it is a SME) may find it difficult to exercise the full control required by data protection legislation on how the provider delivers the requested services. Furthermore, in view of the asymmetric legal position of data subjects and small business users vis á vis big cloud computing providers, a more proactive role for consumer and business interest organisations is recommended in order to negotiate more balanced general terms and conditions of such companies.
-
Access to personal data for national security and law enforcement purposes: It is of the utmost importance to add to the future Regulation that controllers operating in the EU must be prohibited from disclosing personal data to a third country if so requested by a third country's judicial or administrative authority, unless this is expressly authorized by an international agreement or provided for by mutual legal assistance treaties or approved by a supervisory authority. Council Regulation (EC) No 2271/96 is an appropriate example of legal ground for this.46 The Working Party is concerned by this gap in the Commission proposal as it entails a considerable loss of legal certainty for the data subjects whose personal data are stored in data centres all over the world. For that reason, the Working Party would like to stress 47 the need to include in the Regulation the obligatory use of Mutual Legal Assistance Treaties (MLATs) in case of disclosures not authorised by Union or Member States law.
-
Special precautions by the public sector: A special caveat is to be added as to the need for a public body to first assess whether the communication, processing and storage of data outside national territory may expose the security and privacy of citizens and national security and economy to unacceptable risks – in particular if sensitive databases (e.g. census data) and services (e.g. health care.) are involved. 48 This special consideration should be given, at any rate, whenever sensitive data are processed in the Cloud context. From this standpoint, consideration might be given by national governments and European Union institutions to further investigate the concept of a European Governmental cloud as a supra national virtual space where a consistent and harmonized set of rules could be applied.
46
Council Regulation (EC) No 2271/96 of 22 November 1996 protecting against the effects of the extraterritorial application of legislation adopted by a third country, and actions based thereon or resulting therefrom, Official Journal L 309 , 29/11/1996 P. 0001 - 0006, URL: http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31996R2271:EN:HTML Cf. WP 191 - Opinion 01/2012 on the data protection reform proposals, page 23. In this respect, ENISA makes the following recommendation in its paper on Security & Resilience in Governmental Clouds (http://www.enisa.europa.eu/activities/risk-management/emerging-and-futurerisk/deliverables/security-and-resilience-in-governmental-clouds/at_download/fullReport): “In terms of architecture, for sensitive applications private and community clouds appear to be the solution that currently best fits the needs of public administrations since they offer the highest level of governance, control and visibility, even though when planning a private or community cloud, special regard should be given to the scale of the infrastructure.”
47 48
532
23
-
European Cloud Partnership: The Working Party supports the European Cloud Partnership (ECP) strategy presented by Mrs Kroes, Vice-president of the European Commission, in January 2012 at Davos. 49 This strategy involves public IT procurement to stimulate a European cloud market. Transferring personal data to a European cloud provider, sovereignly governed by European data protection law, could bring great data protection advantages to customers, in particular by fostering the adoption of common standards (especially in terms of interoperability and data portability) as well as legal certainty.
49
Neelie Kroes, Vice-President of the European Commission responsible for the Digital Agenda, Setting up the European Cloud Partnership World Economic Forum Davos, Switzerland, 26th January 2012, URL: http://europa.eu/rapid/pressReleasesAction.do?reference=SPEECH/1 23. 533
24
ANNEX a) Rollout models Private cloud50 describes an IT infrastructure that is dedicated to an individual organization; it is located at the organization’s premises or else its management is outsourced to a third party (usually via server hosting) that is under the controller’s strict authority. A private cloud can be compared to a conventional data centre – the difference being that technological arrangements are implemented to optimize use of the available resources and enhance those resources via small investments that are made in a stepwise fashion over time. Public cloud, conversely, is an infrastructure owned by a provider specializing in the supply of services that makes available – and therefore shares – his systems to/among users, businesses and/or public administrative bodies. The services can be accessed via the Internet, which entails transferring data processing operations and/or the data to the service provider’s systems. Therefore the service provider takes on a key role as regards to the effective protection of the data committed to his systems. Along with the data, a user is bound to transfer a major portion of his control over those data. Alongside “public” and “private” clouds, there are so-called “intermediate” or “hybrid” clouds where services provided by private infrastructures co-exist with services purchased from public clouds. Reference should also be made to the “community clouds”, where the IT infrastructure is shared by several organizations for the benefit of a specific user community. Flexibility and simplicity in configuring cloud systems allow their “elastic” dimensioning, i.e. these systems can be adjusted to the specific requirements in accordance with a usage-based approach. Users do not have to manage any IT systems, which are relied upon on the basis of outsourcing agreements and therefore are handled in full by the third party in whose cloud the data are stored. It is often the case that large-sized providers with complex infrastructures come into play; this is why the cloud might span several locations and users might ignore where exactly their data are being stored.
b) Service provision models Depending on user requirements, there are several cloud computing solutions available on the market; they can be grouped into three main categories or “service models”. These models usually apply to both private and public cloud solutions:
50
The NIST (National Institute of Standards and Technology) in the US, which has been working for some years on standardization of cloud-based technologies 50 , and whose definitions are also referred to in ENISA’s paper: Private cloud. The cloud infrastructure is operated solely for an organization. It may be managed by the organization or a third party and may exist on premise or off premise. It should be pointed out that a “private cloud” relies on at least certain technologies that are also typical of “public clouds” – including, in particular, virtualization technologies that foster the re-organisation (or overhaul) of the data processing architecture as explained above. Public cloud. The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services.
534
25
-
IaaS (Cloud Infrastructure as a Service): a provider leases a technological infrastructure, i.e. virtual remote servers the end-user can rely upon in accordance with mechanisms and arrangements such as to make it simple, effective as well as beneficial to replace the corporate IT systems at the company’s premises and/or use the leased infrastructure alongside the corporate systems. Such providers are usually specialized market players and can rely actually on a physical, complex infrastructure that often spans over several geographic areas.
-
SaaS (Cloud Software as a Service): a provider delivers, via the web, various application services and makes them available to end-users. These services are often meant to replace conventional applications to be installed by users on their local systems; accordingly, users are ultimately meant to outsource their data to the individual provider. This is the case, for instance, of typical web-based office applications such as spreadsheets, text processing tools, computerized registries and agendas, shared calendars, etc.; however, the services in question also include cloudbased email applications.
-
PaaS (Cloud Platform as a Service): a provider offers solutions for the advanced development and hosting of applications. These services are usually addressed to market players that use them to develop and host proprietary application-based solutions to meet in-house requirements and/or to provide services to third parties. Again, the services delivered by a PaaS provider makes it unnecessary for the user to rely on additional and/or specific hardware or software at internal level.
A full-fledged transition to a thoroughly public cloud system would appear not to be feasible in the short term on account of several reasons, in particular as regards large-sized entities like major companies or organizations that have to fulfil specific obligations – e.g. major banks, governmental bodies, large municipalities, etc. This can be accounted for mainly on two grounds: firstly, there is a momentum-like factor related to the investments required to achieve such transition; secondly, one has to take account of the especially valuable and/or sensitive information that is to be processed in the specific cases. Another factor militating in favour of the reliance on private clouds (at least in the cases mentioned above) has to do with the circumstance that no public cloud provider can often ensure a quality of service (as based on SLAs, Service Level Agreements) such as to keep pace with the critical nature of the service the controller is to provide – maybe because bandwidth and reliability of the Net are not enough or appropriate in a given area, or else with regard to specific user-provider connections. On the other hand, one can reasonably assume that private clouds may be leased or rented in some of the above cases (because this may prove more cost-effective), or else hybrid cloud models (including both public and private components) can be deployed. The relevant implications would have to be considered carefully in all cases. In the absence of internationally agreed standards, there is the risk of “do-it-yourself” cloud solutions, or else federated cloud solutions, which would entail increased lock-in dangers (as well as what have been termed “privacy monocultures”)51 and prevent full control over the data without ensuring interoperability. Both interoperability and data portability are indeed key factors for the development of cloud-based technology as well as in order to enable full exercise of the data protection rights vested in data subjects (such as access or rectification).
51
See the European Parliament’s study “Does it Help or Hinder? Promotion of Innovation on the Internet and Citizens’ Right to Privacy” published in December 2011. 535
26
From this standpoint, the current debate over cloud technologies provides a significant example of the tension existing between cost-oriented and rights-oriented approaches, as briefly outlined in Section 2 above. Whilst relying on private clouds may be feasible and indeed advisable in a data protection perspective by having regard to the specific circumstances of the processing, this may not be viable to organisations in the long run mainly in a cost-oriented perspective. A careful assessment of the interests at stake is necessary, as no one-size-fits-all solution can be currently pointed to in this area.
536
27
ARTICLE 29 DATA PROTECTION WORKING PARTY
0836-02/10/EN WP 179
Opinion 8/2010 on applicable law
Adopted on 16 December 2010
This Working Party was set up under Article 29 of Directive 95/46/EC. It is an independent European advisory body on data protection and privacy. Its tasks are described in Article 30 of Directive 95/46/EC and Article 15 of Directive 2002/58/EC. The secretariat is provided by Directorate C (Fundamental Rights and Union citizenship) of the European Commission, Directorate General Justice, B-1049 Brussels, Belgium, Office MO59 06/036. Website: http://ec.europa.eu/justice/policies/privacy/index_en.htm
537
Executive summary This opinion clarifies the scope of application of Directive 95/46/EC, and in particular of its Article 4, which determines which national data protection law(s) adopted pursuant to the Directive may be applicable to the processing of personal data. The opinion also highlights some areas for possible further improvement. Determining the application of EU law to the processing of personal data serves to clarify the scope of EU data protection law both in the EU/EEA and in a wider international context. A clear understanding of applicable law will help to ensure both legal certainty for controllers and a clear framework for individuals and other stakeholders. Furthermore, a correct understanding of the applicable law provisions should ensure that no lacunae or loopholes may be found in the high level of protection of personal data provided by Directive 95/46. With regard to Article 4(1)a, the reference to "an" establishment means that the applicability of a Member State's law will be triggered by the location of an establishment of the controller in that Member State, and other Member Statesâ&#x20AC;&#x2122; laws could be triggered by the location of other establishments of that controller in those Member States. To trigger the application of the national law, the notion of the "context of activities" of the establishment is decisive. It implies that the establishment of the controller is involved in activities implying the processing of personal data, taking into consideration its degree of involvement in the processing activities, the nature of the activities and the need to guarantee effective data protection. With regard to the "use of equipment" provision in Article 4(1)c, which may entail the application of the Directive to controllers not established in the EU/EEA territory, the opinion clarifies that it should apply in those cases where there is no establishment in the EU/EEA which would trigger the application of Article 4(1)a or where the processing is not carried out in the context of such an establishment. The opinion also notes that a broad interpretation of the notion of "equipment' justified by its expression by "means" in other EU languages - may in some cases result in European data protection law being applicable where the processing in question has no real connection with the EU/EEA. The opinion also provides guidance and examples with regard to: the other provisions of Article 4; the security requirements stemming from the law applicable pursuant to Article 17(3); the possibility for data protection authorities to use their powers to verify and intervene in a processing operation that is taking place on their territory even if the law applicable is the law of another Member State (Article 28(6). The opinion also suggests that the wording used in the Directive and the consistency between the different parts of Article 4 would benefit from further clarification as a part of the revision of the general data protection framework. In this perspective, simplifying the rules for determining applicable law would consist of a shift back to the country of origin principle: all establishments of a controller within the EU would then apply the same law - that of the main establishment - regardless of the territory in which they are located. However, this could only be acceptable if a comprehensive harmonisation of national legislation is reached, including harmonisation of security obligations. Additional criteria could apply when the controller is established outside the EU, with a view to ensuring that a sufficient connection exists with EU territory, while avoiding that the EU territory is used to conduct illegal data processing activities by controllers established in third countries. The following criteria may be developed in this view: the targeting of individuals, resulting in the application of EU data protection law when the activity involving the processing of personal data is targeted at individuals in the EU; the application of the equipment criterion in a residual and limited form, which would address borderline cases (data about non EU data subjects, controllers having no link with EU) where there is a relevant data-processing infrastructure in the EU. -2-
538
The Working Party on the Protection of Individuals with regard to the processing of personal data established by Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 (OJ L 281, 23.11.1995, p. 31), having regard to Articles 29 and 30 paragraphs 1(a) and 3 of that Directive, having regard to its Rules of Procedure, has adopted the following opinion:
-3-
539
I. II.
Introduction ................................................................................................................ 5 General observations and policy issues...................................................................... 7 II.1. Brief history: from Convention 108 to Directive 95/46/EC............................... 7 II.2. Role of concepts ................................................................................................. 7 II.2.a) Context and strategic importance ............................................................... 7 II.2.b) Scope of EU law and of national law within the EU/EEA......................... 8 II.2.c) Avoidance of lacunae and undue overlap................................................... 9 II.2.d) Applicable law and jurisdiction in the context of the Directive............... 10 III. Analysis of provisions .......................................................................................... 10 III.1. Controller established in one or more Member States (Article 4(1)a) ......... 10 a) “…an establishment of the controller on the territory of the Member State …” 11 b) “… processing is carried out in the context of the activities ...” .................. 12 III.2. Controller established where Member State's law applies by virtue of international public law (Article 4(1)b)........................................................................ 17 III.2.a) “… the controller is not established on the Member State’s territory …” 17 III.2.b) “…, but in a place where its national law applies by virtue of international public law…” ........................................................................................................... 18 III.3. Controller not established on Community territory but processing data through equipment located in a Member State (Article 4(1)c)..................................... 18 a) “… the controller is not established on Community territory …” ............... 19 b) “… and for purposes of processing personal data makes use of equipment, automated or otherwise situated on the territory of the Member State …”.......... 20 c) “…unless used only for purposes of transit through Community territory …” 23 d) “… must designate a representative established on the Member State’s territory …” (Article 4(2)).................................................................................... 23 III.4. Considerations on the practical consequences of the application of Article 4(1)c 23 III.5. Law applicable to security measures (Article 17(3)) ................................... 25 III.6. Competence and cooperation of supervisory authorities (Article 28(6)) ..... 25 III.6.a) “…supervisory authority is competent, whatever national law applicable…”............................................................................................................ 26 III.6.b) “…to exercise its powers on the territory of its own Member State…” .. 26 III.6.c) “…mutual cooperation to the extent necessary for performance of duties…” 27 IV. Conclusions .......................................................................................................... 28 IV.1. Clarifying current provisions........................................................................ 28 IV.2. Improving current provisions ....................................................................... 30 ANNEX ............................................................................................................................ 33
-4-
540
I.
Introduction
Defining the law applicable to the processing of personal data under Directive 95/46/EC (‘Directive’ or ‘Directive 95/46’) is a key issue for a number of reasons. Provisions on applicable law are crucial in determining the external scope of EU data protection law, in other words, to determine the extent to which EU data protection law is applicable to processing of personal data taking place wholly or partly outside the EU/EEA, but still having a relevant connection with the EU/EEA territory. However, rules on applicable law also determine the scope of data protection law within the EU/EEA, so as to avoid possible conflicts between and overlapping of the national laws of the EU/EEA Member States implementing the Directive1. Furthermore, a correct understanding of the applicable law provisions should ensure that no lacunae or loopholes arise in the high level of protection of personal data provided by Directive 95/46. The Directive includes a number of provisions addressing applicable law issues, in particular Article 4, Article 17 and Article 28. These provisions define the national data protection law which applies pursuant to the Directive, and the authority which will be responsible for the enforcement of that law. It is important to bear in mind that there is an interaction between substantive law and jurisdiction. This is considered in further detail below. It has been suggested that the implementation and interpretation of the Directive’s provisions on applicable law are far from uniform throughout the European Union. The Commission’s ‘First report on the implementation of the Data Protection Directive’ highlighted that the implementation of Article 4 of the Directive was "deficient in several cases, with the result that the kind of conflicts of law this Article seeks to avoid could arise"2. According to the technical annex to the report, which presents a detailed analysis of several national provisions, such a deficient transposition could be partly explained by the complexity of the provision itself. Similarly, a study sponsored by the European Commission3 highlights the ambiguity and divergent implementation of the applicable law rules in the Directive and recommends that "better, clearer and unambiguous rules are desperately needed on applicable law". More recently, the Commission Communication “A comprehensive approach on personal data protection in the European Union” 4 mentions that “The Commission will examine how to revise and clarify the existing provisions on applicable law, including the current determining criteria, in order to improve legal certainty, clarify Member States' responsibility for applying data protection rules and ultimately provide for the same 1
2
3
4
Directive 95/46/EC also applies to the EFTA countries Norway, Iceland and Liechtenstein under the EEA agreement (cf. Decision of the EEA Joint Committee No 83/1999 of 25 June 1999 amending Protocol 37 and Annex XI (Telecommunication services) to the EEA Agreement; OJ L 296/41, of 23.11.2000). First report on the implementation of the Data Protection Directive (95/46/EC), May 2003, p. 17. The report is available at http://ec.europa.eu/justice/policies/privacy/lawreport/report_en.htm "Comparative study on different approaches to new privacy challenges, in particular in the light of technological developments", January 2010, available at http://ec.europa.eu/justice/policies/privacy/studies/index_en.htm. COM (2010) 609 final of 4.11.2010. -5-
541
degree of protection of EU data subjects, regardless of the geographic location of the data controllerâ&#x20AC;?. The complexity of applicable law issues is also growing due to increased globalisation and the development of new technologies: companies are increasingly operating in different jurisdictions, providing services and assistance around-the-clock; the internet makes it much easier to provide services from a distance and to collect and share personal data in a virtual environment; cloud computing makes it difficult to determine the location of personal data and of the equipment being used at any given time. It is thus crucial that the precise meaning of the provisions of the Directive dealing with applicable law are sufficiently clear to all involved in the implementation of the Directive as well as in the day-to-day application of national data protection laws in both the public and the private sector. Therefore, the Working Party has decided to contribute to the clarification of some key provisions of the Directive and to deal with the concept of applicable law, much as it has done already with regard to the concept of personal data and the concepts of "controller" and "processor"5. In this opinion, the Working Party will also refer to the other opinions in which it has dealt with the issue of applicable law where it arises in relation to the specific topics covered by those opinions6. The final objective of the Working Party is to provide legal certainty in the application of EU data protection law. This entails, on the one hand, that data subjects are aware of which rules apply to protect their personal data, and on the other hand, that businesses as well as other private and public bodies know which data protection rules regulate their data processing. Clarifying the concept of applicable law is of great importance, independently of possible amendments to the current provisions of the Directive in the future. Current provisions will remain valid until amended, and to the extent that they are not amended. Therefore clarification of the applicable law provisions will help to ensure better compliance with the Directive pending any amendment of the legislation. In addition, in preparing this opinion the Working Party has been able to draw on the experience of applying the current provisions with a view to providing guidance to the legislator to assist in any future revision of the Directive. Finally, the provisions on determining applicable law with regard to data protection are designed to govern the application of the Directive within its own scope as defined in Article 3. As such, they will often interact with other areas of law without influencing them beyond its scope.7 5
6
7
Opinion 4/2007 on the concept of personal data (WP 136); Opinion 1/2010 on the concepts of "controller" and "processor" (WP 169). All opinions are available at: http://ec.europa.eu/justice/policies/privacy/workinggroup/index_en.htm In particular, Working document on determining the international application of EU data protection law to personal data processing on the Internet by non-EU based web sites (WP 56), Opinion 10/2006 on the processing of personal data by the Society for Worldwide Interbank Financial Telecommunication (SWIFT) (WP 128) and Opinion 1/2008 on data protection issues related to search engines (WP 148). Although the Directive contains provisions on liability (Article 23) and sanctions (Article 24), general principles of civil or criminal law are in principle not affected, as mentioned in Recital 21 of the Directive. They would be affected only as far as necessary to foresee sanctions in case of violation of -6-
542
II.
General observations and policy issues
II.1.
Brief history: from Convention 108 to Directive 95/46/EC In 1981, the authors of Convention 108 drawn up under the auspices of the Council of Europe identified the risks posed by conflict of law issues, or the legal gap, that could result from the application of different national laws. However, that Convention did not include specific rules to address these problems: the fact that the Convention would provide for a "common core of substantive law" was considered to be the main guarantee that, even if different regulations subsist, the principles to be applied at the end would be the same, which would avoid differences in terms of level of protection. The need for criteria to determine applicable law was addressed by the European Commission when preparing the Directive on data protection. In its initial proposal8, the Commission identified the location of the data file as a primary determining factor, and the controllers' residence as the secondary determining factor when the file is located in a third country. In the course of the discussion in European Parliament and in the Council of the EU, there was a shift from the criterion of the location of the file to the criterion of the establishment of the controller. The location of the means was identified as the second criterion when the controller is not established in the EU. The Council supplemented these criteria and provided further indications with regard to the notion of establishment. The Commission's amended proposal9 specified that the processing should take place "in the context of the activities of an establishment" of the controller, and took into account the possibility that the controller may have several establishments in different Member States. One major change concerned the fact that the main criterion to determine applicable law was not the place where the controller has its main establishment but where there was an establishment of the controller. The consequences of these amendments, in terms of distributive rather than uniform application of national law in case of multiple establishments, will be developed below.
II.2.
Role of concepts
II.2.a) Context and strategic importance Determining the application of EU law to the processing of personal data, as said before, serves to clarify the scope of EU data protection law both in the EU/EEA and in a wider international context. A clear understanding of applicable law will
8
9
data protection principles. In practice, national implementation of the Directive has led to different scenarios, including or not criminal sanctions. To mention another example, although the Directive contains provisions on the need for consent - see Article 2(h), Article 7(a) and Article 8(2)(a) - or the relevance of contractual obligations - see Article 7 (b) - it does not enter into contract law (e.g. conditions for concluding a contract, law applicable) or other aspects of civil law beyond its own provisions. COM (1990) 314 - 2 of 18.07.1990, Proposal for a European Parliament and Council Directive concerning the protection of individuals in relation to the processing of personal data. COM (1992) 422 final of 15.10.1992. -7-
543
help to ensure both legal certainty for controllers and a clear framework for individuals concerned and other stakeholders. The identification of applicable law is closely connected to the identification of the controller10 and its establishment(s): the main consequence of this link is the reaffirmation of the responsibilities of the controller, and its representative if the controller is established in a third country. As it will be elaborated below, this does not mean that there will always be one applicable law, especially if the controller has several establishments: the location of those establishments and the nature of their activities will also be decisive. But the clear connection between the applicable law and the controller can be a guarantee of effectiveness and enforceability, especially in a context in which it can be difficult, or sometimes impossible, to locate a file (as may be the case for cloud computing). Clear guidelines as to applicable law rules should help address new developments: technological (internet; network based files/cloud computing) and commercial (multinational companies). II.2.b) Scope of EU law and of national law within the EU/EEA The main criteria in determining the applicable law are the location of the establishment of the controller, and the location of the means or equipment11 being used when the controller is established outside the EEA. This means that neither the nationality or place of habitual residence of data subjects, nor the physical location of the personal data, are decisive for this purpose12. This induces a broad scope of application, with legal implications extending beyond the EEA territory: the Directive â&#x20AC;&#x201C; and national laws of implementation â&#x20AC;&#x201C; apply to the processing of personal data outside the EEA (where carried out in the context of activities of an establishment of the controller in the EEA), as well as to controllers established outside the EEA (when they use equipment in the EEA). As a consequence, the provisions of the Directive can be applicable to services with an international dimension such as search engines, social networks and cloud computing. These examples are developed below in the document. Where personal data is processed by a data controller (X) whose only establishment is located in Member State A, the national law of Member State A will be the law applicable to the processing, regardless of where it is carried out.
10 11
12
See Opinion 1/2010 on the concepts of "controller" and "processor" (WP 169). As explained below in III.2.b, the notion of "equipment" has been expressed in other EU languages by "means". This supports a broad interpretation of the notion of equipment and explains why the two notions are used in this document. See in the same line Directive 2000/31/EC on certain legal aspects of information society services, in particular electronic commerce, in the Internal Market. An additional relevant factor is the location of the processor with regard to the law applicable to security measures (Article 17). However, this criterion is not decisive in itself and has to be applied in connection to the main criterion of the establishment of the controller. -8-
544
Where X also has an establishment (Y) in Member State B, the national law applicable to the processing by Y will be the national law of Member State B, provided that the processing is carried out in the context of the activities of Y. If the processing by Y is carried out in the context of the activities of the establishment of X in Member State A, the law applicable to the processing will be the law of Member State A. Where personal data is processed by a data controller that is not established in any Member State, the processing will fall within the scope of the national law of any Member State in which equipment (or means) used by the data controller to process the data is located. Examples of these different scenarios will be considered in the course of this opinion.
The purpose of this broad scope of application is primarily to ensure that individuals are not deprived of the protection to which they are entitled under the Directive, and, at the same time, to prevent circumvention of the law. The Directive provides for criteria for determining both: (i) whether European law â&#x20AC;&#x201C; either jointly with the law of a third country or not â&#x20AC;&#x201C; applies to a particular personal data processing activity; and (ii) where European law applies to the processing, which Member Statesâ&#x20AC;&#x2122; national law applies to the processing. It should also be noted that some processing activities within the EU are outside the scope of the Directive, but they may trigger the application of other EU legal instruments, such as the Framework Decision 2008/977/JHA on data protection in the framework of police and judicial cooperation in criminal matters13, or Regulation 45/2001 on personal data processed by Community institutions and bodies14, or other instruments on specific EU bodies or information systems (e.g. Europol, Eurojust, SIS, CIS, etc)15 II.2.c) Avoidance of lacunae and undue overlap The purpose of clear criteria for determining the applicable law is to avoid both circumvention of Member States' national rules, and overlap of those rules. Whether one or several laws apply to the processing will depend on the number and the activities of the establishment(s) of the controller: o
If the controller has one establishment, there will be one law for the whole EU/EEA, depending on the location of this establishment.16
13
Council Framework Decision 2008/977/JHA of 27.11.2008 on the protection of personal data processed in the framework of police and judicial cooperation in criminal matters (OJ L 350, 30.12.2008, p. 60). Regulation (EC) No 45/2001 of the European Parliament and of the Council of 18 December 2000 on the protection of individuals with regard to the processing of personal data by the Community institutions and bodies and on the free movement of such data (OJ L 8, 12.1.2001, p. 1). Europol: Council Decision 2009/371/JHA, OJ L 121, 15.5.2009, p. 37); Eurojust: Council Decision 2002/187/JHA, OJ L 63, 6.3.2002, p. 1, amended by Council Decision 2009/426/JHA, OJ L 138, 4.6.2009, p. 14. Except with regard to security measures, which will depend on the location of a possible processor, as provided for in Article 17(3) of the Directive. -9-
14
15
16
545
o
If there are several establishments: the application of national legislation will be distributed depending on the activities of each establishment.
Application of the criteria should prevent the simultaneous application of more national laws to the same processing activity. II.2.d) Applicable law and jurisdiction in the context of the Directive In the area of data protection, it is particularly important to distinguish the concept of applicable law (which determines the legal regime applicable to a certain matter) from the concept of jurisdiction (which usually determines the ability of a national court to decide a case or enforce a judgment or order). The applicable law and the jurisdiction in relation to any given processing may not always be the same. The external scope of EU law is an expression of its capacity to lay down rules in order to protect fundamental interests within its jurisdiction. The provisions of the Directive also determine the scope of applicability of the national laws of the Member States, but they do not affect the jurisdiction of national courts to decide relevant cases before them. The provisions of the Directive do, however, refer to the territorial scope of the competence of the supervisory authorities that may apply and enforce the applicable law. Although in most cases these two concepts â&#x20AC;&#x201C; applicable law and competence of supervisory authorities â&#x20AC;&#x201C; tend to coincide, usually resulting in Member State A's law being applied by Member State A's authorities, the Directive explicitly foresees the possibility of different arrangements. Article 28(6) implies that the national data protection authorities should be able to exercise their powers when the data protection law of another Member State applies to the processing of personal data carried out within their jurisdiction. The practical consequences of this issue will be further examined in a future opinion of the Working Party. Such situations result in the handling of cross-border cases, and highlight the need for cooperation between DPAs, taking into account the enforcement powers of each DPA involved. This also illustrates the need for national law to properly implement the relevant provisions of the Directive, as this may be decisive for an effective cross-border cooperation and enforcement. III.
Analysis of provisions
The key provision on applicable law is Article 4, which determines which national data protection law(s) adopted pursuant to the Directive may be applicable to the processing of personal data. III.1.
Controller established in one or more Member States (Article 4(1)a)
The first situation addressed by Article 4(1) is where the controller has one or more establishments within the EU territory. In this case, Article 4(1)a provides that a Member State shall apply its national data protection law where "[...] the processing is carried out in the context of the activities of an establishment of the controller on the territory of the Member State; when the same controller is established on the territory of several Member States, he must take the necessary measures to ensure that each of these establishments complies with the obligations laid down by the national law applicable". - 10 -
546
It is useful to recall that the concept of ‘controller’ is defined in Article 2(d) of the Directive. This definition will not be analysed in this opinion, since it has already been clarified by the Article 29 Working Party in its Opinion on the concepts of "controller" and "processor"17. It is furthermore important to emphasise that an establishment need not have a legal personality, and also that the notion of establishment has flexible connections with the notion of control. A controller can have several establishments, joint controllers can concentrate activities within one establishment or different establishments. The decisive element to qualify an establishment under the Directive is the effective and real exercise of activities in the context of which personal data are processed. a) “…an establishment of the controller on the territory of the Member State …” The notion of establishment is not defined in the Directive. The preamble of the Directive indicates however that "establishment on the territory of a Member State implies the effective and real exercise of activity through stable arrangements (and that) the legal form of (..) an establishment, whether simply branch or a subsidiary with a legal personality, is not the determining factor in this respect" (recital 19). Concerning the freedom of establishment under Article 50 TFEU (former Article 43 TEC) the European Court of Justice (ECJ) has considered that a stable establishment requires that "both human and technical resources necessary for the provision of particular services are permanently available". 18 The strong emphasis put in the preamble of the Directive on "effective and real exercise of activity through stable arrangements" clearly echoes the "stable establishment" referred to by the Court of Justice at the time of the adoption of the Directive. Although it is not clear whether this and subsequent interpretations by the ECJ as regards the freedom of establishment under Article 50 TFEU could be fully applied to the situations covered by Article 4 of the Data Protection Directive, the interpretation of the Court in those cases can provide useful guidance when analysing the wording of the Directive. This interpretation is used in the following examples: - Where "effective and real exercise of activity" takes place, for example in an attorney's office, through "stable arrangements", the office would qualify as an establishment.
17 18
Opinion 1/2010 on the concepts of "controller" and "processor" (WP 169). ECJ judgment of 4 July 1985, Bergholz, (Case 168/84, ECR [1985] p. 2251, paragraph 14) and judgment of 7 May 1998, Lease Plan Luxembourg / Belgische Staat (C-390/96, ECR [1998] p. I2553). In the latter case the issue was to determine whether a company server, situated in a country different from the country of the service provider, could be considered a stable establishment. The purpose was to identify in which country VAT had to be paid. The judge refused to consider computer means as a virtual establishment (returning with this interpretation to a more "classical" notion of ‘establishment’, different from the one adopted in previous judgement of 17 July 1997, ARO Lease / Inspecteur der Belastingdienst Grote Ondernemingen te Amsterdam (C-190/95, ECR 1997 p. I-4383). - 11 -
547
- A server or a computer is not likely to qualify as an establishment as it is simply a technical facility or instrument for the processing of information19. - A one-person office would qualify as long as the office does more than simply represent a controller established elsewhere, and is actively involved in the activities in the context of which the processing of personal data takes place. - In any case, the form of the office is not decisive: even a simple agent may be considered as a relevant establishment if his presence in the Member State presents sufficient stability. Example No. 1: publication for travellers A company established in Member State A, in order to create a publication for travellers, is collecting data concerning the services provided by petrol stations in Member State B. The data are collected by an employee who, travelling throughout B, collects and sends photos and comments to his employer in A. In this case, data are collected in B (without an “establishment” there) and are processed in the context of the activities of the establishment in A: the applicable law is the law of A. Article 4(1)a, referring to an establishment of the controller on the territory of the Member State, raises issues – other than the concept of establishment – that require clarification. First of all, the reference to "an" establishment means that the applicability of a Member State's law will be triggered by the location of an establishment of the controller in that Member State, and other Member States’ laws could be triggered by the location of other establishments of that controller in those Member States. Even if the controller has its main establishment in a third country, just having one of his establishments in a Member State could trigger the applicability of the law of that country, provided that the other conditions of Article 4(1)a are fulfilled (see infra sub b). This is also confirmed by the second part of the provision, which explicitly foresees that where the same controller is established on the territory of several Member States, he should ensure that each of the establishments complies with the relevant applicable law. b) “… processing is carried out in the context of the activities ...” The Directive links the applicability of a Member State's data protection law to a processing of personal data. The concept of ‘processing’ has already been incidentally addressed by the Working Party in other opinions, which highlighted that different operations or sets of operations upon personal data may be carried out simultaneously or in different stages.20 In the context of determining applicable law, this may well mean that different applicable laws may be triggered by different stages of processing personal data. While the multiplication of applicable laws is therefore a serious risk, consideration should be given to the possibility that links at a macro level between the different processing activities could lead alternatively to the application of one single national law. 19 20
Whether they qualify otherwise, for instance as ‘equipment’, will be discussed later on in the text. See, e.g. Opinion 1/2010 on the concepts of "controller" and "processor" (WP 169). - 12 -
548
To determine whether one or several laws apply to the different stages of the processing, it is important to have in mind the global picture of the processing activities: a set of operations carried out in a number of different Member States but all intended to serve a single purpose might well result in the application of a single national law. In such circumstances, the notion of "context of activities" â&#x20AC;&#x201C; and not the location of data â&#x20AC;&#x201C; is a determining factor in identifying the applicable law. The notion of "context of activities" does not imply that the applicable law is the law of the Member State where the controller is established, but where an establishment of the controller is involved in activities relating to data processing. Consideration of different scenarios might help to clarify what is meant by the notion of "context of activities" and its influence in determining the law applicable to different processing activities in a number of different countries. a. Where a controller has an establishment in Austria and processes personal data in Austria in the context of the activities of that establishment, the applicable law would obviously be the law of Austria - that is, where the establishment is situated. b. In the second scenario, the controller has an establishment in Austria, in the context of activities of which he processes personal data collected via its website. The website is accessible to users in various countries. The data protection law applicable will still be the law of Austria - that is, where the establishment is situated independently of the location of users and of the data. c. In the third scenario, the controller is established in Austria and outsources the processing to a processor in Germany. The processing in Germany is in the context of the activities of the controller in Austria. That is to say, the processing is carried out for the business purposes of, and on instructions from the Austrian establishment. Austrian law will be applicable to the processing carried out by the processor in Germany. In addition, the processor will be subject to the requirements of German law in relation to the security measures it is obliged to put in place in connection with the processing21. Such arrangements would require coordinated supervision by the German and Austrian DPAs. d. In the fourth scenario, the controller established in Austria opens a representation office in Italy, which organizes all the Italian contents of the website and handles Italian users' requests. The data processing activities carried out by the Italian office are conducted in the context of the Italian establishment, so that Italian law would apply to those activities.
21
Pursuant to Article 17(3) of Directive 95/46/EC the processor is bound by the obligations as defined by the law of the Member State in which the processor is established with regard to security measures. In case of conflict between the substantive security obligations of the law of the processor and the law of the controller, the lex loci (law of the processor) prevails. While the ultimate liability remains with the controller, the processor has to prove that he took all necessary steps according to his contract with the controller as well as the security obligations as defined by the law of the Member State in which the processor is established (see more under III.5). - 13 -
549
Conclusions on the law applicable can only be drawn on the basis of a precise understanding of the notion "in the context of the activities". The following considerations should be taken into account to conduct this analysis: The degree of involvement of the establishment(s) in the activities in the context of which personal data are processed is crucial. Here the issue is to check "who is doing what", i.e. which activities are being carried out by which establishment, so as to be able to determine whether the establishment is relevant in order to trigger the application of national data protection law. Where an establishment is processing personal data in the context of its own activities, the applicable law will be the law of the Member State in which that establishment is located. Where the establishment processes personal data in the context of the activities of another establishment, the applicable law will be that of the Member State in which the other establishment is located. The nature of the activities of the establishments is a secondary element, but it will help in identifying the law applicable to each establishment: the question whether an activity involves data processing or not, and which processing is taking place in the context of which activity largely depends on the nature of these activities. Alternatively, the fact that different establishments may be involved in totally different activities, in the context of which personal data are being processed, will have an impact on the law applicable. Example 4 develops an illustration of these considerations. The overall objective of the Directive should also be taken into consideration, as it aims at guaranteeing an effective protection to individuals, in a simple, workable and predictable way.
Example No. 2: Transfer of personal data in connection with factoring An Italian utility company transfers information about its debtors to a French investment bank with a view to factoring the debts. The debts have arisen in relation to unpaid electricity bills. This transfer of debt information involves the transfer of customersâ&#x20AC;&#x2122; personal data to the French investment bank, specifically, to the branch office in Italy (that is to say, the establishment of the French bank in Italy). The French investment bank is a data controller in respect of the processing operations that constitute the transfer and its Italian branch performs management and levying of the debt on its behalf. The data are processed by the data controller both in France and at the Italian branch office. The French data controller provides all Italian customers with an information notice on the above operation by way of the Italian branch. The Italian branch is an establishment for the purposes of the Directive, and its activities consisting of processing personal data to inform customers of the arrangements will have to comply with Italian data protection legislation. Security measures within the Italian branch will also have to comply with the conditions of Italian data protection legislation, while the French controller will have to comply in parallel with French security obligations for data processed within its establishment in France. Data subjects, i.e. the debtors, may apply to the office of the Italian branch in order to exercise their data protection rights such as access, rectification, and erasure under Italian law.
- 14 -
550
A functional approach should be taken in the analysis of these criteria: more than the theoretical evaluation made by the parties about the law applicable, it is their practical behaviour and interaction which should be the determining factors: what is the true role of each establishment, and which activity is taking place in the context of which establishment? Attention should be paid to the degree of involvement of each establishment, in relation to the activities in the context of which personal data are processed. An understanding of the notion of "in the context of" is therefore also useful in complex cases to split different activities carried out by different EU establishments of the same company. Example No. 3: Collection of clients' data by shops A chain of "prĂŞt Ă porter" shops has its head office in Spain, and shops all over the EU. The collection of data relating to clients takes place in every shop, but the data are transferred to the Spanish head office where some activities related to the processing of data take place (analysis of clients' profiles, service to customers, targeted advertising). Activities such as direct marketing of Europe-wide customers are directed exclusively by the head office in Spain. Such activities would qualify as taking place in the context of the activities of the Spanish establishment. Spanish law would therefore be applicable to these processing activities. However, the individual shops remain responsible for the aspects of the processing of their customers' personal data which take place in the context of the shops' activities (for example, the collection of customers' personal information). To the extent that processing is carried out in the context of each shop's activities, such processing is subject to the law of the country where the shop in question is established. A direct practical consequence of this analysis is that each shop must take necessary steps to inform individuals about the conditions of collection and further processing of their data under its own national legislation. Clients may go directly to the DPA of their own country in case of complaint. If the complaint relates to direct marketing actions in the context of the activities of the Spanish head office, the local DPA would have to refer the case to the Spanish DPA.
It is thus possible that a single establishment may be involved in a number of different types of activities, and that different national laws may be applicable to the processing of data in the context of these different activities. In order to provide for a predictable and workable approach where there is a possibility of multiple laws applying to the various activities of a single establishment, a functional approach should be used, including consideration of the broader legal context. Example No. 4: Human resources centralised database Situations where the same database can be subject to different applicable laws do increasingly happen in practice. This is often the case in the field of human resources where subsidiaries/establishments in different countries centralise employee data in a single database. While this traditionally happens for reasons of economies of scale, it should not have an impact on the responsibilities of each establishment under local law. This is the case not only from a data protection perspective, but also in the context of - 15 -
551
labour law and public order provisions. If, for instance, data of the employees of an Irish subsidiary (which qualifies as establishment) were transferred to a centralised database in the UK, where data of employees of the UK subsidiary/establishment are also stored, two different data protection laws (Irish and UK) would apply. The application of two different national laws is not simply a result of the data originating in two different Member States, but instead arises as the processing of the Irish employee data by the UK establishment takes place in the context of the activities of the Irish establishment in its capacity of employer. This example illustrates the fact that it is not the place where data are sent or located which determines which national law will apply, the key factors are the nature and place of normal activities which determine the â&#x20AC;&#x153;contextâ&#x20AC;? in which the processing is carried out: human resource or client data are thus normally subject to the data protection law of the country where the activity - in the context of which the data are being processed - takes place. It also confirms that there is no direct correlation between applicable national law and jurisdiction, as national law may apply outside national jurisdiction. To sum up, the criteria used to determine applicable law have an impact at different levels: o
First, they help determining whether EU data protection law is applicable to the processing at all;
o
Second, where EU data protection law applies, the criteria will determine both (a) which Member State data protection law is applicable, and (b) in case of multiple establishments in different Member States, which Member State's data protection law will apply to which processing activity;
o
Third, the criteria will assist where there is an extra-European dimension to the processing activities â&#x20AC;&#x201C; as in the following illustration in which the controller is established outside the EEA.
Example No. 5: Internet service provider An internet service provider (the data controller) has its headquarters outside the EU, e.g. in Japan. It has commercial offices in most Member States of the EU, and an office in Ireland dealing with issues connected with the processing of personal data, including in particular IT support. The controller is developing a data centre in Hungary, with employees and servers devoted to the processing and storage of data relating to the users of its services. The controller in Japan also has other establishments in various Member States of the EU, with different activities: -
the data centre in Hungary is only involved in technical maintenance;
-
the commercial offices of the ISP organise general advertising campaigns;
- 16 -
552
-
the office in Ireland is the only establishment within the EU, with activities in the context of which personal data are effectively being processed (notwithstanding the input from the Japanese headquarters).
The activities of the Irish office trigger the application of EU data protection law: personal data are processed in the context of the Irish office's activities, therefore such processing is subject to EU data protection legislation. The law applicable to processing carried out in the context of the Irish office's activities is Irish data protection legislation, regardless of whether the processing takes place in Portugal, Italy or any other Member State. This means that, in this hypothesis, the data centre in Hungary would have to comply with Irish data protection law with regard to the processing of the personal data of the users of the service provider. This would be without prejudice however to the application of Hungarian law to a distinct processing of personal data by the Hungarian data centre, in relation to its own activities – for instance processing of personal data concerning the employees of the data centre. For the commercial offices based in other Member States, if their activity is limited to general non-user-targeted advertising campaigns which do not involve the processing of users' personal data, they are not subject to EU data protection laws. However, if they decide to conduct a processing in the context of their activities involving the personal data of individuals in the country where they are established (such as sending targeted advertisements to users and possible future users for their own business purposes), they will have to comply with the local data protection legislation. If no connection can be established between the processing of data and the Irish establishment (IT support is very limited and there is no involvement in the processing of personal data), other provisions of the Directive could still trigger the application of data protection principles, for example if the controller uses equipment in the EU. This is considered in chapter III.3 below.
III.2. Controller established where Member State's law applies by virtue of international public law (Article 4(1)b) Article 4(1)b addresses the less common case in which a Member State's data protection law applies where "the controller is not established on the Member State's territory, but in a place where its national law applies by virtue of international public law". III.2.a) “… the controller is not established on the Member State’s territory …” The first condition should be construed as meaning, for reasons of consistency within Article 4(1) that the controller does not have on the Member State's territory any establishment that would trigger the applicability of Article 4(1)a (see also below, III.3.a). In other words, in the absence of a relevant establishment in the EU, no national data protection law could be identified pursuant to Article 4(1)a.
- 17 -
553
III.2.b) “…, but in a place where its national law applies by virtue of international public law…” However, external criteria stemming from international public law may determine in specific situations the extension of the application of a national data protection law beyond the national boundaries. This may be the case where international public law or international agreements determine the law applicable in an embassy or a consulate, or the law applicable to a ship or airplane. In those cases where the controller is established in one of these specific places, the applicable national data protection law will be determined by international law. It is however important to also highlight that national data protection law may not apply to foreign missions or international organisations on EU territory to the extent in which they have a special status under international law, either in general or via a headquarter agreement: such exemption would prevent the application of Article 4(1)a to the mission or international organisation. Example No. 6: Foreign embassies An EU Member State’s embassy in Canada is subject to the national data protection law of that Member State, and not to the Canadian data protection law. Any country’s embassy in the Netherlands is not subject to the Dutch data protection law as any embassy has a special status under international law. A data security breach occurring in the context of the activities of that embassy would therefore not trigger the application of the Dutch data protection law and consequent enforcement measures. A non-governmental organisation with offices in EU Member States would not, in principle, benefit from a similar exemption, unless explicitly provided for by an international agreement with the host country.
III.3. Controller not established on Community territory but processing data through equipment located in a Member State (Article 4(1)c) Article 4(1)c strives to ensure the right to the protection of personal data provided by the EU Directive even where the controller is not established in EU/EEA territory but where the processing of personal data has a clear connection with such territory, as indicated in Recital 2022. Article 4(1)c establishes the application of a Member State's law where "the controller is not established on Community territory and, for purposes of processing personal data makes use of equipment, automated or otherwise, situated on the territory of the said Member State, unless such equipment is used only for purposes of transit through the territory of the Community".
22
Recital 20: "Whereas the fact that the processing of data is carried out by a person established in a third country must not stand in the way of the protection of individuals provided for in this Directive; whereas in these cases, the processing should be governed by the law of the Member State in which the means used are located, and there should be guarantees to ensure that the rights and obligations provided for in this Directive are respected in practice" - 18 -
554
This provision is especially relevant in the light of the development of new technologies and in particular of the internet, which facilitate the collection and processing of personal data at a distance and irrespective of any physical presence of the controller in EU/EEA territory23. a) “… the controller is not established on Community territory …” This provision becomes relevant when the controller has no presence in EU/EEA territory which may be considered as an establishment for the purposes of Article 4(1)a of the Directive, as analyzed above. It is important to clarify the interpretation of the wording "is not established". It should be clear that Article 4(1)c applies only when Article 4(1)a is not applicable: i.e. when the controller does not have any establishment that is relevant for the activities in question in the EU/EEA. Therefore, the fact that a controller established outside the EU/EEA makes use of equipment in Member State A where it has no establishment would not trigger the applicability of that Member State's law, if the controller already has an establishment in Member State B and is processing the personal data in the context of the activities of that establishment. Both the processing in Member State A (where equipment is being used) and in Member State B (where there is the establishment) will be subject to Member State B law. This was made clear by the Working Party in its opinion on data protection issues related to search engines24. On the other hand, Article 4(1)c will apply where the controller has an “irrelevant” establishment in the EU. That is to say, the controller has establishments in the EU but their activities are unrelated to the processing of personal data. Such establishments would not trigger the application of Article 4(1)a. This means that, since there should be no lacunae or inconsistency in the application of the provisions of the Directive, the application of the "equipment" criterion need not be prevented by an irrelevant establishment: it could be prevented by the existence of an establishment only to the extent that this establishment processed personal data in the context of the same activities. A corollary of this interpretation is that a company with diverse activities could trigger the application of both Articles 4(1)a and 4(1)c if it used equipment and had establishments in different contexts. In other words, a controller established outside the EU/EEA and using equipment in the EU would have to comply with Article 4(1)c even if it had an establishment in the EU, as long as this establishment processed personal data in the context of other activities. This establishment would trigger the application of Article 4(1)a for these specific activities. An opportunity to better clarify the scope of Article 4(1)c and what is meant by "the controller is not established on Community territory" may arise during the revision of the data protection framework, in line with the spirit of the Directive and the wording of its Recital 20. The preamble of the Directive clearly states that the objective is to protect individuals and avoid gaps in the application of the principles. For this reason the 23
24
See the Working Party’s Working document on determining the international application of EU data protection law to personal data processing on the Internet by non-EU based web sites (WP 56). Article 29 Working Party Opinion 1/2008 on data protection issues related to search engines (WP 148) - 19 -
555
Working Party considers that Article 4(1)c should apply in those cases where there is no establishment in the EU/EEA which would trigger the application of Article 4(1)a or where the processing is not carried out in the context of the activities of such an establishment. b) “… and for purposes of processing personal data makes use of equipment, automated or otherwise situated on the territory of the Member State …” The crucial element which determines the applicability of this Article and thus of a Member State's data protection law is the use of equipment situated on the territory of the Member State. The Working Party has already clarified that the concept of "making use" presupposes two elements: some kind of activity of the controller and the clear intention of the controller to process personal data25. Therefore, whilst not any use of equipment within the EU/EEA leads to the application of the Directive, it is not necessary for the controller to exercise ownership or full control over such equipment for the processing to fall within the scope of the Directive. It has to be noted that there is a difference between the word used in the English version of Article 4 (1) c ‘equipment’, and the word used in other language versions of Article 4 (1) c, which are more akin to the English word ‘means’. The terminology used in other language versions of Article 4 (1) c is also consistent with the wording of Article 2 (d) defining the controller: the person who decides about the purposes and the “means” of the processing. In view of these considerations, the Working Party understands the word “equipment” as “means”26. It also notes that according to the Directive this could be "automated or otherwise". This leads to a broad interpretation of the criterion, which thus includes human and/or technical intermediaries, such as in surveys or inquiries. As a consequence, it applies to the collection of information using questionnaires, which is the case, for instance, in some pharmaceutical trials. There is a question whether outsourcing activities, notably by processors, carried out in the EU/EEA territory on behalf of controllers established outside EEA may be considered as "equipment". The broad interpretation advocated above leads to a positive answer, provided they are not acting in the context of the activities of an establishment of the controller in the EEA - in which case Article 4(1)a would apply. However, account should be taken of the sometimes undesirable consequences of such an interpretation, as developed below in III.4: if controllers established in different countries over the world have their data processed in a Member State of the EU, where the database and the processor are located, those controllers will have to comply with the data protection law of that Member State.
25 26
WP56, op. cit. It should also be recalled that the English language text of the Directive in previous versions (for instance, in the amended proposal of 1992 - COM (92) 422 final ) also used the term “means”, even though this was modified in the course of the negotiations, at quite a late stage, to the term “equipment”, as can be seen in the text of the common position of March 1995. - 20 -
556
A case-by-case assessment is needed whereby the way in which the equipment is actually used to collect and process personal data is assessed. On the basis of this reasoning, the Working Party recognized the possibility that personal data collection through the computers of users, as for example in the case of cookies or Javascript banners, trigger the application of Article 4(1)c and thus of EU data protection law to service providers established in third countries27. This interpretation of the "use of equipment" provision favours a wide scope of application. However, as mentioned, it also highlights some consequences which are not satisfactory, when the result is that European data protection law is applicable in cases where there is a limited connection with the EU (e.g. a controller established outside the EU, processing data of non-EU residents, only using equipment in the EU). There is an obvious need for more clarity and for further conditions to the application of this criterion, in order to bring more certainty in the future data protection framework. This point will be developed below in the concluding part of this document. As another illustration, the extent to which telecommunication terminals or parts of them should be considered as equipment is not obvious. The fact that the tool is designed or used primarily in order to collect or further process personal data can be considered as an indicator in this respect. However, the fact that a controller knowingly collects personal data, even incidentally, by using some equipment in the EU, also triggers the application of the Directive. Example 7: Geo-location services A company located in New-Zealand uses cars globally, including in EU Member States, to collect information on Wi-Fi access points (including information about private terminal equipment of individuals) in order to provide a geo-location service to its clients. Such activity involves in many cases the processing of personal data. The application of the Data Protection Directive will be triggered in two ways: - First, the cars collecting Wi-Fi information while circulating on the streets can be considered as equipment, in the sense of Article 4(1)c; - Second, while providing the geo-location service to individuals, the controller will also use the mobile device of the individual (through dedicated software installed in the device) as equipment to provide actual information on the location of the device and of its user. Both the collection of information with a view to provide the service, and the provision of the geo-location service itself, will have to comply with the provisions of the Directive.
Example No. 8: Cloud computing Cloud computing, where personal data are processed and stored on servers in several places around the world, is a complex example of the application of the provisions of the Directive. The exact place where data are located is not always known and it can change in time, but this is not decisive to identify the law applicable. It is sufficient that the controller carries out processing in the context of an establishment within the EU, 27
WP56, op. cit., p. 10 f. - 21 -
557
or that relevant means is located on EU territory to trigger the application of EU law, as provided in Article 4(1)c of the Directive. The first decisive step will be to identify who is the controller, and which activities take place at which level. Two perspectives can be identified: The user of the cloud service is a data controller: for instance, a company uses an agenda service on-line to organise meetings with clients. If the company uses the service in the context of the activities of its establishment in the EU, EU law will be applicable to this processing of data via the agenda on-line on the basis of Article 4(1)a. The company should make sure that the service provides for adequate data protection safeguards, notably with regard to the security of personal data stored on the cloud. It will also have to inform its clients of the purpose and conditions of use of their data. The cloud service provider can also in some circumstances be a data controller: this would be the case when it provides for an agenda on-line where private parties can upload all their personal appointments and it offers added value services such as synchronisation of appointments and contacts. If the cloud service provider uses means in the EU, it will be subject to EU data protection law on the basis of Article 4(1)c. As demonstrated below, the application of the Directive would not be triggered by means used for transit purposes only, but it would be triggered by more specific equipment e.g. if the service uses calculating facilities, runs java scripts or installs cookies with the purpose of storing and retrieving personal data of users. The cloud service provider will then have to provide users with information on the way data are being processed, stored, possibly accessed by third parties, and to guarantee appropriate security measures to protect the information.
Example No. 9: A controller publishes country-by-country lists of paedophiles A controller established in one EU/EEA Member State publishes country-by-country lists of persons suspected of or sentenced for criminal offences involving minors. With regard to the right to the protection of personal data of listed persons, the applicable law â&#x20AC;&#x201C; according to which the lawfulness of this processing should be assessed â&#x20AC;&#x201C; is the national data protection law of the Member State where the controller is established. It is irrelevant for the determination of applicable data protection law whether the controller uses equipment in other Member States (such as internet servers with different top-level domain names, including .fr, .it, .pl, etc.), or whether it directly targets citizens from other EU countries (for example, by publishing country-specific lists of names in the language of those countries) in processing data for this purpose. The supervisory authority of the Member State of establishment may in any case be called by other supervisory authorities to cooperate, by acting on complaints lodged by individuals located in other Member States. Of course, different connection criteria and thus applicable laws could be applied in other areas of law, such as for example to file a suit for defamation according to criminal or civil law. - 22 -
558
c)
“…unless used only for purposes of transit through Community territory …”
The application of the national law of an EU Member States is excluded when the equipment used by the controller and located within the Member State is used only in order to ensure transit through Union territory, such as for example in the case of telecommunication networks (cables) or postal services which only ensure that communications transit through the Union in order to reach third countries. As this is an exception to the equipment criterion, it should be subject to a narrow interpretation. It should be noted that the effective application of this exception is becoming infrequent: in practice, more and more telecommunication services merge pure transit and added value services, including for instance spam filtering or other manipulation of data at the occasion of their transmission. The simple "point to point" cable transmission is disappearing gradually. This should also be kept in mind when reflecting on the revision of the data protection framework. d) “… must designate a representative established on the Member State’s territory …” (Article 4(2)) The Directive imposes an obligation on the controller to designate ‘a representative’ in the territory of the Member State whose law is applicable by virtue of the controller's use of equipment in that Member State to process personal data. This is “without prejudice to legal actions which could be initiated against the controller himself”. In this last case, the question of enforcement against a representative raises practical issues, as shown by Member States' experience. This would be the case if for instance the only representative of the controller within the EU is a law firm. There is no uniform answer in national implementing provisions to the question whether the representative can be held responsible and sanctioned, on a civil or criminal basis, on behalf of the controller. The nature of the relationship between the representative and the controller is decisive here. In some Member States, the representative substitutes for the controller, also with regard to enforcement and sanctions, while in others it has a simple mandate. Some national laws explicitly foresee fines applicable to the representatives28, while in other Member States this possibility is not envisaged29. Harmonisation is needed in this respect at European level, with the objective of giving more effectiveness to the role of the representative. In particular, data subjects should be able to exercise their rights against the representative, without prejudice to legal actions which could be initiated against the controller himself. III.4. Considerations on the practical consequences of the application of Article 4(1)c A decisive aspect of the application of Article 4(1)c relates to its practical consequence for the data controller. While located outside the EU/EEA, he will have to apply the 28
29
Belgian data protection law of 8 December 1992, O.J. 18 March 1993; Dutch Act of 6 July 2000 regarding the protection of personal data, Bulletin of Acts, Orders and Decrees (Staatsblad) No. 302, 20 July 2000. See also the Greek legislation (Article 3 par. 3.b in combination with Article 21 par. 1 of Law 2472/1997). The French legislation 78/17 of 6 January 1978, for instance, does not foresee such type of fines on representatives. - 23 -
559
principles of the Directive if he uses equipment located in the EU territory for personal data processing operations. It could be questioned whether the principles will only be applicable to the part of the processing taking place in the EU, or to the controller as such, for all the stages of the processing, even those taking place in a third country. These questions have particular significance in network environments such as cloud computing, or in the context of multinational companies. Let us consider, for example, the implications for controllers established in different countries over the world, having their data processed in France, where the database and the processing equipment are located. If the different controllers make use of infrastructure in France, Article 4(1)c is applicable and all controllers would have to comply with French law. This may have undesirable consequences in terms of economic impact and enforceability. Practical reasons would push for a mitigation of the application of the "equipment/means" criteria, but this is counterbalanced by the fact that data protection principles aim at the protection of a fundamental right. Limiting the rights of individuals to some parts of the processing of their data does not seem admissible. Nor would it be acceptable to reduce the scope of protection to persons residing in the EU, since the fundamental right to protection of personal data is enjoyed regardless of nationality or residence. Consequently, the criterion of Article 4(1)c results in the principles of the Directive being applicable to the controller as such, for all the stages of the processing, even those taking place in a third country. The application of the Directive to a controller for the whole processing should be supported as long as the link with the EU is effective and not tenuous (such as by almost inadvertent, rather than intentional, use of equipment in a Member State). A more specific connecting factor, taking the relevant "targeting" of individuals into account, as a complement to the "equipment/means" criteria could be useful in terms of legal certainty, as further developed in the conclusions. Such a criterion is not new and has been used in other contexts in the EU30, and by the United Statesâ&#x20AC;&#x2122; legislation on the protection of children on-line31. This is also the case in some national laws transposing Directive 2000/31/EC on electronic commerce32, stating that providers not established in the EEA will fall within the scope of these national laws when they target services specifically to their territory. The application of a similar criterion for the data protection legislation in the EU could be reflected upon during future discussions on the revision of the data protection framework. 30
31
32
Cf. Article 15(1)c of Council Regulation (EC) No 44/2001 of 22 December 2000 on jurisdiction and the recognition and enforcement of judgments in civil and commercial matters (OJ L 12, 16.1.2001, p.1), and for its interpretation, see the Conclusions of Advocat General Trstenjak, 18 May 2010, in C144/09, Hotel Alpenhof . The application of the COPPA can indeed be triggered either by the location of a publisher in the US, or by the fact that US children are targeted by the website: foreign-based websites and online services must comply with COPPA if they are directed to, or knowingly collect or disclose personal information from, children in the United States. See 16 CFR 312.2, available at http://www.ftc.gov/os/1999/10/64fr59888.pdf, p. 59912. Directive 2000/31/EC of the European Parliament and of the Council of 8 June 2000 on certain legal aspects of information society services, in particular electronic commerce, in the Internal Market ('Directive on electronic commerce') OJ L 178 , 17.7.2000, p.1 - 24 -
560
Another practical consequence of the application of Article 4(1)c concerns the interaction between this provision and Articles 25 and 26 of the Directive. The fact that the controller established outside the EU/EEA uses equipment on EU/EEA territory - and must therefore comply with all relevant provisions of the Directive - would also entail the possible application of Articles 25 and 26. However, it may be difficult in practice to determine exactly the implications of such a scenario. For instance, if a controller X based outside the EEA collects personal data through the use of equipment located on EU territory (for instance through the use of cookies or via a processor), he has to comply with the Directive for all stages of the processing. There is a certain parallel here with the situation where a controller established in the EEA transfers personal data to a processor outside the EEA: in this case as well, the controller and the processor established outside EEA territory will be bound by the Directive. However, the way in which these principles are implemented in practice, in accordance with the adequacy requirements of Articles 25 and 26 of the Directive, in an Article 4(1)c scenario involving a controller established outside the EEA, is not totally clear. The Working Party considers that the existing tools regulating the conditions for transfers should be further reflected upon so as to better cover this situation.
III.5.
Law applicable to security measures (Article 17(3))
Article 17(3) establishes that the contract or the legal act binding the processor to the controller should also ensure compliance with the security measures "defined by the law of the Member State in which the processor is established". The reason behind this principle is to ensure uniform requirements within one Member State with regard to security measures, and facilitate enforcement. It should be noted however that in a European perspective, security requirements diverge considerably depending on Member States: some provide for very detailed rules while others have just copied the general wording of the Directive. Where national laws are general and their wording is taken from the Directive, this will not have any practical consequences. It would not be a problem for a processor to comply with more detailed obligations imposed on him by the controller according to its national law, or alternatively for a controller to accept more detailed requirements according to the law of the processor. Only in cases where detailed rules are different or even in conflict, Article 17(3) decides in favour of the law of the processor33. However, it seems advisable that further harmonisation of security obligations should be included in the scope of discussion on the revision of the data protection framework.
III.6. Competence and cooperation of supervisory authorities (Article 28(6)) As mentioned above (see para. II.2.e) Article 28(6) aims at bridging the possible gap between applicable law and supervisory jurisdiction, which may arise in the area of data protection within the internal market. Pursuant to this provision, national data protection authorities are competent to supervise the implementation of the data protection legislation on the territory of the Member State 33
This should avoid the appointment of a data processor in another country with lower obligations being regarded as a violation of the obligations of the data controller. - 25 -
561
where they are established. But if the law of another Member State were applicable on its territory, the enforcement powers of the DPA would not be limited: the applicable law criteria of the Directive foresee the possibility that a DPA is empowered to verify and intervene on a processing operation that is taking place on its territory even if the law applicable is the law of another Member State. III.6.a) “…supervisory authority is competent, whatever national law applicable…” This provision makes a national supervisory authority competent to always act within the limits of its territorial jurisdiction, irrespective of whether the law applicable is its national data protection law or the data protection law of another Member State. III.6.b) “…to exercise its powers on the territory of its own Member State…” Also, when a data protection law of another Member State is applicable, the supervisory authority will be in a position to fully exercise on its territory all powers conferred to it by its national legal system. This includes investigative powers, powers of intervention, power to engage in legal proceedings, power to impose sanctions. Where several DPAs are involved, including the DPA of the location and the DPAs whose law is applicable, it is essential that cooperation is organised, and that the role of each DPA is clear. Several questions should therefore be addressed, including notably: - procedural issues, such as the identification of the lead authority, and the way it will cooperate with the other DPAs; - the scope of competences to be exercised by each DPA. In particular, how far will the DPA of the location exercise its powers with regard to the application of the material principles and the sanctions? Should it limit the use of its powers to the verification of facts, can it take provisional measures of enforcement or even definitive measures? Can it give its own interpretation of the provisions of the law applicable, or is it the prerogative of the DPA of the Member State whose law is applicable? It should be noted in this regard that not all national laws foresee the possibility to impose sanctions on all stakeholders.34 A high level of harmonisation of the supervisory powers conferred to supervisory authorities pursuant to Article 28 of the Directive is an essential condition to guarantee that cross-border data protection compliance is ensured in an effective and nondiscriminatory way. This issue deserves further analysis, and the Working Party will provide guidance in this regard in a separate paper.
Example No. 10: Intra-EU cross-border processing of personal data Processing activities are taking place in the UK, but in the context of the activities of an establishment of the controller located in Germany. This will have the following consequences: -
German law will be applicable to the processing in the UK;
- The UK DPA needs to have the power to inspect the premises in the UK, and establish findings, to be transmitted to the German DPA; 34
The Greek law for instance provides for sanctions only on data controllers and their representatives and not on processors. - 26 -
562
- The German DPA should be able to impose a sanction on the controller established in Germany on the basis of the findings of the UK DPA. As an additional element, if the establishment in the UK is a processor, security aspects of the processing are subject to the requirements of UK data protection law. This then leads to the question how the requirements of that law could be properly enforced.
III.6.c) “…mutual cooperation to the extent necessary for performance of duties…” Supervisory authorities have an obligation to cooperate ("shall"), but at the same time this obligation is limited to what is necessary in order to perform their duties. Therefore, requests for cooperation should be related to the exercise of their competences and usually relate to cases with cross-border relevance. The provision refers in particular to the exchange of "all useful information", which could relate for example to information on the relevant provisions and legal instruments applicable to the specific case. However, cooperation is likely to take place also at different levels: handling cross-border complaints, collecting evidence for other DPAs, or imposing sanctions. The issue is even more acute in an international context, with data controllers operating worldwide, and it calls for improvements in terms of enforcement cooperation. Initiatives such as the ‘Global Privacy Enforcement Network (GPEN)’, involving data protection authorities from various continents, are a necessary and welcome step in this perspective.
Example No. 11: Social network having its headquarters in a third country and an establishment in the EU A social network platform has its headquarters in a third country and an establishment in a Member State. The establishment defines and implements the policies relating to the processing of personal data of EU residents. The social network actively targets residents of all EU Member States, which constitute a significant portion of its customers and revenues. It also installs cookies on EU users' computers. In this case, the applicable law will be, pursuant to Article 4(1)a, the data protection law of the Member State where the company is established within the EU. The issue of whether the social network makes use of equipment located in other Member States' territory is irrelevant, since all processing takes place in the context of the activities of the single establishment and the Directive excludes the cumulative application of Articles 4(1)a and 4(1)c. However, the supervisory authority of the Member State where the social network is established in the EU will - pursuant to Article 28(6) – have a duty to cooperate with other supervisory authorities, in order for example to deal with requests or complaints coming from residents of other EU countries.
- 27 -
563
Example No. 12: European e-health platform A platform is set up at European level in order to facilitate the processing of cross-border handling of patient records. The platform allows for the exchange of patients summary data sets, medication records and prescriptions in order to facilitate healthcare services when travelling abroad. While the platform facilitates the exchange of information, there will still be in each Member State one or several establishments in the context of which activities patients' data are processed. For instance, if a Bulgarian resident travelling to Portugal needs urgent treatment, his record will be processed via the platform by Portuguese medical services under Portuguese data protection law. If the patient wished to claim redress once back in Bulgaria with regard to the processing of his data by the Portuguese controller, he would first lodge his claim with the Bulgarian DPA. The Bulgarian DPA will then collaborate with the Portuguese DPA to establish the facts and check whether there has been an infringement under Portuguese legislation. If the European Commission intervenes in the functioning of the platform by organising personal data flows and guaranteeing the security of the system, it may also be considered as processing personal data, which would trigger the application of Regulation (EC) 45/2001. In this example, if the Bulgarian citizen complained about a security breach involving his medical data, the Bulgarian DPA would collaborate with the EDPS in order to identify the conditions and consequences of the breach.
IV.
Conclusions
This opinion aims at clarifying the scope of application of Directive 95/46/EC, and in particular Article 4 of the Directive. However, it also highlights some areas for possible further improvement. The main findings in these two respects are summarised below. IV.1. Clarifying current provisions Determining the application of EU law to the processing of personal data serves to clarify the scope of EU data protection law both in the EU/EEA and in a wider international context. A clear understanding of applicable law will help to ensure both legal certainty for controllers and a clear framework for individuals and other stakeholders. Furthermore, a correct understanding of the applicable law provisions should ensure that no lacunae or loopholes may be found in the high level of protection of personal data provided by Directive 95/46. The key provision on applicable law is Article 4, which determines which national data protection law(s) adopted pursuant to the Directive may be applicable to the processing of personal data. Pursuant to Article 4(1)a, a Member State must apply its national data protection law where the processing is carried out in the context of an establishment of the controller on the territory of the Member State. Key to the identification of a relevant establishment for the purposes of Article 4(1)a is whether the organisation in question conducts the - 28 -
564
effective and real exercise of activities. Furthermore, the reference to "an" establishment means that the applicability of a Member State's law will be triggered by the location of an establishment of the controller in that Member State, and other Member States’ laws could be triggered by the location of other establishments of that controller in those Member States. The notion of "context of activities" – and not the location of data – is a determining factor in identifying the scope of the applicable law. The notion of "context of activities" implies that the applicable law is not the law of the Member State where the controller is established, but where an establishment of the controller is involved in activities implying the processing of personal data. In this context, the degree of involvement of the establishment(s) in the activities, in the context of which personal data is processed, is crucial. In addition, the nature of the activities of the establishments and the need to guarantee effective protection of individuals' rights should be considered. A functional approach should be taken in the analysis of these criteria: more than the theoretical indication by the parties of the law applicable, it is their practical behaviour and interaction which should be decisive. Article 4(1)b addresses the less common case in which a Member State's data protection law applies where "the controller is not established on the Member State's territory, but in a place where its national law applies by virtue of international public law". External criteria stemming from international public law will determine in specific situations the extension of the application of a national data protection law beyond the national boundaries, as for example in the case of embassies or ships. Article 4(1)c strives to ensure the right to the protection of personal data provided by the EU Directive even where the controller is not established in EU/EEA territory but where the processing is in some way connected with the EU/EEA. To ensure consistency within Article 4 and to avoid gaps in the application of data protection law, the Working Party considers that the application of Article 4(1)c should not be prevented by the existence of an establishment of the controller on Community territory where that establishment is not a relevant establishment for the purposes of Article 4(1)a. Instead, the “use of equipment” provision in Article 4(1)c should apply in those cases where there is no establishment in the EU/EEA which would trigger the application of Article 4(1)a or where the processing is not carried out in the context of such an establishment. The crucial element which determines the applicability of Article 4(1)c and thus of a Member State's data protection law is the use of equipment situated on the territory of the Member State. The concept of "making use" presupposes two elements: some kind of activity of the controller and the clear intention of the controller to process personal data. Therefore, whilst not any use of equipment within the EU/EEA leads to the application of the Directive, it is not necessary for the controller to exercise ownership or full control over such equipment for the processing to fall within the scope of the Directive. With regard to the notion of "equipment', its expression by "means" in other EU languages would lead to a broad interpretation of the criteria, favouring a wide scope of application. Such an interpretation may in some cases result in European data protection law being applicable where the processing in question has no real connection with the EU/EEA. In any case, the processing of personal data by a controller established outside the EU/EEA, through equipment in the EU/EEA, triggers the application of the Directive - 29 -
565
pursuant to Article 4(1)c, which means that all other relevant provisions of the Directive will be applicable as well. The application of the national law of a Member State is excluded when the equipment used by the controller and located within the Member State is used only in order to ensure transit through Community territory, such as for example in the case of telecommunication networks (cables) or postal services which only ensure that communications transit through the Community in order to reach third countries. Article 4(2) imposes an obligation on the controller to designate a representative in the territory of the Member State whose law is applicable by virtue of the controller's use of equipment in that Member State to process personal data. In this last case, the enforcement against a representative can be a challenge. Article 17(3) establishes that the contract or the legal act binding the processor to the controller should also provide that the processor is required to comply with the security measures "defined by the law of the Member State in which the processor is established". The reason behind this principle is to ensure uniform requirements within one Member State with regard to security measures, and facilitate enforcement. Article 28(6) aims at bridging the possible gap between applicable law and supervisory jurisdiction, which may arise in the area of data protection within the internal market, by establishing that a DPA should be able to use its powers to verify and intervene in a processing operation that is taking place on its territory even if the law applicable is the law of another Member State. IV.2. Improving current provisions While the indications and examples developed above should contribute to enhancing legal certainty and protection of individuals' rights when defining the law applicable to the processing of personal data, some shortcomings were identified during their development. The wording used in the Directive and the consistency between the different parts of Article 4 would benefit from further clarification as a part of the revision of the general data protection framework. The Working Party has identified a need for such further clarification in several areas: a.
There is a need to address the inconsistencies in the wording used in Articles 4(1)a and 4(1)c with regard to "establishment", and the notion that the controller is "not established" in the EU. To be consistent with Article 4(1)a which uses the criterion of "establishment", Article 4(1)c should apply in all cases where there is no establishment in the EU which would trigger the application of Article 4(1)a or where the processing is not carried out in the context of the activities of such an establishment.
b.
Some clarification would also be useful with regard to the notion of "context of activities" of the establishment. The Working Party has emphasised the need to assess the degree of involvement of the establishment(s) in the activities in the context of which personal data are processed, or in other words to check "who is doing what" in which establishment. This criterion is interpreted taking into account - 30 -
566
the preparatory works of the Directive and the objective set out at the time to keep a distributive approach of national laws applicable to the different establishments of the controller within the EU. The Working Party considers that Article 4(1)a as it stands now leads to a workable but sometimes complex solution, which seems to argue in favour of a more centralised and harmonised approach. c.
The change envisaged in order to simplify the rules for determining applicable law would consist of a shift back to the country of origin principle: all establishments of a controller within the EU would then apply the same law regardless of the territory in which they are located. In this perspective, the location of the main establishment of the controller would be the first criterion to be applied. The fact that several establishments exist within the EU would not trigger a distributed application of national laws.
d.
This could only be acceptable however, if there are no significant differences between the laws of Member States. Any effective application of the country of origin principle would otherwise result in ‘forum shopping’ in favour of Member States whose legislation is considered as more permissive towards data controllers. This could obviously also harm data subjects. Legal certainty for data controllers and for data subjects would only be guaranteed if a comprehensive harmonisation of national legislation is reached, including harmonisation of security obligations. The Working Party therefore supports a strong harmonisation of data protection principles, also as a condition for a possible shift to the country of origin principle.
e.
Additional criteria should apply when the controller is established outside the EU, with a view to ensuring that a sufficient connection exists with EU territory, and to avoid EU territory being used to conduct illegal data processing activities by controllers established in third countries. The two following criteria may be developed in this view: − The targeting of individuals, or "service oriented approach": this would involve the introduction of a criterion for the application of EU data protection law, that the activity involving the processing of personal data is targeted at individuals in the EU. This would need to consist of substantial targeting based on or taking into account the effective link between the individual and a specific EU country. The following examples illustrate what targeting could consist of: the fact that a data controller collects personal data in the context of services explicitly accessible or directed to EU residents, via the display of information in EU languages, the delivery of services or products in EU countries, the accessibility of the service depending on the use of an EU credit card, the sending of advertising in the language of the user or for products and services available in the EU. The Working Party notes that this criterion is already used in the field of consumer protection: applying it in a data protection context would bring additional legal certainty to controllers as they would have to apply the same criterion for activities which often trigger the application of both consumer and data protection rules. − The criterion of the equipment/means: this criterion has shown to have undesirable consequences, such as a possible universal application of EU law. Nonetheless, there is a need to prevent situations where a legal gap - 31 -
567
would allow the EU being used as a data haven, for instance when a processing activity entails inadmissible ethical issues. The equipment/means criterion could therefore be kept, in a fundamental rights perspective, and in a residual form. It would then only apply as a third possibility, where the other two do not: it would address borderline cases (data about non EU data subjects, controllers having no link with EU) where there is a relevant infrastructure in the EU, connected with the processing of information. In this latter case, it might be an option to foresee that only certain data protection principles â&#x20AC;&#x201C; such as legitimacy or security measures â&#x20AC;&#x201C; would apply. This approach, which obviously would be subject to further development and refinement, would probably solve most of the problems in the current Article 4(1)c. f.
As a last recommendation, the Working Party calls for more harmonisation in the obligation of controllers established in third countries to appoint a representative in the EU, with the objective of giving more effectiveness to the role of the representative. In particular, the extent to which data subjects should be able to effectively exercise their rights against the representative should be clarified.
Done in Brussels, on 16 December 2010 For the Working Party, The Chairman Jacob KOHNSTAMM
- 32 -
568
ANNEX Article 4(1)a
Does the processing take place in the context of the Does the controller have an activities of the said establishment / establishment (or of establishments in one or Yes another establishment in more Member States? the same Member State)? (ยงIII.1) (ยงIII.1.b)
The national law of the Member State is applicable. Yes
No Does the processing take The national law of the place in the context of the other Member State is activities of an applicable. establishment on the territory of another Member Yes State? (ยงIII.1.b) No
No
Proceed with article 4, section 1, para b.
Proceed with article 4, section 1, para b.
Article 4(1)b
Start with article 4, section 1, para a.
Is the controller established at a location where the national law of the Member State is applicable by virtue of international public law? (ยงIII.2)
The national law of the Member State is applicable. Yes
No Proceed with article 4, section 1, para c.
- 33 -
569
Article 4(1)c
Start with article 4, section 1, para a and article 4, section 1, para b
Does the controller use automated or nonautomated equipment located in a Member State? (ยงIII.3.b)
No The national law of the Member State is not applicable.
Are these means exclusively used for purposes of transit? (ยงIII.3.c) Yes
The national law of the Member State is applicable. No
Yes The national law of the Member State is not applicable.
- 34 -
570
ARTICLE 29 DATA PROTECTION WORKING PARTY
00264/10/EN WP 169
Opinion 1/2010 on the concepts of "controller" and "processor"
Adopted on 16 February 2010
This Working Party was set up under Article 29 of Directive 95/46/EC. It is an independent European advisory body on data protection and privacy. Its tasks are described in Article 30 of Directive 95/46/EC and Article 15 of Directive 2002/58/EC. The secretariat is provided by Directorate D (Fundamental Rights and Citizenship) of the European Commission, Directorate General Justice, Freedom and Security, B-1049 Brussels, Belgium, Office No LX-46 01/190. Website: http://ec.europa.eu/justice_home/fsj/privacy/index_en.htm
571
TABLE OF CONTENTS
Executive summary ...........................................................................................................1 I.
Introduction.......................................................................................................2
II.
General observations and policy issues...........................................................3
II.1. II.2. II.3.
Role of concepts ..................................................................................................4 Relevant context..................................................................................................6 Some key challenges ...........................................................................................7
III.
Analysis of definitions.......................................................................................7
III.1. III.1.a) III.1.b) III.1.c) III.1.d)
Definition of controller .......................................................................................7 Preliminary element: "determines".....................................................................8 Third element: “purposes and means of processing” .......................................12 First element: “natural person, legal person or any other body” ......................15 Second element: “alone or jointly with others”................................................17
III.2.
Definition of processor .....................................................................................24
III.3.
Definition of third party....................................................................................31
IV.
Conclusions......................................................................................................31
572
Executive summary The concept of data controller and its interaction with the concept of data processor play a crucial role in the application of Directive 95/46/EC, since they determine who shall be responsible for compliance with data protection rules, how data subjects can exercise their rights, which is the applicable national law and how effective Data Protection Authorities can operate. Organisational differentiation in the public and in the private sector, the development of ICT as well as the globalisation of data processing, increase complexity in the way personal data are processed and call for clarifications of these concepts, in order to ensure effective application and compliance in practice. The concept of controller is autonomous, in the sense that it should be interpreted mainly according to Community data protection law, and functional, in the sense that it is intended to allocate responsibilities where the factual influence is, and thus based on a factual rather than a formal analysis. The definition in the Directive contains three main building blocks: - the personal aspect ("the natural or legal person, public authority, agency or any other body"); - the possibility of pluralistic control ("which alone or jointly with others"); and - the essential elements to distinguish the controller from other actors ("determines the purposes and the means of the processing of personal data"). The analysis of these building blocks leads to a number of conclusions that have been summarized in paragraph IV of the opinion. This opinion also analyzes the concept of processor, the existence of which depends on a decision taken by the controller, who can decide either to process data within his organization or to delegate all or part of the processing activities to an external organization. Two basic conditions for qualifying as processor are on the one hand being a separate legal entity with respect to the controller and on the other hand processing personal data on his behalf. The Working Party recognises the difficulties in applying the definitions of the Directive in a complex environment, where many scenarios can be foreseen involving controllers and processors, alone or jointly, with different degrees of autonomy and responsibility. In its analysis, it has emphasized the need to allocate responsibility in such a way that compliance with data protection rules will be sufficiently ensured in practice. However, it has not found any reason to think that the current distinction between controllers and processors would no longer be relevant and workable in that perspective. The Working Party therefore hopes that the explanations given in this opinion, illustrated with specific examples taken from the daily experience of data protection authorities, will contribute to effective guidance on the way to interpret these core definitions of the Directive.
1
573
The Working Party on the Protection of Individuals with regard to the processing of personal data set up by Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995, having regard to Articles 29 and 30 paragraphs 1(a) and 3 of that Directive, and Article 15 paragraph 3 of Directive 2002/58/EC of the European Parliament and of the Council of 12 July 2002, having regard to its Rules of Procedure, has adopted the following opinion: I.
Introduction
The concept of data controller and its interaction with the concept of data processor play a crucial role in the application of Directive 95/46/EC, since they determine who shall be responsible for compliance with data protection rules, and how data subjects can exercise their rights in practice. The concept of data controller is also essential for the determination of the applicable national law and the effective exercise of the supervisory tasks conferred on Data Protection Authorities. It is therefore of paramount importance that the precise meaning of these concepts and the criteria for their correct use are sufficiently clear and shared by all those in the Member States who play a role in the implementation of the Directive and in the application, evaluation and enforcement of the national provisions that give effect to it. There are signs that there may be a lack of clarity, at least as to certain aspects of these concepts, and some divergent views among practitioners in different Member States that may lead to different interpretations of the same principles and definitions introduced for the purpose of harmonisation at European level. This is why the Article 29 Working Party has decided, as part of its strategic work programme for 2008-2009, to devote special attention to the elaboration of a document setting out a common approach to these issues. The Working Party recognizes that the concrete application of the concepts of data controller and data processor is becoming increasingly complex. This is mostly due to the increasing complexity of the environment in which these concepts are used, and in particular due to a growing tendency, both in the private and in the public sector, towards organisational differentiation, in combination with the development of ICT and globalisation, in a way that may give rise to new and difficult issues and may sometimes result in a lower level of protection afforded to data subjects. Although the provisions of the Directive have been formulated in a technology-neutral way and so far were able to resist well to the evolving context, these complexities may indeed lead to uncertainties with regard to the allocation of responsibility and the scope of applicable national laws. These uncertainties may have a negative effect on compliance with data protection rules in critical areas, and on the effectiveness of data protection law as a whole. The Working Party has already dealt with some of these issues 2
574
in relation to specific questions1, but deems it necessary now to give more developed guidelines and specific guidance in order to ensure a consistent and harmonised approach. Therefore, the Working Party has decided to provide in this opinion - in a similar way as already done in the Opinion on the concept of personal data2 - some clarifications and some concrete examples3 with respect to the concepts of data controller and data processor. II.
General observations and policy issues
The Directive explicitly refers to the concept of controller in several provisions. The definitions of ‘controller’ and ‘processor’ in Article 2 (d) and (e) of Directive 95/46/EC (further “the Directive”) read as follows: ‘Controller’ shall mean the natural or legal person, public authority, agency or any other body which alone or jointly with others determines the purposes and means of the processing of personal data; where the purposes and means of processing are determined by national or Community laws or regulations the controller or the specific criteria for his nomination may be designated by national or Community law; ‘Processor’ shall mean a natural or legal person, public authority, agency or any other body which processes personal data on behalf of the controller. These definitions have been shaped during the negotiations about the draft proposal for the Directive in the early 1990’s and the concept of ‘controller’ was essentially taken from the Council of Europe’s Convention 108 concluded in 1981. During these negotiations some important changes took place. In the first place, ‘controller of the file’ in Convention 108 was replaced by ‘controller’ in relation to ‘processing of personal data’. This is a wide notion, defined in Article 2 (b) of the Directive as “any operation or set of operations which is performed upon personal data, whether or not by automatic means, such as collection, recording, organization, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, blocking, erasure or destruction.” The concept of ‘controller’ was thus no longer used for a static object (‘the file’) but related to activities reflecting the life cycle of information from its collection to its destruction, and this needed to be looked at both in detail and in its entirety (‘operation or set of operations’). Although the result may have been the same in many cases, the concept was thereby given a much wider and more dynamic meaning and scope.
1
2 3
See e.g. Opinion 10/2006 on the processing of personal data by the Society for Worldwide Interbank Financial Telecommunication (SWIFT), adopted on 22 November 2006 (WP 128), and more recently Opinion 5/2009 on online social networking, adopted on 12 June 2009 (WP 163). Opinion 4/2007 on the concept of personal data, adopted on 20 June 2007 (WP 136) These examples are based on current national or European practice and may have been amended or edited to ensure a better understanding. 3
575
Other changes involved the introduction of the possibility of ‘pluralistic control’ (“either alone or jointly with others”), the requirement that the controller should “determine the purposes and means of the processing of personal data”, and the notion that this determination could be made by national or Community law or in another way. The Directive also introduced the concept of ‘processor’, which is not mentioned in Convention 108. These and other changes will be analyzed in more detail in the course of this opinion. II.1.
Role of concepts
While the concept of controller (of the file) plays a very limited role4 in Convention 108, this is completely different in the Directive. Article 6 (2) explicitly provides that “it shall be for the controller to ensure that paragraph 1 is complied with”. This refers to the main principles relating to data quality, including the principle in Article 6 (1)(a) that “personal data must be processed fairly and lawfully”. This means in effect that all provisions setting conditions for lawful processing are essentially addressed to the controller, even if this is not always clearly expressed. Furthermore, the provisions on the rights of the data subject, to information, access, rectification, erasure and blocking, and to object to the processing of personal data (Articles 10-12 and 14), have been framed in such a way as to create obligations for the controller. The controller is also central in the provisions on notification and prior checking (Articles 18-21). Finally, it should be no surprise that the controller is also held liable, in principle, for any damage resulting from unlawful processing (Article 23). This means that the first and foremost role of the concept of controller is to determine who shall be responsible for compliance with data protection rules, and how data subjects can exercise the rights in practice.5 In other words: to allocate responsibility. This goes to the heart of the Directive, its first objective being “to protect individuals with regard to the processing of personal data”. That objective can only be realised and made effective in practice, if those who are responsible for data processing can be sufficiently stimulated by legal and other means to take all the measures that are necessary to ensure that this protection is delivered in practice. This is confirmed in Article 17 (1) of the Directive, according to which the controller “must implement appropriate technical and organizational measures to protect personal data against accidental or unlawful destruction or accidental loss, alteration, unauthorized disclosure or access, in particular where the processing involves the transmission of data over a network, and against all other unlawful forms of processing.”
4
5
It is not used in any of the substantive provisions, except in Article 8.a in relation to the right to be informed (principle of transparency). The controller as the responsible party is only visible in certain parts of the explanatory memorandum. See also Recital 25 of Directive 95/46/EC: “Whereas the principles of protection must be reflected, on the one hand, in the obligations imposed on persons, public authorities, enterprises, agencies or other bodies responsible for processing, in particular regarding data quality, technical security, notification to the supervisory authority, and the circumstances under which processing can be carried out, and, on the other hand, in the right conferred on individuals, the data on whom are the subject of processing, to be informed that processing is taking place, to consult the data, to request corrections and even to object to processing in certain circumstances.” 4
576
The means to stimulate responsibility can be pro-active and reactive. In the first case, they are to ensure an effective implementation of data protection measures and sufficient means of accountability for controllers. In the second case, they may involve civil liability and sanctions in order to ensure that any relevant damage is compensated and that adequate measures are taken to correct any mistakes or wrongdoing. The concept of controller is also an essential element in determining which national law is applicable to a processing operation or set of processing operations. The main rule of applicable law under Article 4 (1)(a) of the Directive is that each Member State applies its national provisions to “the processing of personal data, where (…) carried out in the context of the activities of an establishment of the controller on the territory of the Member State”. This provision continues as follows: “when the same controller is established on the territory of several Member States, he must take the necessary measures to ensure that each of these establishments complies with the obligations laid down by the national law applicable”. This means that the establishment(s) of the controller is (are) also determinative for the applicable national law(s), and possibly for a number of different applicable national laws and the way in which they relate to each other.6 Finally, it should be noted that the concept of controller appears in many different provisions of the Directive as an element of their scope or of a specific condition applying under them: e.g. Article 7 provides that personal data may be processed only if: “(c) processing is necessary for compliance with a legal obligation to which the controller is subject, (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller or in a third party to whom the date are disclosed, or (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party or parties to whom the data are disclosed, except where such interests are overridden …” . The identity of the controller is also an important element of the information to the data subject that is required under Articles 10 and 11. The concept of ‘processor’ plays an important role in the context of confidentiality and security of processing (Articles 16-17), as it serves to identify the responsibilities of those who are more closely involved in the processing of personal data, either under direct authority of the controller or elsewhere on his behalf. The distinction between ‘controller’ and ‘processor’ mostly serves to distinguish between those involved that are responsible as controller(s) and those that are only acting on their behalf. This is again mostly a matter of how to allocate responsibility. Other consequences, either in terms of applicable law or otherwise, may flow from there. However, in case of a processor, there is a further consequence - both for controller and processor - that under Article 17 of the Directive, the applicable law for security of processing shall be the national law of the Member State where the processor is established.7
6
7
The Working Party intends to adopt a separate opinion on "applicable law" in the course of 2010. When Community institutions and bodies process personal data, the assessment of controllership is also relevant with regard to the possible application of Regulation (EC) 45/2001 or other relevant EU legal instruments. See Article 17 (3) second indent: “the obligation …. as defined by the law of the Member State in which the processor is established, shall also be incumbent on the processor”. 5
577
Finally, as defined in Article 2(f), “third party’ shall mean any natural or legal person, public authority, agency or any other body other than the data subject, the controller, the processor and the persons who, under the direct authority of the controller or the processor, are authorized to process data.” Controller and processor and their staff are therefore considered as the ‘inner circle of data processing’ and are not covered by special provisions on third parties. II.2.
Relevant context
Different developments in the relevant environment have made these issues more urgent and also more complex than before. At the time of signature of Convention 108, and to a large extent also when Directive 95/46/EC was adopted, the context of data processing was still relatively clear and straightforward, but that is no longer the case. This is first of all due to a growing tendency towards organisational differentiation in most relevant sectors. In the private sector, the distribution of financial or other risks has led to ongoing corporate diversification, which is only enhanced by mergers and acquisitions. In the public sector, a similar differentiation is taking place in the context of decentralisation or separation of policy departments and executive agencies. In both sectors, there is a growing emphasis on the development of delivery chains or service delivery across organisations and on the use of subcontracting or outsourcing of services in order to benefit from specialisation and possible economies of scale. As a result, there is a growth in various services, offered by service providers, who do not always consider themselves responsible or accountable. Due to organisational choices of companies (and their contractors or subcontractors) relevant databases may be located in one or more countries within or outside the European Union. The development of Information and Communication Technologies ("ICT") has greatly facilitated these organisational changes and has also added a few of its own. Responsibilities on different levels – often the result of organisational differentiation – usually require and stimulate the extensive use of ICT. The development and deployment of ICT products and services also lead to new roles and responsibilities in their own right, which do not always clearly interact with existing or developing responsibilities in client organisations. It is therefore important to be aware of relevant differences and to clarify responsibilities where required. The introduction of micro-technology – such as RFID chips in consumer products – raises similar issues of shifting responsibilities. At the other end, there are new and difficult issues involved in the use of distributed computing, notably ‘cloud computing’ and ‘grids’.8 Globalisation is another complicating factor. Where organisational differentiation and development of ICT involve multiple jurisdictions, such as often around the Internet, issues of applicable law are bound to arise, not only within the EU or EEA, but also in relation to third countries. An illustration can be found in the framework of the antidoping context, where the World Anti Doping Agency (WADA), established in Switzerland, operates a database including information on athletes (ADAMS) which is managed from Canada in co-operation with national anti-doping organisations around the 8
'Cloud computing' is a kind of computing where scalable and elastic IT capabilities are provided as a service to multiple customers using internet technologies. Typical cloud computing services provide common business applications online that are accessed from a web browser, while the software and data are stored on the servers. In this sense the cloud is not an island but a global connector of the world's information and users. With regard to 'grids', see below example 19. 6
578
world. The division of responsibilities and the attribution of controllership have been pointed out by the WP29 as raising specific difficulties.9 This means that the central issues at stake in this opinion have a high degree of practical relevance and may have great consequences. II.3.
Some key challenges
In terms of the objectives of the Directive, it is most important to ensure that the responsibility for data processing is clearly defined and can be applied effectively. If it is not sufficiently clear what is required from whom – e.g. no one is responsible or a multitude of possible controllers – there is an obvious risk that too little, if anything, will happen and that the legal provisions will remain ineffective. It is also possible that ambiguities in interpretation will lead to competing claims and other controversies, in which case the positive effects will be less than expected or could be reduced or outweighed by unforeseen negative consequences. In all these cases, the crucial challenge is thus to provide sufficient clarity to allow and ensure effective application and compliance in practice. In case of doubt, the solution that is most likely to promote such effects may well be the preferred option. However, the same criteria that provide sufficient clarity may also lead to additional complexity and unwanted consequences. For example, the differentiation of control, in line with organisational realities, may lead to complexity in applicable national law, where different jurisdictions are involved. The analysis should therefore have a sharp eye for the difference between acceptable consequences under present rules, and the possible need for adjustment of present rules to ensure continued effectiveness and to avoid undue consequences under changing circumstances. This means that the current analysis is of great strategic importance and should be applied with care and in full awareness of possible interconnections between different issues. III.
Analysis of definitions
III.1. Definition of controller The definition of controller in the Directive contains three main building blocks, which will be analyzed separately for the purposes of this opinion. They are the following: o “the natural or legal person, public authority, agency or any other body” o “which alone or jointly with others” o “determines the purposes and means of the processing of personal data”.
9
Opinion 3/2008 of 1 August 2008 on the World Anti-Doping Code Draft International Standard for the Protection of Privacy, WP156 7
579
The first building block relates to the personal aspect of the definition. The third block contains the essential elements to distinguish the controller from other actors, while the second block looks into the possibility of ‘pluralistic control’. These building blocks are closely inter-related. However for the sake of the methodology to be followed in this opinion, each of these items will be dealt with separately. For practical purposes, it is helpful to start with the first element of the third building block – i.e. the meaning of the word “determines” – and to continue with the rest of the third block, and only then deal with the first and the second block. III.1.a) Preliminary element: "determines" As already mentioned above, the concept of controller played a minor role in Convention 108. Pursuant to Article 2 of the Convention, the "controller of the file" was defined as the body "who is competent ... to decide". The Convention emphasizes the need for a competence, which is determined "according to the national law". Therefore, the Convention referred back to national data protection laws, which, pursuant to the explanatory memorandum, would contain "precise criteria for determining who the competent person is". While the first Commission proposal reflects this provision, the amended Commission proposal refers instead to the body "who decides", thereby eliminating the need that the competence to decide is established by law: the definition by law is still possible but not necessary. This is then confirmed by the Council Common Position and the adopted text, both referring to the body "which determines". Against this background, the historic development highlights two important elements: firstly, that it is possible to be a controller irrespective of a specific competence or power to control data conferred by law; secondly, that in the process of adoption of Directive 95/46 the determination of the controller becomes a Community concept, a concept which has its own independent meaning in Community law, not varying because of possibly divergent - provisions of national law. This latter element is essential with a view to ensuring the effective application of the Directive and a high level of protection in the Member States, which requires a uniform and therefore autonomous interpretation of such a key concept as "controller", which in the Directive acquires an importance which it didn't have in Convention 108. In this perspective, the Directive completes this evolution by establishing that, even if the capacity to "determine" may arise from a specific attribution made by law, it would usually stem from an analysis of the factual elements or circumstances of the case: one should look at the specific processing operations in question and understand who determines them, by replying in a first stage to the questions "why is this processing taking place? Who initiated it?". Being a controller is primarily the consequence of the factual circumstance that an entity has chosen to process personal data for its own purposes. Indeed, a merely formal criterion would not be sufficient at least for two kinds of reasons: in some cases the formal appointment of a controller - laid down for example by law, in a contract or in a notification to the data protection authority - would just be lacking; in other cases, it may happen that the formal appointment would not reflect the reality, by formally entrusting the role of controller to a body which actually is not in the position to "determine". 8
580
The relevance of factual influence is also shown by the SWIFT case10, where SWIFT was formally considered data processor but de facto acted - at least to a certain extent - as data controller. In that case, it was made clear that even though the designation of a party as data controller or processor in a contract may reveal relevant information regarding the legal status of this party, such contractual designation is nonetheless not decisive in determining its actual status, which must be based on concrete circumstances. This factual approach is also supported by the consideration that the directive establishes that the controller is the one who "determines" rather than "lawfully determines" the purpose and means. The effective identification of controllership is decisive, even if the designation appears to be unlawful or the processing of data is exercised in an unlawful way. It is not relevant whether the decision to process data was "lawful" in the sense that the entity making such a decision was legally capable of doing so, or that a controller was formally appointed according to a specific procedure. The question of the lawfulness of the processing of personal data will still be relevant in a different stage and be assessed in the light of other Articles (in particular, Articles 6-8) of the Directive. In other terms, it is important to ensure that even in those cases where data are processed unlawfully, a controller can be easily found and held responsible for the processing. A last characteristic of the concept of controller is its autonomy, in the sense that, although external legal sources can help identifying who is a controller, it should be interpreted mainly according to data protection law.11 The concept of controller should not be prejudiced by other - sometimes colliding or overlapping - concepts in other fields of law, such as the creator or the right holder in intellectual property rights. Being a right holder for intellectual property does not exclude the possibility of qualifying as "controller" as well and thus be subject to the obligations stemming from data protection law. The need for a typology The concept of controller is a functional concept, intended to allocate responsibilities where the factual influence is, and thus based on a factual rather than a formal analysis. Therefore, determining control may sometimes require an in-depth and lengthy investigation. However, the need to ensure effectiveness requires that a pragmatic approach is taken with a view to ensure predictability with regard to control. In this perspective, rules of thumb and practical presumptions are needed to guide and simplify the application of data protection law. This calls for an interpretation of the Directive ensuring that the "determining body" can be easily and clearly identified in most situations, by reference to those - legal and/or factual - circumstances from which factual influence normally can be inferred, unless other elements indicate the contrary.
10
11
The case concerns the transfer to US authorities, with a view to fight terrorism financing, of banking data collected by SWIFT with a view to perform financial transactions on behalf of banks and financial institutions. See infra, the interference with concepts existing in other areas of law (for example, the concept of right holder for intellectual property or scientific research, or responsibility pursuant to civil law).
9
581
These circumstances can be analysed and classified according to the following three categories of situations, which allow a systematic approach to these issues: 1) Control stemming from explicit legal competence. This is inter alia the case referred to in the second part of the definition, i.e. when the controller or the specific criteria for his nomination are designated by national or Community law. The explicit appointment of the controller by law is not frequent and usually does not pose big problems. In some countries, the national law has provided that public authorities are responsible for processing of personal data within the context of their duties. However, more frequent is the case where the law, rather than directly appointing the controller or setting out the criteria for his appointment, establishes a task or imposes a duty on someone to collect and process certain data. For example, this would be the case of an entity which is entrusted with certain public tasks (e.g., social security) which cannot be fulfilled without collecting at least some personal data, and sets up a register with a view to fulfil them. In that case, it follows from the law who is the controller. More generally, the law may impose an obligation on either public or private entities to retain or provide certain data. These entities would then normally be considered as the controller for any processing of personal data in that context. 2) Control stemming from implicit competence. This is the case where the capacity to determine is not explicitly laid down by law, nor the direct consequence of explicit legal provisions, but still stems from common legal provisions or established legal practice pertaining to different areas (civil law, commercial law, labour law, etc). In this case, existing traditional roles that normally imply a certain responsibility will help identifying the controller: for example, the employer in relation to data on his employees, the publisher in relation to data on subscribers, the association in relation to data on its members or contributors. In all these cases, the capacity to determine processing activities can be considered as naturally attached to the functional role of a (private) organization, ultimately entailing responsibilities also from a data protection point of view. In legal terms, this would apply regardless of whether the capacity to determine would be vested in the mentioned legal bodies, would be exercised by the appropriate organs acting on their behalf, or by a natural person in a similar role (see further below on the first element in point c). However, the same would be the case for a public authority with certain administrative tasks, in a country where the law would not be explicit as to its responsibility for data protection.
10
582
Example No. 1: Telecom operators An interesting example of legal guidance to the private sector relates to the role of telecommunication operators: Recital 47 of Directive 95/46/EC clarifies that "where a message containing personal data is transmitted by means of a telecommunications or electronic mail service, the sole purpose of which is the transmission of such messages, the controller in respect of the personal data contained in the message will normally be considered to be the person from whom the message originates, rather than the person offering the transmission services; (...) nevertheless, those offering such services will normally be considered controllers in respect of the processing of the additional personal data necessary for the operation of the service". The provider of telecommunications services should therefore, in principle, be considered controller only for traffic and billing data, and not for any data being transmitted12. This legal guidance from the Community legislator is completely in line with the functional approach followed in this opinion. 3) Control stemming from factual influence. This is the case where the responsibility as controller is attributed on the basis of an assessment of the factual circumstances. In many cases, this will involve an assessment of the contractual relations between the different parties involved. This assessment allows for the drawing of external conclusions, assigning the role and responsibilities of controller to one or more parties. This might be particularly helpful in complicated environments, often making use of new information technologies, where relevant actors are often inclined to see themselves as "facilitators" and not as responsible controllers. It may be that a contract is silent on who is the controller, but contains sufficient elements to assign the responsibility of controller to a party that apparently exercises a dominant role in this respect. It may also be that the contract is more explicit as to the controller. If there is no reason to doubt that this accurately reflects the reality, there is nothing against following the terms of the contract. However, the terms of a contract are not decisive under all circumstances, as this would simply allow parties to allocate responsibility where they think fit. The fact itself that somebody determines how personal data are processed may entail the qualification of data controller, even though this qualification arises outside the scope of a contractual relation or is explicitly excluded by a contract. A clear example of this was the SWIFT case, whereby this company took the decision to make available certain personal data - which were originally processed for commercial purposes on behalf of financial institutions - also for the purpose of the fight against terrorism financing, as requested by subpoenas issued by the U.S. Treasury.
12
A DPA dealt with control in a case brought by a data subject complaining against unsolicited e-mail advertising. Through his complaint, the data subject requested the communication network provider to either confirm or deny that it was the sender of the advertising e-mail. The DPA stated that the company only providing a client with access to a communication network, i.e. neither initiating the data transmission nor selecting the addressees or modifying the information contained in the transmission, cannot be considered as data controller. 11
583
In case of doubt, other elements than the terms of a contract may be useful to find the controller, such as the degree of actual control exercised by a party, the image given to data subjects and reasonable expectations of data subjects on the basis of this visibility (see also below on the third element in point b). This category is particularly important since it allows to address and to allocate responsibilities also in those cases of unlawful conduct, where the actual processing activities may even be carried out against the interest and the willingness of some of the parties. Preliminary conclusion Among these categories, the first two allow in principle a more secure indication of the determining body and may well cover more than 80% of the relevant situations in practice. However, a formal legal designation should be in line with data protection rules, by ensuring that the designated body has effective control over the processing operations, or in other words that the legal appointment reflects the reality of things. Category 3 requires a more complex analysis and is more likely to lead to divergent interpretations. The terms of a contract can often help to clarify the issue, but are not decisive under all circumstances. There is a growing number of actors who do not consider themselves as determining the processing activities, and thus responsible for them. A conclusion on the basis of factual influence is in those cases the only feasible option. The question of the lawfulness of this processing will still be assessed in the light of other Articles (6-8). If none of the abovementioned categories is applicable, the appointment of a controller should be considered as "null and void". Indeed, a body which has neither legal nor factual influence to determine how personal data are processed cannot be considered as a controller. From a formal perspective, a consideration which corroborates this approach is that the definition of data controller should be considered as a mandatory legal provision, from which parties cannot simply derogate or deviate. From a strategic perspective, such an appointment would run counter to the effective application of data protection law and would nullify the responsibility that data processing entails. III.1.b) Third element: “purposes and means of processing” The third element represents the substantive part of the test: what a party should determine in order to qualify as controller. The history of this provision shows many developments. Convention 108 referred to the purpose of the automated data files, the categories of personal data and the operations to be applied to them. The Commission took these substantive elements, with minor language modifications, and added the competence to decide which third parties may have access to the data. The amended Commission proposal made a step forward in shifting from “the purposes of the file” to “the purposes and objective of the processing”, thus passing from a static definition linked to a file to a dynamic definition linked to the processing activity. The amended proposal still referred to four elements (purposes/objective, personal data, operations and third parties having access to them), which were reduced to two (“purposes and means”) only by the Council Common Position. 12
584
Dictionaries define “purpose” as “an anticipated outcome that is intended or that guides your planned actions” and “means” as “how a result is obtained or an end is achieved”. On the other hand, the Directive establishes that data must be collected for specified, explicit and legitimate purposes and not further processed in a way incompatible with those purposes. Determination of the "purposes" of the processing and the "means" to achieve them is therefore particularly important. It can also be said that determining the purposes and the means amounts to determining respectively the "why" and the "how" of certain processing activities. In this perspective, and taking into account that both elements go together, there is a need to provide guidance about which level of influence on the "why" and the "how" may entail the qualification of an entity as a controller. When it comes to assessing the determination of the purposes and the means with a view to attribute the role of data controller, the crucial question is therefore to which level of details somebody should determine purposes and means in order to be considered as a controller. And in correlation to this, which is the margin of manoeuvre that the Directive allows for a data processor. These definitions become particularly relevant when various actors are involved in the processing of personal data, and it is necessary to determine which of them are data controller (alone or jointly with others) and which are instead to be considered data processors - if any. The emphasis to be put on purposes or means may vary depending on the specific context in which the processing takes place. A pragmatic approach is needed, placing greater emphasis on discretion in determining purposes and on the latitude in making decisions. In these cases, the question is why the processing is happening and what is the role of possible connected actors like outsourcing companies: would the outsourced company have processed data if it were not asked by the controller, and at what conditions? A processor could operate further to general guidance provided mainly on purposes and not going very deep in details with regard to means. Example No. 2: Mail marketing Company ABC enters into contracts with different organisations to carry out its mail marketing campaigns and to run its payroll. It gives clear instructions (what marketing material to send out and to whom, and who to pay, what amounts, by what date etc). Even though the organisations have some discretion (including what software to use) their tasks are pretty clearly and tightly defined and though the mailing house may offer advice (e.g. advising against sending mailings in August) they are clearly bound to act as ABC instructs. Moreover, only one entity, the Company ABC, is entitled to use the data which are processed – all the other entities have to rely on the legal basis of Company ABC if their legal ability to process the data is questioned. In this case it is clear that the company ABC is the data controller and each of the separate organisations can be considered as a processor regarding the specific processing of data carried out on its behalf. With regard to the determination of the means, the term “means” evidently comprises very different sorts of elements, which is also illustrated by the history of this definition. 13
585
In the original proposal, the role of controller would stem from determining four elements (purposes/objective, personal data, operations and third parties having access to them). The final formulation of the provision, referring only to “purposes and means”, cannot be construed as being in contradiction to the older version, as there cannot be any doubt about the fact that e.g. the controller must determine which data shall be processed for the envisaged purpose(s). Therefore, the final definition must rather be understood as being only a shortened version comprising nevertheless the sense of the older version. In other words, “means” does not only refer to the technical ways of processing personal data, but also to the “how” of processing, which includes questions like “which data shall be processed”, “which third parties shall have access to this data”, “when data shall data be deleted”, etc. Determination of the “means” therefore includes both technical and organizational questions where the decision can be well delegated to processors (as e.g. “which hardware or software shall be used?”) and essential elements which are traditionally and inherently reserved to the determination of the controller, such as “which data shall be processed?”, "for how long shall they be processed?”, “who shall have access to them?”, and so on. Against this background, while determining the purpose of the processing would in any case trigger the qualification as controller, determining the means would imply control only when the determination concerns the essential elements of the means. In this perspective, it is well possible that the technical and organizational means are determined exclusively by the data processor. In these cases - where there is a good definition of purposes, but little or even no guidance on technical and organizational means - the means should represent a reasonable way of achieving the purpose(s) and the data controller should be fully informed about the means used. Would a contractor have an influence on the purpose and carry out the processing (also) for its own benefit, for example by using personal data received with a view to generate added-value services, it would be a controller (or possibly a joint controller) for another processing activity and therefore subject to all the obligations of the applicable data protection law. Example No. 3: Company referred to as data processor but acting as controller Company MarketinZ provides services of promotional advertisement and direct marketing to various companies. Company GoodProductZ concludes a contract with MarketinZ, according to which the latter company provides commercial advertising for GoodProductZ customers and is referred to as data processor. However, MarketinZ decides to use GoodProducts customer database also for the purpose of promoting products of other customers. This decision to add an additional purpose to the one for which the personal data were transferred converts MarketinZ into a data controller for this processing operation. The question of the lawfulness of this processing will still be assessed in the light of other Articles (6-8).
14
586
In some legal systems decisions taken on security measures are particularly important, since security measures are explicitly considered as an essential characteristic to be defined by the controller. This raises the issue of which decisions on security may entail the qualification of controller for a company to which processing has been outsourced. Preliminary conclusion Determination of the “purpose” of processing is reserved to the “controller”. Whoever makes this decision is therefore (de facto) controller. The determination of the “means” of processing can be delegated by the controller, as far as technical or organisational questions are concerned. Substantial questions which are essential to the core of lawfulness of processing are reserved to the controller. A person or entity who decides e.g. on how long data shall be stored or who shall have access to the data processed is acting as a ‘controller’ concerning this part of the use of data, and therefore has to comply with all controller's obligations. III.1.c) First element: “natural person, legal person or any other body” The first element of the definition refers to the personal side: who can be a controller, and therefore considered ultimately responsible for the obligations stemming from the Directive. The definition mirrors exactly the formulation of Article 2 of Convention 108 and was not object of specific discussion in the decision-making process of the Directive. It refers to a broad series of subjects, which can play the role of controller, ranging from natural to legal persons and including "any other body". It is important that the interpretation of this element should ensure the effective application of the Directive by favouring as much as possible a clear and univocal identification of the controller in all circumstances, irrespective of whether a formal appointment has been made and publicised. First of all, it is important to stay as close as possible to the practice established both in the public and private sector by other areas of law, such as civil, administrative and criminal law. In most cases these provisions will indicate to which persons or bodies responsibilities should be allocated and will in principle help to identify who is the data controller. In the strategic perspective of allocating responsibilities, and in order to provide data subjects with a more stable and reliable reference entity for the exercise of their rights under the Directive, preference should be given to consider as controller the company or body as such rather than a specific person within the company or the body. It is the company or the body which shall be considered ultimately responsible for data processing and the obligations stemming from data protection legislation, unless there are clear elements indicating that a natural person shall be responsible. In general, it should be assumed that a company or public body is responsible as such for the processing activities taking place within its realm of activities and risks.
15
587
Sometimes, companies and public bodies appoint a specific person responsible for the implementation of the processing operations. However, also in such a case where a specific natural person is appointed to ensure compliance with data protection principles or to process personal data, he/she will not be the controller but will act on behalf of the legal entity (company or public body), which will still be liable in case of breach of the principles in its capacity as controller.13 Especially for big and complex structures, it is a crucial issue of "data protection governance" to ensure both a clear responsibility of the natural person representing the company and concrete functional responsibilities within the structure, for example by entrusting other persons to act as representatives or points of contact for data subjects. Special analysis is needed in cases where a natural person acting within a legal person uses data for his or her own purposes outside the scope and the possible control of the legal person's activities. In this case the natural person involved would be controller of the processing decided on, and would bear responsibility for this use of personal data. The original controller could nevertheless retain some responsibility in case the new processing occurred because of a lack of adequate security measures. As already mentioned above, the role of the controller is crucial and particularly relevant when it comes to determining liability and imposing sanctions. Even if liability and sanctions will vary depending on the Member States, since they are imposed according to national laws, the need to clearly identify the natural or legal person responsible for breaches of data protection law is beyond doubt an essential pre-condition for the effective application of the Directive. The identification of â&#x20AC;&#x2DC;the controllerâ&#x20AC;&#x2122; in a data protection perspective will be interconnected in practice with the civil, administrative or criminal law rules providing for the allocation of responsibilities or sanctions to which a legal or a natural person can be subject14. Civil liability should not raise specific issues in this context as it applies in principle to both legal and natural persons. Criminal and/or administrative liability, however, may according to national law sometimes apply only to natural persons. If there are criminal or administrative sanctions for data protection infringements according to the respective national law, this law will normally also decide who is responsible: where criminal or administrative liability of legal persons is not recognised, such liability might be taken on by functionaries of legal persons according to the special rules of national law15.
13
14
15
A similar reasoning is applied with regard to Regulation (EC) 45/2001, whose Article 2(d) refers to "the Community institution or body, the Directorate-General, the unit or any other organisational entity". It has been made clear in supervision practice that officials of EU institutions and bodies, who have been appointed as "controllers", act on behalf of the body for which they work. See the Commission's "Comparative Study on the Situation in the 27 Member States as regards the Law Applicable to Non-contractual Obligations Arising out of Violations of Privacy and Rights relating to Personality", February 2009, available at http://ec.europa.eu/justice_home/doc_centre/civil/studies/doc/study_privacy_en.pdf This does not exclude that national laws may provide for criminal or administrative liability not only for the controller but also for any person infringing data protection law. 16
588
European law contains useful examples of criteria attributing criminal responsibility16, notably when an offence is committed for the benefit of the legal person: Responsibility can be attributed in such a case to any person, "acting either individually or as part of an organ of the legal person, who has a leading position within the legal person, based on one of the following: (a) a power of representation of the legal person; (b) an authority to take decisions on behalf of the legal person; (c) an authority to exercise control within the legal person." Preliminary conclusion Summarising the above reflections it can be concluded that the one liable for a data protection breach is always the controller, i.e. the legal person (company or public body) or the natural person as formally identified according to the criteria of the Directive. If a natural person working within a company or public body uses data for his or her own purposes, outside the activities of the company, this person shall be considered as a de facto controller and will be liable as such. Example No. 4: Secret monitoring of employees A member of the board of a company decides to secretly monitor the employees of the company, even though this decision is not formally endorsed by the board. The company should be considered as controller and face the possible claims and liability with regard to the employees whose personal data have been misused. The liability of the company is notably due to the fact that as a controller, it has the obligation to ensure compliance with security and confidentiality rules. Misuse by a functionary of the company or an employee could be considered as the result of inappropriate security measures. This is irrespective of whether at a later stage also the member of the board or other natural persons within the company may be considered liable, both from a civil law perspective - also towards the company - as well as from a criminal law perspective. This could be the case e.g. if the board member made use of collected data for extorting personal favours from employees: he would have to be considered as ‘controller’ and be liable concerning this specific use of data.
III.1.d) Second element: “alone or jointly with others” This paragraph, drawing on the previous analysis of the typical characteristics of a controller, will deal with those cases where multiple actors interact in the processing of personal data. Indeed, there are an increasing number of cases in which different actors act as controllers and the definition laid down by the Directive caters for this. The possibility that the controller operates "alone or jointly with others" was not mentioned in Convention 108 and was actually introduced only by the European Parliament before the adoption of the Directive. In the Commission opinion on the EP's 16
See e.g. Directive 2008/99/EC of 19 November 2008 on the protection of the environment through criminal law, Council Framework Decision of 13 June 2002 on combating terrorism. Legal instruments are either based on Article 29, Article 31(e) and Article 34(2)(b) TEU or correspond to the legal bases for instruments used in the first pillar, resulting from the ECJ jurisprudence in cases C176/03, COM/Council, [ECJR] 2005, I-7879 and C-440/05, COM/Council, [ECJR] 2007, I-9097. See also the Communication by the COM (2005) 583 final). 17
589
amendment, the Commission refers to the possibility that "for a single processing operation a number of parties may jointly determine the purpose and means of processing to be carried out" and therefore that in such a case "each of the cocontrollers must be considered as being constrained by the obligations imposed by the Directive so as to protect the natural persons about whom the data are processed". The Commission opinion did not completely reflect the complexities in the current reality of data processing, since it focused only on the case where all the controllers equally determine and are equally responsible for a single processing operation. Instead, the reality shows that this is only one of the different kinds of â&#x20AC;&#x2DC;pluralistic controlâ&#x20AC;&#x2122; which may exist. In this perspective, "jointly" must be interpreted as meaning "together with" or "not alone" in different forms and combinations. First of all, it should be noted that the likelihood of multiple actors involved in processing personal data is naturally linked to the multiple kinds of activities that according to the Directive may amount to "processing", which is at the end of the day the object of the "joint control". The definition of processing laid down by Article 2.b of the Directive does not exclude the possibility that different actors are involved in different operations or sets of operations upon personal data. These operations may take place simultaneously or in different stages. In such a complex environment it is even more important that roles and responsibilities can be easily allocated, so as to ensure that the complexities of joint control do not result in an unworkable distribution of responsibilities which would hamper the effectiveness of data protection law. Unfortunately, due to the multiplicity of possible arrangements, it is not possible to draw up an exhaustive "closed" list or categorization of the different kinds of "joint control". However, it is useful to provide also in this context guidance both through some categories and examples of joint control and through some factual elements from which joint control may be inferred or assumed. In general, the assessment of joint control should mirror the assessment of "single" control developed above in paragraph III.1.a to c. In the same line, also in assessing joint control a substantive and functional approach should be taken, as illustrated above, focusing on whether the purposes and means are determined by more than one party. Example No. 5: Installing video-surveillance cameras The owner of a building concludes a contract with a security company, so that the latter installs some cameras in various parts of the building on behalf of the controller. The purposes of the video-surveillance and the way the images are collected and stored are determined exclusively by the owner of the building, which therefore has to be considered as the sole controller for this processing operation. Also in this context, contractual arrangements can be useful in assessing joint control, but should always be checked against the factual circumstances of the relationship between the parties.
18
590
Example No. 6: Headhunters Company Headhunterz Ltd helps Enterprize Inc in recruiting new staff. The contract clearly states that "Headhunterz Ltd will act on behalf of Enterprize and in processing personal data acts as a data processor. Enterprize is the sole data controller". However, Headhunterz Ltd is in an ambiguous position: on the one hand it plays the role of a controller towards the job seekers, on the other hand it assumes to be processor acting on behalf of the controllers, such as Enterprize Inc and other companies seeking staff trough it. Furthermore, Headhunterz - with its famous value-added service "global matchz" - looks for suitable candidates both among the CVs received directly by Enterprize and those it already has in its extensive database. This ensures that Headhunterz, which according to the contract is paid only for contracts actually signed, enhances the matching between job offers and job seekers, thus increasing its revenues. From the elements above, it can be said that, in spite of the contractual qualification, Headhunterz Ltd shall be considered as a controller, and as controlling jointly with Enterprize Inc at least those sets of operations relating to Enterprize recruitment. In this perspective, joint control will arise when different parties determine with regard to specific processing operations either the purpose or those essential elements of the means which characterize a controller (see supra paragraph III.1.a to c). However, in the context of joint control the participation of the parties to the joint determination may take different forms and does not need to be equally shared. Indeed, in case of plurality of actors, they may have a very close relationship (sharing, for example, all purposes and means of a processing) or a more loose relationship (for example, sharing only purposes or means, or a part thereof). Therefore, a broad variety of typologies for joint control should be considered and their legal consequences assessed, allowing some flexibility in order to cater for the increasing complexity of current data processing reality. Against this background, it is necessary to deal with the different degrees in which multiple parties may interact or be linked between them in processing personal data. First of all, the mere fact that different subjects cooperate in processing personal data, for example in a chain, does not entail that they are joint controllers in all cases, since an exchange of data between two parties without sharing purposes or means in a common set of operations should be considered only as a transfer of data between separate controllers. Example No. 7: Travel agency (1) A travel agency sends personal data of its customers to the airlines and a chain of hotels, with a view to making reservations for a travel package. The airline and the hotel confirm the availability of the seats and rooms requested. The travel agency issues the travel documents and vouchers for its customers. In this case, the travel agency, the airline and the hotel will be three different data controllers, each subject to the data protection obligations relating to its own processing of personal data. However, the assessment may change when different actors would decide to set up a shared infrastructure to pursue their own individual purposes. When in setting up this 19
591
infrastructure these actors determine the essential elements of the means to be used, they qualify as joint data controllers - in any case to that extent - even if they do not necessarily share the same purposes. Example No. 8: Travel agency (2) The travel agency, the hotel chain and the airline decide to set up an internet-based common platform in order to improve their cooperation with regard to travel reservation management. They agree on important elements of the means to be used, such as which data will be stored, how reservations will be allocated and confirmed, and who can have access to the information stored. Furthermore, they decide to share the data of their customers in order to carry out integrated marketing actions. In this case, the travel agency, the airline and the hotel chain, will have joint control on how personal data of their respective customers are processed and will therefore be joint controllers with regard to the processing operations relating to the common internet-based booking platform. However, each of them would still retain sole control with regard to other processing activities, e.g. those relating to the management of their human resources. In some cases, various actors process the same personal data in a sequence. In these cases, it is likely that at micro-level the different processing operations of the chain appear as disconnected, as each of them may have a different purpose. However, it is necessary to double check whether at macro-level these processing operations should not be considered as a â&#x20AC;&#x153;set of operationsâ&#x20AC;? pursuing a joint purpose or using jointly defined means. The following two examples clarify this idea by providing two different possible scenarios. Example No. 9: Transfer of employee data to tax authorities Company XYZ collects and processes personal data of its employees with the purpose of managing salaries, missions, health insurances, etc. However, a law also imposes an obligation on the company to send all data concerning salaries to the tax authorities, with a view to reinforce fiscal control. In this case, even though both company XYZ and the tax authorities process the same data concerning salaries, the lack of shared purpose or means with regard to this data processing will result in qualifying the two entities as two separate data controllers. Example No. 10: Financial transactions Instead, let's take the case of a bank, which uses a financial messages carrier in order to carry out its financial transactions. Both the bank and the carrier agree about the means of the processing of financial data. The processing of personal data concerning financial transactions is carried out at a first stage by the financial institution and only at a later stage by the financial messages carrier. However, even if at micro level each of these subjects pursues its own purpose, at macro level the different phases and purposes and means of the processing are closely linked. In this case, both the bank and the message carrier can be considered as joint controllers. 20
592
Other cases exist where the various actors involved jointly determine, in some cases to a different extent, the purposes and/or the means of a processing operation. There are cases where each controller is responsible for only a part of the processing, but the information is put together and processed through a platform. Example No. 11: E-Government portals E-Government portals act as intermediaries between the citizens and the public administration units: the portal transfers the requests of the citizens and deposits the documents of the public administration unit until these are recalled by the citizen. Each public administration unit remains controller of the data processed for its own purposes. Nevertheless, the portal itself may be also considered controller. Indeed, it processes (i.e. collects and transfers to the competent unit) the requests of the citizens as well as the public documents (i.e. stores them and regulates any access to them, such as the download by the citizens) for further purposes (facilitation of e-Government services) than those for which the data are initially processed by each public administration unit. These controllers, among other obligations, will have to ensure that the system to transfer personal data from the user to the public administration's system is secure, since at a macro-level this transfer is an essential part of the set of processing operations carried out through the portal. Another possible structure is the "origin-based approachâ&#x20AC;&#x153;, which arises when each controller is responsible for the data it introduces in the system. This is the case of some EU-wide databases, where control - and thus the obligation to act on requests for access and rectification - is attributed on the basis of the national origin of personal data. Another interesting scenario is provided by online social networks. Example No 12: Social networks Social network service providers provide online communication platforms which enable individuals to publish and exchange information with other users. These service providers are data controllers, since they determine both the purposes and the means of the processing of such information. The users of such networks, uploading personal data also of third parties, would qualify as controllers provided that their activities are not subject to the so-called "household exception" 17.
After analysing those cases where the different subjects determine jointly only part of the purposes and means, a very clear cut and unproblematic case is the one where multiple subjects jointly determine and share all the purposes and the means of processing activities, giving rise to a full-fledged joint control.
17
For more details and examples, see the Article 29 Working Party's Opinion 5/2009 on online social networking, adopted on 12 June 2009 (WP 163) 21
593
In the latter case, it is easy to determine who is competent and in a position to ensure data subjects' rights as well as to comply with data protection obligations. However, the task of determining which controller is competent - and liable - for which data subjects' rights and obligations is much more complex where the various joint controllers share purposes and means of processing in an asymmetrical way. Need to clarify distribution of control First of all, it should be pointed out that, especially in cases of joint control, not being able to directly fulfil all controller’s obligations (ensuring information, right of access, etc) does not exclude being a controller. It may be that in practice those obligations could easily be fulfilled by other parties, which are sometimes closer to the data subject, on the controller's behalf. However, a controller will remain in any case ultimately responsible for its obligations and liable for any breach to them. According to a previous text presented by the Commission during the process of adoption of the Directive, having access to certain personal data would have entailed being (joint) controller for these data. However, this formulation was not retained in the final text and the experience shows that on the one hand access to data does not entail as such control, while on the other hand having access to data is not an essential condition to be a controller. Therefore, in complex systems with multiple actors access to personal data and other data subjects' rights can be ensured at different levels by different actors. Legal consequences also relate to the liability of controllers, raising in particular the issue of whether “joint control” established by the Directive always entails joint and several liability. Article 26 on liability uses the singular “controller”, thus hinting at a positive reply. However, as already mentioned, the reality may present various ways of acting “jointly with”, i.e. "together with". This might lead in some circumstances to joint and several liability, but not as a rule: in many cases the various controllers maybe be responsible – and thus liable - for the processing of personal data at different stages and to different degrees. The bottom line should be ensuring that even in complex data processing environments, where different controllers play a role in processing personal data, compliance with data protection rules and responsibilities for possible breach of these rules are clearly allocated, in order to avoid that the protection of personal data is reduced or that a "negative conflict of competence" and loopholes arise whereby some obligations or rights stemming from the Directive are not ensured by any of the parties. In these cases, more than ever, it is important that a clear information notice is given to the data subjects, explaining the various stages and actors of the processing. Moreover, it should be made clear if every controller is competent to comply with all data subject's rights or which controller is competent for which right.
22
594
Example No. 13: Banks and information pools on defaulting customers Several banks may establish a common “information pool” - where national law allows for these pools - whereby each of them contributes information (data) concerning defaulting customers and all of them have access to the total amount of information. Some legislations provide that all requests of data subjects, e.g. for access or deletion, need only to be made to one “entry-point”, the provider. The provider is responsible for finding the correct controller and for organizing that due answers are given to the data subject. The identity of the provider is published in the Data Processing Register. In other jurisdictions, such information pools may be operated by separate legal entities as controller, while requests for subject access are handled by the participating banks acting as its intermediary. Example No. 14: Behavioural advertising Behavioural advertising uses information collected on an individual's web-browsing behaviour, such as the pages visited or the searches made, to select which advertisements to display to that individual. Both publishers, which very often rent advertising spaces on their websites, and ad network providers, who fill those spaces with targeted advertising, may collect and exchange information on users, depending on specific contractual arrangements. From a data protection perspective, the publisher is to be considered as an autonomous controller insofar as it collects personal data from the user (user profile, IP address, location, language of operating system, etc) for its own purposes. The ad network provider will also be controller insofar as it determines the purposes (monitoring users across websites) or the essential means of the processing of data. Depending on the conditions of collaboration between the publisher and the ad network provider, for instance if the publisher enables the transfer of personal data to the ad network provider, including for instance through a re-direction of the user to the webpage of the ad network provider, they could be joint controllers for the set of processing operations leading to behavioural advertising. In all cases, (joint) controllers shall ensure that the complexity and the technicalities of the behavioural advertising system do not prevent them from finding appropriate ways to comply with controllers' obligations and to ensure data subjects' rights. This would include notably: • information to the user on the fact that his/her data are accessible by a third party: this could be done more efficiently by the publisher who is the main interlocutor of the user, • and conditions of access to personal data: the ad-network company would have to answer to users' requests on the way they perform targeted advertising on users data, and comply with correction and deletion requests. In addition, publishers and ad network providers may be subject to other obligations stemming from civil and consumer protection laws, including tort laws and unfair commercial practices.
23
595
Preliminary conclusion Parties acting jointly have a certain degree of flexibility in distributing and allocating obligations and responsibilities among them, as long as they ensure full compliance. Rules on how to exercise joint responsibilities should be determined in principle by controllers. However, factual circumstances should be considered also in this case, with a view to assessing whether the arrangements reflect the reality of the underlying data processing. In this perspective, the assessment of joint control should take into account on the one hand the necessity to ensure full compliance with data protection rules, and on the other hand that the multiplication of controllers may also lead to undesired complexities and to a possible lack of clarity in the allocation of responsibilities. This would risk making the entire processing unlawful due to a lack of transparency and violate the principle of fair processing. Example No. 15: Platforms for managing health data In a Member State, a public authority establishes a national switch point regulating the exchange of patient data between healthcare providers. The plurality of controllers tens of thousands - results in such an unclear situation for the data subjects (patients) that the protection of their rights would be in danger. Indeed, for data subjects it would be unclear whom they could address in case of complaints, questions and requests for information, corrections or access to personal data. Furthermore, the public authority is responsible for the actual design of the processing and the way it is used. These elements lead to the conclusion that the public authority establishing the switch point shall be considered as a joint controller, as well as a point of contact for data subjects' requests. Against this background, it can be argued that joint and several liability for all parties involved should be considered as a means of eliminating uncertainties, and therefore assumed only in so far as an alternative, clear and equally effective allocation of obligations and responsibilities has not been established by the parties involved or does not clearly stem from factual circumstances. III.2. Definition of processor The concept of processor was not laid down by Convention 108. For the first time, the role of processor is recognised by the first Commission proposal, but without the introduction of this concept, with a view to "avoid situations whereby processing by a third party on behalf of the controller of the file has the effect of reducing the level of protection enjoyed by the data subject". Only with the amended Commission proposal and further to a proposal of the European Parliament, the concept of processor is explicitly and autonomously spelt out, before acquiring the current formulation in the Council Common position. In the same way as for the definition of controller, the definition of processor envisages a broad range of actors that can play the role of processor (“… a natural or legal person, public authority, agency or any other body …”).
24
596
The existence of a processor depends on a decision taken by the controller, who can decide either to process data within his organization, for example through staff authorized to process data under his direct authority (see a contrario Article 2.f), or to delegate all or part of the processing activities to an external organization, i.e. - as put forward by the explanatory memorandum of the amended Commission proposal - by "a legally separate person acting on his behalf". Therefore, two basic conditions for qualifying as processor are on the one hand being a separate legal entity with respect to the controller and on the other hand processing personal data on his behalf. This processing activity may be limited to a very specific task or context or may be more general and extended. Furthermore, the role of processor does not stem from the nature of an entity processing data but from its concrete activities in a specific context. In other words, the same entity may act at the same time as a controller for certain processing operations and as a processor for others, and the qualification as controller or processor has to be assessed with regard to specific sets of data or operations. Example No. 16: Internet service providers of hosting services An ISP providing hosting services is in principle a processor for the personal data published online by its customers, who use this ISP for their website hosting and maintenance. If however, the ISP further processes for its own purposes the data contained on the websites then it is the data controller with regard to that specific processing. This analysis is different from an ISP providing email or internet access services (see also example No. 1: telecom operators). The most important element is the prescription that the processor act “…on behalf of the controller…”. Acting on behalf means serving someone else's interest and recalls the legal concept of “delegation”. In the case of data protection law, a processor is called to implement the instructions given by the controller at least with regard to the purpose of the processing and the essential elements of the means. In this perspective, the lawfulness of the processor's data processing activity is determined by the mandate given by the controller. A processor that goes beyond its mandate and acquires a relevant role in determining the purposes or the essential means of processing is a (joint) controller rather than a processor. The question of the lawfulness of this processing will still be assessed in the light of other Articles (6-8). However, delegation may still imply a certain degree of discretion about how to best serve the controller's interests, allowing the processor to choose the most suitable technical and organizational means. Example No. 17: Outsourcing of mail services Private bodies provide mail services on behalf of (public) agencies – e.g. the mailing of family and maternity allowances performed on behalf of the National Social Security Agency. In that case a DPA indicated that the private bodies in question should be appointed as processors considering that their task, though carried out with a certain degree of autonomy, was limited to only a part of the processing operations necessary for the purposes determined by the data controller. 25
597
Still with a view to ensuring that outsourcing and delegation do not result in lowering the standard of data protection, the Directive contains two provisions which are specifically addressed to the processor and which define in great detail his obligations with regard to confidentiality and security. - Article 16 establishes that the processor himself, as well as any person acting under his authority who has access to personal data, must not process them except on instructions from the controller. - Article 17 in relation to security of processing establishes the need for a contract or a binding legal act regulating the relations between data controller and data processor. This contract shall be in written form for evidence purpose and shall have a minimum content, stipulating in particular that the data processor shall act only on instructions from the controller and implement technical and organizational measures to adequately protect personal data. The contract should include a detailed enough description of the mandate of the processor. In this respect, it should be noted that in many cases service providers specialized in certain processing of data (for example, payment of salaries) will set up standard services and contracts to be signed by data controllers, de facto setting a certain standard manner of processing personal data18. However, the fact that the contract and its detailed terms of business are prepared by the service provider rather than by the controller is not in itself a sufficient basis to conclude that the service provider should be considered as a controller, in so far as the controller has freely accepted the contractual terms, thus accepting full responsibility for them. In the same line, the imbalance in the contractual power of a small data controller with respect to big service providers should not be considered as a justification for the controller to accept clauses and terms of contracts which are not in compliance with data protection law. Example No. 18: Email platforms John Smith looks for an email platform to be used by himself and the five employees of his company. He discovers that a suitable user-friendly platform - and also the only one offered for free - keeps personal data for an excessive amount of time and transfers them to third countries without adequate safeguards. Furthermore, the contractual terms are "take it or leave it". In this case, Mr Smith should either look for another provider or - in case of alleged non compliance with data protection rules or lack of availability in the market of other suitable providers - refer the matter to competent authorities, such as DPAs, consumer protection and antitrust authorities, etc.
The fact that the Directive requires a written contract to ensure security of processing does not mean that there cannot be controllers/processors relations without prior contracts. In this perspective, the contract is neither constitutive nor decisive, even if it
18
The elaboration of the terms of the contract by the service provider is without prejudice to the fact that essential aspects of the processing, as described in point III.1.b, are determined by the controller. 26
598
may help to better understand the relations between the parties19. Therefore, also in this case a functional approach shall be applied, analysing the factual elements of the relations between the different subjects and the way purposes and means of the processing are determined. In case a controller/processor relation appears to exist, these parties are obliged to conclude a contract according to the law (cf. Article 17 of the Directive). Plurality of processors It increasingly happens that processing of personal data is outsourced by a controller to several data processors. These processors may have a direct relationship with the data controller, or be sub-contractors to which the processors have delegated part of the processing activities entrusted to them. These complex (multi-level or diffused) structures of processing personal data are increasing with new technologies and some national laws explicitly refer to them. Nothing in the Directive prevents that on account of organizational requirements, several entities may be designated as data processors or (sub-)processors also by subdividing the relevant tasks. However, all of them are to abide by the instructions given by the data controller in carrying out the processing. Example No. 19: Computer grids Large scale research infrastructures are increasingly using distributed computing facilities, especially grids, to profit in terms of computing and storage capacity. Grids are installed in different research infrastructures established in different countries. A European grid may, for instance, consist of national grids, which in turn are under the responsibility of a national body. This European grid, however, may not have a central body, responsible for its functioning. Researchers using such a grid can not usually identify where their data are exactly being processed, and thus who is the responsible data processor (the case is even more complicated if there are grid infrastructures in third countries). Should a grid infrastructure use the data in an unauthorised manner, this party may be considered data controller, if it does not act on behalf of the researchers. The strategic issue here is that - with a plurality of actors involved in the process - the obligations and responsibilities stemming from data protection legislation should be clearly allocated and not dispersed along the chain of outsourcing/subcontracting. In other words, one should avoid a chain of (sub-)processors that would dilute or even prevent effective control and clear responsibility for processing activities, unless the responsibilities of the various parties in the chain are clearly established. In this perspective, in the same line as described above in paragraph III.1.b - while it is not necessary that the controller defines and agrees on all the details of the means used to pursue the envisaged purposes - it would still be necessary that he is at least informed of the main elements of the processing structure (for example, subjects involved, security 19
However, in some cases, the existence of a written contract can constitute a necessary condition to automatically qualify as a processor in certain contexts. In Spain, for example, the report on callcentres defines as processors all call-centres in third countries, as long as they are complying with the contract. This is the case even if the contract has been drafted by the processor and the controller merely â&#x20AC;&#x153;adheresâ&#x20AC;? to it. 27
599
measures, guarantees for processing in third countries, etc), so that he is still in a position to be in control of the data processed on his behalf. It shall also be considered that, while the Directive imposes liability on the controller, it does not prevent national data protection laws from providing that, in addition, also the processor should be considered liable in certain cases. Some criteria may be helpful in determining the qualification of the various subjects involved: o Level of prior instructions given by the data controller, which determines the margin of manoeuvre left to the data processor; o Monitoring by the data controller of the execution of the service. A constant and careful supervision by the controller to ensure thorough compliance of the processor with instructions and terms of contract provides an indication that the controller is still in full and sole control of the processing operations; o Visibility/image given by the controller to the data subject, and expectations of the data subjects on the basis of this visibility.
Example No. 20: Call centres A data controller outsources some of its operations to a call centre and instructs the call centre to present itself using the identity of the data controller when calling the data controller's clients. In this case the expectations of the clients and the way the controller presents himself to them through the outsourcing company lead to the conclusion that the outsourcing company acts as a data processor for (on behalf of) the controller. o Expertise of the parties: in certain cases, the traditional role and professional expertise of the service provider play a predominant role, which may entail its qualification as data controller. Example No. 21: Barristers A barrister represents his/her client in court, and in relation to this mission, processes personal data related to the client's case. The legal ground for making use of the necessary information is the client's mandate. However, this mandate is not focused on processing data but on representation in court, for which activity such professions have traditionally their own legal basis. Such professions are therefore to be regarded as independent â&#x20AC;&#x2DC;controllersâ&#x20AC;&#x2122; when processing data in the course of legally representing their clients. In a different context, a closer assessment of the means put in place to reach the purposes may also be determining.
28
600
Example No. 22: "Lost and found" website A ‘lost and found’ website was presented as being merely a processor as it would be those who post lost items who would determine the content and thus, at a micro level, the purpose (e.g. finding a lost brooch, parrot etc). A data protection authority rejected this argument. The website was set up for the business purpose of making money from allowing the posting of lost items and the fact that they did not determine which specific items were posted (as opposed to determining the categories of items) was not crucial as the definition of “data controller” does not expressly include the determination of content. The website determines the terms of posting etc and is responsible for the propriety of content.
Although there could have been a tendency to generally identify outsourcing as the task of a processor, nowadays situations and assessments are often much more complex.
Example No. 23: Accountants The qualification of accountants can vary depending on the context. Where accountants provide services to the general public and small traders on the basis of very general instructions (”Prepare my tax returns”), then - as with solicitors acting in similar circumstances and for similar reasons - the accountant will be a data controller. However, where an accountant is employed by a firm, and subject to detailed instructions from the in-house accountant, perhaps to carry out a detailed audit, then in general, if not a regular employee, he will be a processor, because of the clarity of the instructions and the consequent limited scope for discretion. However, this is subject to one major caveat, namely that where they consider that they have detected malpractice which they are obliged to report, then, because of the professional obligations they owe they are acting independently as a controller.
Sometimes, the complexity of processing operations may lead to put more focus on the margin of manoeuvre of those entrusted with the processing of personal data, e.g. when the processing entails a specific privacy risk. Introducing new means of processing may lead to favouring the qualification as data controller rather than data processor. These cases may also lead to a clarification - and appointment of the controller - explicitly provided for by law.
29
601
Example No. 24: Processing for historical, scientific and statistical purposes National law may introduce, with regard to processing of personal data for historical, scientific and statistical purposes, the notion of intermediary organization to designate the body in charge of transforming non-encoded data into encoded data, so that the controller of the processing for historical, scientific and statistical purposes would not be able to re-identify the data subjects. If several controllers of initial processing operations transmit data to one or more third parties for further processing for historical, scientific and statistical purposes, the data are first encoded by an intermediary organization. In this case the intermediary organization may be considered as controller pursuant to specific national regulations, and it is subject to all resulting obligations (relevance of the data, informing the data subject, notification etc.). This is justified by the fact that when data from different sources are brought together, there is a particular threat to data protection, justifying the intermediary organization's own responsibility. Consequently, it is not simply considered as processor but fully regarded as controller pursuant to national law. In the same line, the autonomous decision-making power left to the various parties involved in the processing is relevant. The case of clinical drug trials shows that the relationship between sponsor companies and external entities entrusted to carry out the trials depends on the discretion left to the external entities in respect of data processing. This entails that there may be more than one controller, but also more than one processor or person in charge of the processing. Example No. 25: Clinical drug trials The pharmaceutical company XYZ sponsors some drug trials and selects the candidate trial centres by assessing the respective eligibility and interests; it draws up the trial protocol, provides the necessary guidance to the centres with regard to data processing and verifies compliance by the centres with both the protocol and the respective internal procedures. Although the sponsor does not collect any data directly, it does acquire the patients' data as collected by trial centres and processes those data in different ways (evaluating the information contained in the medical documents; receiving the data of adverse reactions; entering these data in the relevant database; performing statistical analyses to achieve the trial results). The trial centre carries out the trial autonomously â&#x20AC;&#x201C; albeit in compliance with the sponsor's guidelines; it provides the information notices to patients and obtains their consent as also related to processing of the data concerning them; it allows the sponsor's collaborators to access the patients' original medical documents to perform monitoring activities; and it handles and is responsible for the safekeeping of those documents. Therefore, it appears that responsibilities are vested in the individual actors. Against this background, in this case both trial centres and sponsors make important determinations with regard to the way personal data relating to clinical trials are processed. Accordingly, they may be regarded as joint data controllers. The relation between the sponsor and the trial centres could be interpreted differently in those cases where the sponsor determines the purposes and the essential elements of the means and the researcher is left with a very narrow margin of manoeuvre. 30
602
III.3. Definition of third party The concept of "third party" was not laid down by Convention 108, but was introduced by the amended Commission proposal further to an amendment proposed by the European Parliament. According to the explanatory memorandum, the amendment was reworded in order to make clear that third parties do not include the data subject, the controller and any person authorized to process the data under the controller's direct authority or on his behalf, as is the case with the processor. This means, that "persons working for another organization, even if it belongs to the same group or holding company, will generally be third parties" while on the other hand "branches of a bank processing customer's accounts under the direct authority of their headquarters would not be third parties". The Directive uses "third party" in a way which is not dissimilar to the way in which this concept is normally used in civil law, where third party is usually a subject which is not part of an entity or of an agreement. In the data protection context, this concept should be interpreted as referring to any subject who has no specific legitimacy or authorization which could stem, for example, from its role as controller, processor, or their employee in processing personal data. The Directive uses this concept in many provisions, usually with a view to establish prohibitions, limitations and obligations for the cases where personal data might be processed by other parties which in origin were not supposed to process certain personal data. Against this background, it can be concluded that a third party receiving personal data either lawfully or unlawfully - would in principle be a new controller, provided that the other conditions for the qualification of this party as controller and the application of the data protection legislation are met. Example No. 26: Unauthorised access by an employee An employee of a company in carrying out his tasks gets to know personal data to which he is not authorized to have access. In this case, this employee should be considered as "third party" vis-Ă -vis his employer, with all the resulting consequences and liabilities in terms of lawfulness of communication and processing of data.
IV.
Conclusions
The concept of data controller and its interaction with the concept of data processor play a crucial role in the application of Directive 95/46/EC, since they determine who shall be responsible for compliance with data protection rules, how data subjects can exercise their rights, which is the applicable national law and how effective Data Protection Authorities can operate. Organisational differentiation both in the public and in the private sector, the development of ICT as well as the globalisation of data processing increase complexity in the way personal data are processed and call for clarifications of these concepts, in order to ensure effective application and compliance in practice. 31
603
The concept of controller is autonomous, in the sense that it should be interpreted mainly according to Community data protection law, and functional, in the sense that it is intended to allocate responsibilities where the factual influence is, and thus based on a factual rather than a formal analysis. The definition in the Directive contains three main building blocks: the personal aspect ("the natural or legal person, public authority, agency or any other body"); the possibility of pluralistic control ("which alone or jointly with others"); and the essential elements to distinguish the controller from other actors ("determines the purposes and the means of the processing of personal data"). The analysis of these building blocks leads to the following main outcomes: â&#x20AC;˘
The capacity to "determine the purposes and the means ...." may stem from different legal and/or factual circumstances: an explicit legal competence, when the law appoints the controller or confers a task or duty to collect and process certain data; common legal provisions or existing traditional roles that normally imply a certain responsibility within certain organisations (for example, the employer in relation to data of its employees); factual circumstances and other elements (such as contractual relations, actual control by a party, visibility towards data subjects, etc). If none of these categories is applicable, the appointment of a controller should be considered as "null and void". Indeed, a body which has neither legal nor factual influence to determine how personal data are processed cannot be considered as a controller. Determining the "purpose" of processing triggers the qualification of (de facto) controller. Instead, the determination of the "means" of processing can be delegated by the controller, as far as technical or organisational questions are concerned. However, substantial questions which are essential to the core of lawfulness of processing - such as data to be processed, length of storage, access, etc. - are to be determined by the controller.
â&#x20AC;˘
The personal aspect of the definition refers to a broad series of subjects, which can play the role of controller. However, in the strategic perspective of allocating responsibilities, preference should be given to considering as controller the company or body as such rather than a specific person within the company or the body. It is the company or the body which shall be considered ultimately responsible for data processing and the obligations stemming from data protection legislation, unless there are clear elements indicating that a natural person shall be responsible, for example when a natural person working within a company or a public body uses data for his or her own purposes, outside the activities of the company.
â&#x20AC;˘
The possibility of pluralistic control caters for the increasing number of situations where different parties act as controllers. The assessment of this joint control should mirror the assessment of "single" control, by taking a substantive and functional approach and focusing on whether the purposes and the essential elements of the means are determined by more than one party.
32
604
The participation of parties in the determination of purposes and means of processing in the context of joint control may take different forms and does not need to be equally shared. This opinion provides many examples of different kinds and degrees of joint control. Different degrees of control may give rise to different degrees of responsibility and liability, and "joint and several" liability can certainly not be assumed in all cases. Furthermore, it is well possible that in complex systems with multiple actors, access to personal data and exercise of other data subjects' rights can be ensured also at different levels by different actors. This opinion also analyzes the concept of processor, the existence of which depends on a decision taken by the controller, who can decide either to process data within his organization or to delegate all or part of the processing activities to an external organization. Therefore, two basic conditions for qualifying as processor are on the one hand being a separate legal entity with respect to the controller and on the other hand processing personal data on his behalf. This processing activity may be limited to a very specific task or context or may accommodate a certain degree of discretion about how to serve the controller's interests, allowing the processor to choose the most suitable technical and organizational means. Furthermore, the role of processor does not stem from the nature of an actor processing personal data but from its concrete activities in a specific context and with regard to specific sets of data or operations. Some criteria may be helpful in determining the qualification of the various actors involved in the processing: the level of prior instruction given by the data controller; the monitoring by the data controller of the level of the service; the visibility towards data subjects; the expertise of the parties; the autonomous decision-making power left to the various parties. The residual category of "third party" is defined as any actor who has no specific legitimacy or authorization - which could stem, for example, from its role as controller, processor, or their employee - in processing personal data. * * * The Working Party recognises the difficulties in applying the definitions of the Directive in a complex environment, where many scenarios can be foreseen involving controllers and processors, alone or jointly, with different degrees of autonomy and responsibility. In its analysis, it has emphasized the need to allocate responsibility in such a way that compliance with data protection rules will be sufficiently ensured in practice. However, it has not found any reason to think that the current distinction between controllers and processors would no longer be relevant and workable in that perspective. The Working Party therefore hopes that the explanations given in this opinion, illustrated with specific examples taken from the daily experience of data protection authorities, will contribute to effective guidance on the way to interpret these core definitions of the Directive. Done in Brussels, on 16 February 2010 For the Working Party, The Chairman Jacob KOHNSTAMM 33
605
ARTICLE 29 DATA PROTECTION WORKING PARTY
01248/07/EN WP 136
Opinion 4/2007 on the concept of personal data
Adopted on 20th June
This Working Party was set up under Article 29 of Directive 95/46/EC. It is an independent European advisory body on data protection and privacy. Its tasks are described in Article 30 of Directive 95/46/EC and Article 15 of Directive 2002/58/EC. The secretariat is provided by Directorate C (Civil Justice, Rights and Citizenship) of the European Commission, Directorate General Justice, Freedom and Security, B-1049 Brussels, Belgium, Office No LX-46 01/43. Website: http://ec.europa.eu/justice_home/fsj/privacy/index_en.htm
606
THE WORKING PARTY ON THE PROTECTION OF INDIVIDUALS WITH REGARD TO THE PROCESSING OF PERSONAL DATA
set up by Directive 95/46/EC of the European Parliament and of the Council of 24 October 19951, having regard to Articles 29 and 30 paragraphs 1 (a) and 3 of that Directive, and Article 15 paragraph 3 of Directive 2002/58/EC of the European Parliament and of the Council of 12 July 2002 having regard to Article 255 of the EC Treaty and to Regulation (EC) no 1049/2001 of the European Parliament and of the Council of 30 May 2001 regarding public access to European Parliament, Council and Commission documents having regard to its Rules of Procedure HAS ADOPTED THE PRESENT OPINION:
1
Official Journal No. L 281 of 23.11.1995, p. 31, available at: http://europa.eu.int/comm/internal_market/en/media/dataprot/index.htm - 2-
607
I.
INTRODUCTION ....................................................................................................3
II.
GENERAL CONSIDERATIONS AND POLICY ISSUES..................................4
III. ANALYSIS OF THE DEFINITION OF “PERSONAL DATA” ACCORDING TO THE DATA PROTECTION DIRECTIVE...........................6 1.
FIRST ELEMENT: “ANY INFORMATION ............................................................6
2.
SECOND ELEMENT: “RELATING TO” ................................................................9
3.
THIRD ELEMENT: “IDENTIFIED OR IDENTIFIABLE” [NATURAL PERSON] .................................................................................................................12
4.
FOURTH ELEMENT: “NATURAL PERSON” .....................................................21
IV. WHAT HAPPENS IF THE DATA FALL OUTSIDE OF THE DEFINITION?........................................................................................................24 V.
CONCLUSIONS.....................................................................................................25
I. INTRODUCTION The Working Party is aware of the need to conduct a deep analysis of the concept of personal data. Information about current practice in EU Member States suggests that there is some uncertainty and some diversity in practice among Member States as to important aspects of this concept which may affect the proper functioning of the existing data protection framework in different contexts. The outcome of this analysis of a central element for the application and interpretation of data protection rules is bound to have a profound impact on a number of important issues, and will be particularly relevant for topics such as Identity Management in the context of e-Government and e-Health, as well as in the RFID context. The objective of the present opinion of the Working Party is to come to a common understanding of the concept of personal data, the situations in which national data protection legislation should be applied, and the way it should be applied. Working on a common definition of the notion of personal data is tantamount to defining what falls inside or outside the scope of data protection rules. A corollary of this work is to provide guidance on the way national data protection rules should be applied to certain categories of situations occurring Europe-wide, thus contributing to the uniform application of such norms, which is a core function of the Article 29 Working Party. This document makes use of examples drawn from the national practice of European DPAs to support and illustrate the analysis. Most examples have only been edited for proper use in this context. - 3-
608
II. GENERAL CONSIDERATIONS AND POLICY ISSUES The Directive contains a broad notion of personal data The definition of personal data contained in Directive 95/46/EC (henceforth "the data protection Directive" or "the Directive") reads as follows: “Personal data shall mean any information relating to an identified or identifiable natural person (“data subject”); an identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity”. It needs to be noted that this definition reflects the intention of the European lawmaker for a wide notion of "personal data", maintained throughout the legislative process. The Commission's original proposal explained that "as in Convention 108, a broad definition is adopted in order to cover all information which may be linked to an individual"2. The Commission's modified proposal noted that "the amended proposal meets Parliament's wish that the definition of "personal data" should be as general as possible, so as to include all information concerning an identifiable individual"3, a wish that also the Council took into account in the common position4. The objective of the rules contained in the Directive is to protect individuals. Articles 1 of Directive 95/46/EC and of Directive 2002/58/EC clearly state the ultimate purpose of the rules contained therein: to protect the fundamental rights and freedoms of natural persons and in particular their right to privacy, with regard to the processing of personal data. This is a very important element to take into account in the interpretation and application of the rules of both instruments. It may play a substantive role in determining how to apply the provisions of the Directive to a number of situations where the rights of individuals are not at risk, and it may caution against any interpretation of the same rules that would leave individuals deprived of protection of their rights. The scope of application of the Directive excludes a number of activities, and flexibility is embedded in the text to provide an appropriate legal response to the circumstances at stake Despite the broad concept of ‘personal data' and of 'processing’ contained in the Directive, the mere fact that a certain situation may be considered as involving 'the processing of personal data' in the sense of the definition does not alone determine that this situation is to be subject to the rules of the Directive, in particular pursuant to Article 3 thereof. Apart from exemptions due to the remit of community law, the exemptions under Article 3 take into account the technical way of processing (in manual non-structured form) and the intention of use (for purely personal or household activities by a natural person). Even where processing of personal data within the scope of the Directive is involved, not all the rules contained therein may be applicable in the particular case. A number of provisions of the Directive contain a substantial degree of 2 3 4
COM (90) 314 final, 13.9.1990, p. 19 (commentary on Article 2) COM (92) 422 final, 28.10.1992, p. 10 (commentary on Article 2) Common position (EC) No 1/95, adopted by the Council on 20 February 1995, OJ NO C 93 of 13.4.1995, p.20 - 4-
609
flexibility, so as to strike the appropriate balance between protection of the data subject’s rights on the one side, and on the other side the legitimate interests of data controllers, third parties and the public interest which may be present. Some examples of such provisions are contained in Article 6 (retention period depending on data being necessary), 7.f (balance of interest to justify processing), last paragraph of 10 (c) and 11.1 (c) (information to the data subject where necessary to guarantee fair processing), or 18 (exemptions from notification requirements), just to mention a few cases. The scope of the data protection rules should not be overstretched An undesirable result would be that of ending up applying data protection rules to situations which were not intended to be covered by those rules and for which they were not designed by the legislator. The material exemptions under Article 3 mentioned above and the clarifications in recitals 26 and 27 of the Directive show how the legislator wanted to see data protection applied. One limitation concerns the way of processing data. It is useful to recall that the reasons for enacting the first data protection laws in the seventies stemmed from the fact that new technology in the form of electronic data processing allows easier and more widespread access to personal data than the traditional forms of data handling. Consequently data protection under the Directive aims at protecting such forms of processing which are typical for a higher risk of “easy access to personal data” (recital 27). The processing of personal data by non-automatic means is only included within the scope of the Directive where the data form part of a filing system or are intended to form part of such system (Article 3). Another general limitation for the application of data protection under the Directive would be processing of data under circumstances, where means for identifying the data subject are not “likely reasonably to be used” (recital 26), an issue which will be discussed later. But unduly restricting the interpretation of the concept of personal data should also be avoided. In those cases where a mechanistic application of every single provision of the Directive would at first sight lead to excessively burdensome or perhaps even absurd consequences, it must be first checked 1) whether the situation falls within the scope of the Directive, in particular in accordance to Article 3 thereof; and 2) where it falls within its scope, whether the Directive itself or national legislation adopted pursuant to it do not allow for exemptions or simplifications with regard to particular situations in order to achieve an appropriate legal response while ensuring the protection of the individual’s rights and of the interests at stake. It is a better option not to unduly restrict the interpretation of the definition of personal data but rather to note that there is considerable flexibility in the application of the rules to the data. National Data Protection Supervisory Authorities play an essential role in this respect in the framework of their missions of monitoring the application of data protection law, which involves providing interpretation of legal provisions and concrete guidance to controllers and data subjects. They should endorse a definition that is wide enough so that it can anticipate evolutions and catch all “shadow zones” within its scope, while making legitimate use of the flexibility contained in the Directive. In fact, the text of the Directive invites to the development of a policy that combines a wide interpretation - 5-
610
of the notion of personal data and an appropriate balance in the application of the Directive’s rules. III. ANALYSIS OF THE DEFINITION OF “PERSONAL DATA”
ACCORDING TO THE DATA PROTECTION DIRECTIVE The definition in the Directive contains four main building blocks, which will be analyzed separately for the purposes of this document. They are the following ones: -
“any information”
-
“relating to”
-
“an identified or indentifiable”
-
“natural person”
Those four building blocks are closely intertwined and feed on each other. However, for the sake of the methodology to be followed in this document, each of these items will be dealt with separately.
1. FIRST ELEMENT: “ANY INFORMATION The term “any information” contained in the Directive clearly signals the willingness of the legislator to design a broad concept of personal data. This wording calls for a wide interpretation. From the point of view of the nature of the information, the concept of personal data includes any sort of statements about a person. It covers "objective" information, such as the presence of a certain substance in one's blood. It also includes "subjective" information, opinions or assessments. This latter sort of statements make up a considerable share of personal data processing in sectors such as banking, for the assessment of the reliability of borrowers ("Titius is a reliable borrower"), in insurance ("Titius is not expected to die soon") or in employment ("Titius is a good worker and merits promotion"). For information to be 'personal data', it is not necessary that it be true or proven. In fact, data protection rules already envisage the possibility that information is incorrect and provide for a right of the data subject to access that information and to challenge it through appropriate remedies5. From the point of view of the content of the information, the concept of personal data includes data providing any sort of information. This covers of course personal information considered to be “sensitive data” in Article 8 of the directive because of its particularly risky nature, but also more general kinds of information. The term "personal data" includes information touching the individual’s private and family life “stricto sensu”, but also information regarding whatever types of activity is undertaken by the individual, like that concerning working relations or the economic or social behaviour of the individual. It includes therefore information on individuals, regardless
5
Rectification could be done by adding contrasting comments or by using the appropriate legal remedies, such as appeal mechanisms - 6-
611
of the position or capacity of those persons (as consumer, patient, employee, customer, etc). Example No. 1: Professional habits and practices Drug prescription information (e.g. drug identification number, drug name, drug strength, manufacturer, selling price, new or refill, reasons for use, reasons for no substitution order, prescriber's first and last name, phone number, etc.), whether in the form of an individual prescription or in the form of patterns discerned from a number of prescriptions, can be considered as personal data about the physician who prescribes this drug, even if the patient is anonymous. Thus, providing information about prescriptions written by identified or identifiable doctors to producers of prescription drugs constitutes a communication of personal data to third party recipients in the meaning of the Directive. This interpretation is supported by the wording of the Directive itself. On the one hand, it has to be considered that the concept of private and family life is a wide one, as the European Court on Human Rights has made clear6. On the other hand, the rules on protection of personal data go beyond the protection of the broad concept of the right to respect for private and family life. It should be noted that the Charter of Fundamental Rights of the European Union enshrines the protection of personal data in Article 8 as an autonomous right, separate and different from the right to private life referred to in Article 7 thereof and the same is the case at national level in some Member States. This is consistent with the terms of Article 1.1, aimed at protecting “the fundamental rights and freedoms of natural persons, and in particular [but not exclusively] their right to privacy”. Accordingly, the Directive makes particular reference to the processing of personal data in contexts outside of the home and family, like that provided for by labour law (Article 8.2 (b)), criminal convictions, administrative sanctions or judgements in civil cases (Article 8.5) or direct marketing (Article 14 (b)). The European Court of Justice7 has endorsed this broad approach. Considering the format or the medium on which that information is contained, the concept of personal data includes information available in whatever form, be it alphabetical, numerical, graphical, photographical or acoustic, for example. It includes information kept on paper, as well as information stored in a computer memory by means of binary code, or on a videotape, for instance. This is a logical consequence of covering automatic processing of personal data within its scope. In particular, sound and image data qualify as personal data from this point of view, insofar as they may represent information on an individual. In this regard, the particular reference to sound and image data in Article 33 of the Directive has to be understood as a confirmation 6
7
Judgement of the European Court of Human Rights in the case Amann v Switzerland of 16.2.2000, §65 : "[...] the term “private life” must not be interpreted restrictively. In particular, respect for private life comprises the right to establish and develop relationships with other human beings; furthermore, there is no reason of principle to justify excluding activities of a professional or business nature from the notion of “private life” (see the Niemietz v. Germany judgment of 16 December 1992, Series A no. 251-B, pp. 33-34, § 29, and the Halford judgment cited above, pp. 1015-16, § 42). That broad interpretation corresponds with that of the Council of Europe’s Convention of 28 January 1981 [...]" Judgment of the European Court of Justice C-101/2001of 6.11.2003 (Lindqvist), §24: "The term personal data used in Article 3(1) of Directive 95/46 covers, according to the definition in Article 2(a) thereof, any information relating to an identified or identifiable natural person. The term undoubtedly covers the name of a person in conjunction with his telephone coordinates or information about his working conditions or hobbies". - 7-
612
and clarification that this sort of data is indeed included within its scope (provided all the other conditions are fulfilled), and that the Directive applies to them. In fact, that is a logical assumption for the provision contained in this Article, which seeks to assess whether the rules of the Directive provide appropriate legal responses in those areas. This is further clarified by Recital 14, stating that "given the importance of the developments under way, in the framework of the information society, of the techniques used to capture, transmit, manipulate, record, store or communicate sound and image data relating to natural persons, this Directive should be applicable to processing involving such data". On the other hand, it is not necessary for the information to be considered as personal data that it is contained in a structured database or file. Also information contained in free text in an electronic document may qualify as personal data, provided the other criteria in the definition of personal data are fulfilled. E-mail will for example contain 'personal data'. Example No. 2: Telephone Banking: In telephone banking, where the customer's voice giving instructions to the bank are recorded on tape, those recorded instructions should be considered as personal data. Example No. 3: Videosurveillance Images of individuals captured by a video surveillance system can be personal data to the extent that the individuals are recognizable. Example No. 4: a child's drawing As a result of a neuro-psychiatric test conducted on a girl in the context of a court proceeding about her custody, a drawing made by her representing her family is submitted. The drawing provides information about the girl's mood and what she feels about different members of her family. As such, it could be considered as being â&#x20AC;&#x153;personal dataâ&#x20AC;?. The drawing will indeed reveal information relating to the child (her state of health from a psychiatric point of view) and also about e.g. her father's or motherâ&#x20AC;&#x2122;s behaviour. As a result, the parents in that case may be able to exert their right of access on this specific piece of information. Special reference should be made here to biometric data These data may be defined as biological properties, physiological characteristics, living traits or repeatable actions where those features and/or actions are both unique to that individual and measurable, even if the patterns used in practice to technically measure them involve a certain degree of probability. Typical examples of such biometric data are provided by fingerprints, retinal patterns, facial structure, voices, but also hand geometry, vein patterns or even some deeply ingrained skill or other behavioural characteristic (such as handwritten signature, keystrokes, particular way to walk or to speak, etc...) A particularity of biometric data is that they can be considered both as content of the information about a particular individual (Titius has these fingerprints) as well as an element to establish a link between one piece of information and the individual (this object has been touched by someone with these fingerprints and these fingerprints correspond to Titius; therefore this object has been touched by Titius). As such, they can work as "identifiers". Indeed, because of their unique link to a specific individual, biometric data may be used to identify the individual. This dual character appears also - 8-
613
in the case of DNA data, providing information about the human body and allowing unambiguous and unique identification of a person. Human tissue samples (like a blood sample) are themselves sources out of which biometric data are extracted, but they are not biometric data themselves (as for instance a pattern for fingerprints is biometric data, but the finger itself is not). Therefore the extraction of information from the samples is collection of personal data, to which the rules of the Directive apply. The collection, storage and use of tissue samples themselves may be subject to separate sets of rules8.
2. SECOND ELEMENT: “RELATING TO” This building block of the definition is crucial as it is very important to precisely find out which are the relations/links that matter and how to distinguish them. In general terms, information can be considered to “relate” to an individual when it is about that individual. In many situations, this relationship can be easily established. For instance the data registered in one’s individual file in the personnel office are clearly “related to” the person’s situation as an employee. So are the data on the results of a patient's medical test contained in his medical records, or the image of a person filmed on a video interview of that person. A number of other situations can be mentioned, though, where it is not always as selfevident as in the previous cases to determine that the information “relates” to an individual. In some situations, the information conveyed by the data concerns objects in the first instance, and not individuals. Those objects usually belong to someone, or may be subject to particular influence by or upon individuals or may maintain some sort of physical or geographical vicinity with individuals or with other objects. It is then only indirectly that it can be considered that the information relates to those individuals or those objects. Example No. 5: the value of a house The value of a particular house is information about an object. Data protection rules will clearly not apply when this information will be used solely to illustrate the level of real estate prices in a certain district. However, under certain circumstances such information should also be considered as personal data. Indeed, the house is the asset of an owner, which will hence be used to determine the extent of this person’s obligation to pay some taxes, for instance. In this context, it will be indisputable that such information should be considered as personal data. A similar analysis is applicable where the data are about processes or events in the first place, for instance information on the functioning of a machine where human intervention is required. Under some circumstances, this information may also be considered as "relating" to an individual.
8
See Council of Europe Recommendation No. Rec (2006) 4 of the Committee of Ministers to Member States on research on biological materials of human origin, of 15.3.2006 - 9-
614
Example No. 6: car service record The service register of a car held by a mechanic or garage contains the information about the car, mileage, dates of service checks, technical problems, and material condition. This information is associated in the record with a plate number and an engine number, which in turn can be linked to the owner. Where the garage establishes a connection between the vehicle and the owner, for the purpose of billing, information will "relate" to the owner or to the driver. If the connection is made with the mechanic that worked on the car with the purpose of ascertaining his productivity, this information will also "relate" to the mechanic. The Working Party has already paid attention to the issue of when the information may be considered as "relating" to a person. In the context of discussions on the data protection issues raised by RFID tags, the Working Party noted that "data relates to an individual if it refers to the identity, characteristics or behaviour of an individual or if such information is used to determine or influence the way in which that person is treated or evaluated9." In view of the cases mentioned above, and along the same lines, it could be pointed out that, in order to consider that the data “relate” to an individual, a "content" element OR a "purpose" element OR a "result" element should be present. The “content” element is present in those cases where - corresponding to the most obvious and common understanding in a society of the word "relate" - information is given about a particular person, regardless of any purpose on the side of the data controller or of a third party, or the impact of that information on the data subject. Information "relates" to a person when it is "about" that person, and this has to be assessed in the light of all circumstances surrounding the case. For example, the results of medical analysis clearly relate to the patient, or the information contained in a company's folder under the name of a certain client clearly relates to him. Or the information contained in a RFID tag or a bar code incorporated in an identity document of a certain individual relates to that person, as in future passports with a RFID chip. Also a "purpose" element can be responsible for the fact that information "relates" to a certain person. That “purpose” element can be considered to exist when the data are used or are likely to be used, taking into account all the circumstances surrounding the precise case, with the purpose to evaluate, treat in a certain way or influence the status or behaviour of an individual.
9
Working Party document No WP 105: "Working document on data protection issues related to RFID technology", adopted on 19.1.2005, p. 8. -10-
615
Example No. 7: call log for a telephone The call log of a telephone inside a company office provides information about the calls that have been made from that telephone connected to a certain line. That information can be brought into relation with different subjects. On the one hand, the line has been made available to the company, and the company is contractually obliged to pay those calls. The phone set is under the control of a certain employee during working times and calls are supposed to be made by him. The call log may also provide information about the person who was called. The phone can also be used by whatever person is allowed into the premises in the absence of the employee (e.g. by cleaning staff). For different purposes, the information on the use of that phone set can be related to the company, the employee, or the cleaning staff (for instance to check the time cleaning staff leave their workplace, as they are supposed to confirm by phone at what time they leave before locking the premises). It should be mentioned that the concept of personal data extends here to both outgoing and incoming calls insofar as all of them contain information concerning people's private life, social relationships and communications. A third kind of 'relating' to specific persons arises when a "result" element is present. Despite the absence of a "content" or "purpose" element, data can be considered to "relate" to an individual because their use is likely to have an impact on a certain person's rights and interests, taking into account all the circumstances surrounding the precise case. It should be noted that it is not necessary that the potential result be a major impact. It is sufficient if the individual may be treated differently from other persons as a result of the processing of such data. Example No. 8: monitoring of taxis' position to optimize service having an impact on drivers. A system of satellite location is set up by a taxi company which makes it possible to determine the position of available taxis in real time. The purpose of the processing is to provide better service and save fuel, by assigning to each client ordering a cab the car that is closest to the clientâ&#x20AC;&#x2122;s address. Strictly speaking the data needed for that system is data relating to cars, not about the drivers. The purpose of the processing is not to evaluate the performance of taxi drivers, for instance through the optimization of their itineraries. Yet, the system does allow monitoring the performance of taxi drivers and checking whether they respect speed limits, seek appropriate itineraries, are at the steering wheel or are resting outside, etc. It can therefore have a considerable impact on these individuals, and as such the data may be considered to also relate to natural persons. The processing should be subject to data protection rules. These three elements (content, purpose, result) must be considered as alternative conditions, and not as cumulative ones. In particular, where the content element is present, there is no need for the other elements to be present to consider that the information relates to the individual. A corollary of this is that the same piece of information may relate to different individuals at the same time, depending on what element is present with regard to each one. The same information may relate to individual Titius because of the "content" element (the data is clearly about Titius), AND to Gaius because of the "purpose" element (it will be used in order to treat Gaius in a certain way) AND to Sempronius because of the "result" element (it is likely to -11-
616
have an impact on the rights and interests of Sempronius). This means also that it is not necessary that the data "focuses" on someone in order to consider that it relates to him. Resulting from the previous analysis, the question of whether data relate to a certain person is something that has to be answered for each specific data item on its own merits. In a similar way, the fact that information may relate to different persons should be kept in mind in the application of substantive provisions (e.g. on the scope of the right of access). Example No. 9: information contained in the minutes of a meeting. An example of the need to perform the previous analysis with regard to each piece of information separately concerns the information contained in the minutes of a meeting, recording typically the attendance of participants Titius, Gaius and Sempronius; the statements made by Titius and Gaius; and a report of proceedings on certain topics as summarized by the author of the minutes, Sempronius. As personal data relating to Titius one can only consider the information that he attended the meeting at a certain time and place, and that he made certain statements. The presence in the meeting of Gaius, his statements and the proceedings about an issue as summarized by Sempronius are NOT personal data relating to Titius. This is so even if this information is contained in the same document, and even if it was Titius who triggered the issue to be discussed at the meeting. It is therefore excluded from Titius' right of access to his own personal data. Whether and to what extent that information can be considered as personal data of Gaius and Sempronius will have to be determined separately, using the analysis described before.
3. THIRD ELEMENT: [NATURAL PERSON]
“IDENTIFIED
OR
IDENTIFIABLE”
The Directive requires that the information relate to a natural person that is “identified or identifiable”. This raises the following considerations. In general terms, a natural person can be considered as “identified” when, within a group of persons, he or she is "distinguished" from all other members of the group. Accordingly, the natural person is “identifiable” when, although the person has not been identified yet, it is possible to do it (that is the meaning of the suffix "-able"). This second alternative is therefore in practice the threshold condition determining whether information is within the scope of the third element. Identification is normally achieved through particular pieces of information which we may call “identifiers” and which hold a particularly privileged and close relationship with the particular individual. Examples are outward signs of the appearance of this person, like height, hair colour, clothing, etc… or a quality of the person which cannot be immediately perceived, like a profession, a function, a name etc. The Directive mentions those “identifiers” in the definition of “personal data” in Article 2 when it states that a natural person "can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity". "Directly" or "indirectly" identifiable Further clarification is contained in the commentary to the Articles of the amended Commission proposal, in the sense that "a person may be identified directly by name or -12-
617
indirectly by a telephone number, a car registration number, a social security number, a passport number or by a combination of significant criteria which allows him to be recognized by narrowing down the group to which he belongs (age, occupation, place of residence, etc.)". The terms of this statement clearly indicate that the extent to which certain identifiers are sufficient to achieve identification is something dependent on the context of the particular situation. A very common family name will not be sufficient to identify someone - i.e. to single someone out - from the whole of a country's population, while it is likely to achieve identification of a pupil in a classroom. Even ancillary information, such as "the man wearing a black suit" may identify someone out of the passers-by standing at a traffic light. So, the question of whether the individual to whom the information relates is identified or not depends on the circumstances of the case. Concerning "directly" identified or identifiable persons, the name of the person is indeed the most common identifier, and, in practice, the notion of “identified person” implies most often a reference to the person’s name. In order to ascertain this identity, the name of the person sometimes has to be combined with other pieces of information (date of birth, names of the parents, address or a photograph of the face) to prevent confusion between that person and possible namesakes. For example, the information that a sum of money is owed by Titius can be considered to relate to an identified individual because it is linked with the name of the person. The name is a piece of information that reveals that the individual uses that combination of letters and sounds to distinguish himself and be distinguished by other persons with whom he establishes relations. The name may also be the starting point leading to information about where the person lives or can be found, may also give information about the persons in his family (through the family name) and a number of different legal and social relations associated with that name (education records, medical records, bank accounts). It may even be possible to know the appearance of the person if his picture is associated with that name. All these new pieces of information linked to the name may allow someone to zoom in on the flesh and bone individual, and therefore through the identifiers the original information is associated with a natural person who can be distinguished from other individuals. As regards "indirectly" identified or identifiable persons, this category typically relates to the phenomenon of "unique combinations", whether small or large in size. In cases where prima facie the extent of the identifiers available does not allow anyone to single out a particular person, that person might still be “identifiable” because that information combined with other pieces of information (whether the latter is retained by the data controller or not) will allow the individual to be distinguished from others . This is where the Directive comes in with "one or more factors specific to his physical, physiological, mental, economic, cultural or social identity". Some characteristics are so unique that someone can be identified with no effort ("present Prime Minister of Spain"), but a combination of details on categorical level (age category, regional origin, etc) may also be pretty conclusive in some circumstances, particularly if one has access to additional information of some sort. This phenomenon has been studied extensively by statisticians, always keen to avoid a breach of confidentiality.
-13-
618
Example No. 10: fragmentary information in the press Information is published about a former criminal case which won much public attention in the past. In the present publication there is none of the traditional identifiers given, especially no name or date of birth of any person involved. It does not seem unreasonably difficult to gain additional information allowing one to find out who the persons mainly involved are, e.g. by looking up newspapers from the relevant time period. Indeed, it can be assumed that it is not completely unlikely that somebody would take such measures (as looking up old newspapers) which would most likely provide names and other identifiers for the persons referred to in the example. It seems therefore justified to consider the information in the given example as being ‘information about identifiable persons’ and as such ‘personal data’. At this point, it should be noted that, while identification through the name is the most common occurrence in practice, a name may itself not be necessary in all cases to identify an individual. This may happen when other "identifiers" are used to single someone out. Indeed, computerised files registering personal data usually assign a unique identifier to the persons registered, in order to avoid confusion between two persons in the file. Also on the Web, web traffic surveillance tools make it easy to identify the behaviour of a machine and, behind the machine, that of its user. Thus, the individual’s personality is pieced together in order to attribute certain decisions to him or her. Without even enquiring about the name and address of the individual it is possible to categorise this person on the basis of socio-economic, psychological, philosophical or other criteria and attribute certain decisions to him or her since the individual’s contact point (a computer) no longer necessarily requires the disclosure of his or her identity in the narrow sense. In other words, the possibility of identifying an individual no longer necessarily means the ability to find out his or her name. The definition of personal data reflects this fact10. The European Court of Justice has spoken in that sense when considering that "referring, on an internet page, to various persons and identifying them by name or by other means, for instance by giving their telephone number or information regarding their working conditions and hobbies, constitutes the processing of personal data [...] within the meaning of [...] Directive 95/46/CE"11. Example No. 11: asylum seekers Asylum seekers hiding their real names in a sheltering institution have been given a code number for administrative purposes. That number will serve as an identifier, so that different pieces of information concerning the stay of the asylum seeker in the institution will be attached to it, and by means of a photograph or other biometric indicators, the code number will have a close and immediate connection to the physical person, thus allowing him to be distinguished from other asylum seekers and to have attributed to him different pieces of information, which will then refer to an “identified” natural person. 10
11
Report on the application of data protection principles to the worldwide telecommunication networks, by Mr Yves POULLET and his team, for the Council of Europe's T-PD Committee, point 2.3.1, T-PD (2004) 04 final Judgment of the European Court of Justice C-101/2001of 06.11.2003 (Lindqvist), §27 -14-
619
Article 8.7 also provides that “Member States shall determine the conditions under which a national identification number or any other identifiers of general application may be processed”. It is worthwhile noting the sense of this provision, which does not contain any particular indication of what sort of conditions Member States should adopt, but still is placed in the Article dealing with sensitive data. Recital 33 refers to this sort of data as “data which are capable by their nature of infringing fundamental freedoms or privacy”. It is reasonable to think that the legislator may have felt similar concerns regarding national identification numbers due to their strong potential for easily and unequivocally connecting different pieces of information about a given individual. Means to identify Recital 26 of the Directive pays particular attention to the term "identifiable" when it reads that “whereas to determine whether a person is identifiable account should be taken of all the means likely reasonably to be used either by the controller or by any other person to identify the said person.” This means that a mere hypothetical possibility to single out the individual is not enough to consider the person as “identifiable”. If, taking into account “all the means likely reasonably to be used by the controller or any other person”, that possibility does not exist or is negligible, the person should not be considered as “identifiable”, and the information would not be considered as “personal data”. The criterion of “all the means likely reasonably to be used either by the controller or by any other person" should in particular take into account all the factors at stake. The cost of conducting identification is one factor, but not the only one. The intended purpose, the way the processing is structured, the advantage expected by the controller, the interests at stake for the individuals, as well as the risk of organisational dysfunctions (e.g. breaches of confidentiality duties) and technical failures should all be taken into account. On the other hand, this test is a dynamic one and should consider the state of the art in technology at the time of the processing and the possibilities for development during the period for which the data will be processed. Identification may not be possible today with all the means likely reasonably to be used today. If the data are intended to be stored for one month, identification may not be anticipated to be possible during the "lifetime" of the information, and they should not be considered as personal data. However, it they are intended to be kept for 10 years, the controller should consider the possibility of identification that may occur also in the ninth year of their lifetime, and which may make them personal data at that moment. The system should be able to adapt to these developments as they happen, and to incorporate then the appropriate technical and organisational measures in due course. Example No. 12: Publication of X-ray plates together with the patient's first name A lady's X-ray plate had been published in a scientific journal, together with the lady's first name, which was a very unusual one. The first name of the person, combined by the knowledge by their relatives or acquaintances that she suffered a certain ailment rendered the person identifiable to a number of persons, and the X-ray plate would then be considered as personal data. Example No. 13: pharmaceutical research data Hospitals or individual physicians transfer data from medical records of their patients to a company for the purposes of medical research. No names of the patients are used but only serial numbers attributed randomly to each clinical case, in order to ensure -15-
620
coherence and to avoid confusion with information on different patients.. The names of patients stay exclusively in possession of the respective doctors bound by medical secrecy. The data do not contain any additional information which make identification of the patients possible by combining it. In addition, all other measures have been taken to prevent the data subjects from being identified or becoming identifiable, be it legal, technical or organizational. Under these circumstances, a Data Protection Authority may consider that no means are present in the processing performed by the pharmaceutical company, which make it likely reasonably to be used to identify the data subjects. One relevant factor, as mentioned before, for assessing "all the means likely reasonably to be used" to identify the persons will in fact be the purpose pursued by the data controller in the data processing. National Data Protection Authorities have been confronted with cases where, on the one hand, the controller argues that only scattered pieces of information are processed, without reference to a name or any other direct identifiers, and advocates that the data should not be considered as personal data and not be subject to the data protection rules. On the other hand, the processing of that information only makes sense if it allows identification of specific individuals and treatment of them in a certain way. In these cases, where the purpose of the processing implies the identification of individuals, it can be assumed that the controller or any other person involved have or will have the means "likely reasonably to be used" to identify the data subject. In fact, to argue that individuals are not identifiable, where the purpose of the processing is precisely to identify them, would be a sheer contradiction in terms. Therefore, the information should be considered as relating to identifiable individuals and the processing should be subject to data protection rules. Example No. 14: Videosurveillance This is particularly relevant in the context of video surveillance, where controllers often argue that identification would only happen in a small percentage of the material collected and therefore before identification in these few instances actually takes place no personal data are processed. As the purpose of video surveillance is, however, to identify the persons to be seen in the video images in all cases where such identification is deemed necessary by the controller, the whole application as such has to be considered as processing data about identifiable persons, even if some persons recorded are not identifiable in practice. Example No. 15: dynamic IP addresses The Working Party has considered IP addresses as data relating to an identifiable person. It has stated that "Internet access providers and managers of local area networks can, using reasonable means, identify Internet users to whom they have attributed IP addresses as they normally systematically “log” in a file the date, time, duration and dynamic IP address given to the Internet user. The same can be said about Internet Service Providers that keep a logbook on the HTTP server. In these cases there is no doubt about the fact that one can talk about personal data in the sense of Article 2 a) of the Directive …)”12
12
WP 37: Privacy on the Internet - An integrated EU Approach to On-line Data Protection- adopted on 21.11.2000 -16-
621
Especially in those cases where the processing of IP addresses is carried out with the purpose of identifying the users of the computer (for instance, by Copyright holders in order to prosecute computer users for violation of intellectual property rights), the controller anticipates that the "means likely reasonably to be used" to identify the persons will be available e.g. through the courts appealed to (otherwise the collection of the information makes no sense), and therefore the information should be considered as personal data. A particular case would be that of some sorts of IP addresses which under certain circumstances indeed do not allow identification of the user, for various technical and organizational reasons. One example could be the IP addresses attributed to a computer in an internet cafĂŠ, where no identification of the customers is requested. It could be argued that the data collected on the use of computer X during a certain timeframe does not allow identification of the user with reasonable means, and therefore it is not personal data. However, it should be noted that the Internet Service Providers will most probably not know either whether the IP address in question is one allowing identification or not, and that they will process the data associated with that IP in the same way as they treat information associated with IP addresses of users that are duly registered and are identifiable. So, unless the Internet Service Provider is in a position to distinguish with absolute certainty that the data correspond to users that cannot be identified, it will have to treat all IP information as personal data, to be on the safe side. Example No. 16: damage caused by graffiti Passenger vehicles owned by a transportation company suffer repeated damage when they are dirtied with graffiti. In order to evaluate the damage and to facilitate the exercise of legal claims against their authors, the company organises a register containing information about the circumstances of the damage, as well as images of the damaged items and of the "tags" or "signature" of the author. At the moment of entering the information into the register, the authors of the damage are not known nor to whom the "signature" corresponds. It may well happen that it will never be known. However, the purpose of the processing is precisely to identify individuals to whom the information relates as the authors of the damage, so as to be able to exercise legal claims against them. Such processing makes sense if the data controller expects as "reasonably likely" that there will one day be means to identify the individual. The information contained in the pictures should be considered as relating to "identifiable" individuals, the information in the register as "personal data", and the processing should be subject to the data protection rules, which allow such processing as legitimate under certain circumstances and subject to certain safeguards. Where identification of the data subject is not included in the purpose of the processing, the technical measures to prevent identification have a very important role to play. Putting in place the appropriate state-of-the-art technical and organizational measures to protect the data against identification may make the difference to consider that the persons are not identifiable, taking account of all the means likely reasonably to be used by the controller or by any other person to identify the individuals. In this case, the implementation of those measures are not the consequence of a legal obligation arising from Article 17 of the Directive (which only applies if the information is personal data in the first place), but rather a condition for the information precisely not to be considered to be personal data and its processing not to be subject to the Directive. -17-
622
Pseudonymised data Pseudonymisation is the process of disguising identities. The aim of such a process is to be able to collect additional data relating to the same individual without having to know his identity. This is particularly relevant in the context of research and statistics. Pseudonymisation can be done in a retraceable way by using correspondence lists for identities and their pseudonyms or by using two-way cryptography alorythms for pseudonymisation. Disguising identities can also be done in a way that no reidentification is possible, e.g. by one-way cryptography, which creates in general anonymised data. The effectiveness of the pseudonymisation procedure depends on a number of factors (at which stage it is used, how secure it is against reverse tracing, the size of the population in which the individual is concealed, the ability to link individual transactions or records to the same person, etc.). Pseudonyms should be random and unpredictable. The number of pseudonyms possible should be so large that the same pseudonym is never randomly selected twice. If a high level of security is required, the set of potential pseudonyms must be at least equal to the range of values of secure cryptographic hash functions13. Retraceably pseudonymised data may be considered as information on individuals which are indirectly identifiable. Indeed, using a pseudonym means that it is possible to backtrack to the individual, so that the individualâ&#x20AC;&#x2122;s identity can be discovered, but then only under predefined circumstances. In that case, although data protection rules apply, the risks at stake for the individuals with regard to the processing of such indirectly identifiable information will most often be low, so that the application of these rules will justifiably be more flexible than if information on directly identifiable individuals were processed. Key-Coded data Key-coded data are a classical example of pseudonimisation. Information relates to individuals that are earmarked by a code, while the key making the correspondence between the code and the common identifiers of the individuals (like name, date of birth, address) is kept separately. Example No. 17: non-aggregated data for statistics An example to illustrate the importance of taking into account all the circumstances to assess whether the means for identification are "likely reasonably" to be used could be that of personal information processed by the national institute for statistics, where, at a certain stage, the information is kept in non-aggregated form and relates to specific individuals, but these are designated with a code instead of a name (e.g. the individual coded X1234 drinks a glass of wine more than 3 times a week). The institute for statistics keeps separately the key to these codes (the list associating the codes with the names of the persons). That key can be considered to be "likely reasonably to be used" by the institute for statistics, and therefore the set of individual-related information can be considered as personal data and should be subject to the data protection rules by the 13
See the Working document â&#x20AC;&#x153;Privacy-enhancing technologies" by the Working Group on "privacy enhancing technologies" of the Committee on "Technical and organisational aspects of data protection" of the German Federal and State Data Protection Commissioners (October 1997), published on http://ec.europa.eu/justice_home/fsj/privacy/studies/index_en.htm -18-
623
institute. Now, we can imagine that a list with data about wine drinking habits of consumers is transferred to the national wine-producer organization in order to enable them to back up their public stance by statistical figures. To determine whether that list of information is still personal data, it should be assessed whether the individual wine consumers can be identified "taking into account all the means likely reasonably to be used by the controller or any other person". If the codes used are unique for each specific person, the risk of identification occurs whenever it is possible to get access to the key used for the encryption. Therefore the risks of an external hack, the likelihood that someone within the senderâ&#x20AC;&#x2122;s organization despite his professional secrecy - would provide the key and the feasibility of indirect identification are factors to be taken into account to determine whether the persons can be identified taking into account all the means likely reasonably to be used by the controller or any other person, and therefore whether information should be considered as "personal data". If they are, the data protection rules will apply. A different question is that those data protection rules could take into account whether risks for the individuals are reduced, and make processing subject to more or less strict conditions, based on the flexibility allowed by the rules of the Directive. If, on the contrary, the codes are not unique, but the same code number (e.g. "123") is used to designate individuals in different towns, and for data from different years (only distinguishing a particular individual within a year and within the sample in the same city), the controller or a third party could only identify a specific individual if they knew to what year and to what town the data refer. If this additional information has disappeared, and it is not likely reasonably to be retrieved, it could be considered that the information does not refer to identifiable individuals and would not be subject to the data protection rules. This sort of data is commonly used in clinical trials with medicines. Directive 2001/20 of 4 April 2001 on the implementation of good clinical practice and the conduct of clinical trials14 lays down a legal framework for the pursuit of these activities. The medical professional/researcher ("investigator") testing the medicines collects the information about clinical results on each patient, earmarking him with a code. The researcher provides the information to the pharmaceutical company or other parties involved ("sponsors") only in this coded form, as they are only interested in biostatistical information. However, the investigator keeps separately a key associating this code with common information to identify the patients in a separate way. To protect the health of patients in case the medicines turn out to pose dangers, the investigator is obliged to keep this key, so that individual patients may be identified in case of need and receive appropriate treatment. The question here is whether the data used for the clinical trial can be considered to relate to "identifiable" natural persons and thus be subject to the data protection rules. According to the analysis described before, to determine whether a person is identifiable account should be taken of all the means likely reasonably to be used either by the controller or by any other person to identify the said person. In this case, the identification of individuals (to apply the appropriate treatment in case of need) is one of the purposes of the processing of the key-coded data. The pharmaceutical company has construed the means for the processing, included the organisational measures and its relations with the researcher who holds the key in such a way that the identification 14
JO L 121 du 1.5.2001, p. 34.
-19-
624
of individuals is not only something that may happen, but rather as something that must happen under certain circumstances. The identification of patients is thus embedded in the purposes and the means of the processing. In this case, one can conclude that such key-coded data constitutes information relating to identifiable natural persons for all parties that might be involved in the possible identification and should be subject to the rules of data protection legislation. This does not mean, though, that any other data controller processing the same set of coded data would be processing personal data, if within the specific scheme in which those other controllers are operating reidentification is explicitly excluded and appropriate technical measures have been taken in this respect. In other areas of research or of the same project, re-identification of the data subject may have been excluded in the design of protocols and procedure, for instance because there is no therapeutical aspects involved. For technical or other reasons, there may still be a way to find out to what persons correspond what clinical data, but the identification is not supposed or expected to take place under any circumstance, and appropriate technical measures (e.g. cryptographic, irreversible hashing) have been put in place to prevent that from happening. In this case, even if identification of certain data subjects may take place despite all those protocols and measures (due to unforeseeable circumstances such as accidental matching of qualities of the data subject that reveal his/her identity ), the information processed by the original controller may not be considered to relate to identified or identifiable individuals taking account of all the means likely reasonably to be used by the controller or by any other person. Its processing may thus not be subject to the provisions of the Directive. A different matter is that for the new controller who has effectively gained access to the identifiable information, it will undoubtedly be considered to be "personal data". FAQ 14-7 of the Safe Harbour Scheme The issue of key-coded data in pharmaceutical research has been addressed within the Safe Harbour Scheme15. FAQ 14-7 reads as follows: FAQ 14 - Pharmaceutical and Medical Products 7. Q: Invariably, research data are uniquely key-coded at their origin by the principal investigator so as not to reveal the identity of individual data subjects. Pharmaceutical companies sponsoring such research do not receive the key. The unique key code is held only by the researcher, so that he/she can identify the research subject under special circumstances (e.g. if follow-up medical attention is required). Does a transfer from the EU to the United States of data coded in this way constitute a transfer of personal data that is subject to the Safe Harbor Principles? 7. A: No. This would not constitute a transfer of personal data that would be subject to the Principles. The Working Party considers that this statement in the Safe Harbour scheme is not inconsistent with the reasoning explained above in favour of considering such information as personal data subject to the Directive. Actually, this FAQ is not sufficiently precise as it does not state to whom and under what conditions the data is transferred. The Working Party understands that the FAQ refers to the case where the 15
Commission Decision 2000/520/EC of 26.7.2000 - O. J. L 215/7 of 25.8.2000 -20-
625
key coded data is sent to a recipient in the US (for instance, the pharmaceutical company), which receives only key-coded data and will never be aware of the identity of the patients which is known and will be known in case of need for treatment only to the medical professional/researcher in the EU, but never to the company in the US. Anonymous data "Anonymous data" in the sense of the Directive can be defined as any information relating to a natural person where the person cannot be identified, whether by the data controller or by any other person, taking account of all the means likely reasonably to be used either by the controller or by any other person to identify that individual. "Anonymised data” would therefore be anonymous data that previously referred to an identifiable person, but where that identification is no longer possible. Recital 26 also refers to this concept when it reads that “the principles of protection shall not apply to data rendered anonymous in such a way that the data subject is no longer identifiable”. Again, the assessment of whether the data allow identification of an individual, and whether the information can be considered as anonymous or not depends on the circumstances, and a case-by-case analysis should be carried out with particular reference to the extent that the means are likely reasonably to be used for identification as described in Recital 26. This is particularly relevant in the case of statistical information, where despite the fact that the information may be presented as aggregated data, the original sample is not sufficiently large and other pieces of information may enable the identification of individuals. Example No. 18: Statistical surveys and combination of scattered information Apart from their general obligation to respect data protection rules, in order to ensure anonymity of the statistical surveys, statisticians are subjected to a specific duty of professional secrecy, and under those rules it is forbidden for them to publish non anonymous data. This obliges them to publish aggregated statistical data which cannot possibly be attributed to an identified person behind the statistics. This rule is particularly relevant concerning the publication of census data. In each situation a threshold should be determined under which it is deemed possible to identify the persons concerned. If a criterion appears to lead to identification in a given category of persons, however large (i.e. only one doctor operates in a town of 6000 inhabitants), this “discriminating” criterion should be dropped altogether or other criteria be added to “dilute” the results on a given person so as to allow for statistical secrecy. Example No. 19: Publication of video surveillance A shopkeeper installs a camera surveillance system in his shop. He publishes, in his shop, the pictures of thieves who have been caught by means of the camera surveillance system. After police intervention, he blanks out the faces of the thieves, by darkening them. However, even after this operation, there still exists a possibility that the persons on the photos can be recognized by their friends, relatives or neighbours, because of the fact that e.g. their figure, haircut and clothes are still recognizable.
4. FOURTH ELEMENT: “NATURAL PERSON” The protection afforded by the rules of the Directive applies to natural persons, that is, to human beings. The right to the protection of personal data is, in that sense, a universal one that is not restricted to nationals or residents in a certain country. Recital -21-
626
2 of the Directive explicitly makes this point by stating that “data processing systems are designed to serve man” and that they “must, whatever the nationality or residence of natural persons, respect their fundamental rights and freedoms”. The concept of natural person is referred to in Article 6 of the Universal Declaration of Human Rights, according to which “Everyone has the right to recognition everywhere as a person before the law”. Member States’ legislation, usually in the field of Civil Law, outlines more precisely the concept of personality of human beings, understood as the capacity to be the subject of legal relations, starting with the birth of the individual and ending with his death. Personal data are therefore data relating to identified or identifiable living individuals in principle. This raises a number of questions for the purposes of this analysis. Data on dead persons Information relating to dead individuals is therefore in principle not to be considered as personal data subject to the rules of the Directive, as the dead are no longer natural persons in civil law. However, the data of the deceased may still indirectly receive some protection in certain cases. On the one hand, the data controller may not be in a position to ascertain whether the person to whom the data relate is still living or may be dead. Or even if he may do so, the information on the dead may be processed under the same regime as that on the living without distinction. As the data controller is subject to the data protection obligations imposed by the Directive as regards the data on living individuals, it will probably be easier for him in practice to process also the data on the dead in the way imposed by the data protection rules, rather than to separate the two sets of data. On the other hand, the information on dead individuals may also refer to living persons. For instance, the information that the dead Gaia suffered from haemophilia indicates that her son Titius also suffers from the same disease, as it is linked to a gene contained in the X-chromosome. Thus, where the information which is data on the dead can be considered to relate at the same time also to the living and be personal data subject to the Directive, the personal data of the deceased may indirectly enjoy the protection of data protection rules. Thirdly, information on deceased persons may be subject to specific protection granted by sets of rules other than data protection legislation, drawing the lines of what some call "personalitas praeterita". The obligation of confidentiality of medical staff does not end with the death of the patient. National legislation on the right to one's own image and honour may grant also protection to the memory of the dead. And fourthly, nothing prevents a Member State from extending the scope of the national legislation implementing the provisions of Directive 95/46/EC to areas not included in the scope thereof provided that no other provision of Community law precludes it, as the ECJ has recalled16. It is possible that some national legislator may decide to extend the provisions of national data protection law to some aspects
16
Judgment of the European Court of Justice C-101/2001 of 06/11/2003 (Lindqvist), § 98 -22-
627
concerning processing data on deceased persons, where a legitimate interest may justify it17. Unborn children The extent to which data protection rules may apply before birth depends on the general position of national legal systems about the protection of unborn children. To take mainly account of inheritance rights, some Member States acknowledge the principle that children conceived but not yet born are considered as if they were born as far as benefits are concerned (and thus can receive a heritage or accept a donation), subject to the condition that they may effectively be born. In other Member States, specific protection is given by particular legal provisions, also subject to the same condition. To determine whether national data protection provisions protect also information on unborn children, that general approach of the national legal system should be considered, together with the idea that the purpose of data protection rules is to protect the individual. A second question is posed by the consideration that the legal system's general response relies on the expectation that the situation of unborn children is limited in time to the period of pregnancy. It does not take account of the fact that this situation may actually last considerably longer, as in the case of frozen embryos. Finally, specific legal responses may be found in particular provisions on reproduction techniques, dealing with the use of medical or genetic information about embryos. Legal persons As the definition of personal data refers to individuals, i.e. natural persons, information relating to legal persons is in principle not covered by the Directive, and the protection granted by it does not apply18. However, certain data protection rules may still indirectly apply to information relating to businesses or to legal persons, in a number of circumstances. Some provisions of the e-privacy Directive 2002/58/EC extend to legal persons. Article 1 thereof provides that "2. The provisions of this Directive particularise and complement Directive 95/46/EC for the purposes mentioned in paragraph 1. Moreover, they provide for protection of the legitimate interests of subscribers who are legal persons." Accordingly, Articles 12 and 13 extend the application of some provisions concerning directories of subscribers and unsolicited communication also to legal persons. Information about legal persons may also be considered as "relating to" natural persons on their own merits, in accordance with the criteria set out in this document. This may be the case where the name of the legal person derives from that of a natural person. Another case may be that of corporate e-mail, which is normally used by a certain employee, or that of information about a small business (legally speaking an "object" rather than a legal person), which may describe the behaviour of its owner. In all these cases, where the criteria of "content", "purpose" or "result" allow the information on 17
18
Minutes of the Council of the European Union, 8.2.1995, document 4730/95: "Re Article 2(a) "The Council and the Commission confirm that it is for the Member States to lay down whether and to what extent this Directive shall be applied to deceased persons." Recital 24 of the Directive: "Whereas the legislation concerning the protection of legal persons with regard to the processing of data which concerns them is not affected by this Directive;" -23-
628
the legal person or on the business to be considered as "relating" to a natural person, it should be considered as personal data, and the data protection rules should apply. The European Court of Justice has made clear that nothing prevents the Member States from extending the scope of the national legislation implementing the provisions of the Directive to areas not included within the scope thereof, provided that no other provision of community law precludes it19. Accordingly some Member States such as Italy, Austria or Luxembourg have extended the application of certain provisions of national law adopted pursuant to the Directive (such as those on security measures) to the processing of data on legal persons. As in the case of information on dead people, practical arrangements by the data controller may also result in data on legal person being subject de facto to data protection rules. Where the data controller collects data on natural and legal persons indistinctly and includes them in the same sets of data, the design of the data processing mechanisms and the auditing system may be set up so as to comply with data protection rules. In fact, it may be easier for the controller to apply the data protection rules to all sorts of information in his files than to try to sort out what refers to natural and what to legal persons.
IV.
WHAT HAPPENS IF THE DATA FALL OUTSIDE OF THE DEFINITION? As we have seen throughout this document, in different circumstances information may be considered not to be personal data. This is the case where the data cannot be considered to relate to an individual, or because the individual cannot be considered to be identified or identifiable. When the information that is processed does not fall within the concept of "personal data", the consequence is that the Directive does not apply, pursuant to Article 3 thereof. This does not mean, though, that individuals may be deprived of any kind of protection in the particular situation. We should take into account the following considerations. If the Directive does not apply, national data protection law may apply. As laid down in Article 34, the Directive is addressed to the Member States. Outside of its scope, Member States are not subject to the obligations it imposes, basically to bring into force the laws, regulations and administrative provisions necessary to comply with it. However, as the European Court of Justice has made clear, nothing prevents Member States from extending the scope of the national legislation implementing the provisions of the Directive to areas not included within the scope thereof, provided that no other provision of community law precludes it. It may therefore very well happen that certain situations not involving processing of personal data as defined in the Directive are nevertheless subject to protective measures under national law. This may for instance apply to a subject like key-coded data, regardless of whether it is personal data or not. Where data protection rules do not apply, certain activities may still constitute an interference with Article 8 of the European Convention on Human Rights, which protects the right to private and family life, in the light of the far-reaching jurisprudence of the ECHR. Other sets of rules, such as torts law, criminal law or antidiscrimination law may also provide protection to individuals in those cases where data protection rules do not apply and various legitimate interests may be at stake. 19
Judgment of the European Court of Justice C-101/2001 of 06.11.2003 (Lindqvist), ยง 98 -24-
629
V.
CONCLUSIONS In this opinion the Working Party has provided guidance on the way in which the concept of personal data in Directive 95/46/EC and related community legislation should be understood and how it should be applied in different situations. As a general consideration it has been noted that the European lawmaker intended to adopt a broad notion of personal data, but this notion is not unlimited. It should always be kept in mind that the objective of the rules contained in the Directive is to protect the fundamental rights and freedoms of individuals, in particular their right to privacy, with regard to the processing of personal data. These rules were therefore designed to apply to situations where the rights of individuals could be at risk and hence in need of protection. The scope of the data protection rules should not be overstretched, but unduly restricting the concept of personal data should also be avoided. The Directive has defined its scope, excluding a number of activities, and allows flexibility in the application of rules to activities that are within its scope. Data protection authorities play an essential role in finding an appropriate balance in this application (see paragraph II). The Working Party’s analysis has been based on the four main “building blocks” that can be distinguished in the definition of “personal data”: i.e. “any information”, “relating to”, “an identified or identifiable”, “natural person”. These elements are closely intertwined and feed on each other, but together determine whether a piece of information should be considered as “personal data”. The analysis is supported by examples from the national practice of European DPAs. •
The first element – “any information” – calls for a wide interpretation of the concept, regardless of the nature or content of the information, and the technical format in which it is presented. This means that both objective and subjective information about a person in whatever capacity may be considered as “personal data”, and irrespective of the technical medium on which it is contained. The opinion also discusses biometric data and the legal distinctions with human samples from which they may be extracted (see paragraph III.1).
•
The second element – “relating to” – has so far been often overlooked, but plays a crucial role in determining the substantive scope of the concept, especially in relation to objects and new technologies. The opinion provides three alternative elements – i.e. content, purpose or result – to determine whether information “relates to” an individual. This also covers information that may have a clear impact on the way in which an individual is treated or evaluated (see paragraph III.2).
•
The third element – “identified or identifiable” – focuses on the conditions under which an individual should be considered as “identifiable”, and especially on “the means likely reasonably to be used” by the controller or by any other person to identify that person. The particular context and circumstances of a specific case play an important role in this analysis. The opinion also deals with “pseudonymised data” and the use of “key-coded data” in statistical or pharmaceutical research (see paragraph III.3).
•
The fourth element – “natural person” – deals with the requirement that “personal data” are about “living individuals”. The opinion also discusses the interfaces with data on deceased persons, unborn children and legal persons (see paragraph III.4). -25-
630
The opinion finally discusses what happens if data fall outside the scope of the definition of â&#x20AC;&#x153;personal dataâ&#x20AC;?. Different solutions may be available to deal with issues in these cases, including national legislation outside the scope of the Directive, provided that other community law is respected (see paragraph IV). The Working Party invites all interested parties to carefully study the guidance provided in this opinion and to take it into account when interpreting and applying provisions of national law in line with Directive 95/46/EC. The members of the Working Party, mostly representatives of supervisory data protection authorities at national level, are committed to further developing the guidance provided in this opinion within their own jurisdictions and to ensuring a proper application of their national law in line with Directive 95/46/EC. The Working Party intends to apply and develop the guidance provided in this opinion wherever appropriate, and to carefully take it into account in its further work, particularly when dealing with topics such as Identity Management in the context of e-Government and e-Health, as well as in the RFID context. As to the latter subject, the Working Party intends to contribute to a further analysis of the way in which data protection rules may impact on the use of RFIDs and of the possible need for additional measures that may be necessary in order to ensure a proper respect of data protection rights and interests in that context. The Working Party would finally also welcome any feedback from interested parties and supervisory authorities on their practical experience with the guidance provided in this opinion, including any additional examples to those mentioned in this document. It intends to revisit the subject in due course, with a view to further enhancing the common understanding of the key concept of personal data, and ensuring a harmonized application and a better implementation of Directive 95/46/EC and related community legislation on that basis. -------------------------
For the Working Party
The Chairman Peter SCHAAR
-26-
631
ARTICLE 29 DATA PROTECTION WORKING PARTY
01197/11/EN WP187
Opinion 15/2011 on the definition of consent
Adopted on 13 July 2011
This Working Party was set up under Article 29 of Directive 95/46/EC. It is an independent European advisory body on data protection and privacy. Its tasks are described in Article 30 of Directive 95/46/EC and Article 15 of Directive 2002/58/EC. The secretariat is provided by Directorate C (Fundamental Rights and Union Citizenship) of the European Commission, Directorate General Justice, B-1049 Brussels, Belgium, Office No MO59 02/013. Website: http://ec.europa.eu/justice/data-protection/index_en.htm
632
Executive Summary
The Opinion provides a thorough analysis of the concept of consent as currently used in the Data Protection Directive and in the e-Privacy Directive. Drawing on the experience of the members of the Article 29 Working Party, the Opinion provides numerous examples of valid and invalid consent, focusing on its key elements such as the meaning of "indication", "freely given", "specific", "unambiguous", "explicit", "informed" etc. The Opinion further clarifies some aspects related to the notion of consent. For example, the timing as to when consent must be obtained, how the right to object differs from consent, etc. Consent is one of several legal grounds to process personal data. It has an important role, but this does not exclude the possibility, depending on the context, of other legal grounds perhaps being more appropriate from both the controller’s and from the data subject’s perspective. If it is correctly used, consent is a tool giving the data subject control over the processing of his data. If incorrectly used, the data subject’s control becomes illusory and consent constitutes an inappropriate basis for processing. This Opinion is partly issued in response to a request from the Commission in the context of the ongoing review of the Data Protection Directive. It therefore contains recommendations for consideration in the review. Those recommendations include: (i) clarifying the meaning of “unambiguous” consent and explaining that only consent that is based on statements or actions to signify agreement constitutes valid consent; (ii) requiring data controllers to put in place mechanisms to demonstrate consent (within a general accountability obligation); (iii) adding an explicit requirement regarding the quality and accessibility of the information forming the basis for consent, and (iv) a number of suggestions regarding minors and others lacking legal capacity.
2 633
THE WORKING PARTY ON THE PROTECTION OF INDIVIDUALS WITH REGARD TO THE PROCESSING OF PERSONAL DATA set up by Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995, having regard to Articles 29 and 30 paragraphs 1(a) and 3 of that Directive, having regard to its Rules of Procedure,
HAS ADOPTED THE PRESENT OPINION
I.
Introduction
The data subjectâ&#x20AC;&#x2122;s consent has always been a key notion in data protection, but it is not always clear where consent is needed, and what conditions have to be fulfilled for consent to be valid. This may lead to different approaches and divergent views of good practice in different Member States. This may weaken the position of data subjects. This problem has become more serious as the processing of personal data has become an increasingly prominent feature of modern society, both in on-line and off-line environments, often involving different Member States. This is why the Article 29 Working Party, as part of its Work Programme for 2010-2011, has decided to take a careful look into this subject. Consent is also one of the subjects about which the Commission has asked for input in the context of the review of Directive 95/46/EC. The Commission Communication "A comprehensive approach on personal data protection in the European Union"1 says that: "The Commission will examine ways of clarifying and strengthening the rules on consent". The Communication explains2 this as follows: "When informed consent is required, the current rules provide that the individual's consent for processing his or her personal data should be a 'freely given specific and informed indication of his or her wishes by which the individual signifies his or her agreement to this data processing. However, these conditions are currently interpreted differently in Member States, ranging from a general requirement of written consent to the acceptance of implicit consent." "Moreover, in the online environment - given the opacity of privacy policies - it is often more difficult for individuals to be aware of their rights and give informed consent. This is even more complicated by the fact that, in some cases, it is not even clear what would constitute freely given, specific and informed consent to data processing, such as in the case of behavioural advertising, where internet browser settings are considered by some, but not by others, to deliver the user's consent." 1 2
COM (2010) 609 final of 4.11.2010. The Commission's first report on the implementation of the Data Protection Directive (95/46/EC) (COM(2003)265 final, already mentioned on page 17: "The notion of "unambiguous consent" (Article 7(a)) in particular, as compared with the notion of "explicit consent" in Article 8, needs further clarification and more uniform interpretation. It is necessary that operators know what constitutes valid consent, in particular in on-line scenarios."
3 634
"Clarification concerning the conditions for the data subject's consent should therefore be provided, in order to always guarantee informed consent and ensure that the individual is fully aware that he or she is consenting, and to what data processing, in line with Article 8 of the EU Charter of Fundamental Rights. Clarity on key concepts can also favour the development of self-regulatory initiatives to develop practical solutions consistent with EU law." To meet the Commission's request for input and to execute its Work Programme for 2010-2011, the Article 29 Working Party has committed to draft an Opinion. The goal of the Opinion is to clarify matters to ensure a common understanding of the existing legal framework. At the same time, this action follows the logic of earlier Opinions on other key provisions of the Directive3. Potential changes to the existing framework will take a while, so clarifying the current notion of "consent" and its main elements has its own virtues and advantages. Clarifying the existing provisions will also help to show which areas need improvement. Thus, building on the analysis, the Opinion will endeavour to formulate policy recommendations to assist the Commission and policy makers as they consider changes to the applicable data protection legal framework. The basic content of the Opinion is as follows: After providing an overview of the legislative history and role of consent in data protection legislation, we examine the different elements and requirements for consent to be valid under applicable law, including some relevant parts of the e-Privacy Directive 2002/58/EC. The analysis is illustrated with practical examples based on national experiences. This exercise supports the recommendations, in the final part of this Opinion, that say that certain elements have to be in place to seek and obtain valid consent under the Directive. It also provides policy recommendations for policy makers to consider in the context of the review of Directive 95/46/EC.
II.
General observations and policy issues
II.1.
Brief history
While some national data protection/privacy laws adopted in the seventies foresaw consent as one of the legal grounds for processing personal data4, this was not echoed in the Council of Europeâ&#x20AC;&#x2122;s Convention 1085. There are no apparent reasons for consent not playing a bigger role in the Convention6. At EU level, reliance on consent as a criterion for legitimising personal data processing operations was foreseen from the very beginning of the legislative process that ended
3
4
5
6
Such as Opinion 8/2010 on applicable law, adopted on 16.12.2010 (WP 179) and Opinion 1/2010 on the concepts of "controller" and "processor", adopted on 16.02.2010 (WP 169). See for example, Article 31 of the French Loi n 78-17 of 6 January 1978 "relative a l'informatique, aux fichiers et aux libertĂŠs". The Convention for the Protection of Individuals with regard to Automatic Processing of Personal Data (referred to as "Convention 108â&#x20AC;?). It entered into force on 1 October 1985. Convention 108 introduced the notions of "lawful processing" and "legitimate purpose" (Article 5), but unlike Directive 95/46/EC did not provide a list of criteria for legitimate data processing. The consent of a data subject only played a role in the context of mutual assistance (Article 15). However, the requirement of "consent" was later on mentioned repeatedly in various Recommendations of the Committee of Ministers.
4 635
with the adoption of Directive 95/46/EC. Article 12 of the Commission's proposal7 in 1990 set out the properties that consent had to have to legitimise data processing operations: it had to be "expressly given" and "specific". Article 17, on sensitive data, required that consent be "express and written". The Commission's amended proposal8 in 1992 introduced text close to the definition of "the data subject's consent" in today's Article 2(g), replacing the original Article 12. It stated that consent had to be "freely given and specific". The reference to "expressly given" was replaced by consent as "an express indication of his (the data subjectâ&#x20AC;&#x2122;s) wishes". The explanatory memorandum accompanying the 1992 amended proposal9 stated that consent could be achieved either orally or in writing. As for sensitive data, the requirement for "written" consent remained. In 1992 the Commission's amended proposal re-structured the previous proposal, and introduced an Article 7 that deals with legal grounds for processing. Article 7(a) stated that processing could be carried out if "the data subject has consented"; the original list included, as today, five additional legal grounds (in addition to consent), that can be used to legitimize the data processing. The Council Common Position10 in 1995 introduced the final (today's) definition of consent. It was defined as "any freely given specific and informed indication of his wishes by which the data subject signifies his agreement to personal data relating to him being processed". The main change from the 1992 Commission position involved deleting the word "express" that had preceded the word "indication". At the same time, the word "unambiguous" was added to Article 7(a), so it reads as follows: "if the data subject has given his consent unambiguously". The requirement for written consent for sensitive data was replaced with "explicit consent". Council's reasons11 did not specifically explain those changes. Page 4 however states that "... a number of amendments have ... been made to ... introduce a measure of flexibility which guarantees equivalent protection ... but does not lead to any lowering in the level of protection; they allow the general principles to be applied in an efficient and non-bureaucratic way in keeping with the wide variety of ways in which ... data are processed." The role of consent was explicitly recognised in the EU Charter of Fundamental Rights in dealing with the protection of personal data. Article 8(2) states that personal data can be processed "on the basis of the consent of the person concerned or some other legitimate basis laid down by law". Therefore, consent is recognised as an essential aspect of the fundamental right to the protection of personal data. At the same time, consent under the Charter is not the only legal ground enabling the processing of personal data; the Charter explicitly recognises that the law may lay down other legitimate grounds, as is the case with Directive 95/46/EC.
7
8
9
10
11
Proposal for a Directive concerning the protection of individuals in relation to the processing of personal data, COM (90), 314 final, SYN 287 and 288, Brussels, 13 September 1990. Amended proposal for a Council Directive on the protection of individuals with regard to the processing of personal data an on the free movement of such data, COM (92) 422 FINAL- SYN 287, Brussels, 15 October 1992. See page 11 of the amended proposal for a Council Directive on the protection of individuals with regard to the processing of personal data an on the free movement of such data, COM (92) 422 FINAL- SYN 287, Brussels, 15 October 1992. Common Position of the Council on the proposal for a Parliament and Council Directive on the protection of individuals with regard to the processing of personal data and the free movement of such data, (00/287) COD, adopted on 15/03/95. See page 4 of the Common Position.
5 636
In sum, the legislative history, particularly in the EU, shows that consent has played an important role in conceptions of data protection and privacy. At the same time, it shows that consent has not been deemed as the only legal ground for legitimising data processing operations. The legislative history of Directive 95/46/EC shows relative consensus on the conditions of valid consent, namely: freely given, specific and informed. However, it also shows some uncertainty over the ways in which consent may be expressed - whether it has to be explicit, written, etc. This is further analyzed below.
II.2.
Role of concept: ground for lawfulness
General/Specific ground: Consent is used in the Directive both as a general ground for lawfulness (Article 7) and as a specific ground in some specific contexts (Article 8.2(a), Article 26.1(a)). Article 7 cites consent as the first of six different bases to legitimise the processing of personal data, while Article 8 provides for the possibility of using consent to legitimise the processing of special categories of (sensitive) data, that would otherwise be prohibited. In this last case the standard for obtaining consent is higher, as this consent must go beyond the general standard of consent by being "explicit". Furthermore, the Directive allows for interaction with other legislation, as mentioned in Recital 23: "Member States are empowered to ensure the implementation of the protection of individuals both by means of a general law on the protection of individuals as regards the processing of personal data and by sectorial laws". The way this system works in practice is complex: Member States have taken their own approach and, in some cases, this has led to diversity. The concept of consent has not always been transposed word for word at national level. As an illustration, consent as a general concept is not defined in French data protection legislation, but its meaning has been precisely and consistently explained in the jurisprudence of the data protection authority (CNIL), in relation to the definition contained in the Data Protection Directive. In the UK, it has been developed by common law in reference to the wording of the Directive. In addition, consent has sometimes been explicitly defined in specific sectors, for instance in the context of e-privacy, egovernment or e-health. The notion developed in specific legislation will therefore interact with that developed in general data protection legislation. Consent is also a notion used in other fields of law, particularly contract law. In this context, to ensure a contract is valid, other criteria than those mentioned in the Directive will be taken into account, such as age, undue influence, etc. There is no contradiction, but an overlap, between the scope of civil law and the scope of the Directive: the Directive does not address the general conditions of the validity of consent in a civil law context, but it does not exclude them. This means, for instance, that to assess the validity of a contract in the context of Article 7(b) of the Directive, civil law requirements will have to be taken into account. In addition to the application of the general conditions for the validity of consent under civil law, the consent required in Article 7(a) must also be interpreted taking into account Article 2(h) of the Directive.
6 637
This interaction with other legislation is not only visible at national but also at European level. A similar understanding of the elements of the Directive has been drawn from other contexts, as shown by a judgment of the Court of Justice in the field of labour law12: consent was required in the context of giving up a social right. The Court interpreted the notion of consent in the context of Directive 93/104 concerning certain aspects of the organisation of working time. It stated that 'worker's agreement' required consent by the worker (not by a union on the worker's behalf), and read "agreement" (…) to mean freely given informed consent. It also held that the worker signing an employment contract with a reference to a collective agreement authorising an extension of working time did not meet the requirements that consent be freely and expressly given, with full knowledge of all the facts. This interpretation of consent in a specific context is very close to the wording of Directive 95/46/EC. Consent is not the only ground for lawfulness The Directive clearly presents consent as a ground for lawfulness. However, some Member States see it as a preferred ground, sometimes close to a constitutional principle, linked to the status of data protection as a fundamental right. Other Member States may see it as one of six options, an operational requirement that is no more important than the other options. Clarifying the relation of consent with the other grounds of lawfulness - e.g. in relation to contracts, tasks of public interest or legitimate interests of the controller, and the right to object - will help to highlight the role of consent in specific cases. The order in which the legal grounds are cited under Article 7 is relevant, but it does not mean that consent is always the most appropriate ground to legitimise the processing of personal data. Article 7 starts with consent, and goes on to list the other grounds, including contracts and legal obligations, moving gradually to the balance of interests. It should be noted that the five other grounds following consent require a “necessity” test, which strictly limits the context in which they can apply. This does not mean that the consent requirement leaves more margin of manoeuvre than the other grounds in Article 7. Moreover, obtaining consent does not negate the controller's obligations under Article 6 with regard to fairness, necessity and proportionality, as well as data quality. For instance, even if the processing of personal data is based on the consent of the user, this would not legitimise the collection of data which is excessive in relation to a particular purpose. Nor does obtaining consent allow the circumvention of other provisions, such as Article 8(5). Only in very limited circumstances can consent legitimise data processing activities which would otherwise be prohibited, notably in relation to the processing of some sensitive data (Article 8) or to allow the use of personal data for further processing, whether or not this is compatible with the original purpose. As a principle, consent should not be seen as an exemption from the other data protection principles, but as a safeguard. It is primarily a ground for lawfulness, and it does not waive the application of other principles. 12
Judgment of the Court (Grand Chamber) of 5 October 2004, Pfeiffer, Roith, Süß, Winter, Nestvogel, Zeller, Döbele in joined Cases C-397/01 to C-403/01.
7 638
The choice of the most appropriate legal ground is not always obvious, especially between Article 7(a) and 7(b). Under Article 7(b), the processing must be necessary to perform a contract, or in order to take steps at the request of the data subject prior to entering into a contract, and no more. A data controller using Article 7(b) as a legal ground in the context of the conclusion of a contract cannot extend it to justify the processing of data going beyond what is necessary: he will need to legitimise the extra processing with a specific consent to which the requirements of Article 7(a) will apply. This shows the need for granularity in contract terms. In practice, it means that it can be necessary to have consent as an additional condition for some part of the processing. Either the processing is necessary to perform a contract, or (free) consent must be obtained. In some transactions a number of legal grounds could apply, at the same time. In other words, any data processing must at all times be in conformity with one or more legal grounds. This does not exclude the simultaneous use of several grounds, provided they are used in the right context. Some data collection and further processing may be necessary under the contract with the data subject – Article 7(b); other processing may be necessary as a result of a legal obligation – Article 7(c); the collection of additional information may require separate consent – Article 7(a); still other processing could also be legitimate under the balance of interests – Article 7(f).
Example: buying a car The data controller may be entitled to process personal data according to different purposes and on the basis of different grounds: - Data necessary to buy the car: Article 7(b), - To process the car's papers: Article 7(c), - For client management services (e.g. to have the car serviced in different affiliate companies within the EU): Article 7(f), - To transfer the data to third parties for their own marketing activities: Article 7(a).
II.3.
Related concepts
Control The notion of consent is traditionally linked with the idea that the data subject should be in control of the use that is being made of his data. From a fundamental rights perspective, control exercised through consent is an important concept. At the same time, and from the same perspective, an individual’s decision to accept a data processing operation should be subject to rigorous requirements, particularly taking into account that in doing so, an individual may be waiving a fundamental right. Although consent plays a role in giving control to data subjects, it is not the only way to do this. The Directive provides other means of control, in particular the right to object, but this is a different instrument to be exercised at a different stage of the processing, i.e. after the processing has started and based on a different legal ground.
8 639
Consent is related to the concept of informational self-determination. The autonomy of the data subject is both a pre-condition and a consequence of consent: it gives the data subject influence over the processing of data. However, as explored in the next chapter, this principle has limits, and there are cases where the data subject is not in a position to take a real decision. The data controller may want to use the data subject’s consent as a means of transferring his liability to the individual. For instance, by consenting to the publication of personal data on the Internet, or to a transfer to a dubious entity in a third country, he may suffer damage and the controller may argue that this is only what the data subject has agreed to. It is therefore important to recall that a fully valid consent does not relieve the data controller of his obligations, and it does not legitimise processing that would otherwise be unfair according to Article 6 of the Directive. The notion of control is also linked to the fact that the data subject should be able to withdraw his consent. Withdrawal is not retroactive, but it should, as a principle, prevent any further processing of the individual’s data by the controller. The way this works in practice will be explored further below (Chapter III). Transparency A second dimension of consent relates to information: transparency towards the data subject. Transparency is a condition of being in control and for rendering the consent valid. Transparency as such is not enough to legitimise the processing of personal data, but it is an essential condition in ensuring that consent is valid. To be valid, consent must be informed. This implies that all the necessary information must be given at the moment the consent is requested, and that this should address the substantive aspects of the processing that the consent is intended to legitimise. This would normally cover the elements of information listed in Article 10 of the Directive, but will also depend on when, and the circumstances in which, consent is requested. Regardless of whether or not consent is given, the transparency of data processing is also a condition of fairness, which has its own value also after the moment the initial information has been provided Activity/timing: ways to signify consent This third dimension relates to the way in which control is exercised: in which ways can consent be expressed and when should it be sought in order to ensure that it is real consent? These questions have a decisive impact on the way in which consent is exercised and interpreted. Although the timing for seeking consent is not spelt out in the Directive, it is clearly implied from the language of the various provisions which indicate that, as a general rule, consent has to be given before the processing starts13. Obtaining consent before the processing of data starts is an essential condition to legitimise the processing of data. This point is further elaborated below in Chapter III.B regarding the e-Privacy Directive.
13
As an illustration, the German version of the Directive (and the German Federal Data Protection Law) uses the notion “Einwilligung”. This notion is defined in the German Civil code as “prior acceptance”.
9 640
Consent, considered as an authorization by the individual to allow the processing of data pertaining to him/her, may be expressed in different ways: Article 2(h) refers to any "indication"; it must be unambiguous (Article 7a) and explicit regarding sensitive data (ex Article 8). However, it is essential to emphasize the fact that consent differs from the right to object provided for in Article 14. While in Article 7(a) the controller cannot process the data until he obtains the consent of the data subject, in Article 7(f) the controller can process the data, subject to conditions and safeguards, as long as the data subject has not objected. As stated in the Working Partyâ&#x20AC;&#x2122;s Working Paper 114: "the importance of consent constituting a positive act excludes de facto any system whereby the data subject would have the right to oppose the transfer only after it has taken place"14. For these reasons, the right to object ex Article 14 of the Directive should not be confused with consent. The latter is a legal ground to process personal data ex Article 7(a), 8.2(a), 26.1 or as foreseen in various provisions of Directive 2002/58/EC.
II.4.
Appropriate use of consent as a legal basis
There is a need to emphasise that consent is not always the primary or the most desirable means of legitimising the processing of personal data. Consent is sometimes a weak basis for justifying the processing of personal data and it loses its value when it is stretched or curtailed to make it fit to situations that it was never intended to be used in. The use of consent "in the right context" is crucial. If it is used in circumstances where it is not appropriate, because the elements that constitute valid consent are unlikely to be present, this would lead to great vulnerability and, in practice, this would weaken the position of data subjects in practice. This approach has already been supported by the Working Party and the EDPS in their contributions to the discussions on the new data protection framework. It has been stated in particular that "it is not always clear what constitutes true, unambiguous consent. Some data controllers exploit this uncertainty by relying on methods not suitable to deliver true, unambiguous consent"15 in violation of the conditions of Article 6 of the Directive. In the same line, the WP29 has observed that "complexity of data collection practices, business models, vendor relationships and technological applications in many cases outstrips the individualâ&#x20AC;&#x2122;s ability or willingness to make decisions to control the use and sharing of information through active choice"16. It is therefore important to clarify the limits of consent and to make sure that only consent that is construed in a way according to the law is deemed as such.17
14
15
16
17
WP114 - Working document of the Article 29 Working Party on a common interpretation of Article 26(1) of Directive 95/46/EC of 24 October 1995. Opinion of the European Data Protection Supervisor of 14 January 2011 on the Communication from the Commission on "A comprehensive approach on personal data protection in the European Union". "The Future of Privacy: Joint contribution to the Consultation of the European Commission on the legal framework for the fundamental right to protection of personal data", 1 December 2009, WP 168. Opinion of the European Data Protection Supervisor of 14 January 2011, op.cit.
10 641
III.
Analysis of provisions
In this analysis we will focus on Directive 95/46/EC in chapter III.A. Some relevant parts of the e-Privacy Directive 2002/58/EC will be analysed in chapter III.B. It should be noted that the Directives are not exclusive of each other. The general conditions for consent to be valid, as foreseen in Directive 95/46/EC, apply both in the off-line and in the on-line world. Directive 2002/58/EC specifies these conditions for some explicitly identified on-line services, always in the light of the general conditions of the Data Protection Directive. III.A
Directive 95/46/EC
The concept of "the data subject's consent" is defined in Article 2(h) and subsequently used in Articles 7, 8 and 26. The role of consent is also mentioned in recitals 30 and 45. These provisions and all relevant details will be discussed separately and in this chapter. III.A.1. Article 2(h) According to Article 2(h) 'the data subject's consent' shall mean "any freely given specific and informed indication of his wishes by which the data subject signifies his agreement to personal data relating to him being processed". This definition contains different key elements that will be discussed below. “… any … indication of his wishes ... signifying …” There is in principle no limits as to the form consent can take. However, for consent to be valid, in accordance with the Directive, it should be an indication. Even if it can be "any" form of indication, it should be clear what exactly can fall within the definition of an indication. The form of the indication (i.e. the way in which the wish is signified) is not defined in the Directive. For flexibility reasons, “written” consent has been kept out of the final text. It should be stressed that the Directive includes “any” indication of a wish. This opens the possibility of a wide understanding of the scope of such an indication. The minimum expression of an indication could be any kind of signal, sufficiently clear to be capable of indicating a data subject's wishes, and to be understandable by the data controller. The words “indication” and “signifying” point in the direction of an action indeed being needed (as opposed to a situation where consent could be inferred from a lack of action). Consent should include any indication of a wish, by which the data subject signifies his agreement: it could include a handwritten signature affixed at the bottom of a paper form, but also oral statements to signify agreement, or a behaviour from which consent can be reasonably concluded. Beyond the classical example of a signature, dropping a business card in a glass bowl could therefore fall within the definition. The same applies if an individual sends his name and address to an organisation in order to obtain information from it. In this case his action should be understood to constitute to the processing of such data insofar as it is necessary to process and respond to the request.
11 642
In its opinion on the use of location data with a view to providing value added services (WP115), the Working Party has assessed how individuals should be put in a position to consent to services that require their automatic location (e.g. the possibility of calling a specific number to obtain information on the weather conditions at one's location). In that case, it has been acknowledged that, provided users are given full information in advance about the processing of their location data, calling the relevant number would amount to consenting to being located.
Example: Bluetooth advertising boards There is a developing advertising tool consisting of boards sending messages asking for the establishment of a Bluetooth connection to send ads to people passing nearby. The messages are sent to people that have activated their Bluetooth devices on their mobiles. The sole activation of the Bluetooth function does not constitute a valid consent (i.e. the Bluetooth function could be activated for other purposes). On the other hand, when someone is informed about the service and approaches a few centimetres from the board with his or her mobile, there is, normally speaking, an indication of a wish: this shows which people are really interested in getting the ads. Only those people should be considered as having consented, and only they should receive the messages on their phones. It is questionable whether the absence of any behaviour - or perhaps better: passive behaviour - could also be interpreted as an indication in very specific circumstances (i.e. a totally unambiguous context). The notion of "indication" is wide, but it seems to imply a need for action. Other elements of the definition of consent, and the additional requirement in Article 7(a) for consent to be unambiguous, support this interpretation. The requirement that the data subject must 'signify' his consent seems to indicate that simple inaction is insufficient and that some sort of action is required to constitute consent, although different kinds of actions, to be assessed "in context", are possible. In practice, in the absence of active behaviour of the data subject, it will be problematic for the data controller to verify whether silence was intended to mean acceptance or consent. For example, a data controller may have not have the certainty needed to assume consent in the following case: let us imagine a situation where upon sending a letter to customers informing them of an envisaged transfer of their data unless they object within 2 weeks, only 10% of the customers respond. In this example, it is contestable that the 90% that did not respond did indeed agree to the transfer. In such cases the data controller has no clear indication of the intention of data subjects. Besides, he will have no evidence and will therefore be unable to demonstrate that he obtained consent. In practice, the ambiguity of a passive response will make it difficult to fulfil the requirements of the Directive. “… freely given …” Consent can only be valid if the data subject is able to exercise a real choice, and there is no risk of deception, intimidation, coercion or significant negative consequences if he/she does not consent. If the consequences of consenting undermine individuals' freedom of choice, consent would not be free. The Directive itself foresees in Article 8.2(a) that in some cases, to be determined by Member States, the prohibition of the
12 643
processing of special categories of personal data may not be lifted by the consent of the data subject. An example of the above is provided by the case where the data subject is under the influence of the data controller, such as an employment relationship. In this example, although not necessarily always, the data subject can be in a situation of dependence on the data controller - due to the nature of the relationship or to special circumstances and might fear that he could be treated differently if he does not consent to the data processing. In several opinions, the Working Party has explored the limits of consent in situations where it cannot be freely given. This was notably the case in its opinions on electronic health records (WP131), on the processing of data in the employment context (WP48), and on processing of data by the World Anti-Doping Agency (WP162). In WP131, the Working Party mentioned that "free consent means a voluntary decision, by an individual in possession of all of his faculties, taken in the absence of coercion of any kind, be it social, financial, psychological or other. Any consent given under the threat of non-treatment or lower quality treatment in a medical situation cannot be considered as â&#x20AC;&#x2DC;freeâ&#x20AC;&#x2122; ... Where as a necessary and unavoidable consequence of the medical situation a health professional has to process personal data in an EHR system, it is misleading if he seeks to legitimise this processing through consent. Reliance on consent should be confined to cases where the individual data subject has a genuine free choice and is subsequently able to withdraw the consent without detriment." 18 If, once consent is withdrawn, the data processing continues based on another legal ground, doubts could be raised as to the original use of consent as the initial legal ground: if the processing could have taken place from the beginning using this other ground, presenting the individual with a situation where he is asked to consent to the processing could be considered as misleading or inherently unfair. It would be different if there were a change of circumstances, for example if a new legal basis were to appear in the course of the processing, such as a new law regulating the database concerned. If this new ground can validly apply to the data processing, the processing can go on. However, in practice such circumstances are not frequent. In principle, consent can be considered to be deficient if no effective withdrawal is permitted. The Working Party has taken a consistent position on the interpretation of free consent in the context of employment19: "where consent is required from a worker, and there is a real or potential relevant prejudice that arises from not consenting, the consent is not valid in terms of satisfying either Article 7 or Article 8 as it is not freely given. If it is not possible for the worker to refuse it is not consent.â&#x20AC;Ś An area of difficulty is where the giving of consent is a condition of employment. The worker is in theory able to refuse consent but the consequence may be the loss of a job opportunity. In such circumstances consent is not freely given and is therefore not valid. The situation is even clearer cut
18
19
WP162 on WADA reaches the same conclusion: "The sanctions and consequences attached to a possible refusal by participants to subject themselves to the obligations of the Code (for example providing whereabouts filings) prevent the Working Party from considering that the consent would be, in any way, given freely". WP48 on the processing of personal data in the employment context. WP114 - Working document of the Article 29 Working Party on a common interpretation of Article 26(1) of Directive 95/46/EC of 24 October 1995 - is also relevant here.
13 644
where, as is often the case, all employers impose the same or a similar condition of employment.â&#x20AC;?
Example: pictures on intranet Consent in the context of employment may be valid, as the following example shows: a company decides to set up an intranet which will feature employeesâ&#x20AC;&#x2122; names and main roles. Each employee is asked whether they would like to have their pictures uploaded alongside each name. Individuals who want to have their picture uploaded are invited to send a picture to a given address. Upon receiving adequate information, the action of an individual to send a picture would be deemed to be consent. If the company has digital pictures of each employee, and asks each one for their consent to have them uploaded for the above purposes, each employee clicking a button to signify their consent would also be deemed to be giving valid consent. In either case, the choice of employees as to whether their picture appears on the intranet is being fully respected.
The context of employment requires specific discussion: The cultural and social aspects of the employment relationship play a role here, as does the way the data protection principles interact with other legislation. In the context of employment, personal data can be processed for various purposes: o Data necessary for the exercise of its tasks by the employee: application of Article 7(b) - necessity for the contract o To determine employees' entitlement to acquire stock options: it could either be on the basis of consent - Article 7(a), or considered as inherent to the administrative aspects of the contractual work relationship - Article 7(b) o Processing the social security number for social security purposes: Article 7(c) legal obligation, or possibly Article 8(b) - obligations in the field of employment law o Processing of ethnic data: in some countries, this could also be an obligation due to employment law - Article 8(b), while in other countries it would be strictly forbidden. Although there may be a strong presumption that consent is weak in such contexts, this does not completely exclude its use, provided there are sufficient guarantees that consent is really free. While a situation of subordination is often the main reason preventing consent to be free, other contextual elements can influence the decision of the data subject. They can have for instance a financial dimension, or an emotional or a practical dimension. The fact that the collection of data is performed by a public authority can also have some influence on the data subject. It can however be difficult to draw the line between a simple incentive and something that has a real influence on the freedom of the data subject to exercise a choice. The examples below try to illustrate the different nature of the efforts or costs to the individuals that could influence their decision.
14 645
Example - Electronic health records In many Member States there is a move to create an electronic summary of patientsâ&#x20AC;&#x2122; health records. This will allow healthcare providers to access key information wherever the patient needs treatment. - In the first scenario, the creation of the summary record is absolutely voluntary, and the patient will still receive treatment whether or not he or she has consented to the creation of a summary record. In this case consent for the creation of the summary record is freely given because the patient will suffer no disadvantage if consent is not given or is withheld. - In the second scenario, there is a moderate financial incentive to choose the e-health record. Patients refusing the e-health record do not suffer disadvantage in the sense that the costs do not change for them. It could be considered here as well that they are free to consent or not to the new system. - In the third scenario, patients refusing the e-health system have to pay a substantial extra cost compared to the previous tariff system and the processing of their file is considerably delayed. This signifies a clear disadvantage for those not consenting, with the purpose to bring all citizens within the e-health system in a scheduled deadline. Consent is therefore not sufficiently free. One should therefore also examine the existence of other legitimate grounds to process the personal data or examine the application of Article 8.3 of Directive 95/46/EC.
Example: body scanners The use of body scanners is developing in some public spaces, in particular in airports to access the boarding area. Considering that passengers' data are being processed at the moment the scanning takes place20, the processing must comply with one of the legal grounds under Article 7. Going through body scanners is sometimes presented as an option to passengers, implying that the processing could be justified by their consent. However the refusal to go through body scanners might create suspicions, or trigger additional controls, such as the undertaking of a body search. Many passengers will consent to being scanned because by doing so they will avoid potential problems or delays, while their first priority is to get on board of their flight on time. Such consent is not sufficiently free. As the processing must be proved to be necessary (for public security reasons), the legitimate basis should not be found in Article 7 (a) but in an act of the legislator â&#x20AC;&#x201C; Article 7(c) or (e) â&#x20AC;&#x201C; resulting in an obligation for passengers to cooperate. The basis for the body scanner screening should thus be the legislation: this legislation could still foresee a choice between scanning and pat-down, however this choice would only be offered to the individual in a complementary perspective, as part of additional measures.
The nature of the data controller can also be decisive with regard to the choice of legal ground to process personal data. This is especially the case for data controllers in the public sector, where the processing of data is normally linked to the performance of a 20
See the letter of 11 February 2009 from the Chairman of the Article 29 Working Party to Mr. Daniel CALLEJA CRESPO, Director in DG TREN on body scanners, in reply to the Consultation of the Commission on "the impact of the use of body scanners in the field of aviation security on human rights, privacy, personal dignity, health and data protection". Available at http://ec.europa.eu/justice/policies/privacy/workinggroup/wpdocs/2009-others_en.htm.
15 646
legal obligation as mentioned in Article 7(c) or the performance of a task carried out in the public interest as mentioned in 7(e). Accordingly, the use of consent of the individual concerned to legitimise the data processing is not the appropriate legal basis. This is particularly clear in the case of processing of personal data by public authorities vested with authoritative powers - such as law enforcement authorities acting within the remit of their tasks in the field of police and justice activities. Police authorities cannot rely on the individual's consent for measures which have not been provided for, or would otherwise not be allowed by law. It should be acknowledged, nevertheless, that even though States may have a legal duty to process personal data, the individual does not always have a duty to collaborate. There may be cases where "added value services" are provided to data subjects, which they can decide to use or not. But in most of the cases the processing is actually mandatory. It is often not so easy to identify whether the processing of personal data by public authorities rightfully relies on the consent of the individual. The processing of personal data in the public sector therefore often involves hybrid schemes, which can lead to uncertainty and abuse if wrongly justified by consent. While consent may in exceptional cases be a valid ground for States to process personal data, a careful check should be performed on a case-by-case basis to assess whether consent is indeed sufficiently free. As the following examples demonstrate, when a public authority is the data controller, the legal ground for legitimising the processing will be the compliance with a legal obligation ex Article 7(c), or the performance of a task of public interest ex Article 7(e), rather than consent. Example: e-government New ID cards with electronic functionalities embedded in a chip are being developed in Member States. It may not be compulsory to activate the electronic services of the card. But without activation, the user could be prevented from accessing certain administrative services, which would otherwise become very difficult to reach (transfer of some services on-line, reduction of office opening hours). Consent cannot be claimed to be the legitimate ground to justify the processing. In this case the law organising the development of e-services, together with all the appropriate safeguards, should be the relevant ground. Example: PNR data The question of whether the consent of passengers can be validly used to legitimise the transfer of booking details (â&#x20AC;&#x153;PNR dataâ&#x20AC;?) by European airlines to the US authorities has been discussed. The Working Party considers that passengersâ&#x20AC;&#x2122; consent cannot be given freely as the airlines are obliged to send the data before the flight departure, and passengers therefore have no real choice if they wish to fly.21 The legal basis here is not the consent of the passenger but, rather in accordance with Article 7(c), the obligations foreseen in the international agreement between the EU and the US on the processing and transfer of Passenger Name Record (PNR) data.
21
See Opinion 6/2002 of the Article 29 Working Party on transmission of passenger manifest information and other data from airlines to the United States.
16 647
Example: national census During a national census, the population is asked to answer various questions about their personal and professional situation. Answering these questions is compulsory. In addition, the census also includes a question to which the answer is clearly indicated as optional, concerning the means of transport used by the individual. Although there is certainly no free consent for the main part of the census, there is a free choice to answer this last optional question. This should not disguise the fact, however, that the main purpose followed by the State in issuing this questionnaire is to obtain answers. Generally speaking, consent does not constitute a valid ground in this context.
“… specific …” To be valid, consent must be specific. In other words, blanket consent without specifying the exact purpose of the processing is not acceptable. To be specific, consent must be intelligible: it should refer clearly and precisely to the scope and the consequences of the data processing. It cannot apply to an open-ended set of processing activities. This means in other words that the context in which consent applies is limited. Consent must be given in relation to the different aspects of the processing, clearly identified. It includes notably which data are processed and for which purposes. This understanding should be based on the reasonable expectations of the parties. “Specific consent” is therefore intrinsically linked to the fact that consent must be informed. There is a requirement of granularity of the consent with regard to the different elements that constitute the data processing: it can not be held to cover “all the legitimate purposes” followed by the data controller. Consent should refer to the processing that is reasonable and necessary in relation to the purpose. It should be sufficient in principle for data controllers to obtain consent only once for different operations if they fall within the reasonable expectations of the data subject. Recently the ECJ issued a preliminary ruling22 regarding Article 12(2) of the ePrivacy Directive, concerning the need for renewed consent of subscribers who had already consented to have their personal data published in one directory, to have their personal data transferred to be published by other directory services. The Court held that where the subscriber has been correctly informed of the possibility that his personal data may be passed to a third-party undertaking and s/he has already consented to the publication of those data in such a directory, renewed consent is not needed from the subscriber for the transfer of those same data, if it is guaranteed that the data in question will not be used for purposes other than those for which the data were collected with a view to their first publication (paragraph 65).
22
Judgment of the Court of 5 May 2011, Deutsche Telekom AG (Case C-543/09). This case started with the referral made by the German Federal Administrative Court regarding telecom directories and in particular the interpretation of Article 25(2) of the Universal Service Directive (2002/22/EC) and Article 12(2) of the ePrivacy Directive (2002/58/EC). It is clearly linked to the special role of directories in the Universal Service Directive.
17 648
Distinct consent may nevertheless be needed if the controller intends to process the data for different purposes. For instance, consent could be given to cover both information about new products to the individual on and specific promotion actions, as this could be considered as falling within the reasonable expectations of the data subject. But a separate and additional consent should be requested to allow for the sending of the individualâ&#x20AC;&#x2122;s data to third parties. The need for granularity in the obtaining of consent should be assessed on a case-by-case basis, depending on the purpose(s) or the recipients of data. It should be recalled that the processing could have several different legal grounds: some data could be processed because they are necessary in the framework of a contract with the data subject, such as for product fulfilment and service management, and specific consent may be needed for processing beyond what is necessary for the performance of the contract, for instance to assess the payment capacities (credit scoring) of the data subject. The Working Party has clarified this aspect of consent in WP131 on electronic health records (EHR): "Specific" consent must relate to a well-defined, concrete situation in which the processing of medical data is envisaged. Therefore a "general agreement" of the data subject - e.g. to the collection of his medical data for an EHR and to any future transfers of these medical data to health professionals involved in treatment - would not constitute consent in the terms of Article 2(h) of the Directive. The same reasoning is expressed in WP115 on the use of location data with a view to providing value added services: "(the) definition explicitly rules out consent being given as part of accepting the general terms and conditions for the electronic communications service offered. ... Depending on the type of service offered, consent may relate to a specific operation or may constitute agreement to being located on an ongoing basis." In the Court decision mentioned above in Chapter II under the "Role of consent", even if the term "specific" is not explicitly used, the reasoning also insists on the need for consent to be specific by stating that "it is not sufficient that the relevant workerâ&#x20AC;&#x2122;s employment contract refers to a collective agreement which permits such an extension". Example: social networks Access to social network services is often subject to agreeing to different kinds of processing of personal data. The user may be required to consent to receiving behavioural advertising to register with a social network service, without further specification or alternative options. Considering the importance that some social networks have acquired, some categories of users (such as teenagers) will accept the receipt of behavioural advertising in order to avoid the risk of being partially excluded from social interactions. The user should be put in a position to give free and specific consent to receiving behavioural advertising, independently of his access to the social network service. A pop-up box could be used to offer the user such a possibility.
18 649
The social network service offers the possibility to use external applications. The user is, in practice, often prevented from using an application if he does not consent to the transmission of his data to the developer of the application for a variety of purposes, including behavioural advertising and reselling to third parties. Considering that the application can run without it being necessary that any data is transferred to the developer of the application, the WP encourages granularity while obtaining the consent of the user, i.e. obtaining separate consent from the user for the transmission of his data to the developer for these various purposes. Different mechanisms, such as pop-up boxes, could be used to offer the user the possibility to select the use of data to which he agrees (transfer to the developer; added value services; behavioural advertising; transfer to third parties; etc). The specificity of consent also means that if the purposes for which data is processed by the controller change at some point in time, the user must be informed and put in a position to be able to consent to the new processing of data. The information provided must in particular address the consequences of a refusal of the proposed changes.
“… informed …” The last element of the definition of consent - but not the last requirement, as we will see below - is its informed character. Articles 10 and 11 of the Directive set out an obligation to provide information to data subjects. The obligation to inform is therefore distinct but in many cases is obviously linked to consent. While consent does not always follow the provision of information (another ground in Article 7 can be used), there must always be information before there can be consent. This means in practice that "consent by the data subject (must be) based upon an appreciation and understanding of the facts and implications of an action. The individual concerned must be given, in a clear and understandable manner, accurate and full information of all relevant issues, in particular those specified in Articles 10 and 11 of the Directive, such as the nature of the data processed, purposes of the processing, the recipients of possible transfers, and the rights of the data subject. This includes also an awareness of the consequences of not consenting to the processing in question"23. Consent will in many cases be obtained at the moment of collection of personal data, when the processing starts. In this case, the information to be provided coincides with what is listed in Article 10 of the Directive. However consent can also be requested “downstream”, when the purpose of the processing changes. In this case the information to be provided will have to focus on what is needed in the specific context, in relation to the purpose.
23
WP131 - Working Document on the processing of personal data relating to health in electronic health records.
19 650
Informed consent is particularly decisive in the context of transfers of personal data to third countries: "it requires that the data subject (is) properly informed of the particular risk that his/her data are to be transferred to a country lacking adequate protection" 24. Two sorts of requirements can be identified in order to ensure appropriate information: • Quality of the information - The way the information is given (in plain text, without use of jargon, understandable, conspicuous) is crucial in assessing whether the consent is “informed”. The way in which this information should be given depends on the context: a regular/average user should be able to understand it. • Accessibility and visibility of information - information must be given directly to individuals. It is not enough for information to be “available” somewhere. The Court of Justice has insisted on this point in its 2004 judgment25, referring to an employment contract including conditions which were not spelt out in the contract but referred to. The information must be clearly visible (type and size of fonts), prominent and comprehensive. Dialogue boxes can be used to give specific information at the time when consent is requested. As mentioned above in relation to “specific consent”, on-line information tools are especially useful in relation to social network services, in order to provide sufficient granularity and clarity to privacy settings. Layered notices can also be a useful tool here, as they contribute to giving the right information in an easily accessible way. As time goes by, doubts may arise as to whether consent that was originally based on valid, sufficient information remains valid. For a variety of reasons, people often change their views, because their initial choices were poorly made, or because of a change in circumstances, such as a child becoming more mature26. This is why, as a matter of good practice, data controllers should endeavor to review, after a certain time, an individual’s choices, for example, by informing them of their current choice and offering the possibility to either confirm or withdraw27. The relevant period would of course depend on the context and the circumstances of the case.
Example: crime mapping Some police forces are considering publishing maps, or releasing other data, showing where particular types of crime took place. Usually safeguards built into the process mean that no personal data about the victims of crime is published, because crime is only linked to relatively broad geographical regions. However, some police forces want to pin-point crime more exactly, where the victim of a crime consents to this. In such a case it becomes possible to link more precisely the data subject with the place where a crime has been committed. However, the victim is not specifically told that identifiable information about him/her will be published openly on the internet and how this information can be used. Consent is therefore not valid in this case because victims may not fully understand the extent to which information about them is being published. 24
25 26 27
WP12 - Working Document Transfers of personal data to third countries: Applying Articles 25 and 26 of the EU data protection directive. See also WP114 - Working document of the Article 29 Working party on a common interpretation of Article 26(1) of Directive 95/46/EC of 24 October 1995. See footnote 12 (Chapter II.2) Working document 1/2008 on the protection of children's personal data, WP 147, 18 February 2008. The Article 29 Working Party made similar recommendation in Article 29 Opinion 171 on online behavioural advertising, adopted on 22.06.2010.
20 651
The more complex data processing is, the more can be expected from the data controller. The more difficult it becomes for an average citizen to oversee and understand all the elements of the data processing, the larger the efforts should become for the data controller to demonstrate that consent was obtained based on specific, understandable information. Consent, as defined in Article 2(h), should be read together with the further requirements mentioned later in the text of the Directive. Article 7 adds the word “unambiguous” to the elements of the definition, and Article 8 adds the word “explicit” when the processing relates to the processing of specific categories of data.
III.A.2. Article 7(a) Pursuant to Article 7(a) of the Directive, the unambiguous consent of the data subject constitutes a legal basis to process personal data. Thus, to be valid, in addition to the criteria set forth under Art 2(h), consent must also be unambiguous. For consent to be unambiguous, the procedure to seek and to give consent must leave no doubt as to the data subject's intention to deliver consent. In other words, the indication by which the data subject signifies his agreement must leave no room for ambiguity regarding his/her intent. If there is a reasonable doubt about the individual's intention, there is ambiguity. As further described below, this requirement compels data controllers to create robust procedures for individuals to deliver their consent; namely either to seek clear express consent or to rely on certain types of procedures that deliver individuals' clear inferred consent. The data controller must also be sufficiently certain that the person giving consent is actually the data subject. This is particularly relevant where consent is given by telephone or online. A related issue concerns the proof of consent. Data controllers relying on consent may want, or need, to demonstrate that consent has been obtained, for example in the context of a dispute with a data subject. Indeed, in some cases, they may be asked for such evidence in the context of enforcement actions. As a consequence, and as a matter of good practice, data controllers should create and retain evidence showing that the consent was indeed given, i.e. the consent should be verifiable. Let us now analyze the following methods for providing consent and assess whether they deliver unambiguous consent. Express statements to signify agreement, such as signed agreement or written statements of the desire to agree, are procedures or mechanisms well suited to deliver unambiguous consent. At the same time, in principle, they provide evidence to the data controller that consent had been obtained. Example: consent to receive promotional information by regular mail A hotel asks individuals to include their postal address on a paper form if they wish to receive promotional information by regular mail. If the individual, after providing the postal information, signs the form to signify his/her agreement, this will constitute 21 652
unambiguous consent. In this case, consent will be both express and in writing. This procedure provides the data controller with adequate proof of having obtained consent from all customers insofar as the data controller retains all the signed forms. However, not all forms of consent that may seem to be explicit will deliver consent. This issue was discussed in the recent ECJ Case (Volker und Markus Schecke v Land Hessen), which referred to the publication of the names of beneficiaries of various EU funds28 and of the amounts received by each beneficiary. The Advocate General analysed whether the conditions for unambiguous consent were met in a case where individuals had signed a statement saying: "I am aware that Article 44a of Regulation … No 1290/2005 requires publication of information on the beneficiaries of [funds from] the EAGF and the EAFRD and the amounts received per beneficiary." The Advocate General concluded: "Acknowledging prior notice that publication of some kind will happen is not the same as giving ‘unambiguous’ consent to a particular kind of detailed publication. Nor can it properly be described as a ‘freely given specific indication’ of the applicants’ wishes in accordance with the definition of the data subject’s consent in Article 2(h)." She therefore concluded that the applicants had not given their consent to the processing (i.e. the publication) of their personal data within the meaning of Article 7(a) of Directive 95/46/EC.29 Express consent may also be given in the on-line environment. As in the off-line world, there are very suitable means for delivering unambiguous consent, as illustrated in the following example. Example: on-line consent to be enrolled in a loyalty program A hotel web site includes a reservation form, enabling individuals to reserve rooms in advance electronically. The on-line form where individuals introduce the desired dates and payment related information also includes a visible box to be ticked by individuals who want their data to be used for the purposes of enrolling them in a loyalty program. Ticking the box after having received relevant information would constitute express, unambiguous consent as the action of ticking the box is clear enough to leave no doubt as to the individual's wish to be enrolled in the loyalty programme. Express consent may also be given orally, through statements intended to signify agreement. Express oral consent would be given in the following situation. Example: oral consent to receive promotional information Whilst paying at a hotel’s checkout lane, the clerk at the counter asks clients if they would like to provide their address so that the hotel can send them promotional information. Individuals that respond by providing their postal address, after having 28 29
European Agricultural Guarantee Fund (EAGF) and the European Agricultural Fund for Rural Development (EAFRD). Opinion of Advocate General Sharpston delivered on 17 June 2010, Volker und Markus Schecke GbR, in Joined Cases C-92/09 and C-93/09. It should be noted that the ECJ ruled in its judgment of 9 November 2010 that the data processing was not based on consent: "63. The European Union legislation in question, which merely provides that beneficiaries of aid are to be informed in advance that the data concerning them will be published, thus does not seek to base the personal data processing for which it provides on the consent of the beneficiaries concerned."
.
22 653
heard the request from the clerk and the relevant information, would be giving express consent. The action of providing their address may constitute an unequivocal indication of the individual's wish. However the data controller may choose to put in place mechanisms to prove more reliably that consent had been given. In some circumstances unambiguous consent may be inferred from certain actions, in particular this will be the case when the actions lead to an unmistakable conclusion that consent is given. However, this depends on relevant information about the data processing having been given, enabling the individual to make a decision (who is the data controller, what are the purposes of the processing, etc). Example: consent to be photographed Whilst checking in at a hotelâ&#x20AC;&#x2122;s check-in lane, the clerk at the counter informs guests that a photo-shoot will take place at one of the hotels' cafeterias that afternoon. Selected images will be used for marketing material, particularly for paper based hotel brochures. If hotel guests would like to be pictured, they are invited to be in the cafeteria during the relevant hours. A different cafeteria is available for those who do not want to be photographed. Hotel guests that - having been informed - decide to go to the cafeteria during the shooting hours may be deemed to have given their consent to be photographed. Their consent is inferred from their action of going to the cafeteria where the photo-shoot is taking place at the relevant time. Going to the cafeteria constitutes an indication of the individual's wishes, which in principle may be deemed unambiguous insofar as there is little doubt that the individual going to the cafeteria wanted to be photographed. However, the hotel might consider it prudent to have documentary evidence of the consent obtained, in case the validity of such consent is challenged in the near future.
As already stated, the same requirements including unambiguous consent apply both in the off-line and in the on-line world. However, the Working Party notes that the risk of ambiguous consent is likely to be greater in the on-line world, this calls for specific attention. The next example illustrates a case where consent inferred from certain action (participation in an on-line game) does not meet the requirements for valid consent. Example: on-line game An on-line game provider requires players to provide age, name and address for the purposes of participating in the on-line game (distribution of players among ages and addresses). The website features a notice, accessible through a link (although access to such notice is not necessary to participate in the game), which indicates that by using the website (and thus providing information) players are consenting to their data being processed to deliver them marketing information, by the on-line game provider and by third parties. Accessing and participating in the game is not tantamount to giving unambiguous consent to the further processing of their personal information for purposes other than the participation in the game. Participation in the game does not imply the individuals' intent to consent to processing other than what is necessary to play. This type of behaviour does not constitute an unambiguous indication of the individualâ&#x20AC;&#x2122;s wish to have his/her data used for marketing purposes.
23 654
Example: default privacy settings The default settings of a social network, which users do not necessarily need to access to use it, enable the entire "friends of friends" category making all the personal information of each user viewable to all "friends of friends". Users who do not wish to have their information viewed by "friends of friends" are required to click a button. If they remain passive, or fail to engage in the action consisting in clicking a button, they are deemed by the controller to have consented to having their data viewable. However, it is very questionable whether not clicking on the button means that individuals at large are consenting to have their information viewable by all the friends of friends. Because of the uncertainty as to whether the lack of action is meant to signify consent, not clicking may not be considered unambiguous consent. The above example illustrates a case where the individual remains passive (e.g. lack of action or "silence"). Unambiguous consent does not fit well with procedures to obtain consent based on inaction or silence from individuals: a party's silence or inaction has inherent ambiguity (the data subject might have meant to assent or might merely have meant not to perform the action). The following example further illustrates this. There is ambiguity in the situation where individuals are deemed to have provided consent if they have not responded to a letter where they are informed that lack of responding means that they are consenting. In this type of situation, the individual behavior (or rather lack of it) raises serious doubts as to whether the individual meant to signify agreement. The fact that the individual did not undertake any positive action does not allow to be concluded that he gave his consent. Thus, it will not meet the requirement of unambiguous consent. Besides, as further illustrated below, it will also be very difficult for the data controller to provide evidence showing that the individual consented. The Working Party has stated the unsuitability of consent based on individuals' silence in the context of sending direct marketing through emails. "Implied consent to receive such mails is not compatible with the definition of consent of Directive 95/46/EC ..... Similarly, pre-ticked boxes, e.g., on websites are not compatible with the definition of the Directive either"30. The following example confirms this view: Example: invalid consent for further uses of customer data An on-line book retailer sends an email to its loyalty program customers informing them that their data will be transferred to an advertising company, which plans to use it for marketing purposes. Users are given two weeks to respond to the email. They are informed that a lack of response will be deemed consent to the transfer. This type of mechanism, whereby consent is derived from a lack of reaction from individuals, does not deliver valid, unambiguous consent. It is not possible to ascertain without any doubt that individuals have agreed to the transfer from their lack of response.
It follows from the above that, as a consequence of the requirement for consent to be unambiguous, data controllers are de facto encouraged to have in place procedures and 30
Opinion 5/2004 on unsolicited communications for marketing purposes under Article 13 of Directive 2002/58/EC, adopted on 27 February 2004 (WP90).
24 655
mechanisms that leave no doubt that consent has been given, either on the basis of an express action carried out by the individual or by being clearly inferred from an action carried out by an individual. As mentioned above, a matter of good practice data controllers should consider putting in place relevant measures and procedures to show that consent has been given. The more complicated the environment in which they operate, the more measures will be necessary to ensure that consent is verifiable. This information should be put at the disposal of the data protection authority upon request. III.A.3. Article 8.2(a) Article 8 of the Directive provides special protection to "special categories of data" which by their nature are considered to be very sensitive. The processing of such data is prohibited unless at least one of several specified exceptions applies. Article 8(2)(a) provides that the prohibition will not apply if the data subject has given his/her explicit consent to the processing. In legal terms "explicit consent" is understood as having the same meaning as express consent. It encompasses all situations where individuals are presented with a proposal to agree or disagree to a particular use or disclosure of their personal information and they respond actively to the question, orally or in writing. Usually, explicit or express consent is given in writing with a hand-written signature. For example, explicit consent will be given when data subjects sign a consent form that clearly outlines why a data controller wishes to collect and further process personal data. Although explicit consent is traditionally in writing, be it on paper or in electronic form, as illustrated before in chapter III.A.2, this is not necessary so it can also be given orally. This is confirmed by the fact that the requirement for consent suggested under Article 8 to be in writing was deleted in the final version of the Directive. However, as illustrated in the same chapter, oral consent may be difficult to prove and, therefore, in practice, data controllers are advised to resort to written consent for evidentiary reasons. The requirement for explicit consent means that consent that is inferred will not normally meet the requirement of Art 8(2). In this regard, it is worth recalling the Article 29 Working Party opinion on electronic health records31 stating that "In contrast to the provisions of Article 7 of the Directive, consent in the case of sensitive personal data and therefore in an EHR must be explicit. Opt-out solutions will not meet the requirement of being â&#x20AC;&#x2DC;explicitâ&#x20AC;&#x2122;.....".
Example: medical data for research A patient who is informed by a clinic that his medical file will be transferred to a researcher unless he objects (by calling a number), will not meet the requirement of explicit consent.
31
WP131 - Working Document on the processing of personal data relating to health in electronic health records (EHR).
25 656
As stated above in chapter II.A.2, individuals may give explicit consent, orally and also in writing, by engaging in an affirmative action to express their desire to accept a form of data processing. In the on-line environment explicit consent may be given by using electronic or digital signatures. However, it can also be given through clickable buttons depending on the context, sending confirmatory emails, clicking on icons, etc32. The endorsement of procedures that entail an affirmative action by the individual is explicitly recognised by Recital 17 of the e-Privacy Directive which states that â&#x20AC;&#x153;Consent may be given by any appropriate method enabling a freely given specific and informed indication of the user's wishes, including by ticking a box when visiting an Internet websiteâ&#x20AC;?. Consent does not have to be recordable to be valid. However, it is in the interest of the data controller to retain evidence. Obviously, the strength of the evidence provided by a specific mechanism may vary, providing more or less evidence of the consent. Consent that has been obtained through a clickable button with the identity of the individual supported with an email address only will have much less evidentiary value than a similar process that is supported, for example with recordable consent mechanisms33. The need for strong evidence will also depend on the type of data collected and the purpose followed: an electronic signature will not be needed to consent to receiving commercial offers, but may be necessary to consent to the processing of certain types of financial data on-line. Explicit consent given in an on-line environment will need to be recordable so that it is accessible to be used for subsequent reference.34 In the light of the above, on-line registration forms, to be completed by individuals with their identification information and their agreement to the data processing will be considered to meet the requirement for explicit consent, provided that all other requirements are fulfilled. For example, to open a personalised on-line medical file, patients may give their consent by providing their contact details and ticking a specific box to signify their agreement. The use of stronger authentication methods - for example, the use of digital signatures - will of course achieve the same outcome and constitute stronger evidence35. In certain cases, Member States may decide that a given data processing operation must be legitimised on the basis of consent and specify the type of consent. For example, to apply for a health card containing access to a medical history, Member States may decide that individuals that register on-line must sign with a particular digital signature. This option will ensure that the consent is express; it also gives the data controller more assurance that it will be able to prove individuals' consent. 32
33
34
35
This interpretation is in line with EU legislation, mainly on electronic commerce and on the broader use of digital signatures, which has required Member States to amend their legislation containing formal requirements for documents to be "in writing" and to be "handwritten" so that their electronic counterparts are equally accepted, if certain conditions are met. In this regard, see for example Greek and German law regarding the requirements of providing consent by electronic means requiring consent to be recorded in a secure manner, the possibility to be accessed by the user or subscriber any time and to be revocable at any time (Article 5(3) of the Greek Law 3471/2006 on the protection of personal data in the electronic communications sector; Article 13(2) of the German Law on Teleservices, Article 94 of the German Law on Telecommunications, and Article 28 (3a) of the German Federal Data Protection Law). It is outside the scope of this Opinion to analyse the technical conditions that must be fulfilled by electronic documents and digital signatures to be accorded equivalent evidentiary value as their hand-written counterparts. This is a matter that goes beyond data protection legislation and which has been regulated at EU level. This is because the use of certain types of digital signatures (advanced electronic signatures which are based on a qualified certificate and which are created by a secure-signature-creation device) are automatically presumed to have the same legal value as evidence as written ones.
26 657
III.A.4. Article 26.1 Article 26.1(a) foresees the unambiguous consent of the data subject as an exception to the prohibition to transfer data to non-adequate third countries. The reflections made above regarding Article 7(a) apply here as well. This means that, in addition to the requirements for valid consent ex Article 2(g), consent must also be unambiguous. The Article 29 Working Party has devoted much effort to providing guidance on the application of Article 25 and 26 of the Directive, including the exception of consent. In this context it is worth recalling the Working Party's document WP1236 on the meaning of unambiguous consent: "Because the consent must be unambiguous, any doubt about the fact that consent has been given would also render the exemption inapplicable. This is likely to mean that many situations where consent is implied (for example because an individual has been made aware of a transfer and has not objected) would not qualify for this exemption". In the light of the above, unambiguous consent is more likely to be obtained when individuals engage in an affirmative action to signify their agreement to the transfer, for example, by signing a consent form or engaging in other actions that unmistakably support the conclussion that consent has been given. In WP 11437 regarding the use of consent for data transfers, the Working Party stated that "Consent is unlikely to provide an adequate long-term framework for data controllers in cases of repeated or even structural transfers for the processing in question. In fact, particularly if the transfer forms an intrinsic part of the main processing (e.g. centralisation of a world database of human resources, which needs to be fed by continual and systematic data transfers to be operational), the data controllers could find themselves in insoluble situations if just one data subject subsequently decided to withdraw his consent. Strictly speaking, the data relating to a person who had withdrawn his consent could no longer be transferred; failing this, the transfer would continue to be partially based on the data subjectâ&#x20AC;&#x2122;s consent, but an alternative solution (a contract, BCR, etc.) would have to be found for data relating to subjects who had withdrawn their consent. Relying on consent may therefore prove to be a â&#x20AC;&#x153;false good solutionâ&#x20AC;?, simple at first glance but in reality complex and cumbersome."
III.A.5. Consent given by individuals lacking full legal capacity Under Directive 95/46/EC there are no particular rules on obtaining the consent of individuals lacking full legal capacity, including children. It is important that this reality is taken into account in the context of the review of the Data Protection Directive. In addition to the issues raised above, consent of these persons presents its own, specific problems.
36
37
WP12 - Working Document Transfers of personal data to third countries: Applying Articles 25 and 26 of the EU data protection Directive, adopted on 24 July 1998. Working document on a common interpretation of Article 26(1) of Directive 95/46/EC of 24 October 1995, adopted on 25.11.2005.
27 658
With regard to children, the conditions for delivering valid consent vary from Member State to Member State. The Article 29 Working Party, has on several occasions, reflected on the issue of children's consent and researched national practices38. Previous work shows that when children's consent is sought, legal requirements may require obtaining the consent of the child and the representative, or the sole consent of the child if he or she is already mature. The ages when one or the other rule applies vary. There are no harmonized procedures for verifying a childâ&#x20AC;&#x2122;s age. The lack of general rules on this leads to a fragmented approach and does not recognise the need for a specific protection of children in specific circumstances, because of their vulnerability, and because it causes legal uncertainty, particularly as far as the way children's consent is obtained. The Working Party considers that this absence of harmonisation has consequences in terms of legal certainty. Harmonising the conditions for allowing incapable individuals to exercise their rights at EU level, especially with regard to the age threshold, would certainly bring additional guarantees. However, the Working Party is aware that this may well go beyond the scope of data protection as it touches more generally on civil law issues. The Working Party draws the attention of the Commission to the challenges raised in this area. Furthermore, the Article 29 Working Party believes that the interests of children and other individuals lacking full legal capacity would be better protected if the Directive contained additional provisions, specifically addressed to the collection and further processing of their data. These provisions could foresee the circumstances in which the consent of the representative is required, together with, or in place of, the consent of the incapable individual, and could foresee circumstances where it should not be possible to use consent as basis for legitimising the processing of personal data. It should also foresee the requirement to use on-line age verification mechanisms. There are different mechanisms and different thresholds. For example, age verification, rather than being subject to one single rule, could be based on a sliding scale approach whereby the mechanism to be used would depend on the circumstances, such as the type of processing (the purposes), whether particularly risky, type of data collected, data usages, (whether the data is intended for disclosure), etc.
III.B.
Directive 2002/58/EC
The recently amended e-Privacy Directive (Directive 2002/58/EC)39 is a lex specialis vis-Ă -vis Directive 95/46/EC insofar as it offers a sector specific regime with regard to privacy and electronic communications. Most of its provisions apply to providers of
38
39
WP147 - Working Document 1/2008 on the protection of children's personal Data (General guidelines and the special case of schools); WP160 Opinion 2/2009 on the protection of children's personal data (General Guidelines and the special case of schools). Directive 2009/136/EC of the European Parliament and of the Council of 25 November 2009 amending Directive 2002/22/EC on universal service and usersâ&#x20AC;&#x2122; rights relating to electronic communications networks and services, Directive 2002/58/EC concerning the processing of personal data and the protection of privacy in the electronic communications sector and Regulation (EC) No 2006/2004 on cooperation between national authorities responsible for the enforcement of consumer protection laws, 18.12.2009.
28 659
publicly available electronic communication services only (e.g. providers of telephony, Internet service providers, etc). Some of the provisions of the e-Privacy Directive rely on consent as the legal basis upon which providers of publicly available electronic communication services may rely in order to process data40. This is the case, for example, regarding the use of traffic or location data. The Article 29 Working Party considers it useful to comment on selected aspects related to the use of consent under the e-Privacy Directive that are of particular interest. To this end, we will address the following five issues: a) The relationship between the definition and overall meaning of consent between the Directive 95/46/EC and the e-Privacy Directive. This is based on Article 2.2(f) of the ePrivacy Directive. b) The question of whether, to breach the confidentiality of communications (for example, to monitor or intercept a telephone communication), it is necessary to obtain the consent of one or both communicating parties. This is governed by Articles 6(3), and 5.1. c) The question regarding the timing as to when consent must be obtained. This is addressed in various provisions of the e-Privacy Directive, including Article 5(3), 6 and 13. d) The scope of application of the right to object and its distinction from consent. This distinction can be analysed under Article 13 of the e-Privacy Directive. e) The possibility to withdraw consent as explicitly foreseen in Article 6.3 and 9.3-4 of the e-Privacy Directive. III.B.1. Article 2(f) - Consent and relation with Directive 95/46/EC “consent of user or subscriber” Article 2 of the e-Privacy Directive explicitly states that the definitions of Directive 95/46/EC shall apply regarding Directive 2002/58/EC. Article 2(f) says "consent by a user or a subscriber corresponds to the data subject's consent in Directive 95/46/EC". This means that whenever consent is required under the e-Privacy Directive, the criteria to determine whether consent is valid are the same as those set forth by Directive 95/46/EC, namely the definition in Article 2(g) and the specificity included in Article 7(a). The view that consent in the e-Privacy Directive must be understood by reference to Article 2(g) and Article 7(a) together is confirmed in Recital 1741,
40
Traffic data means data processed for the purpose of the conveyance of a communication on an electronic communications network or for the billing in respect of that communication, including data relating to the routing, duration or time of a communication. 41 It reads which says: "For the purposes of this Directive, consent…should have the same meaning as the data subject's consent as defined and further specified in Directive 95/46/EC"
29 660
III.B.2. Article 5.1. - Whether consent is necessary from one or two parties “… consent of users concerned …” Article 5(1) of the e-Privacy Directive protects confidentiality of communications by prohibiting any kind of interception or surveillance of communications without the consent of all users concerned. In this case, Article 5(1) requires the consent of "all users concerned", in other words, the two parties to a communication. Consent of one of the parties is not enough. In the context of elaborating its Opinion 2/200642, the Article 29 Working Party looked into several services that entailed the screening of email content and, in some cases, the tracking of email opening. The Working Party expressed concern that in such services one of the communicating parties was not informed. For these services to be compliant with Article 5(1) consent of both communicating parties is necessary.
III.B.3 Articles 6(3), 9, 13 and 5(3) - Timing when consent is required "... having been provided with clear and comprehensive information, ..." Various provisions of the e-Privacy Directive contain either explicit or implicit language indicating that consent is to be provided prior to the processing. This is in line with Directive 95/46/EC. Article 6(3) of the e-Privacy Directive includes an explicit reference to the prior consent of the subscriber or user concerned, laying down an obligation to provide information and obtain prior consent before processing traffic data for the purposes of marketing electronic communication services or value added services. For certain types of services, consent may be obtained from the subscriber at the moment of the subscription to the service. In other cases, it may be feasible to obtain it directly from the user. A similar approach is followed under Article 9 regarding the processing of location data other than traffic data. The service provider must inform the users or subscribers - prior to obtaining their consent - of the type of location data other than traffic data, which will be processed. Article 13 sets forth a requirement to obtain prior consent from subscribers to use automatic calling systems without human intervention, fax or e-mail for purposes of direct marketing. Article 5(3) contains a specific rule regarding the storing of information or gaining of access to information on a user's terminal, including for the purpose of tracking the user's on-line activities. While Article 5(3) does not use the word prior, this is a clear and obvious conclusion from the wording of the provision. It makes good sense for consent to be obtained prior to the starting of the data processing. Otherwise, the processing carried out during the period of time from the moment the processing had started until the moment that consent had been obtained 42
Opinion 2/2006 on privacy issues related to the provision of email screening services, adopted on 21.02.2006 (WP118).
30 661
would be unlawful because of lack of legal ground. Furthermore, in such cases, if the individual decided against consenting, any data processing that had already taken place would be unlawful for that reason as well. It follows from the above that whenever consent is required, it must be prior to the data processing starting. The possibility of starting the processing without having obtained consent first is only lawful when the Data Protection Directive or the ePrivacy Directive, rather than requiring consent, provides an alternative ground and refers to the right to object to or refuse the processing. These mechanisms are clearly distinguished from consent. In these cases, the processing may have already started and the individual has the right to object or refuse it. An example of this can be found in Article 5(3) of the former e-Privacy Directive, which said (emphasis added): "the use of electronic communications networks to store information or to gain access to information stored in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned is provided with clear and comprehensive information in accordance with Directive 95/46/EC, inter alia about the purposes of the processing, and is offered the right to refuse such processing by the data controller." This should be compared with the new wording of Article 5(3) of the e-Privacy Directive as amended by Directive 2009/136/EC43, which states that "(...) the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent (...)". The consequences of this change in the wording of Article 5(3) have been explained by the Article 29 Working Party in its opinion 2/2010 on online behavioural advertising44. The difference between refusal and consent is also further developed in the next chapter. In many cases where the e-Privacy Directive or the Data Protection Directive provides for a possibility to refuse the processing of personal data, it is because the legal basis for the initial data processing is based on legal grounds other than consent, such as an existing contract. This is further illustrated in the next section, which comments on Article 13 of the e-Privacy Directive.
III.B.4. Article 13(2-3) - right to object and its distinction from consent
“…customers clearly and distinctintly are given the opportunity to object …" Article 13 of the e-Privacy Directive foresees the use of consent to send electronic communications for direct marketing purposes lawfully. It does so by relying on a standard principle and a specific provision. 43
44
Directive 2009/136/EC of the European Parliament and of the Council of 25 November 2009 amending Directive 2002/22/EC on universal service and users’ rights relating to electronic communications networks and services, Directive 2002/58/EC concerning the processing of personal data and the protection of privacy in the electronic communications sector and Regulation (EC) No 2006/2004 on cooperation between national authorities responsible for the enforcement of consumer protection laws Text with EEA relevance, O. J. L 337 , 18/12/2009 P. 0011 - 0036 Opinion of 22 June 2010, WP 171: the issue whether consent may be expressed via "the appropriate settings of
a browser or other application" [recital 66 of directive 2009/136/EC] is explicitly dealt with in point 4.1.1 of WP 171.
31 662
Regarding the use of automated calling machines, fax machines and email, it requires the prior consent of the data subject. If the addressee of the commercial communication is an existing client and the communication aims at promoting the provider's own or similar products or services, the requirement is not consent, but ensuring that individuals "are given the opportunity to object" ex Article 13(2). Recital 41 explains the reasoning why the legislator, in this case, did not require consent: "Within the context of an existing customer relationship, it is reasonable to allow the use of electronic contact details for the offering of similar products or services". Thus, in principle, the contractual relationship between the individual and the service provider is the legal ground that allows the first contact by email. However, individuals should have the opportunity to object to further contacts. As the Working Party has already indicated: "This opportunity should continue to be offered with each subsequent direct marketing message, free of charge, except for any costs for the transmission of this refusal".45 The need for consent should be distinguished from this right to object. As illustrated above in Chapter III.A.2, consent based on the lack of individuals' action, for example, through pre-ticked boxes, does not meet the requirements of valid consent under the Directive 95/46/EC. The same conclusion applies to browser settings which would accept by default the targeting of the user (through the use of cookies). This is made clear in the new wording of Article 5(3) quoted supra in Chapter III.B.3. These two examples fail to meet in particular the requirements for an unambiguous indication of wishes. It is essential that the data subject is given the opportunity to make a decision and to express it, for instance by ticking the box himself, in view of the purpose of the data processing. In its opinion on behavioural advertising, the Working Party has concluded that "it seems of paramount importance for browsers to be provided with default privacyprotective settings. In other words, to be provided with the setting of 'non-acceptance and non-transmission of third party cookies'. To complement this and to make it more effective, the browsers should require users to go through a privacy wizard when they first install or update the browser and provide for an easy way of exercising choice during use"46. III.B.5. Articles 6.3, 9.3-4. - possibility to withdraw consent “… possibility to withdraw consent at any time …” The possibility to withdraw consent, which is implicit in Directive 95/46/EC, is taken up in various provisions of the e-Privacy Directive. This was explicitly stated in the Working Party's Opinion on the use of location data with a view to providing value added services47:
45
46 47
Opinion 5/2004 on unsolicited communications for marketing purposes under Article 13 of Directive 2002/58/EC, adopted on 27.02.2004. Opinion of 22.06. 2010, WP 171, op.cit. Opinion 5/2005 on the use of location data with a view to providing value-added services, adopted on 25.11.2005 (WP115).
32 663
"Under Article 9 of Directive 2002/58/EC, people who have given their consent for the processing of location data other than traffic data may withdraw consent at any time and must have the possibility, using a simple means and free of charge, of temporarily refusing the processing of such data. The Working Party regards these rights — which can be taken as implementing the right to object to the processing of location data — as essential given the sensitive nature of location data. The Working Party believes that it is a precondition for the exercise of these rights that individuals are kept informed, not only when they subscribe to a service but also when they use it. Where a service requires ongoing processing of location data, the Working Party takes the view that the service provider should regularly remind the individual concerned that his or her terminal equipment has been, will be or can be located. This will allow that person to exercise the right to withdraw under Article 9 of Directive 2002/58/EC, should he or she wish to do so." As already mentioned above, this implies that withdrawal is exercised for the future, not for the data processing that took place in the past, in the period during which the data was collected legitimately. Decisions or processes previously taken on the basis of this information can therefore not be simply annulled. However, if there is no other legal basis justifying the further storage of the data, they should be deleted by the data controller.
IV.
Conclusions
This opinion looks into the legal framework regarding the use of consent under Directive 95/46/EC and Directive 2002/58/EC. The goal of this exercise is twofold: First, it aims to clarify the existing legal requirements and illustrate how they work in practice. At the same time, in doing so, it provides a reflection on whether the existing framework remains suitable in the light of the many new ways of processing personal data or whether changes to it may be necessary. IV.1. Clarification of the key aspects of the current framework Article 2 (h) of Directive 95/46/EC defines consent as "any freely given specific and informed indication of his wishes by which the data subject signifies his agreement to personal data relating to him being processed". Article 7 of the Directive, which sets forth the legal basis for processing personal data, sets out unambiguous consent as one of the legal grounds. Article 8 requires explicit consent as a legal ground to process sensitive data. Article 26.1 of Directive 95/46/EC and various provisions of the ePrivacy Directive require consent to carry out specific data processing activities within their scope of application. The points developed in this opinion aim at clarifying the various elements of this legal framework in an effort to make it easier to apply by stakeholders in general. Elements/observations of general nature •
Consent is one of the six legal grounds to process personal data (one of five for sensitive data); it is an important ground as it gives some control to the data subject with regard to the processing of his data. The relevance of consent as an enabler of the individual’s autonomy and self-determination relies on its use in the right context and with the necessary elements. 33 664
•
Generally speaking, the legal framework of Directive 95/46/EC applies whenever consent is sought, independently of whether this happens off-line or on-line. For example, the same rules apply when a bricks and mortar retailer seeks sign up for a loyalty card scheme via a paper form, as would be the case if it did this through its Internet site. In addition, the ePrivacy Directive specifies certain data processing operations which are subject to consent: they mostly relate to the processing of data in connection with the provision of publicly available electronic communication services. The requirements for consent to be valid within Directive 2002/58/EC are the same as under Directive 95/46/EC.
•
Situations where data controllers use consent as a legal ground to process personal data should not be confused with situations where the controller bases the processing on other legal grounds which entail an individual right to object. For example, this may be the case when the processing relies on the 'legitimate interests' of the data controller ex Article 7(f) of Directive 95/46/EC, yet the individual has the right to object ex Article 14(a) of Directive 95/46/EC. Another example is when a data controller sends e-mail communications to existing clients in order to promote the data controller's own or similar products or services, however, individuals have a right to object under Article 13.2 of Directive 2002/58/EC. In both cases, the data subject has the right to object to the processing, this is not the same as consent.
•
Reliance on consent to process personal data does not relieve the data controller from his obligation to meet the other requirements of the data protection legal framework, for example, to comply with the principle of proportionality under Article 6.1(c), security of the processing ex Article 17, etc.
•
Valid consent presupposes individuals' capacity to consent. Rules regarding the capacity to consent are not harmonised and may therefore vary from Member State to Member State.
•
Individuals who have consented should be able to withdraw their consent, preventing further processing of their data. This is confirmed also under the ePrivacy Directive for specific data processing operations based on consent, such as the processing of location data other than traffic data.
•
Consent must be provided before the processing of personal data starts, but it can also be required in the course of a processing, where there is a new purpose. This is stressed in various provisions of Directive 2002/58/EC, either through the requirement "prior" (e.g. Article 6.3) or through the wording of the provisions (e.g. Article 5.3).
Specific elements of the legal framework related to consent •
For consent to be valid, it must be freely given. This means that there must be no risk of deception, intimidation or significant negative consequences for the data subject if he/she does not consent. Data processing operations in the employment environment where there is an element of subordination, as well as in the context of government services such as health may require careful assessment of whether individuals are free to consent.
•
Consent must be specific. Blanket consent without determination of the exact purposes does not meet the threshold. Rather than inserting the information in the 34 665
general conditions of the contract, this calls for the use of specific consent clauses, separated from the general terms and conditions. •
Consent must be informed. Articles 10 and 11 of the Directive lists the type of information that must necessarily be provided to individuals. In any event, the information provided must be sufficient to guarantee that individuals can make well informed decisions about the processing of their personal data. The need for consent to be "informed" translates into two additional requirements. First, the way in which the information is given must ensure the use of appropriate language so that data subjects understand what they are consenting to and for what purposes. This is contextual. The use of overly complicated legal or technical jargon would not meet the requirements of the law. Second, the information provided to users should be clear and sufficiently conspicuous so that users cannot overlook it. The information must be provided directly to individuals. It is not enough for it to be merely available somewhere.
•
As to how consent must be provided, Article 8.2(a) requires explicit consent to process sensitive data, meaning an active response, oral or in writing, whereby the individual expresses his/her wish to have his/her data processed for certain purposes. Therefore, express consent cannot be obtained by the presence of a pre-ticked box. The data subject must take some positive action to signify consent and must be free not to consent.
•
For data other than sensitive data, Article 7(a) requires consent to be unambiguous. "Unambiguous" calls for the use of mechanisms to obtain consent that leave no doubt as to the individual's intention to provide consent. In practical terms, this requirement enables data controllers to use different types of mechanisms to seek consent, ranging from statements to indicate agreement (express consent), to mechanisms that rely on actions that aim at indicating agreement.
•
Consent based on an individual's inaction or silence would normally not constitute valid consent, especially in an on-line context. This is an issue that arises in particular with regard to the use of default settings which the data subject is required to modify in order to reject the processing. For example, this is the case with the use of pre-ticked boxes or Internet browser settings that are set by default to collect data.
IV.2 Assessment of the current framework and possible need for changes Overall assessment The Working Party considers that the current data protection framework contains a wellthought out set of rules that establish the conditions for consent to be valid in order to legitimise data processing operations. These apply in both the off- and on-line environments. More particularly: The framework successfully achieves the balancing of a number of concerns. On the one hand, it ensures that only true, informed, consent is deemed as such. In this regard, Article 2(h) explicitly requiring consent to be freely given, specific and informed, is relevant and satisfactory. On the other hand, this requirement is not a straight jacket but it rather provides sufficient flexibility, avoiding technologically specific rules. This is illustrated in the same Article 2(h) where it defines consent as any indication of the individual’s wishes. This provides sufficient leeway in terms of the ways in which such 35 666
an indication can be provided. Articles 7 and 8, requiring respectively unambiguous and explicit consent, capture well the need for a balance between the two concerns, giving flexibility and avoiding overly rigid structures while guaranteeing protection. The result is a framework which, if properly applied and implemented, is capable of keeping pace with the wide variety of data processing operations that often result from technological developments. In practice however, establishing when consent is needed and more particularly the requirements for valid consent, including how to apply them concretely, is not always easy because of a lack of uniformity across Member States. Implementation at national level has resulted in different approaches. More specific shortcomings were identified during the discussions in the Article 29 Working Party that led to this Opinion, further described below. Possible changes •
The notion of unambiguous consent is helpful for setting up a system that is not overly rigid but provides strong protection. While it has the potential to lead to a reasonable system, unfortunately, its meaning is often misunderstood or simply ignored. While the indications and examples developed above should contribute to enhancing the legal certainty and protection of individuals' rights when consent is used as a legal basis, the above situation seems to call for some amendments.
•
More particularly, the Article 29 Working Party considers that the wording itself ("unambiguous") would benefit from further clarification as a part of the revision of the general data protection framework. Clarification should aim at emphasizing that unambiguous consent requires the use of mechanisms that leave no doubt of the data subject’s intention to consent. At the same time it should be made clear that the use of default options which the data subject is required to modify in order to reject the processing (consent based on silence) does not in itself constitute unambiguous consent. This is especially true in the on-line environment.
•
In addition to the clarification described above, the Article 29 Working Party suggests the following: i. First, include in the definition of consent of Article 2(h) the word “unambiguous” (or equivalent) in order to reinforce the notion that only consent that is based on statements or actions to signify agreement constitutes valid consent. In addition to adding clarity, this would align the concept of consent under Article 2(h) with the requirements for valid consent under Article 7. Moreover, the meaning of the word “unambiguous” could be further explained in a recital of the future legal framework. ii. Second, in the context of a general accountability obligation, the controllers should be in a position to demonstrate that consent has been obtained. Indeed, if the burden of proof is reinforced so that data controllers are required to demonstrate that they have effectively obtained the consent of the data subject, they will be compelled to put in place standard practices and mechanisms to seek and prove unambiguous consent. The type of mechanisms will depend on the
36 667
context and should take into account the facts and circumstances of the processing, more particularly its risks. â&#x20AC;˘
The Article 29 Working Party is not convinced that the legal framework should require explicit consent as a general rule for all types of processing operations, including those currently covered by Article 7 of the Directive. It considers that unambiguous consent which encompasses explicit consent but also consent resulting from unambiguous actions should remain the required standard. This choice gives more flexibility to data controllers to collect consent and the overall procedure may be quicker and more user friendly.
â&#x20AC;˘
Several aspects of the legal framework that apply to consent are deduced from the wording, legal history or have been developed through case law and Article 29 Working Party Opinions. It would provide more legal certainty if such aspects were expressly built in the new data protection legislative framework. The following points could be taken into account:
â&#x20AC;˘
i.
The inclusion of an express clause setting up the right of individuals to withdraw their consent.
ii.
The reinforcement of the notion that consent must be given before the processing starts, or before any further use of the data for purposes not covered by an initial consent, where there is no other legal ground for the processing.
iii.
The inclusion of explicit requirements regarding the quality (obligation to provide information on data processing in a manner which is easy to understand, in clear and plain language) and accessibility of the information (obligation for the information to be conspicuous, prominent and directly accessible). This is vital for enabling individuals to make informed decisions.
Finally, with regard to individuals lacking legal capacity, provisions ensuring enhanced protection could be foreseen, including: i.
Clarifications as to the circumstances in which consent is required from parents or representatives of an incapable individual, including the age threshold below which such consent would be mandatory.
ii.
Laying down the obligation to use age verification mechanisms, which may vary depending on circumstances such as the age of children, the type of processing, whether particularly risky, and whether the information will be kept by the data controller or made available to third parties;
iii. A requirement for information to be adapted to children insofar as this would make it easier for children to understand what it means when data from them are collected, and thus deliver consent; iv. Specific safeguards identifying data processing activities, such as behavioural advertising, where consent should not be a possible basis to legitimise the processing of personal data. 37 668
The Article 29 Working Party will revisit the issue of consent. More particularly, national data protection authorities as well as the Working Party may decide at a later stage to draft guidelines to developing this Opinion further, providing additional practical examples related to the use of consent.
Done in Brussels, on 13 July 2011
For the Working Party The Chairman Jacob KOHNSTAMM
38 669
ARTICLE 29 DATA PROTECTION WORKING PARTY
00879/12/EN WP 194
Opinion 04/2012 on Cookie Consent Exemption
Adopted on 7 June 2012
This Working Party was set up under Article 29 of Directive 95/46/EC. It is an independent European advisory body on data protection and privacy. Its tasks are described in Article 30 of Directive 95/46/EC and Article 15 of Directive 2002/58/EC. The secretariat is provided by Directorate C (Fundamental Rights and Union Citizenship) of the European Commission, Directorate General Justice, B-1049 Brussels, Belgium, Office No MO-59 02/013. Website: http://ec.europa.eu/justice/data-protection/index_en.htm 670
THE WORKING PARTY ON THE PROTECTION OF INDIVIDUALS WITH REGARD TO THE PROCESSING OF PERSONAL DATA set up by Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995, having regard to Articles 29 and 30 paragraphs 1(a) and 3 of that Directive, having regard to its Rules of Procedure, HAS ADOPTED THE PRESENT OPINION
1 Introduction Article 5.3 of Directive 2002/58/EC, as amended by Directive 2009/136/EC has reinforced the protection of users of electronic communication networks and services by requiring informed consent before information is stored or accessed in the user’s (or subscriber’s) terminal device. The requirement applies to all types of information stored or accessed in the user’s terminal device although the majority of discussion has centred on the usage of cookies as understood by the definition in RFC62651. As such, this opinion explains how the revised Article 5.3 impacts on the usage of cookies but the term should not be regarded as excluding similar technologies. Article 5.3 allows cookies to be exempted from the requirement of informed consent, if they satisfy one of the following criteria: CRITERION A: the cookie is used “for the sole purpose of carrying out the transmission of a communication over an electronic communications network”. CRITERION B: the cookie is “strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service”. While the requirements for informed consent were already examined in detail by the Working Party in two Opinions2, this document is designed to analyze the exemptions to this principle, in the context of cookies and related technologies. This analysis is conducted without prejudice to the right to be informed and the eventual right to oppose set forth by Directive 95/46/EC, which apply to personal data processing whether cookies are used or not.
2 Analysis 2.1 Criterion A The inclusion of the phrase “sole purpose” in CRITERION A specifically limits the types of processing which may be undertaken using cookies and does not leave much room for 1 2
http://tools.ietf.org/html/rfc6265 Opinion 2/2010 on “online behavioural advertising” 2/2010 and in Opinion 16/2011 on “the EASA/IAB Best Practice Recommendation on Online Behavioural Advertising”.
671
2
interpretation. Simply using a cookie to assist, speed up or regulate the transmission of a communication over an electronic communications network is not sufficient. The transmission of the communication must not be possible without the use of the cookie. It can be noted that in the original version of Directive 2002/58/EC, Article 5.3 already included this exemption for cookies that were used “for the sole purpose of carrying out or facilitating the transmission of a communication over an electronic communications network”. The same wording was used in the revised directive, but the words “or facilitating” were removed, which could be interpreted as a further indication that the European Legislator intended to restrict the perimeter of the exemption afforded by Article 5.3 under CRITERION A. At least 3 elements that can be considered as strictly necessary for communications to take place over a network between two parties: 1) The ability to route the information over the network, notably by identifying the communication endpoints. 2) The ability to exchange data items in their intended order, notably by numbering data packets, 3) The ability to detect transmission errors or data loss. The terms “the transmission of a communication over an electronic communications network” in CRITERION A –and in particular the word “over”– are understood to refer to any type of data exchange that takes place with the use of an electronic communication network (as defined in Directive 2002/21/EC), potentially including “application level” data which fulfills at least one of the properties defined above, without limitation to technical data exchanges needed to establish the electronic communication network itself. As such, CRITERION A encompasses cookies that fulfil at least one of the properties defined above for Internet communications.
2.2 Criterion B Similarly, the wording of CRITERION B suggests that the European Legislator intended to ensure that the test for qualifying for such an exemption must remain high. Following a direct reading of the directive, a cookie matching CRITERION B has to pass simultaneously the two following tests: 1) The information society service has been explicitly requested by the user: the user (or subscriber) did a positive action to request a service with a clearly defined perimeter. 2) The cookie is strictly needed to enable the information society service: if cookies are disabled, the service will not work. Furthermore, recital 66 of Directive 2009/136/EC underlines that “Exceptions to the obligation to provide information and offer the right to refuse should be limited to those situations where the technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user.” In other words, there has to be a clear link between the strict necessity of a cookie and the delivery of the service explicitly requested by the user for the exemption to apply.
672
3
Even with such a reading of the directive, it remains to define what constitutes the scope of an “information society service explicitly requested by the subscriber or user”. An information society service can be composed of many components, some of which are not used by all users or are provided for convenience. For example, an online newspaper can be free to access for all, but may provide some additional functionalities for users that are “logged-in” such as the ability to leave comments on articles. In turn these additional functionalities may operate with their own cookies. In this particular context, the Working Party considers that an information society service should be viewed as the sum of several functionalities, and that the precise scope of such a service may thus vary according to the functionalities requested by the user (or subscriber). As a consequence, CRITERION B can be rewritten in terms of “functionalities” provided by an information society service. In these terms, a cookie matching CRITERION B would need to pass the following tests: 1) A cookie is necessary to provide a specific functionality to the user (or subscriber): if cookies are disabled, the functionality will not be available. 2) This functionality has been explicitly requested by the user (or subscriber), as part of an information society service.
2.3 Characteristics of a cookie Cookies are often categorized according to the following characteristics: 1) Whether they are “session cookies” or “persistent cookie”. 2) Whether they are “third party cookies” or not. A “session cookie” is a cookie that is automatically deleted when the user closes his browser, while a “persistent cookie” is a cookie that remains stored in the user’s terminal device until it reaches a defined expiration date (which can be minutes, days or several years in the future). The term “third party cookie” can be misleading:
In the context of European data protection, the Directive 95/46/EC defines a third party as “any natural or legal person, public authority, agency or any other body other than the data subject, the controller, the processor and the persons who, under the direct authority of the controller or the processor, are authorized to process the data.” A “third party cookie” would thus refer to a cookie set by a data controller that is distinct from the one that operates the website visited by the user (as defined by the current URL displayed in the address bar of the browser).
However, from the perspective of browsers, the notion of “third party” is solely defined by looking at the structure of the URL displayed in the address bar of the browser. In this case “third party cookies” are cookies that are set by websites that belong to a domain that is distinct from the domain of the website visited by the user as displayed in the browser address bar, regardless of any consideration whether that entity is a distinct data controller or not.
673
4
While these two approaches often overlap, they are not always equivalent. For the purpose of this opinion, we will follow the first approach and use the term “third party cookie” to describe cookies that are set by data controllers that do not operate the website currently visited by the user. Conversely, the term “first party cookie” will be used to refer to a cookie set by the data controller (or any of its processors) operating the website visited by the user, as defined by the URL that is usually displayed in the browser address bar. Certain characteristics will be taken into account to evaluate if a cookie is “strictly necessary” for a service, “explicitly requested by the user” or limited to a “sole purpose” as worded in CRITERION A or B. A cookie that is exempted from consent should have a lifespan that is in direct relation to the purpose it is used for, and must be set to expire once it is not needed, taking into account the reasonable expectations of the average user or subscriber. This suggests that cookies that match CRITERION A and B will likely be cookies that are set to expire when the browser session ends or even earlier. However, this is not always the case. For example, in the shopping basket scenario presented in the following section, a merchant could set the cookie either to persist past the end of the browser session or for a couple of hours in the future to take into account the fact that the user may accidentally close his browser and could have a reasonable expectation to recover the contents of his shopping basket when he returns to the merchant’s website in the following minutes. In other cases, the user may explicitly ask the service to remember some information from one session to another, which requires the use of persistent cookies to fulfil that purpose. Additionally, following the previous definitions, “third party” cookies are usually not “strictly necessary” to the user visiting a website since these cookies are usually related to a service that is distinct from the one that has been “explicitly requested” by the user. As a consequence, “first party” session cookies are far more likely to be exempted from consent than “third party” persistent3 cookies. But while these characteristics may serve as an initial indicator to prioritize compliance actions, they are not sufficient alone to establish if a cookie matches CRITERION A or B. One can imagine a cookie being used to authenticate users logging into a website. This cookie is used to ensure that the user may only access content to which they are authorized. A similar cookie may be used to identify and track users across a domain and deliver tailored content or advertising based on the profile held by the website operator. Both cookies may be similar in type (i.e. session or persistent); have a similar expiration date; or indeed be controlled by third parties. The risk to data protection comes from the purpose(s) of processing rather than the information contained within the cookie. Ultimately, it is thus the purpose and the specific implementation or processing being achieved that must be used to determine whether or not a cookie can be exempted from consent according to CRITERION A or B.
3
Some recent technologies often referred as “Ever-cookies” or “Zombie-cookies” allow cookies to remain permanently on the user’s terminal device despite reasonable efforts to remove them. It is very unlikely that such cookies would be exempted from consent under any scenario.
674
5
2.4 Multipurpose cookies While it is possible to use a cookie for several purposes, such a cookie may only be exempted from consent if all the distinct purposes for which the cookie is used are individually exempted from consent. For example, it is possible to create a cookie that has a unique name or value that can both be used for the purpose of remembering user preferences and for the purpose of tracking. While remembering the user’s preferences may be considered in some circumstances to fall under an exemption (as illustrated in section 3.6), tracking is very unlikely to meet CRITERION A or B. As such, the website would still need to seek user consent for the tracking purpose. In practice, this should encourage website owners to use a different cookie for each distinct purpose. As already highlighted by the Working Party in Opinion 16/2012, if a website uses several cookies or cookies that cover several purposes, this does not mean that it must present a separate “banner” or consent request for each cookie or purpose. A single point of information and consent, presented in a clear and comprehensive manner is sufficient in most cases.
3 Cookie use case scenarios This section applies the previously analyzed consent exemption criteria to common cookie use case scenarios.
3.1 “User-input” cookies The term “user input cookies” can be used as a generic term to describe session cookies that are used to keep track of the user’s input in a series of message exchanges with a service provider in a consistent manner. These would be expected to be first party cookies typically relying on a Session-ID (a random temporary unique number) and expire when the session ends at the latest. First party user input session cookies are typically used to keep track of the user’s input when filling online forms over several pages, or as a shopping cart, to keep track of the items the user has selected by clicking on a button (e.g. “add to my shopping cart”). These cookies are clearly needed to provide an information service explicitly requested by the user. Additionally, they are tied to a user’s action (such as clicking on a button or filling a form). As such these cookies are exempted under CRITERION B.
3.2 Authentication cookies Authentication cookies are used to identify the user once he has logged in (example: on an online banking website). These cookies are needed to allow users to authenticate themselves on successive visits to the website and gain access to authorized content, such as viewing their account balance, transactions, etc. Authentication cookies are usually session cookies. The use of persistent cookies is also possible but they must not be regarded as identical, as discussed below.
675
6
Field Cod
When a user logs in, he explicitly requests access to the content or functionality to which he is authorized. Without the use of an authentication token stored in a cookie the user would have to provide a username/password on each page request. Therefore this authentication functionality is an essential part of the information society service he is explicitly requesting. As such these cookies are exempted under CRITERION B. However it is important to note that the user has only requested access to the site and specific functionality to perform the task he requires. The act of authentication must not be taken as an opportunity to use the cookie for other secondary purposes such as behavioural monitoring or advertising without consent. Persistent login cookies which store an authentication token across browser sessions are not exempted under CRITERION B. This is an important distinction because the user may not be immediately aware of the fact that closing the browser will not clear their authentication settings. They may return to the website under the assumption that they are anonymous whilst in fact they are still logged in to the service. The commonly seen method of using a checkbox and a simple information note such as “remember me (uses cookies)” next to the submit form would be an appropriate means of gaining consent therefore negating the need to apply an exemption in this case.
3.3 User centric security cookies The exemption that applies to authentication cookies under CRITERION B (as previously described) can be extended to other cookies set for the specific task of increasing the security of the service that has been explicitly requested by the user. This is the case for example for cookies used to detect repeated failed login attempts on a website, or other similar mechanisms designed to protect the login system from abuses (though this may be a weak safeguard in practice). This exemption would not however cover the use of cookies that relate to the security of websites or third party services that have not been explicitly requested by the user. While login cookies are typically set to expire at the end of a session, user security cookies are expected to have a longer lifespan to fulfil their security purpose.
3.4 Multimedia player session cookies Multimedia player session cookies are used to store technical data needed to play back video or audio content, such as image quality, network link speed and buffering parameters. These multimedia session cookies are commonly known as “flash cookies”, so called because the most prevalent internet video technology in use today is Adobe Flash. As there is no longterm need for this information they should expire once the session ends. When the user visits a website containing related text and video contents, both of these contents are equally part of a service explicitly requested by the user. The video display functionality thus matches CRITERION B. As already highlighted in Section 3.2, to benefit from the exemption, website operators must avoid the inclusion of additional information into the “flash” or other cookies which are not strictly necessary for the playback of the media content.
676
Field Cod
7
3.5 Load balancing session cookies Load balancing is a technique that allows distributing the processing of web server requests over a pool of machines instead of just one. One of the techniques that are used to achieve load balancing is based on a “load balancer”: web requests from the users are directed to a load balancing gateway which forwards the request to one of the available internal servers in the pool. In some cases, this redirection needs to be persistent during a session: all requests originating from a specific user must always be forwarded to the same server in the pool to maintain the consistency of the processing. Among several techniques, a cookie may be used to identify the server in the pool in order for the load balancer to redirect the requests appropriately. These are session cookies. The information in the cookie has the sole purpose of identifying one of the communication endpoints (one of the servers in the pool) and is thus necessary to carry out the communication over the network. As such these cookies are exempted under CRITERION A.
3.6 UI customization cookies User interface customization cookies are used to store a user’s preference regarding a service across web pages and not linked to other persistent identifiers such as a username. They are only set if the user has explicitly requested the service to remember a certain piece of information, for example, by clicking on a button or ticking a box. They may be session cookies or have a lifespan counted in weeks or months, depending on their purpose. Typical examples of customization cookies are:
Language preference cookies that are used to remember the language selected by a user on a multilingual website (e.g. by clicking on a “flag”).
Result display preference cookies that are used to remember the user’s preference regarding online search queries (e.g. by selecting the number of results per page).
These customization functionalities are thus explicitly enabled by the user of an information society service (e.g. by clicking on button or ticking a box) although in the absence of additional information the intention of the user could not be interpreted as a preference to remember that choice for longer than a browser session (or no more than a few additional hours). As such only session (or short term) cookies storing such information are exempted under CRITERION B. The addition of additional information in a prominent location (e.g. “uses cookies” written next to the flag) would constitute sufficient information for valid consent to remember the user’s preference for a longer duration, negating the requirement to apply an exemption in this case.
3.7 Social plug-in content sharing cookies Many social networks propose “social plug-in modules” that website operators can integrate in their platform notably to allow social networks users to share contents they like with their “friends” (and propose other related functionalities such as publishing comments). These plug-ins store and access cookies in the user’s terminal equipment in order to allow the social network to identify their members when they interact with these plug-ins.
677
8
To address this use case, it is important to distinguish users who “logged-in” through their browser in a particular social network account, from “non-logged-in” users who are either simply not a member of that specific social network or who have “disconnected” from their social network account. Since by definition social plug-ins are destined to members of a particular social network, they are not of any use for non members, and therefore do not match CRITERION B for those users. This can be extended to actual members of a social network who have explicitly “logged-out” of the platform, and as such do not expect to be “connected” to the social network anymore. Consent from non-members and “logged-out” members is thus needed before third party cookies can be used by social plug-ins. On the other hand, many “logged in” users expect to be able to use and access social plug-ins on third party websites. In this particular case, the cookie is strictly necessary for a functionality explicitly requested by the user and CRITERION B applies. Such cookies are session cookies4: to serve their particular purpose, their lifespan should end when the user “logs-out” of his social network platform or if the browser is closed. Social networks that wish to use cookies for additional purposes (or a longer lifespan) beyond CRITERION B have ample opportunity to inform and gain consent from their members on the social network platform itself.
4 Non exempted cookies This section recalls or clarifies cookie usage scenarios do not fall in the exemption afforded under CRITERION A or B.
4.1 Social plug-in tracking cookies As described previously, many social networks propose “social plug-in modules” that website owners can integrate in their platform, to provide some services than can be considered as “explicitly requested” by their members. However these modules can also be used to track individuals, both members and non-members, with third party cookies for additional purposes such as behavioural advertising, analytics or market research, for example. With such purposes, these cookies cannot be deemed to be “strictly necessary” to provide a functionality explicitly requested by the user. Therefore these tracking cookies cannot be exempted under CRITERION B. Without consent, it seems unlikely that there is any legal basis for social networks to collect data through social plug-ins about non-members of their network. By default, social plug-ins should thus not set a third party cookie in pages displayed to non-members. On the other hand, as previously noted, social networks have ample opportunity to collect consent from their members directly on their platform if they wish to conduct such tracking activities, having provided their users with clear and comprehensive information about this activity.
4.2 Third party advertising Third party cookies used for behavioural advertising are not exempted from consent as already highlighted in detail by the Working Party in Opinion 2/2010 and Opinion 16/2011. This requirement for consent naturally extends to all related third party operational cookies 4
Persistent authentication cookies have been demonstrated to be not exempt in section 3.2
678
9
used in advertising including cookies used for the purpose of frequency capping, financial logging, ad affiliation, click fraud detection, research and market analysis, product improvement and debugging, as neither of these purposes can be considered to be related to a service or functionality of an information society service explicitly requested by the user, as required by CRITERION B. In this regard, the Working Party has been actively participating since December 22, 2011 in the work of the World Wide Web Consortium (W3C) to standardize the technology and the meaning of Do Not Track. In view of the fact that cookies often contain unique identifiers, that allow for the tracking of user behaviour over time and across websites and the possible combination of these identifiers with other identifying or identifiable data, the Working Party is concerned about the possible exclusion from Do Not Track of certain cookies that are said to be necessary for operational purposes. Such purposes are: Frequency Capping, Financial Logging, 3rd Party Auditing, Security, Contextual Content, Research and Market Analytics, Product Improvement and Debugging5. In order for the Do Not Track standard to bring compliance to companies serving cookies to European citizens, Do Not Track must effectively mean “Do Not Collect” without exceptions. Therefore where a user has expressed the preference to not be tracked (DNT=1) no identifier, for the purpose of tracking, must be set or otherwise processed. There are technical solutions available, and many more are currently being developed, to effectively apply privacy by design, both within the web browser and on the server side to achieve the operational purposes described above.
4.3 First party analytics Analytics are statistical audience measuring tools for websites, which often rely on cookies. These tools are notably used by website owners to estimate the number of unique visitors, to detect the most preeminent search engine keywords that lead to a webpage or to track down website navigation issues. Analytics tools available today use a number of different data collection and analysis models each of which present different data protection risks. A firstparty analytic system based on “first party” cookies clearly presents different risks compared to a third-party analytics system based on “third party” cookies. There are also tools which use “first party” cookies with the analysis performed by another party. This other party will be considered as a joint controller or as a processor depending on whether it uses the data for its own purposes or if it is prohibited to do so through technical or contractual arrangements. While they are often considered as a “strictly necessary” tool for website operators, they are not strictly necessary to provide a functionality explicitly requested by the user (or subscriber). In fact, the user can access all the functionalities provided by the website when such cookies are disabled. As a consequence, these cookies do not fall under the exemption defined in CRITERION A or B. However, the Working Party considers that first party analytics cookies are not likely to create a privacy risk when they are strictly limited to first party aggregated statistical purposes and when they are used by websites that already provide clear information about these cookies in their privacy policy as well as adequate privacy safeguards. Such safeguards are expected to include a user friendly mechanism to opt-out from any data collection and comprehensive anonymization mechanisms that are applied to other collected identifiable information such as IP addresses. 5
http://www.w3.org/TR/tracking-compliance/
679
10
In this regard, should article 5.3 of the Directive 2002/58/EC be re-visited in the future, the European legislator might appropriately add a third exemption criterion to consent for cookies that are strictly limited to first party anonymized and aggregated statistical purposes. First party analytics should be clearly distinguished from third party analytics, which use a common third party cookie to collect navigation information related to users across distinct websites, and which pose a substantially greater risk to privacy.
5 Summary and guidelines This analysis has shown that the following cookies can be exempted from informed consent under certain conditions if they are not used for additional purposes: 1) User input cookies (session-id), for the duration of a session or persistent cookies limited to a few hours in some cases. 2) Authentication cookies, used for authenticated services, for the duration of a session. 3) User centric security cookies, used to detect authentication abuses, for a limited persistent duration. 4) Multimedia content player session cookies, such as flash player cookies, for the duration of a session. 5) Load balancing session cookies, for the duration of session. 6) UI customization persistent cookies, for the duration of a session (or slightly more). 7) Third party social plug-in content sharing cookies, for logged in members of a social network. Having regard to social networks, the working party notes however that the use of third party social plug-in cookies for other purposes than to provide a functionality explicitly requested by their own members requires consent, notably if these purposes involve tracking users across websites. The working party recalls that third party advertising cookies cannot be exempted from consent, and further clarifies that consent would also be needed for operational purposes related to third party advertising such as frequency capping, financial logging, ad affiliation, click fraud detection, research and market analysis, product improvement and debugging. While some operational purposes might certainly distinguish one user from another, in principle these purposes do not justify the use of unique identifiers. This point is of particular relevance in the context of the current discussions regarding the implementation of the Do Not Track standard in Europe. This analysis also shows that first party analytics cookies are not exempt from consent but pose limited privacy risks, provided reasonable safeguards are in place, including adequate information, the ability to opt-out easily and comprehensive anonymisation mechanisms. Some primary guidelines can be drawn from the analysis and the cookie use scenarios presented in this opinion:
680
11
1) When applying CRITERION B, it is important to examine what is strictly necessary from the point of view of the user, not the service provider. 2) If a cookie is used for several purposes, it can only benefit from an exemption to informed consent if each distinct purpose individually benefits from such an exemption. 3) First party session cookies are far more likely to be exempted from consent than third party persistent cookies. However the purpose of the cookie should always be the basis for evaluating if the exemption can be successfully applied rather than a technical feature of the cookie. Ultimately, to decide if a cookie is exempt from the principle of informed consent it is important to verify carefully if it fulfils one of the two exemption criteria defined in Article 5.3 as modified by Directive 2009/136/EC. After a careful examination, if substantial doubts remain on whether or not an exemption criterion applies, website operators should closely examine if there is not in practice an opportunity to gain consent from users in a simple unobtrusive way, thus avoiding any legal uncertainty.
Done at Brussels, on 7th June 2012
For the Working Party The Chairman Jacob KOHNSTAMM
681
12