training privacy by design

75
What does Privacy by Design look like? Privacy by Design?

Upload: tommy-vandepitte

Post on 22-Jan-2018

38 views

Category:

Education


0 download

TRANSCRIPT

What does Privacy by Design look like?

Privacy by Design?

- Internal -

A waste of time ?

- Internal -

Investment in the future

- Internal -

It is a tale of old

- Internal -

Plan

- Internal -

then build

- Internal -

a sustainable house

REMEMBER OUR MISSION STATEMENT

Insert mission statement

- Internal -

Sustainability includes privacy-by-design

- Internal -

From the start

- Internal -

Multiple iterations

- Internal -

International

1. Proactive not Reactive: Preventative, not Remedial;

2. Privacy as the Default setting;

3. Privacy Embedded into Design;

4. Full Functionality: Positive-Sum, not Zero-Sum;

5. End-to-End Security: Full Lifecycle Protection;

6. Visibility and Transparency: Keep it Open;

7. Respect for User Privacy: Keep it User-Centric

- Internal -

GDPR angle (art. 25 GDPR)

• Principles (art. 5 GDPR)

o fair

o lawful (also art. 6, 9, 10, 44-29 GDPR + other laws)

o transparency (also art. 13-14 GDPR)

o purpose limitation

o data minimisation

o accuracy / data quality

o storage limitation / retention policy

o confidentiality + integrity / avoid data breaches (also art. 32-34 GDPR)

• Rights of the data subjects (art. 12 -23 GDPR)

• Privacy by default (art. 25 GDPR)

- Internal -

Special attention for

Special categories of data (art. 9 + 10 GDPR)

Special category of data subjects: children (art. 8 GDPR)

Third parties (art. 26 + 28 GDPR)

Third countries (art. 44 e.s. GDPR)

- Internal -

Honor simplicity

- Internal -

Avoid clear design flaws

Pu

rpo

se

- Internal -

Avoid clear design flaws

Se

cu

rity

- Internal -

Possible supporting framework: RMIAS

- Internal -

Look at the entire data lifecycle

Less people can

reach it gatekeepers

Data retention forces at work

Can we legitimately collect / create

the data (for that purpose)? (legal

constraints, contractual constraints,…)

Is the storage secure? Which

functions / roles need access?

Everybody else should be

kept out.

Is the integrity guarded?

Is the availability up to standard?

Can we legitimately use the data for

that purpose?

Is everybody with access bound by

confidentiality?

Can we legitimately share the data

(for that purpose)?

Do we want to share that data?

- Internal -

Take different perspectives

- Internal -

Have a “design jam” with the (internal) stakeholders

- Internal -

Don’t trap the customer…

- Internal -

Don’t screw the customer…

- Internal -

Be customer-centric

- Internal -

Eat your own dog food

- Internal -

Be transparent

- Internal -

Special attention for special categories of data

- Internal -

Special attention for cross-border (outside EU)

- Internal -

Know what you protect

• Aggregation

• Anonymisation

- Internal -

Work purpose-bound

- Internal -

Minimize the data

necessary ?

relevant ?

- Internal -

Aim for high data quality

- Internal -

Balancetest

Legal requirement

Impliedconsent

Explicitconsent

Have a clear basis for legitimacy

- Internal -

Consent?

- Internal -

The value of consent?

- Internal -

Make consent really informed (small bites)

- Internal -

Privacy statements

- Internal -

Guide the user

- Internal -

Guide the user

- Internal -

Technical and Organisational Measures

- Internal -

Environment

Physical

Human

Device

Application

Repository

Carrier

Create defense in depth

Risk Assessment

Risk Decision

Controls

Incident

Management

Changes• In the regulatory environment

• In processes

• In people (JLT)

• In technology

Netw

ork

Data

3rd Parties

• 1st line

• 2nd line

• 3rd line

• Impact

• Probability

• Avoid

• Mitigate

• Share

• Accept

Changes

- Internal -

Use layered security measures

- Internal -

Implement a technical solution if possible

- Internal -

Don’t forget human computer interface

- Internal -

Assume breach

- Internal -

Think like an “attacker”

…but also

- Internal -

Segregate data (per data set)

- Internal -

Validate ID and Authenticate

- Internal -

Single sign-on

- Internal -

Encrypt

- Internal -

Encrypt in transit

- Internal -

Separate

- Internal -

Limit number of recipients

- Internal -

Test

- Internal -

Monitor for anomalies

- Internal -

Know how to detect and respond to data leaks

- Internal -

Data breach notification & communication

- Internal -

Get partners to commit on paper

- Internal -

External = three steps

Select

• RFI, RFP, BaFO

• Questionnaires and Questions

Contract

• Negotiations: need-to-have (law) v nice-to-have (practice)

• Risk Acceptance (as the case may be)

• Contract Management: execution retention

Follow-up

• Informal: “wine and dine”, relationship management, …

• Formal: questionnaires, audit, …

• Special: rights of data subjects (e.g. rectification, block)

- Internal -

Build in controls

- Internal -

Limit retention - consider the purpose(s)

- Internal -

Archive asap

- Internal -

Destroy asap

- Internal -

Take rights of data subjects into account

- Internal -

It starts with access…

- Internal -

It starts with access…

- Internal -

Right to be forgotten

- Internal -

Rights of data subjects - response

- Internal -

Have a clear view on the individual “ready”

- Internal -

Build to meet data subject requests

- Internal -

Give the user choices where possible

- Internal -

ARCHITECTURE LIFECYCLE

• Databases

• Links

• Silos v transversalInfo

rmation a

sset

ow

ners

hip

Data governance

- Internal -

Embed in the architecture

Insert architecture

- Internal -

Check or insert in the data register

- Internal -

High risk data processing operations (> PIA)

That would be GREAT

Soooo… if you could do all that…