GDPR & Cloud Providers Keynote Presentation

(1)

GDPR & Cloud Providers

Keynote Presentation

9 March 2015

Cloudscape VII

Kuan Hon

Research Consultant, Cloud Legal Project & MCCRC

Centre for Commercial Law Studies

Queen Mary, University of London

(2)

(3)

Data Protection Directive – recap



“Controller” legally-obliged to comply with data

protection ( DP ) principles in processing

personal data ( PD )

+ rules for “special category” sensitive data eg health



May use “processor” – incl. cloud provider

must choose processor providing “sufficient

guarantees” re. security measures + written contract ( instructions, security ) + ensure compliance



Direct processor obligations – few Member

States ( MS )

(4)

GDPR progress

 Commission - draft General Data Protection Regulation

( GDPR ) 2012

 & crime / law enforcement Directive

 European Parliament – different version - Mar 2014

 Council - yet another version being debated - Dec 2014

 “nothing is agreed until everything is agreed” ( PGA )

 EU institutions must agree same text before GDPR can

become law – flowchart

 Moving target !! + 2 years after adoption

 Regulation not Directive – though discretion, ambiguity

@kuan0

(5)

20/2/1995

15/6/1995

2012 2013 2014 2015 2016 2017

Council 1st reading - amendments inevitable ! ? ? ? Parliament 1st

reading – 207 amendments 12/3/2014 Commission

proposal 25/1/2012

1990 1991 1992 1993 1994 1995

DPD adopted 25/10/1995 Parliament 2nd reading - amendments Council Common Position - amendments Commission amended proposal 15/10/1992 Parliament 1st reading – 95 amendments 11/3/1992 Commission

proposal 17/7/1990

Data Protection Directive

Draft General Data Protection Regulation

GDPR

adopted ? ? Comparative legislative timeline

(6)

6 6

Cloud providers – often “processors”

 May use sub-processors – layered services eg SaaS on

IaaS / PaaS, PaaS on IaaS

 Current laws – 1970s outsourcing ( 12Cs, 9Ds ):

 delivery, processors’ intelligible access, “active” processing as per controller’s “instructions”

 encryption: provider doesn’t know whether PD

 infrastructure - not active / instructions / knowledge o IaaS, PaaS, pure storage SaaS – controller self-service

o provider won’t know if PD without “looking”, even unencrypted

 direction – sub-processors & layered cloud

 commoditised, shared infrastructure – cf customised

 GDPR would perpetuate 1970s assumptions

(7)

PROCESSORS UNDER GDPR

(8)

Direct processor obligations



If processing PD in “context of activities” of

“establishment” in EU

like current “controller establishment” test

o DCs ?; “establishment”, “context” very broad ( Google Spain )

 Parl – incl non-EU processing



If processing activities “related to” offering goods

/ services to DS in EU or monitoring them

Parl – + processors; free



All -

even if processing exempt

- personal

( SNS / email ); crime / national security ?

@kuan0

(9)

Processor’s “main establishment”



For one stop shop purposes ie which MS’s “lead

regulator” if multiple MSs

Council next week ?



Place of central administration in EU

Council – if none, EU establishment where main

processing activities in EU occur ( DCs ? )

Parliament – EU establishment where main decisions

on purposes

o If no EU establishment ?

(10)

Liability: “involved”, unlawful processing



Processors (

sub-processors, DC providers ?

)

liable for entire amount of damage ( controller fault ? ) o unless written allocation ( Parl ); recourse claims ( Council )

“incompatible”: strict liability. Council: non-compliance

“may” ( cf “must” ) be exempted if prove it’s not

responsible for “the event” - eg DS / force majeure

role of seal etc ( later )



Processors’ princelier pockets ?

analogy: chaffeur limo service vs rental ( carmakers ? )

(11)

DPA powers over processors



Same as over controllers – extensive powers



Processor must cooperate - info, orders etc



Audit powers, access to premises ( on-site

inspections )

– though Google agreed to allow DPA Italy – US

premises (summary, order, approval )



Fines – up to 5% annual worldwide turnover or

€100m if greater ( Parl )

(12)

Requirements when using processors



Controller must -

choose processor providing sufficient guarantees to

implement appropriate tech/org measures “in such a

way that the processing will meet” GDPR

o compliance with GDPR > security / instructions

o sufficient guarantees - code / certification ( Parl, Council )

ensure compliance ( deleted by Council ), and

implement contract with certain terms ( next )



NB Art. 17 processor agreements

not continued:

no “grandfathering !

Redo all ( not just cloud ) !



What if no “controller” – personal use of cloud

service ?

(13)

Processor contract terms 1



Written contract (

>> current requirements

)

subject-matter, duration, nature & purpose, type of personal data and categories of data subjects,

rights of controller ( Council ) – prying processors

“instructions”

o but cloud…. self-service infrastructure use

employ only staff under confidentiality obligations

security measures ( later )

sub-processors ( soon )

DS requests – unclear, Council “assist” ( but cloud ? )

(14)

Processor contract terms 2

“assist controller” to ensure compliance

o re. security, breach notification, DPbD/D, DPIA, prior

authorisation / consultation – how far ? commoditised cloud…

data delivery at end, “not process otherwise”

o deletion unless EU law requires retention – Parl

info to controller to show compliance ( & allow onsite

inspection – Parl / audits – Council – cloud ? )



processor as police

!

self-service cloud ??

GDPR ( non-contractual ) obligation to “immediately

inform the controller if, in his opinion, an instruction

breaches this Regulation or Union or Member State data protection provisions” - Council

(15)

Sub-processors



“Enlist” iff prior controller consent ( vs direction ? )

Different Parl & Council formulations - unclear



Sub-processor contracts or “other legal act” under

EU law – must impose

same obligations

for

“sufficient guarantees” – Council

code / certification including standard Commission / DPA

standard clauses - “an element” to demonstrate “sufficient guarantees”

(16)

Security 1



Controllers may process PD for NIS reasons

extent “strictly necessary” – legit. interest

gap – controllers only



“Security of processing” – tech & org measures

to ensure security level appropriate to risks, with

regard to state of the art, costs

 + DPIA – Parl; + available tech, nature etc of processing, likelihood / severity of risk - Council

 C & I ( implicitly A )

o explicit with Parl: security policy + “resilience”, restoration; sensitive PD: measures to ensure “situational awareness” of risks, ability to take “near real time” action; regular testing

 Commission power to specify security requirements

o deleted by Parl & Council ( ENISA role ? )

@kuan0

(17)

Security 2

 certifications / codes of conduct “may be used as an element” to demonstrate compliance



Risk evaluation to assess appropriate security level

 variations between Parl and Council

 cloud - commoditised mixed use infrastructure… prying processors, customisation, HCD ? ( cost )



Processor directly sliable for security breach

 including personal use, no “controller”

o if user’s bad password ? – prove not responsible

o NB personal user could process own PD, other people’s…

(18)

Risk analysis, DPIA, prior consultation

 Parl – risk analysis to check if “specific risks” likely

 controller, “or, where applicable the processor”

o when applicable ? prying processors, again ? cf commoditised cloud

 including > 5k data subjects in 12 mths; sensitive data, location data, data on children or employees “in large scale filing

systems”; profiling; core activities require regular & systematic monitoring

 Controller’s DPIA / prior DPA consultation - profiling, etc

 “or processor on controller's behalf”

o when ? ( not for prior consultation - Council )

 processor “should assist” controller “where necessary and upon request” - comply with obligations “deriving from” DPIA / prior consultation ( Council recital ) - cf commoditised cloud ?

(19)

19 19

Data protection officer



Controller

and processor

must appoint if

processing “by” public sector body

processing by org. >= 250 employees ( processor? )

o Changed to > 5k DS in 12 mths – Parl

core activities of controller or processor – nature

requires regular & systematic monitoring of DS o + core activities – sensitive data, location data, data on

children or employees in large scale filing systems – Parl

unclear - must processor appoint if controller is public

sector etc ? ( prying processor )



“or”, MS decision whether to require DPO –

Council

(20)

( Parl. R. 75a) – “at least the following

qualifications…”

 extensive knowledge of the substance and application of data protection law, including technical and

organisational measures and procedures;

 mastery of technical requirements for privacy by design, privacy by default and data security;

 industry-specific knowledge in accordance with the size of the controller or processor and the sensitivity of the data to be processed; the ability to carry out

inspections, consultation, documentation, and log file analysis; and the ability to work with employee representation…

 The designation as a data protection officer does not

necessarily require fulltime occupation…

(21)

Other processor obligations



Transfers ( restriction on PD exports unless

adequate protection / safeguards ) - processors

no own decision; legitimate interests but not if frequent /

massive / (Parl) structural / repetitive; protection through

law only ( eg contract ), not technology; anti-FISA clause ( Parl ); processor BCRs ( Parl would exclude ) – see eg

A4Cloud paper



DP by design / default - tech / org measures, at

design & use stages, to ensure / show compliance

with DP principles

+ processors & public procurement tenders ( Parl )



Record-keeping requirements

@kuan0

(22)

Codes & certifications / seals

 Council - DPA-approved industry code / certification may

help demonstrate compliance ( “as an element” ) -

processor “sufficient guarantees” ( Parl too ), security, DPIA etc

 Detailed certification procedures, role of DPAs, accreditation of certification bodies, auditors - Council

 Approved codes; not certification but DPA-awarded

“European Data Protection Seal” – Parl

 EDP seal - shield against fines if non-intentional, non-negligent

 Iff legally enforceable [ by DS ] ? ( Council )

 Legal consequences ? – incl. liability – incentives,

certifiers / accreditors, erroneous certificates, comply with code but breach, etc…

(23)

Issues – cloud-inappropriate ?

 Encrypted data, infrastructure providers – still caught

 Google Spain – mixed data

 Liability risk ( no intermediary defence ? )

 Council would exclude E-Commerce Directive application

 Unclear responsibility allocation ( controller & processor )

 Often “controller or processor” – either, both, when ?

 Net cast very wide; obligations too in some cases

 Processing “related to” offering goods etc, EU data centres ?

 Customisation required ? eg security

 Access to premises – controllers, DPAs

 ( Intelligible access, “instructions” vs use / disclosure, vs

infrastructure cloud, commoditised cloud )

(24)

Practical implications

 Cloud providers & other ( sub ) processors - contract terms

 liability allocation, indemnities etc ( & seek fault-based ? )

 Could non-EEA providers

 raise all prices - or refuse if EEA, PD etc ? ( & if customer lies ?? ); close EEA ops, free consumer services; stop using EEA DCs ?

 impact on innovation / services needs considered policy decision

 Or, will laws just be ignored, if too wide ?

 Enforceability ( outside EEA ) ? DPA resources ? But huge fines…

 Big players may be the winners

 required contract terms ( incl sub-processors ); security, etc

 Codes & certifications – much increased role

 Clarification – which processor obligations apply when,

scope, liability; certifications / codes

(25)

(26)

26 26 82 27 139 72 24 91 34 33

0 50 100 150 GDPR (2012)

DPD (1995) DPD (1990)

No. of articles No. of recitals No. of pages

Note: no. of pages of legislative text are from English PDF versions – excluding explanatory text

Rough scale of data protection legislation

(27)

27 27

363

3999

95 207 0 500 1000 1500 2000 2500 3000 3500 4000 4500 DPD GDPR

Number of amendments

European Parliament: how many amendments ?

Proposed by Committees Approved by Parliament (1st reading)

(28)

28 28

12

27 28

15 0 5 10 15 20 25 30 DPD GDPR

Number of EU Member States

How many EU Member States involved ?

Initial proposal

Parliament 1st reading Council 1st reading Parliament 2nd reading

1 Jan 1995: Austria, Finland and Sweden joined 1 July 2013: Croatia joined

(29)

29 29 87 60 509 584 497 0 100 200 300 400 500 600 700 DPD GDPR

Number of footnotes

Council of the EU: how many footnotes ?

9951/94 (12/10/1994 ) 11099/94 (30/11/1994) 11013/13 (21/6/2013) 11028/14 (30/6/2014) 15395/14 (19/12/2014)

From consolidated draft versions considered in Council. The number of footnotes is used as a

rough measure of the extent of Member State

issues, because most ( though not all ) footnotes contained reservations or similar statements by Member States or the Commission

(30)

30 30 Parliament – Committee amendments proposed DPD: 363 GDPR: 3999 Parliament – amendments approved in 1st

reading

DPD: 95 GDPR: 207

Timing

DPD: > 5 yrs. GDPR: 3 yrs +…

Council – no. of footnotes in consolidated text

DPD: 87 (2 yrs. on) 60 (2+ yrs. on)

GDPR:

509 (1.5 yrs. on) 584 (2.5 yrs. on) 497 (3 yrs. on)

No. of Member States

DPD: 12-15 GDPR: 27-28 +…

Vital statistics

DPD (1990): 33, 24, 27 DPD (1995):

34, 72, N/A GDPR: 91, 139, 82

Order: Arts, Rec, pgs

DPD vs GDPR – summary

(31)