Roadmap to the GDPR - Things to Do first

Roadmap to the GDPR: What Companies Should Do FirstJune 9, 2016

Follow us:@AlstonPrivacywww.AlstonPrivacy.com 2

Speakers

Peter SwireSenior Counsel, Atlanta

Alston & Bird

Jan DhontPartner, Brussels

Alston & Bird

Jim HarveyPartner, Atlanta

Alston & Bird


Overview

Information Gathering and Data Processing Inventory

Individual Rights

Information Security and Breach Reporting

Vendor Management

Privacy By Design, (D)PIAs and DPOs


Introduction/Agenda

Each topic has been chosen because it:

Has a long rollout timeline,

May requires a fundamental paradigm shift throughout an organization, or

Presents immediate enforcement danger.


What Companies Should Do First




Develop Personal Data Map / Processing Inventory

Leverage existing information where possible

Assemble relevant:

Policies and Procedures

Regulatory Filings

Data Transfer Agreements

Customer Contracts (templates and relevant signed versions)

(Sub)Processor Information and Agreements

Conduct Gap Assessment


Data Mapping/Data Processing Inventory

ICO’s guidance concerning “Preparing for the GDPR”:

“You should look at the various types of data processing you carry out, identify your legal basis for carrying it out and document it. […] The legal bases in the GDPR are broadly the same as those in the DPA so it should be possible to look at the various types of data processing you carry out and to identify your legal basis for doing so. Again, you should document this in order to help you comply with the GDPR’s ‘accountability’ requirements.”


Accountability Drives Need for Inventory

Process/System Inventory

- What data are we collecting?

- What is the purpose of collection?

- How are we processing the data?

- What is the legal basis for each processing operation?

- Where is the data stored?

- How long are we retaining the data?

- Who has access to the data?

- Where is the data transferred?

Feeds record productionController must maintain records of all processing including breaches – including

processing or breaches of service providers/vendors (Art. 30)

Provides overview of Policies and Procedures- Controller must implement appropriate & effective policies/processes (Art. 24)

- Controller must know legal bases for processing to comply with objection rules (Art. 15-22)- Notices must now disclose (a) legal bases for processing; (b) legitimate interests pursued; (c)

retention periods; and (d) transfer recipients (Art. 13-14)- Controllers need overview to decide where consent needed (art. 7)

Provides overview of effective governance and action areas- Capability to demonstrate compliance with core data privacy principles (Art. 5 (2))

- Privacy By Design/PIAs/Effective Vendor Management


Further Considerations

Process-Based Considerations

Leverage existing information (Partial overviews/DPA notifications)

May be time and resource intensive - consider focusing on core information systems first

Also to be considered for data processors

Involve all stakeholders – IT, system owners, HR, etc.

Leverage mapping for US and global compliance efforts

Already required for GLBA, and common practice for other regulated sectors

Accountability a growing theme globally for compliance

When doing the mapping, can spot other areas of risk in your organization; data mapping updates your knowledge and helps detect lurking problems



Individual Rights Implementation


Individual Rights: What’s New?

Directive GDPR

Right of Access - Art. 12(a) Right of Access - Art. 15

Right to Rectification - Art. 12(b) Right to Rectification - Art. 16

Limited Right to Erasure - Art. 12(b) (Expanded) Right to Erasure - Art. 17

New! Right to Restriction of Processing - Art. 18

New! Right to Data Portability - Art. 20

Right to Object - Art. 14 (Expanded) Right to Object - Art. 21

Automated Individual Decisions - Art. 15 Automated Individual Decisions - Art. 22

Expanded and new rights are not just a matter of updating policy, but also may require system changes

Consider multi-disciplinary approach. Involve Infosec, engineering, etc.


Expanded Right to Object

General Rules: • Any processing based on legitimate

interests can be objected to• Individuals no longer need “compelling”

grounds to object – they can simply demand a stop to processing

• Companies can only continue processing if they document “compelling” legitimate interests that override privacy concerns

Marketing: • Marketing-related processing must stop

as soon as consumer objects to it• Controller must stop both the marketing

AND the profiling/analytics behind it

Link to Erasure: • A successful objection requires you to

delete the user’s data!

Mapping/Scoping

Policies, Procedures, and Records

Technology Builds

Companies need to map out: What processing is subject to objection What systems data is located in

At a minimum, companies need to: Map out what processing is being conducted for what purpose Ensure policies reflect interests that will override user objections Draft procedures for receiving, evaluating, and responding to user

objections Build back-end fulfillment procedures Institute recordkeeping to record objections as well as

grant/denial Draft template denial-of-objection for customer

Most companies have analytics running behind almost every process

Need to ensure that upon objection, marketing analytics can be shut off without affecting other systems

Formal Rules Practical Implications


Sample Bucket-Based Policy

• Customer objection never overrides company interestBucket 1

Fraud/Crime Prevention

•Customer objection almost never overrides company interest

•Compliance with (a) non-EU law and (b) company policy can exceptionally be objected to

Bucket 2

Compliance

• Customer objection rarely overrides company interest in customer service, HR practices, etc.

Bucket 3

Day-to-day Business

• Customer objection usually wins unless improvement is (documented as) essential

• Company must (a) remove customer’s data from test set, and (b) delete customer’s data

Bucket 4

Process Improvement

•Customer objection almost always wins

•Company must (a) stop the analytics, and (b) delete the customer’s data from analytics data set

Bucket 5

Business Analytics

•Customer objection always wins

•Company must ensure that both (a) marketing, and (b) analytics behind it stop upon objection

Bucket 6

Marketing


Right to Erasure

DirectiveErasure of incomplete or inaccurate data

GDPRErase personal data whenever: data are no longer necessary for the

purposes individual withdraws consent to

processing individual objects to processing data have been unlawfully processed Other EU laws requires deletion data concern a child and were collected

through internet services

Practical

Third-party notification: If controller obligatedto delete data it previously published, mustalso inform any other controllers that are“processing the personal data” that individualhas requested deletion and de-listing

Erasure not required for (i) archived data, (ii)data needed for compliance, (iii) data neededfor litigation

Keep suppression file


Profiling and Automated Decision-Making

Regime

Individuals can object to any profiling (analytics) conducted on grounds other than consent or compliance

If profiling/analytics paired with automated decision creating legal or other significant effects, not permitted unless: Consent Authorized by EU/Member State

law Necessary for entering into or

performance of a contract

Practical

Analytics for legal compliance arguably donot require consent or opt-out.

Analytics for marketing are permissible,but must offer right to object as default.

Analytics that have legal or othersignificant effects require consent or legalbasis (data-intensive analytics, refusal ofonline credit application, e-recruiting).

Regime has potential operational impact.Consent and opt-out strategy must besupported by system infrastructure.



Objection and automated decision-making rights carry heightened regulatory risk

because individuals likely to make DPA complaints

With the expanded list of rights, need to examine your systems and your vendors

for areas of possible non-compliance

Right to object (and limits on automated processing) highlight a potentially growing

difference between big data/analytics in the US and what the GDPR contemplates

One option for compliance: rather than re-engineering a particular system or

process for the opt-out, apply the analytics in the US but exclude the system or

process in the EU

Risk of EU becoming a “data island”



Information Security and Breach Reporting


Data Security: What’s New?

DirectiveAppropriate technical and organizationalmeasures

GDPR Level of information security appropriate to the risk –

no specific technical standards

Pseudonymization and encryption to be consideredin light of “risk”

Processes for “regularly testing, assessing andevaluating the effectiveness” of security measures

Processors also directly liable

Practical

Existing InfoSec policies and procedures will need to be gap-assessed

Industry standards or certified standards (e.g. ISO) may help lower compliance risk

Big shift in processor liability

GDPR’s security obligations independent of Telecom & NIS Directives


Data Breach Notification

Notification to Individuals Controllers must notify individuals of any breach likely to result in a “high risk”

to their rights and freedoms Report must be made “without undue delay” No notification necessary if

• Only unintelligible data affected (e.g. hashed encrypted or pseudonymized data)

• Subsequent remedial measures eliminate “high risk”• Requires disproportionate effort – in that case, media notification

required

Notification to DPAs Controllers must notify DPA of any breach likely to result in “risk” to individual

rights and freedoms Report due within 72 hours

• If report not feasible within 72 hours, must detail reasons for delay to DPA

Practical

Institute comprehensive breach reporting infrastructure

Systems, tools, processes for incident detection

Regular audits/testing/training

Make sure vendor contracts include cooperation-for-incidents clauses



Build security into start of projects – PIAs, data minimization, encryption

EU catching up with US practice in many respects, so US-based companies benefit from existing breach response infrastructure

Stricter than US in certain respects: (a) “risk” as a trigger; (b) notice in 72 hours; (c) potentially much broader data elements might require notice

Immediate enforcement danger as soon as GDPR enters into force



Vendor Management


Vendor Management: What’s New?

Directive GDPR

ControllerObligations

Controller obligated to: • Conduct due diligence on processor’s security

infrastructure• Engage processor via written agreement

Controller obligated to: • Conduct due diligence on processor’s “guarantees” for full GDPR

compliance• Keep record of processors used • Keep records of instructions given • Engage processor via written contract

ProcessorObligations

Processor obligated to: • Only process on instructions of controller• Implement adequate security

Processor obligated to: • Implement TOMs ensuring full GDPR compliance • Only process on instructions of controller• Place employees under NDAs/confidentiality• Keep records of all processing activities • Implement adequate data security • Obtain prior consent for subcontracting • Assist controller with breach reporting• Assist controller with customer-rights requests• Employ Privacy by Design/Default • Assist controller in DPIAs and DPA review for risky processing

Liability Rules No controller-processor liability rule Controller jointly & severally liable with processor


Vendor Management: Paradigm Shift

Under the Directive, vendor rules were a subset of information security section

GDPR introduces a major shift to requiring a comprehensive vendor management program

Vendor Management

Vendor SelectionContract

ManagementVendor Auditing

1 2 3


Vendor Selection & Auditing: Practical Implications

Policies and procedures for vendor vetting (e.g. a supplier risk assessment process) and auditing will be needed

Existing vendors must be re-vetted

Vendors should have sufficient assets/insurance to handle GDPR liability

Review RFP/bidding processes

May need to vet a vendor’s usual sub-processors as well

Diligence obligation extends to intra-group outsourcing as well – make sure processing affiliates/data centers are similarly considered

If you are a data processor: consider creating strategy and process to address volume and substance of customer demands under the GDPR


New Contract Terms

New Mandatory Processor Contract Terms Likely Additional Terms for Consideration

• Only process data on instructions from controller • Obligation to immediately report breaches or security incidents to controller

• Inform controller of any legally mandated transfers to another country

• Appropriate indemnities

• Place employees with access to data under NDA/confidentiality clause

• Clause regulating engagement of subprocessors (e.g. general consent with conditions)

• Implement adequate security • Obligation to undergo GDPR training

• Assist controller in facilitating exercise of customer rights • Appropriate changes to limitations of liability & exclusions of particular damages

• Assist the controller in reporting data breaches

• Assist the controller in performing DPIAs and consulting DPAs for risky processing

• Respond to controller’s information requests and/or submit to controller’s audits



Vendor management has been a big point of emphasis in US financial services and other critical infrastructure

E.g., detailed guidance from the Fed/OCC; potentially leverage those existing programs and contract language

Need to coordinate security and privacy in vendor management, because many GDPR requirements can be seen as cybersecurity management rather than privacy



Privacy By Design, (D)PIAs and DPOs


The GDPR’s New Operational Paradigm

The GDPR introduces a new paradigm: Privacy as an integral part of day-to-day operations

Key New Operational Requirements

Privacy by DesignData Protection

Impact AssessmentsData Protection Officers (DPOs)


Privacy By Design & Default; Impact Assessments

Requirements Privacy by Design: consider data protection from

start of project, assess privacy impact/risk, andcontemplate necessary requirements.

Privacy by Default: consider data minimization asdefault. Process and store data only if and as longas needed.

Data Protection Impact Assessments are required if(i) “high risk” to rights and freedoms, (ii)profiling/automated decision-making that legally orsignificantly affects individuals, or (iii) “large scale”sensitive data processing.

DPO must weigh in, and DPA consulted in casethere is an irreducible “high risk” to individuals.

Practical

Processes & awareness to ensure that product designteam consider privacy

Consider two-tier PIA process to achieve PbD: PIA forall new systems or projects; and specific DPIAs whereGDPR requirements are triggered

Will require policy and protocol drafting. Will need toalso consider current systems and services (mapexisting data uses, re-permission, and document)

Judgment calls required at certain points – scope ofDPIA requirement is potentially very broad


Data Protection Officers (DPOs)

DPOs are now mandatory whenever a company’s “core activities” involve: Large-scale monitoring of individuals

Large-scale processing of sensitive data

Member states may pass further laws requiring DPOs in further situations (expected in Germany)

Severe DPO market scarcity expected!DPO’s Tasks:

Advise on privacy issues on request Conduct employee training Monitor GDPR compliance Serve as point of contact with DPA Participate in DPIAs and monitor implementation Consult DPAs on any appropriate matter

Key Aspects of DPO Position: Must have privacy expertise Must receive appropriate resources Must report directly to highest level of

management DPO’s independence must be respected DPO (if internal) has protected employment


PbD: Further Considerations

Like data mapping, is a good practice to detect and address privacy risk

Existing legislation or practice in Australia, Canada, and elsewhere, so can build from that if you do business there

FTC strongly supports PbD as best practice

Enhances need to build good relationships with engineers and privacy team if the multi-disciplinary approach is not already in place


About Alston & Bird’s Privacy and Data Security Practice:

Follow us: @AlstonPrivacy

www.AlstonPrivacy.com

Cybersecurity Preparedness & Response Team

Alston & Bird’s Cybersecurity Preparedness & Response Team specializes in assisting clients in

both preventing and responding to security incidents and data breaches, including all

varieties of network intrusion and data loss events.

www.alstonsecurity.com

Privacy & Data Security Team

Our team helps clients at every step of the information life cycle, from developing and

implementing corporate policies and procedures to representation on transactional

matters, public policy and legislative issues, and litigation.

www.alston.com/privacy

Questions


New York Webcast Participation

If you are requesting CLE credit in New York, please enter the following code on the Attorney Affirmation sheet. Refer to your webcast confirmation for a link to the sheet

[code]

Documents

Roadmap to the GDPR - Things to Do first