Training privacy by design
- 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
- 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
- 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
- 50. - Internal - Encrypt in transit
- 52. - Internal - Limit number of recipients
- 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…
Editor's Notes
- #30: Determined purpose Explicited purpose Legitimate purpose Only collect data that is adequate, relevant and not excessive (necessary) for the determined purpose. Different purpose determines different data set. Consequence: meet the requirements per data set.
- #33: the data subject has unambiguously given his consent; or processing is necessary in order to take steps at the request of the data subject prior to entering into a contract; or processing is necessary for the performance of a contract to which the data subject is party; or E.g. when a data subject requests a credit, it is legitimate to request, receive and process some personal data on that data subject, to determine whether or not it is opportune to grant a credit or not. processing is necessary for compliance with a legal obligation to which the controller is subject; or Note: generally only national legislation is considered as a source of legitimacy under this provision. E.g. the collection of personal data as imposed by AML regulation (Know-Your-Customer), collection of personal data as imposed by MiFID regulation (Know-Your-Customer: appropriateness / suitability), transferring data to (tax or supervisory) authorities which act under legal investigation powers, … processing is necessary in order to protect the vital interests of the data subject; or processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller or in a third party to whom the data are disclosed; or processing is necessary for the purposes of the legitimate interests pursued by the controller or by the third party or parties to whom the data are disclosed, except where such interests are overridden by the interests for fundamental rights and freedoms of the data subject, and in particular their right to privacy with respect to the processing of personal data. E.g. processing medical data of a patient in coma to ensure that the necessary treatment is provided.