Data Subject

The individual whose personal data is being stored or processed.

Data Controller

The entity (company, school, government, etc.) that determines why and how personal data is processed ("the purpose and the means of processing").

Data Processor

An entity that processes personal data on behalf of a data controller, for example a SaaS provider. Processors do have obligations under data protection law, but many obligations only apply to controllers, so understanding which of the two you are is important. You may actually be both. For example, AWS is a data controller for the data it holds about its customers (accounts, usage, billing) but a processor in the context of what its customers do with the AWS cloud infrastructure they set up.

📚 Reading Assignment: OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data

Collection Limitation Principle
7. There should be limits to the collection of personal data and any such data should be obtained by lawful and fair means and, where appropriate, with the knowledge or consent of the data subject.

Data Quality Principle
8. Personal data should be relevant to the purposes for which they are to be used, and, to the extent necessary for those purposes, should be accurate, complete and kept up to date.

Purpose Specification Principle
9. The purposes for which personal data are collected should be specified not later than at the time of data collection and the subsequent use limited to the fulfilment of those purposes or such others as are not incompatible with those purposes and as are specified on each occasion of change of purpose.

Use Limitation Principle
10. Personal data should not be disclosed, made available or otherwise used for purposes other than those specified in accordance with Paragraph 9 except:

• a) with the consent of the data subject; or
• b) by the authority of law.

Security Safeguards Principle
11. Personal data should be protected by reasonable security safeguards against such risks as loss or unauthorised access, destruction, use, modification or disclosure of data.

Openness Principle
12. There should be a general policy of openness about developments, practices and policies with respect to personal data. Means should be readily available of establishing the existence and nature of personal data, and the main purposes of their use, as well as the identity and usual residence of the data controller.

Individual Participation Principle
13. Individuals should have the right:

• a) to obtain from a data controller, or otherwise, confirmation of whether or not the data controller has data relating to them;
• b) to have communicated to them, data relating to them
• i. within a reasonable time;
• ii. at a charge, if any, that is not excessive;
• iii. in a reasonable manner; and
• iv. in a form that is readily intelligible to them;
• c) to be given reasons if a request made under subparagraphs (a) and (b) is denied, and to be able to challenge such denial; and
• d) to challenge data relating to them and, if the challenge is successful to have the data erased, rectified, completed or amended.

Accountability Principle
14. A data controller should be accountable for complying with measures which give effect to the principles stated above.

Proactive not reactive; preventive not remedial

Think about privacy before your first data breach - you should have prevented that from ever happening in the first place! Build a strong privacy culture in your organization and consider privacy risks and potential mitigations throughout the development lifecycle, from the very earliest design stages onward.

Privacy as the default setting

You might have heard of the concept of 'paved roads' in security: make the secure thing the easy, default option rather than something that requires effort, both for your developers and your customers. We should aim for exactly the same in privacy. For example, your user profiles should be private by default, until the user opts in to making some information public. This principle encompasses the FIPPs principles of Purpose Specification, Collection Limitation, Data Minimization, and Use Limitation. This makes sense: if you're collecting excessive amounts of personal data, for example, then your 'default' state is clearly not privacy-preserving.

Privacy embedded into design

Make privacy an integral part of your design process, not an afterthought. This principle is closely linked to the principle of accountability: you need to establish organizational and technical processes to make sure privacy really is baked into your development and product lifecycles. Who is responsible for what when it comes to privacy? Is that clear to everyone, from senior management to your most junior engineers? Is it also clear to your sales and marketing teams?

Full functionality – positive-sum, not zero-sum

Privacy doesn't have to come at a price: don't think of it as a zero-sum game. Only rarely is there a tradeoff to be made between security and privacy; usually, you should be striving to implement strong protection for both. Similarly, your users shouldn't have to trade product features for their privacy (don't penalize them for enabling privacy settings!), and privacy doesn't necessarily need to be a cost center for your company. There is huge business value in building customer trust with strong privacy and security guarantees. All your customers are nervous about data breaches: if you can convince them you're the most trustworthy vendor in the market, they'll choose you over their competitors. Privacy-enhancing technologies, which we'll explore later in the course, also create potential for new business opportunities. They can be used to responsibly share and repurpose data, for example to contribute anonymized data for scientific research.

End-to-end security – full lifecycle protection

An insecure system will never be able to protect its users' privacy. Security is the foundation that privacy is built upon: it's crucial that you get it right. If your privacy and security teams are separate, ensure you are in regular communication and pool your efforts where you can to build a strong culture of both privacy and security in your organization.

Visibility and transparency – keep it open

Enable independent verification of your privacy promises. All your stakeholders should be able to 'trust, but verify'. Being transparent is important: inform users in clear language how and why you are processing their data. But also consider how you can prove that this is really what you are doing, for example via independent audits or (where feasible) by open-sourcing your code and protocols, as Signal do to build trust in their privacy guarantees.

Respect for user privacy – keep it user-centric

Prioritize the interests of individual users. Enable them to exercise their privacy rights, be transparent with them, and treat them fairly. Provide them with fine-grained privacy controls that they can use to meet their needs. Consider: knowing what you know about how your business works, would you be happy to be a user of your product? If you have any misgivings about how your data would be used, then you are likely violating this principle.

📚 Reading Assignment: How To Protect Your Users With The Privacy By Design Framework - Heather Burns, Smashing Magazine (2017). This article explains how GDPR-specific requirements such as Privacy Impact Assessments relate to privacy by design, and provides case studies of privacy by design epic wins and failures in apps.

This suggestion is confirmed in the "Edit Account" option, which only allows users to edit their name and email address. This does not meet the third PbD principle "Privacy must be embedded into design."...

...There are no user controls or granular options. If I wanted to exercise control over my data, I would have to write an email to a generic customer-service address or, alternatively — in the time-honored tradition of privacy policies that are really trying to fob users off — send them a letter in the post. This does not meet the seventh PbD principle of giving users granular privacy options with maximized privacy defaults...

...It’s clear that the only way I can ensure my privacy with this pub chain is to not use the app or its Wi-Fi at all. This creates the zero-sum dichotomy, which the fourth PbD principle seeks to avoid.

<- Back

Next ->