Implementing Privacy By Design

The General Data Protection Regulation (GDPR) introduced many changes to the way businesses and public bodies think about privacy. One of those ways is in the decision to encode the concept of “Privacy by Design” (PbD) into law through Article 25.

Fortunately, unlike much of the GDPR, the concept of Privacy by Design is fairly well-trodden.

What is Privacy by Design, why does the GDPR require it, and how can you implement PbD at your own business? You’ll find the answers and checklists to help you along the way are below.

What is Privacy by Design?

The most basic explanation of Privacy by Design is little more than “data protection through technology design.”

At its core, it means that you need to integrate data protection and privacy features into your system engineering, practices and procedures. It shouldn’t be an afterthought or a supplement to your processes or infrastructure.

One way to describe it is by outlining what Privacy by Design isn’t. For example, if you’re an individual browsing the internet, it doesn’t matter if you use a VPN and firewall to protect your computer if you also use the password: “password123” on every single account. A VPN won’t make up for your use of weak passwords. You need to integrate privacy at every level and then you can add on extra security features like a VPN.

What does this mean in practice for businesses? Some examples of Privacy by Design include:

Conducting a Data Protection Impact Assessment (DPIA) before using personal information in any way
Providing the contact details of your Data Protection Officer (DPO) or other responsible party
Writing a Privacy Policy that’s easy to read and kept up-to-date

Even still, Privacy by Design goes much further than this and impacts almost every area of your technology use and data processing. These examples merely demonstrate some of the ways you can engineer privacy into your processes.

The 7 Principles of Privacy by Design

There are seven principles in the concept of Privacy by Design and each one is just as important as the next. These principles are:

Proactive not Reactive/Preventative not Remedial
Privacy as the Default
Privacy Embedded into Design
Full Functionality
End-to-End Security
Visibility and Transparency
Respect for User Privacy

Let’s start with Principle 1: Proactive not Reactive/Preventative not Remedial.

The first principle argues that data privacy needs to come up at the beginning of the planning process. If your security practice consists of putting out fires and dealing with breaches, then you are being reactive. It sets up the philosophical heart of the rest of the principles.

Principle 2 Privacy as the Default Setting is perhaps the most difficult principle for companies to wrap their minds around. It argues that privacy needs to be at the forefront of what you do. That means restricting your sharing, using data minimization, deleting data you no longer use, and always operating on a legal basis. It also means using opt-in and opt-out functions and safeguards for consumer data.

In Principle 3, the idea is that privacy needs to find a home in the design or both your architecture and business. In other words, privacy is a core functionality of the product. You should be using encryption, authentication, and testing vulnerabilities on a regular basis. It doesn’t matter if your process works as it should; it has a design flaw if there’s a security vulnerability.

Principle 4 puts forth that there’s no reason to be afraid of Privacy by Design. If you are sacrificing functionality for privacy, then you are doing it wrong. It’s more of a culture shift that requires a balance between growth and security.

Within the End-to-End Security principle (#5), there’s an argument that privacy protection follows data through the lifecycle from collection to deletion/archival. Encryption and authentication are the standard at every stage, but you need to go further at other stages. For example, you should only collect data you need and have a legal basis for. And when you finish with the data, you should use GDPR-compliant deletion/destruction methods for end-to-end protection.

In the penultimate Principle 6 Visibility and Transparency, you learn that privacy isn’t just for privacy’s sake. Data subjects should know about your privacy (and processing) practices and you should share them in the open. The principle argues a case for a well-written Privacy Policy, which is essential if you fall under the jurisdiction of the GDPR or another law like CalOPPA, anyway. It also argues that there needs to be a mechanism for data subjects to air their grievances, ask questions, and ask for changes.

Finally, Principle 7 argues that everything needs to remain user-centric. It means acknowledging that even if you have the data, it belongs to the consumer you collected it from. Your data subject can grant and withdraw their consent for your use of their data – not the other way around.