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 -
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…