Practical Guide to Privacy by Design

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.

If you don't embrace privacy by design, you may make your Privacy Policy inaccurate, which will also breach the GDPR.

We'll break down the practical steps you need to take to avoid these problems when complying with the GDPR and other privacy laws.

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

Having a Privacy Policy does not in itself achieve privacy by design. However, a Privacy Policy plays several key roles in following both the concept of privacy by design and the related requirements of the GDPR:

• Drafting a Privacy Policy can raise points that need to be covered by your privacy procedures and data processing. This means it's useful to work on a Privacy Policy early in the process rather than make it the last thing you do.
• Many of the key measures in achieving privacy by design can be detailed in a Privacy Policy. This helps demonstrate your compliance and commitment to privacy by design, both to regulators and customers.
• Some of the requirements of a privacy by design approach involve keeping users informed about your data handling. A Privacy Policy is the best way to do this.
• Usually your Privacy Policy will make a series of promises about how you handle data. Following privacy by design helps make sure you can keep these promises.

How to Create a Privacy Policy

The Seven Principles of Privacy by Design

Dr. Cavoukian's framework for privacy by design is based on seven principles. Below we detail the key practical steps you must take to follow these principles and in turn comply with the GDPR's requirement for data protection by design and data protection by default. We also detail the implications for your Privacy Policy.

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.

Examples include:

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

The Privacy Policy of Tollers Solicitors demonstrates that a specific, named individual is responsible for data protection:

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.

This extract from AWeber's Privacy Policy shows it recognises data collected in different contexts should be handled in different ways. It will have complied with privacy by design if it has built these differences into its data processing systems:

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.

For example, this Privacy Policy from The Audience Agency details how some services and functionality are only possible if the user provides personal data or accepts cookie use. This doesn't breach privacy by design because these requirements are inherent to the relevant services and technology:

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

It's a good idea to detail your security measures in a Privacy Policy to inform both regulators and data subjects. However, it's vital this information is accurate and not misleading otherwise you undermine the data subject's ability to give informed, meaningful consent to data processing.

The Privacy Policy of Save the Elephants informs the data subject while managing expectations to keep them realistic:

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.

A Privacy Policy is key here and the GDPR sets out a range of points you must cover.

• 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."

The Privacy Policy of Childline is appropriately clear without being patronizing:

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.

It also means you get active consent so you are certain about the data subject's intentions. You cannot rely on passive measures such as "browsewrap" (notices that the user consents to the Privacy Policy simply by using the site).

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:

Conclusion

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.
• A Privacy Policy can demonstrate your use of privacy by design. Meanwhile, following privacy by design helps make sure you live up to the promises you make in a Privacy Policy.

• 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.
  • Visibility and transparency: Write a clear Privacy Policy detailing your procedures and the data subject's rights.
  • 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.