Privacy Principles

View

Data Actors

The individual whose personal data is being stored or processed.

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

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.

Fair Information Practice Principles

Originally developed in 1973 to guide US government agencies in governing their use of personal data, the Fair Information Practice Principles (FIPPs, also called FIPs) were expanded upon by the OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data (adopted in 1980). They have influenced thinking about data protection around the world, providing a "common language" of principles most countries broadly agree upon. If you've ever wondered why two completely different data protection laws look so similar, the FIPPs are one reason why!

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

Privacy by Design

The term privacy by design originates from the Privacy by Design principles established by Ann Cavoukian. These were accepted as an international standard at the 2010 International Assembly of Privacy Commissioners and Data Protection Authorities and have been hugely influential.

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.

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.

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?

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.

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.

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.

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.

GDPR Principles

The GDPR principles are directly based upon the FIPPs. One significant difference is the addition of the principle of lawfulness, fairness and transparency. These three are grouped together because they complement one another. It is important to act lawfully, but not all lawful actions are ethical, so you must also consider how fair your data processing is to data subjects. By also being transparent with them about what you are doing, they can then choose to exercise their rights to control the use of their data if necessary.

  • Lawfulness, fairness, and transparency
  • Purpose limitation
  • Data minimization
  • Accuracy
  • Storage limitation
  • Integrity and confidentiality
  • Accountability - note that the GDPR imposes specific requirements for record-keeping, such as Records of Processing Activities and Data Protection Impact Assessments.

Data Protection by Design and Default

Is privacy by design and default also a core GDPR principle? Yes...and no. Article 25 makes data protection by design and default a legal requirement. However, this is a more specific requirement with a narrower scope. It requires you to:

  • Implement appropriate technical and organizational measures, such as pseudonymization, to put the GDPR principles into practice and protect the rights of data subjects on an ongoing basis. To choose what is appropriate, you should take into account the following factors. If you are processing highly sensitive personal data for millions of people, for example, you will be expected to implement much more sophisticated protections than if you are processing 500 email addresses.
    • The state of the art (both technically and organizationally)
    • The cost of implementation (although you can't use cost as an excuse for violating the GDPR principles)
    • The type, scale, and context of the data processing you are doing
    • The potential risks to the rights and freedoms of individuals
  • Implement appropriate technical and organizational measures to ensure that, by default, only personal data necessary for each specific purpose of the processing is processed, and by default personal data is not made accessible to an "indefinite number of natural persons" (i.e. is not made publicly accessible or accessible to a whole network).
    • For example, the user should have to opt in to make their profile public.
    • Note that limiting personal data to what is necessary means not only limiting how much data you collect but also limiting how long you store it for and who it is accessible to. Even if you collect the bare minimum amount of data, you would violate the principle of data protection by default if you kept the data indefinitely or made it accessible to employees who have no need to access the data.

The European Data Protection Supervisor has recognized this more limited scope, explaining that privacy by design should be seen as a broader aspirational concept (including "a visionary and ethical dimension, consistent with the principles and values enshrined in the EU Charter of Fundamental Rights of the EU") than the legal requirements of data protection by design and default. However, case law so far has sometimes interpreted Article 25 more broadly - see the Further Reading for discussion.

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

Further Reading