Implementing privacy by design in your organization

Be honest: for your organization, is privacy a box to be ticked at the end of a project, or a key requirement, considered every step of the way? If the former approach is familiar, and you’re concerned about how that may impact your compliance and security, you’re in luck.  

Many organizations that have struggled with incorporating privacy into their processes have developed a process and principles that can offer a path forward: privacy by design.

The term, “privacy by design” (PbD) entered the lexicon nearly 30 years ago, in a 1995 framework created by Ann Cavoukian, Information and Privacy Commissioner of Ontario, which she developed after working with the Dutch Data Protection Authority and the Netherlands Organisation for Applied Scientific Research.

The key insight was that it was much easier and effective to build products and services in such a way that safeguards privacy and protection from the outset, rather than retroactively addressing privacy risks once they are discovered.

Strongly associated with the concept of ‘Privacy Enhancing Technologies’, the idea of embedding privacy into a system was revolutionary at the time it was announced and remains an important concept for leaders focused on building privacy-respecting products and systems.

According to the Office of the Australian Information Commissioner, ‘Privacy by design’ is a process for embedding good privacy practices into the design specifications of technologies, business practices and physical infrastructures.

PbD is also one of the guiding principles of the General Data Protection Regulation, (GDPR) discussed specifically in its ‘data protection by design and default’ requirements.  

The 7 core principles of Privacy by Design

Proactive, not reactive

If you were to take one thing away from this article, and the framework itself, it would be this: you should focus on anticipating and preventing privacy risks before they occur. Privacy should not be considered only when a privacy issue is identified or – worse – when there is a breach, but should be part of the foundation of any project, product or team.

Privacy as the default setting

Privacy is not a feature to be enabled or a product or service tier in which to enroll some customers should they opt in. Protect personal data automatically without requiring user action.

Privacy embedded into design

Make privacy an essential component of the system's architecture, not an add-on.  

The situation you’re trying to avoid is a team building or purchasing a new solution such as a customer relationship management system (CRM) and only once the purchase or build is complete informing the privacy team. Attempting to bolt privacy on after the fact is not effective, and can lead to compliance or security failures.

Full functionality

Privacy is not an optional feature, and enabling privacy should not come with drawbacks. Balance privacy with other system objectives, ensuring no trade-offs.  

End-to-end security

Safeguard data throughout its lifecycle, from collection to deletion, via encryption and other means. Collect as little sensitive data as possible, ensure you protect it, and remove it as soon as required.  

Visibility and transparency

Ensure that data practices are open and verifiable to users. Document your data practices and procedures and communicate actions clearly. Being open about how you manage user data is about being accountable to your users.  

Respect for user privacy

Center your design choices on user needs and maintain strong privacy protections. This principle involves ceding some degree of control to your users, allowing them to make decisions about what happens with their data. Such an approach is also at the core of common privacy law provisions such as data subject access rights, and the right to be forgotten.

The difference between PbD and shifting left  

As an approach emphasizing proactive consideration of privacy, PbD is subtly different to another, similar concept: Shifting Privacy Left. Shifting Privacy Left is about considering privacy earlier in the development lifecycle, for example by identifying and mitigating privacy risks before developing products or features.  

But while Shifting Privacy Left brings privacy activities and testing earlier in the lifecycle, PbD is about developing an organization, culture, and products where privacy is considered at a foundational level, reducing or eliminating the chance of a privacy risk before work in a particular project or product begins.

Benefits of a PbD approach

A PbD approach allows you to remove a lot of your organizational risk entirely, allowing you to shift your focus to mitigating the risk that remains. When you‘ve considered privacy from the start, you’ve done things like reduced the amount of data you hold and understood what you possess. Such activities both remove risk and enhance compliance.

This means you will inherently be better able to comply with any existing and future regulations that deal with privacy or security, such as the GDPR, where it is required, and the California Consumer Privacy Act, and the EU’s AI Act, which endorse the approach.

Challenges of a PbD approach  

If you’re coming from an organization with an immature approach to privacy and risk, PbD will represent a major shift in attitudes and processes. Product and engineering teams who may prioritize building first, and asking questions later, may bridle at the idea of “moving slowly” to ensure privacy is considered throughout the product lifecycle.

Even once you overcome these objections, the transition to PbD will involve a significant investment in time, money, resources, and expertise to plan and implement processes that enable PbD.

What does PbD actually look like in action?  

Let’s move beyond the high-level goals to decode what PbD means for an organization. Here is the laundry list of requirements for an organization embracing PbD.  

Conduct privacy impact assessments (PIAs) at the beginning of projects

A PIA is a systemic assessment of a project with the goal of identifying how the project may impact the privacy of individuals, setting out requirements for either managing, minimizing, or eliminating any impact. PIAs must be mandatory at the start of projects that involve the collection or storage of data

Appoint a privacy officer

Either hire or designate a privacy officer, who will consult on the privacy measures during project planning, coordinate internal and external privacy complaints and requests, as well as be a “privacy champion” in your organization. Depending on where your organization is based, relevant privacy laws like the Australian Privacy Act or GDPR may mean a privacy officer is already a requirement.

Establish by-default practices

By establishing by-default practices designed to enhance privacy, you'll set the ground rules and systems for your organization. Expect to tackle priorities like:

• Collecting the minimal amount of information required from your customers and users

• Implementing access controls to limit data exposure

• Performing ongoing testing to evaluate potential audit outcomes

• Establishing clear guidelines and processes for how and when information is disposed of

• Building a privacy-minded culture

• Creating and maintaining effective data governance frameworks that dictate how data is managed across the organization, before being used in specific projects.  

Where to start  

Good data governance means you know what data you have, and can take steps to keep it safe throughout the lifecycle. Implementing a PbD approach is significantly easier with a well-organized, efficiently managed data estate  

RecordPoint’s solution  

PbD is about more than the data estate: it’s a culture, technology, and attitude shift. For PbD to work, it must be embraced completely by an organization, and embedded in every process and team.

To make such a shift effective, you don’t need friction, you need a platform to streamline and optimize your data governance processes. RecordPoint lets you proactively mitigate risk and know your data is compliant with comprehensive data governance, retention scheduling, and automated compliance controls.  

Discover where sensitive data, like PII and PCI, resides across your entire data ecosystem for enhanced visibility and control. Understand what data you have and where it lives with a continuous data inventory and cataloging, so you’re ready to act on it according to key regulations. Classification Intelligence lets you fine-tune how data is tagged and accessed across your organization.

Ensure compliance with regional and industry-specific data governance and privacy regulations like GDPR, PIPEDA, and CCPA; easily adapt retention policies in your file plan to meet changing laws, regulations, or internal policies, and faciliate a PbD approach.

Restrict access to sensitive records with role- and attribute-based access controls (RBAC, ABAC), ensuring that only authorized attributes or users have permissions to view or modify them.

Learn more about how RecordPoint can help you take your organization from privacy problems to a privacy by design approach.

‍