Accelerate Innovation with a Privacy by Design Approach

By building your products with privacy by design principles, you can accelerate your time to market while retaining customer trust and protecting the privacy of sensitive data.

You’re busy with your team creating the product roadmap for your company’s next couple of months and beyond. You’ve got several exciting releases planned and you’re eager to get started until one of your team members comes to you with some concerns. Your roadmap is ambitious, they say, perhaps too much so — you need to give more consideration to how you’re protecting the sensitive data that you plan to use in your workflows. They mention a recent data breach at another company and caution you about the risks of damaging customer trust if a similar breach occurred at your company. Suddenly, your carefully laid plans have hit a major roadblock. 

As privacy concerns become an increasingly important element of B2B and B2C sales conversations, companies have taken steps to build privacy into their product design processes. Rather than viewing privacy as an obstacle or something to be bolted on later, ‘privacy by design and default’ puts privacy considerations at the beginning of the process, allowing you to plan without undue fear of last-minute concerns from well-meaning coworkers, or, much worse, leaving your company vulnerable to a data breach. 

The History of Privacy by Design

First, let’s define privacy by design. When building a product that collects PII (like an app, service, or website), privacy by design means you think about privacy from the start of the product design and development process to ensure that data privacy preservation is the default behavior. Your design and development teams ask questions like: How are we collecting sensitive data? What is the definition of sensitive data? What is considered sensitive personal data? Where is it going to be stored? What are we going to do with this sensitive data? How long will we retain it?

This term ‘privacy by design’ was coined in 1995 by Ann Cavoukian, but at the time it was primarily conceptual and served as a framework of ideas rather than a requirement. Privacy has historically been considered “nice to have” rather than a need — until recently, most companies that collect PII felt little to no restraint (and weren’t constrained by regulations) when it came to accumulating as much data as possible. Their focus was not on privacy but on more effective collection, more incisive data analysis, and more efficient data storage.

It wasn’t until the introduction of GDPR that the concept of privacy by design gained widespread traction — by including privacy by design as part of legislation, GDPR is making privacy a de facto requirement in the software development process. Additional privacy regulators are considering privacy by design — most recently, the new American Data Privacy & Protection Act (ADPPA) draft bill calls out privacy by design as required under a “Duty of Loyalty”, along with data minimization. This, along with a growing consumer demand for privacy and control of their data, has made up-front privacy considerations a critical part of the product development process. 

What Are the Advantages of Privacy by Design?

Back to your product roadmap conundrum. Your options are as follows:

1. You can ignore your coworker’s concerns and go ahead with the plan. Your manager is concerned that adding a lengthy privacy analysis to the process is going to take too much time.
2. You can rework your roadmap and devote the necessary resources and time to exploring the ways you are collecting PII data, where it is going, what you are doing with it, and whether you actually need to collect it. 

Obviously, roadmap A seems faster and cheaper, at least in the short-term. However, there are a number of downsides that will come into focus as you start collecting and storing PII. Without incorporating privacy by design principles, you run the risk of user data sprawling into places it shouldn’t be, including third-party services. This greatly increases the risk of a data breach, or at the very least, of alarming your users and making them feel uncomfortable using your products. 

If a data breach occurs, suddenly the short-term benefits of roadmap A are eclipsed by the cost of fixing these issues and trying to repair the company’s public reputation. What’s more, you’ll probably have to bolt on a privacy tool later on, which is all the more difficult when your system is established and already awash in PII. 

Even if you never deal with a breach, you will run into difficulties if you try to enter a new market where privacy legislation is more robust. Eventually, it becomes clear that establishing an effective privacy program was never really an option, but rather a requirement. And the only choice is whether to be proactive by addressing privacy as early as possible in the product development process, or much later because of external pressure. 

Roadmap B is a true “shift left” — by taking the principles of privacy by design into account up front (on the “left side” of your product roadmap diagram), you are heading off many of the risks and complications that necessarily come with collecting and storing PII, and addressing these issues up-front, when they can be handled more efficiently and comprehensively. This means that you can also innovate more quickly and fearlessly, because you’ve taken a comprehensive approach to privacy that makes privacy preservation the default, not a “patch”.

There are many other benefits to taking the privacy by design approach. Privacy has become a key point of focus and concern for many consumers, so you can use your privacy posture as a marketing and sales asset. Granting your customers insight and control of their data and assuring them that you consider protecting their data privacy to be a core part of your product can help you differentiate yourself. And finally, when you’re ready to expand into markets with strong data privacy regulations, your product will be ready if it’s built with a privacy by design approach. 

Privacy Awareness

A good example of the ways a privacy by design approach can help is discussed in Mozilla’s recent report on the data collection and protection practices of popular mental health apps. Most of the apps that the researchers looked into were found to be unsatisfactory from a privacy perspective, with a few of the worst offenders being described as “creepy”.

Although you might not be building products that provide something as sensitive as mental health resources or spiritual guidance, it’s easy to see how privacy can become a key differentiator for your company. Many of the apps that Mozilla researched may have chosen some version of the “Option A” discussed earlier, choosing a faster roadmap in order to beat competitors to the finish line. However, the shift in privacy awareness means their approach only brought them embarrassing headlines and damaged the trust of their users, possibly irreparably. 

Privacy by Design With Skyflow

Skyflow Data Privacy Vault lets you apply numerous privacy-enhancing techniques and build privacy into your product architecture. The combination of tokenization, encryption, anonymization, and redaction techniques with a powerful governance engine lets you look at privacy by design as an asset, not an obstacle.

Skyflow Data Privacy Vault can also help you improve your privacy architecture after the fact. The vault is easy to integrate with an existing product architecture, so it can help you to rapidly address the shortcomings of your initial approach to data privacy. 

If you’re interested in learning more about how Skyflow can help you to ensure the data privacy of your users, reach out to us.