A first draft of a training on privacy by design both as an international concept (stemming from Canada) and as a GDPR related concept (article 25).

1. What does Privacy by Design look like?
Privacy by Design?

2. - Internal -
A waste of time ?

3. - Internal -
Investment in the future

4. - Internal -
It is a tale of old

5. - Internal -
Plan

6. - Internal -
then build

7. - Internal -
a sustainable house
REMEMBER OUR MISSION STATEMENT
Insert mission statement 

8. - Internal -
Sustainability includes privacy-by-design

9. - Internal -
From the start

10. - Internal -
Multiple iterations

11. - 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

12. - 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)

13. - 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)

14. - Internal -
Honor simplicity

15. - Internal -
Avoid clear design flaws
Purpose

16. - Internal -
Avoid clear design flaws
Security

17. - Internal -
Possible supporting framework: RMIAS

18. - 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?

19. - Internal -
Take different perspectives

20. - Internal -
Have a “design jam” with the (internal) stakeholders

21. - Internal -
Don’t trap the customer…

22. - Internal -
Don’t screw the customer…

23. - Internal -
Be customer-centric

24. - Internal -
Eat your own dog food

25. - Internal -
Be transparent

26. - Internal -
Special attention for special categories of data

27. - Internal -
Special attention for cross-border (outside EU)

28. - Internal -
Know what you protect
• Aggregation
• Anonymisation

29. - Internal -
Work purpose-bound

30. - Internal -
Minimize the data
necessary ?
relevant ?

31. - Internal -
Aim for high data quality

32. - Internal -
Balance
test
Legal
requirement
Implied
consent
Explicit
consent
Have a clear basis for legitimacy

33. - Internal -
Consent?

34. - Internal -
The value of consent?

35. - Internal -
Make consent really informed (small bites)

36. - Internal -
Privacy statements

37. - Internal -
Guide the user

38. - Internal -
Guide the user

39. - Internal -
Technical and Organisational Measures

40. - 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
Network
Data
3rd Parties
• 1st line
• 2nd line
• 3rd line
• Impact
• Probability
• Avoid
• Mitigate
• Share
• Accept
Changes

41. - Internal -
Use layered security measures

42. - Internal -
Implement a technical solution if possible

43. - Internal -
Don’t forget human computer interface

44. - Internal -
Assume breach

45. - Internal -
Think like an “attacker”
…but also

46. - Internal -
Segregate data (per data set)

47. - Internal -
Validate ID and Authenticate

48. - Internal -
Single sign-on

49. - Internal -
Encrypt

50. - Internal -
Encrypt in transit

51. - Internal -
Separate

52. - Internal -
Limit number of recipients

53. - Internal -
Test

54. - Internal -
Monitor for anomalies

55. - Internal -
Know how to detect and respond to data leaks

56. - Internal -
Data breach notification & communication

57. - Internal -
Get partners to commit on paper

58. - 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)

59. - Internal -
Build in controls

60. - Internal -
Limit retention - consider the purpose(s)

61. - Internal -
Archive asap

62. - Internal -
Destroy asap

63. - Internal -
Take rights of data subjects into account

64. - Internal -
It starts with access…

65. - Internal -
It starts with access…

66. - Internal -
Right to be forgotten

67. - Internal -
Rights of data subjects - response

68. - Internal -
Have a clear view on the individual “ready”

69. - Internal -
Build to meet data subject requests

70. - Internal -
Give the user choices where possible

71. - Internal -
ARCHITECTURE LIFECYCLE
• Databases
• Links
• Silos v transversal
Informationassetownership
Data governance

72. - Internal -
Embed in the architecture
Insert architecture 

73. - Internal -
Check or insert in the data register

74. - Internal -
High risk data processing operations (> PIA)

75. That would be GREAT
Soooo… if you could do all that…