The concept of “Privacy by Design” is an increasingly prominent topic in the privacy world. However, it’s not a new concept – it was first articulated by then-Ontario Information and Privacy Commissioner Ann Cavoukian, and formalized in 1995 by the Ontario Information and Privacy Commission, the Dutch Data Protection Authority and the Netherlands Organization for Applied Scientific Research. Privacy by design was adopted as a framework by the International Assembly of Privacy Commissioners and Data Protection Authorities in 2010.
In this post, we’ll review the seven Privacy by Design principles, their legal significance, and provide advice for applying these principles to your systems.
What is Privacy by Design?
At its core, it’s the notion that privacy values – and the associated legal requirements, limitations and controls, ethical standards, principles, and similar authority – be embedded in systems and processes that collect, use, handle, and store personal information from the very beginning of the conceptualization and design process. It’s similar to Value-Sensitive Design – the concept that technology should be designed in a way that accounts for human values in a principled and comprehensive manner, in which ethical values of both direct and indirect stakeholders are built into the design of a system.
Privacy by Design has seven core foundational principles that drive its outcomes:
- Proactive, not reactive; preventive, not remedial
- Privacy embedded into design
- Privacy as the default setting
- End-to-end security – full lifecycle protection
- Full functionality – positive-sum, not zero-sum
- Visibility and transparency – keep it open
- Respect for user privacy – keep it user-centric
The bottom line – Privacy by Design is all about preventing issues and concerns rather than remediating them after they happen and ensuring that whatever representations are made to stakeholders can be and will be fulfilled. It’s a process and technology design mandate.
Privacy by Design is Evolving from a Recommendation to a Mandate
All of this sounds simple enough, right? However, putting the principles into action and achieving true privacy by design is a complex and challenging matter that requires extensive and thoughtful planning.
Consider first, the law. As a threshold matter, Privacy by Design is itself a mandate that is increasingly written into law. The EU General Data Protection Regulation (GDPR), among other laws, expressly incorporates privacy by design into its requirements at Article 25 (“Data protection by design and by default”). Regulatory bodies in a number of countries, including the United States, explicitly recommend it as good practice in their guidance. So, you can’t just ignore Privacy by Design – if it doesn’t apply to you now, future privacy laws and regulations are sure to change that.
Then, there are all those hundreds or thousands of other privacy laws that apply to the concept as well. Privacy by Design is, among many other things, about complying with both the letter and the spirit of those laws. In and of itself, that reality poses a major design challenge. Those laws are by no means uniform – they often conflict, are vague, or outdated. Nor are they static – laws change, and come and go, on a regular basis. Additionally, ethical considerations must be worked out on a case-by-case basis. For example, in the absence of a legal requirement, what’s an ethical period for retention of some bit of PII in country X? To whom may we appropriately give access to it? Etc., etc., etc.
Putting Privacy by Design into Action
The seven Privacy by Design Principles mentioned earlier are very high-level. In order to design and implement a compliant system, you must first analyze and determine what these abstract mandates actually mean in the specific environment you propose to build. That means not only interpreting the high-level principles and requirements themselves, but also fully understanding how they interact with all the laws that bear on the topic. It also means fully understanding your own internal requirements and processes, including exception management for things like legal holds. That, in turn, means things like policies and procedures, records retention schedules and many other things must be fully developed as well. Remember, you’re building an engine to execute some potentially complex and high-risk rules. If you don’t understand your own rules from the start, you cannot possibly build a system that accurately executes them. The precise challenge is to take the vague and high-level concepts and:
- First reduce the high-level concepts into engineering design principles; then
- Reduce engineering design principles to process diagrams, flow charts and other design elements; then
- Reduce the elements to machine logic; then
- Reduce the machine logic to machine instructions in the form of computer code.
Consider one of the Privacy by Design principles: “Full functionality – positive-sum, not zero-sum.” The explanation of this is “Privacy by Design seeks to accommodate all legitimate interests and objectives in a positive-sum ‘win-win’ manner, not through a dated, zero-sum approach, where unnecessary trade-offs are made. Privacy by design avoids the pretense of false dichotomies, such as privacy versus security, demonstrating that it’s possible to have both.”
What on earth can that mean in terms of designing a big IT system? What’s the flow chart and set of machine instructions that will make your system compliant with this concept? Take this to your systems engineers and ask them to build it for you. See what they say.
Achieving “Positive-Sum” Solutions
So where do you begin? First, avoid one of the most common pitfalls in the information management business: buying or building a system before you have fully analyzed your requirements. Remember, the system executes rules, in this case some complex, detailed, and very high-risk rules. If you don’t know what the rules are, you certainly can’t build a system that executes them.
That means, long before you write a line of code or diagram out a flow chart, you need to carefully analyze:
- Applicable law
- Soft ethical considerations
- Business needs
- Internal policies such as RIM policies and data security policies
Consolidate all the analysis into a highly detailed functional specification outlining precisely what the system must accomplish. Once this is done, you can initiate the design process, consistently referring to the specification. It’s crucial to remember that if you encounter a situation requiring a tradeoff, privacy compliance should never be compromised, even if it affects other functionalities. Privacy by Design expressly precludes that sort of tradeoff.
So, there you have it – a quick but complete recipe for building a system using Privacy by Design concepts. All you need to do now is go build it.
For more on Privacy by Design, download our whitepaper: Data Privacy for the Information Professional
