Privacy by Design (PbD) has been coming up more and more in data security discussions. Alexandra Ross, the Privacy Guru, often brings it up in her consultations with her high tech clients. Its several core principles have been adopted by U.S. government agencies and others as de facto best practices polices.
PbD is about 20 years old and is the brainchild of Ann Cavoukian, formerly the Information & Privacy Commissioner of Ontario, Canada. Why haven’t we all heard more about it? PbD has been accused of being vague, too consumer-oriented, and not technical. Sure, it’s not a formal technical standard like ISO 27001 or PCI DSS.
Get the Free Pen Testing Active Directory Environments EBook
Think of PbD as good solid advice to help guide your data security decisions. The security standards, as complex as some of them are, can’t cover every possible security scenario, and that’s where PbD can step in: it’s like having a data security savvy friend you go to when you’re stuck on a problem.
The Seven Principles
Here are the PbD principles with some brief words on what they really mean:
1. Proactive not Reactive; Preventative not Remedial
The key idea behind this first principle is that you should think about data privacy at the beginning of the data security planning process —not after a data breach. Consider this principle as a kind of a mood setter for the rest of PbD. Always be thinking privacy (ABTP)!
2. Privacy as the Default Setting
This is the hardest one for companies, especially in the high-tech world, to get their heads around. You’re supposed to give consumers the maximum privacy protection as a baseline: for example, explicit opt-in, safeguards to protect consumer data, restricted sharing, minimized data collection, and retention policies in place. Privacy by Default therefore directly lowers the data security risk profile: the less data you have, the less damaging a breach will be.
3. Privacy Embedded into Design
This is another tough one, especially for rapidly growing high-tech startups. Privacy is supposed to be embedded into the design of IT systems and business practices. Talk to a typical software developer, and he’s most worried about completing core functionality for the product. Data security techniques such as encryption and authentication are usually put on the backburner in the rush to get features online. And testing for the most common hackable vulnerabilities in software—typically injection attacks—is also often neglected. These principles tell designers that they should think about privacy as a core feature of the product.
4. Full Functionality – Positive-Sum, Not Zero-Sum
The idea here is that PbD will not compromise business goals. Basically, you can have privacy, revenue, and growth. You’re not sacrificing one for the other. Think of this one as helping to establish a PbD culture in your organization.
5. End-to-End Security – Full Lifecycle Protection
Privacy protections follow the data, wherever it goes. The same PbD principles apply when the data is first created, shared with others, and then finally archived. Appropriate encryption and authentication should protect the data till the very end when it finally gets deleted.
6. Visibility and Transparency – Keep it Open
This is the principle that helps build trust with consumers. Information about your privacy practices should be out in the open and written in non-legalese. There should be a clear redress mechanism for consumers, and lines of responsibility in the organization need to be established.
7. Respect for User Privacy – Keep it User-Centric
This final principle just makes it very clear that consumers own the data. The data held by the organization must be accurate, and the consumer must be given the power to make corrections. The consumer is also the only one who can grant and revoke consent on the use of the data.
Andy blogs about data privacy and security regulations. He also loves writing about malware threats and what it means for IT security.