Privacy by design is both a broad concept and a specific requirement of the GDPR. In both cases, privacy by design means using organizational and technical methods to reduce the amount and scope of data processing to the minimum necessary.
We'll break down the practical steps you need to take to avoid these problems when complying with the GDPR and other privacy laws.
- 1. Background of Privacy by Design
- 2. GDPR Requirements for Privacy by Design
- 3. Other Privacy Laws and Privacy by Design
- 4. Privacy Policies and Privacy by Design
- 6. The Seven Principles of Privacy by Design
- 6.1. Be Proactive, not Reactive; Preventative not Remedial
- 6.2. Privacy as the Default
- 6.3. Privacy Embedded into Design
- 6.4. Full Functionality: Positive-Sum, not Zero-Sum
- 6.5. End-to-End Security: Lifecycle Protection
- 6.6. Visibility and Transparency
- 6.7. Respect for User Privacy
- 7. Conclusion
Background of Privacy by Design
The concept of privacy by design isn't new. It was already covered in broad terms by European privacy regulation (and associated national laws) in the early 1990s, while many other data laws around the world shared similar principles.
The concept came to greater attention in a more formalised manner in 2009. Ann Cavoukian, at the time the Information and Privacy Commissioner of Ontario, presented a framework for "privacy by design" at an international conference for data regulators. Officials from around the world agreed to adopt the concept and build it into both the drafting and implementation of data privacy regulations wherever possible.
The most high profile incorporation of the framework came with the GDPR in 2018.
GDPR Requirements for Privacy by Design
The GDPR affects any processing of personal data where the processor or the data subject (the person the data is about) is in a European Union country, or if the processing itself physically takes place in an EU country.
The GDPR includes two sets of requirements commonly referred to as "data protection by design" and "data protection by default." While this terminology is different, these requirements are a clear implementation of the privacy by design concept.
Article 25 (1) covers data protection by design:
"Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects."
The key phrase here is "at the time of determination of the means for processing." In simple terms, this means you have to consider data privacy when you design your systems and procedures for collecting and handling data. It's too late to start thinking about it once you actually have the personal data.
Note that "pseudonymisation" and "data minimisation" are examples of practical measures rather than an exhaustive list of what you must do.
Article 25 (2) covers data protection by default:
"The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons."
The key here is that it isn't enough to simply have a policy to only collect the data that's necessary for the relevant processing. Instead you need to have practical measures that make sure this happens.
Other Privacy Laws and Privacy by Design
The GDPR isn't the only privacy law that incorporates at least some elements of the privacy by design principle.
For example, the Personal Information Protection and Electronic Documents Act (PIPEDA) in Canada requires businesses to have a specific staff member responsible for data handling; to limit the data they collect; and to have procedures for destroying data that's no longer needed.
Meanwhile proposed or planned domestic laws in Brazil, India and Switzerland all incorporate privacy by design in some format.
Privacy Policies and Privacy by Design
- Answer a few questions about your business:
- Enter the country and click on the "Next Step" button:
The Seven Principles of Privacy by Design
Be Proactive, not Reactive; Preventative not Remedial
In simple terms this means making privacy a key objective that you follow at all times. It arguably means going beyond simply complying with the specific requirements of a privacy law.
The main practical step is that, before you design any system and process for handling data, you figure out what privacy risks your handling of the data will create. You can then decide what steps are needed to minimise or eliminate those risks and build these steps into the system.
Privacy as the Default
This sounds like a concept but is actually a key practical point. It doesn't simply mean getting behind the idea of data privacy. Instead it means taking practical steps that reduce the possibilities of breaching privacy.
- Making somebody in your organization responsible for data privacy and giving them the necessary powers and authority.
- Designing systems to identify and collect the minimum amount and scope of data needed to achieve the relevant purposes.
- Organizing your data handling to restrict access to those people who genuinely need to handle the data.
- Organizing your data processing and storage so that you know how long you'll need to keep data and, as a matter of procedure, delete or anonymize the data when you no longer need it.
There's also a general clause with information about how users can complain to an authority officer:
Privacy Embedded into Design
This is the principle that you build privacy protections into your systems from the outset rather than try to bolt it on later. A key example would be a database of email addresses that you've collected in a variety of contexts such as people signing up to an email newsletter, placing an order for a product, or registering for a conference.
The wrong (or at least sub-optimal) way to handle this would be to create the database and then later on try to craft a query that can take the date the user provided the mail address, add on an appropriate timescale, flag up addresses that might no longer be needed for the original purpose, then manually review them to decide if you should delete them. This creates several possible points of failure when an address could fall between the gaps.
The correct (or at least optimal) way would be to create the database so that, at the time you add an address, it automatically generates an expiry date. When a record reaches this date it should automatically be deleted, or at least automatically blocked from future use until you manually review it.
Full Functionality: Positive-Sum, not Zero-Sum
This is one of the more conceptual principles and it's more about attitude than specific actions. It's effectively a reminder that you shouldn't see privacy as a trade-off against other interests such as serving customers or boosting revenue. If you do find you are limiting the functionality of your site and service to accommodate privacy, it may be a sign you need to rethink your approach and find a better way to design your systems.
This principle doesn't mean there won't be consequences from the privacy choices the user makes.
End-to-End Security: Lifecycle Protection
This means keeping data secure at every point, from collecting it to using it to disclosing it to destroying it. (It's a good reminder that the GDPR's definition of "processing" covers all these activities.)
Some of the practical measures include:
- Using encryption where appropriate
- Using a range of security measures including physical restrictions, electronic restrictions (such as passwords) and organizational restrictions (such as giving different staff members different and appropriate levels of access to data)
- Monitoring access to data so that you can quickly spot any breach
Visibility and Transparency
This principle is based on the idea that keeping data subjects informed will not only win their trust but also helps ensure you are accountable for the way you handle data.
- Your contact details and those of your Data Protection Officer
- The purpose or purposes for which you collect data
- The legal basis under which you process data
- Who (if anyone) you share data with
- Whether you transfer data to non-EU countries and, if so, what safeguards you take to make sure the data has the same level of protection as under the GDPR.
- How long you keep data (or how you decide how long)
- The data subject's rights under the GDPR
- Whether the data subject is legally or contractually required to supply data and what happens if they refuse
- Whether you use any automated decision making with the data
Remember that the GDPR specifically says that any information you give about your data processing must be in:
"A concise, transparent, intelligible and easily accessible form, using clear and plain language, in particular for any information addressed specifically to a child."
Respect for User Privacy
This is something of a catch-all principle putting privacy at the center of everything you do. The most relevant part of the GDPR is the need for the data subject to give meaningful consent. This means they have the necessary information to make an informed decision.
The data subject must take a positive action such as clicking a button, ticking a checkbox or switching a toggle to show they give consent. A recent court ruling means that if you use checkboxes or toggles, you cannot set them to be pre-ticked or set to on by default.
This example from Power to Change doesn't simply rely on the user providing an email address and clicking submit. They also have to actively tick one or both checkboxes to specifically agree to their address being used for a particular purpose or purposes:
Let's recap what you need to know about privacy by design and the GDPR.
- Privacy by design began as a broad concept but was formalized into a framework.
- The GDPR incorporates the principles of privacy by design into two requirements: data protection by design and data protection by default.
- You must build privacy into your data collection and processing procedures and systems rather than add it in later.
- You must design your systems with default procedures that minimize data collection and processing, reducing the risk of unintentionally breaching privacy.
Privacy by design covers seven principles which you can turn into practical action while complying with the GDPR.
- Be proactive: Consider privacy risks and how to mitigate them before you design and build a data processing system.
- Privacy as default: Make somebody responsible for data handling; minimize data collection; restrict staff access to data; keep track of how long you need to retain data.
- Privacy embedded into design: Build privacy protections into your data processing systems rather than apply them later on.
- Full functionality: Make sure you don't compromise functionality for privacy or vice versa. If you do, rethink your approach.
- End-to-End security: Use a range of security measures to cover every point of data processing from collection to disposal.
- Respect for user privacy: Make sure you have meaningful active consent from users before you collect and handle data. Don't rely on browsewrap or pre-ticked checkboxes.