Term and context

"Privacy by Design" is a term that refers to the idea of designing privacy functionality into information systems from the start. It is a term that evolved in the 1990s and matured in the 2000s. The term was used often in political and activist contexts that were promoting the idea of user-centric information privacy.

To understand the term, one has to imagine the context of that time. Information systems were designed with the mindset of the web client connected to the large server. The purpose of a system was the implementation of a business purpose. Only the busniess purpose and the cost of the system were relevant. Regulation such as data protection was perveiced as a cost factor that had to get dealt with at minimum expense.

This lead to a number of strategies and tactics deployed for data protection compliance, such as:

Creative legalese writing of complex and unreadable privacy policies that were made to hide the actual vast data processing consent (see Annie Anton's article).
Power play: Users who disliked data collection were denied service and participation.
Ignorance: requests for insight into data processing were ignored or denied based on claims of business secrecy.
Users were asked to protect their privacy with external actions and tools such as early user-centric PETs.
Software that had options for privacy-friendly configuration came with default configurations that consumed personal data (a strategy still deployed by web browser and operating system vendors today).

In this context, privacy researchers recognized that end users (data subjects) will never posess enough power, resources or time to actually execute their rights guaranteed in data protection acts. The researchers concluded that the burden of delivering compliant IT systems should be put on the system vendors, not on their users. The vendors were seen responsible for designing privacy-friendly systems.

This was the birth of the "Privacy by Design" concept.

Concept

The seven principles of Privacy by Design, as postulated by Anne Cavoukian, are described below.

You can watch Anne's presentation on privacy by Design on YouTube (external content, different data processor!) by clicking on the box below.

The following seven sections will repeat the definitions from Anne Cavoukian's "Privacy by Design" from the article referenced at the end of the page.

Principle 1: Proactive not Reactive; Preventative not Remedial

The Privacy by Design approach is characterized by proactive rather than reactive measures. It anticipates and prevents privacy invasive events before they happen. PbD does not wait for privacy risks to materialize, nor does it offer remedies for resolving privacy infractions once they have occurred – it aims to prevent them from occurring. In short, Privacy by Design comes before-the-fact, not after.

Whether applied to information technologies, organizational practices, physical design, or networked information ecosystems, PbD begins with an explicit recognition of the value and benefits of proactively adopting strong privacy practices, early and consistently (for example, preventing (internal) data breaches from happening in the first place). This implies:

A clear commitment, at the highest levels, to set and enforce high standards of privacy – generally higher than the standards set out by global laws and regulation.
A privacy commitment that is demonstrably shared throughout by user communities and stakeholders, in a culture of continuous improvement.
Established methods to recognize poor privacy designs, anticipate poor privacy practices and outcomes, and correct any negative impacts, well before they occur in proactive, systematic, and innovative ways.

Principle 2: Privacy as the Default

We can all be certain of one thing − the default rules! Privacy by Design seeks to deliver the maximum degree of privacy by ensuring that personal data are automatically protected in any given IT system or business practice. If an individual does nothing, their privacy still remains intact. No action is required on the part of the individual to protect their privacy − it is built into the system, by default.

This PbD principle, which could be viewed as Privacy by Default, is particularly informed by the

following FIPs:

Purpose Specification – the purposes for which personal information is collected, used, retained and disclosed shall be communicated to the individual (data subject) at or before the time the information is collected. Specified purposes should be clear, limited and relevant to the circumstances.
Collection Limitation – the collection of personal information must be fair, lawful and limited to that which is necessary for the specified purposes.
Data Minimization − the collection of personally identifiable information should be kept to a strict minimum. The design of programs, information and communications technologies, and systems should begin with non-identifiable interactions and transactions, as the default. Wherever possible, identifiability, observability, and linkability of personal information should be minimized.
Use, Retention, and Disclosure Limitation – the use, retention, and disclosure of personal information shall be limited to the relevant purposes identified to the individual, for which he or she has consented, except where otherwise required by law. Personal information shall be retained only as long as necessary to fulfill the stated purposes, and then securely destroyed.

Where the need or use of personal information is not clear, there shall be a presumption of privacy

Principle 3: Privacy Embedded into Design

Privacy by Design is embedded into the design and architecture of IT systems and business practices. It is not bolted on as an add-on, after the fact. The result is that privacy becomes an essential component of the core functionality being delivered. Privacy is integral to the system, without diminishing functionality.

Privacy must be embedded into technologies, operations, and information architectures in a holistic, integrative and creative way. Holistic, because additional, broader contexts must always be considered. Integrative, because all stakeholders and interests should be consulted. Creative, because embedding privacy sometimes means re-inventing existing choices because the alternatives are unacceptable.

A systemic, principled approach to embedding privacy should be adopted − one that relies upon accepted standards and frameworks, which are amenable to external reviews and audits. All fair information practices should be applied with equal rigour, at every step in the design and operation.
Wherever possible, detailed privacy impact and risk assessments should be carried out and published, clearly documenting the privacy risks and all measures taken to mitigate those risks, including consideration of alternatives and the selection of metrics.
The privacy impacts of the resulting technology, operation or information architecture, and their uses, should be demonstrably minimized, and not easily degraded through use, misconfiguration or error.

Principle 4: Full Functionality – Positive-Sum, not Zero-Sum

Privacy by Design seeks to accommodate all legitimate interests and objectives in a positive-sum “winwin” manner, not through a dated, zero-sum approach, where unnecessary trade-offs are made. Privacy by Design avoids the pretence of false dichotomies, such as privacy vs. security, demonstrating that it is possible, and far more desirable, to have both.

Privacy by Design does not simply involve the making of declarations and commitments − it relates to satisfying all legitimate objectives − not only the privacy goals. Privacy by Design is doubly-enabling in nature, permitting full functionality − real, practical results and beneficial outcomes to be achieved for multiple parties.

When embedding privacy into a given technology, process, or system, it should be done in such a way that full functionality is not impaired, and to the greatest extent possible, that all requirements are optimized.
Privacy is often positioned in a zero-sum manner as having to compete with other legitimate interests, design objectives, and technical capabilities, in a given domain. Privacy by Design rejects taking such an approach – it embraces legitimate non-privacy objectives and accommodates them, in an innovative positive-sum manner.
All interests and objectives must be clearly documented, desired functions articulated, metrics agreed upon and applied, and trade-offs rejected as often being unnecessary, in favour of finding a solution that enables multi-functionality.

Additional recognition is garnered for creativity and innovation in achieving all objectives and functionalities in an integrative, positive-sum manner. Entities that succeed in overcoming outmoded zero-sum choices are demonstrating first-class global privacy leadership, having achieved the Gold Standard.

Principle 5: End-to-End Security – Full Lifecycle Protection

Privacy by Design, having been embedded into the system prior to the first element of information being collected, extends securely throughout the entire lifecycle of the data involved — strong security measures are essential to privacy, from start to finish. This ensures that all data are securely retained, and then securely destroyed at the end of the process, in a timely fashion. Thus, Privacy by Design ensures cradle to grave, secure lifecycle management of information, end-to-end.

Privacy must be continuously protected across the entire domain and throughout the life-cycle of the data in question. There should be no gaps in either protection or accountability. The “Security” principle has special relevance here because, at its essence, without strong security, there can be no privacy.

Security − Entities must assume responsibility for the security of personal information (generally commensurate with the degree of sensitivity) throughout its entire lifecycle, consistent with standards that have been developed by recognized standards development bodies.
Applied security standards must assure the confidentiality, integrity and availability of personal data throughout its lifecycle including, inter alia, methods of secure destruction, appropriate encryption, and strong access control and logging methods.

Principle 6: Visibility and Transparency – Keep it Open

Privacy by Design seeks to assure all stakeholders that whatever the business practice or technology involved, it is in fact, operating according to the stated promises and objectives, subject to independent verification. Its component parts and operations remain visible and transparent, to both users and providers alike. Remember, trust but verify!

Visibility and transparency are essential to establishing accountability and trust. This PbD principle tracks well to Fair Information Practices in their entirety, but for auditing purposes, special emphasis may be placed upon the following FIPs:

Accountabilty – The collection of personal information entails a duty of care for its protection. Responsibility for all privacy-related policies and procedures shall be documented and communicated as appropriate, and assigned to a specified individual. When transferring personal information to third parties, equivalent privacy protection through contractual or other means shall be secured.
Openness – Openness and transparency are key to accountability. Information about the policies and practices relating to the management of personal information shall be made readily available to individuals.
Compliance – Complaint and redress mechanisms should be established, and information communicated about them to individuals, including how to access the next level of appeal. Necessary steps to monitor, evaluate, and verify compliance with privacy policies and procedures should be taken.

Principle 7: Respect for User Privacy – Keep it User-Centric

Above all, Privacy by Design requires architects and operators to keep the interests of the individual uppermost by offering such measures as strong privacy defaults, appropriate notice, and empowering user-friendly options. Keep it user-centric!

The best Privacy by Design results are usually those that are consciously designed around the interests and needs of individual users, who have the greatest vested interest in the management of their own personal data.

Empowering data subjects to play an active role in the management of their own data may be the single most effective check against abuses and misuses of privacy and personal data. Respect for User Privacy is supported by the following FIPs:

Consent – The individual’s free and specific consent is required for the collection, use or disclosure of personal information, except where otherwise permitted by law. The greater the sensitivity of the data, the clearer and more specific the quality of the consent required. Consent may be withdrawn at a later date.
Accuracy – personal information shall be as accurate, complete, and up-to-date as is necessary to fulfill the specified purposes.
Access – Individuals shall be provided access to their personal information and informed of its uses and disclosures. Individuals shall be able to challenge the accuracy and completeness of the information and have it amended as appropriate.
Compliance – Organizations must establish complaint and redress mechanisms, and communicate information about them to the public, including how to access the next level of appeal.

Respect for User Privacy goes beyond these FIPs, and extends to the need for human-machine interfaces to be human-centered, user-centric and user-friendly so that informed privacy decisions may be reliably exercised. Similarly, business operations and physical architectures should also demonstrate the same degree of consideration for the individual, who should feature prominently at the centre of operations involving collections of personal data.

Critique

"Privacy by Design" was perceived by regulators, activist and politicians as a methodology for embedding privacy in newly designed systems. However, while the seven principles are expressing principal requirements for built-in privacy, they still are closer to the legal philosphy of privacy than they are to the software engineering process. Therefore, two different types of critizism against "privacy by Design" have evolved:

The seven principles for privacy by design do not relate to the software engineering process. They do not provide any functional requirements that are meaningful to a software architect or to a requirements engineer. The principles still have to get interpreted by privacy experts into a paricular specification process. Technicians and software engineers are often left confused concerning what they, in practice, should do with the seven principles when they go about with designing a new information system that consumes personal data. Watch Claudia Diaz' elaborating the weaknesses and show privacy engineering with examples in this lecture video:
Claudia Diaz' presentation "Engineering Privacy by Design" (external content at YoyTube)
The Privacy by Design principles are focused on designing new systems. However the worl is full of decade-old legacy systems and databases that are already there. Only a fraction of the information systems in use will be rebuilt from scratch at any time in digital history. What the principles do not support is the process or re-engineering existing systems.

The term "Privacy by Design" has since been included in new regulation, and is well-present in the privacy debate arount the world. However, it is yet far away from a functional or technical specification that will be instructive to software architects.

References

Anne Cavoukian: Privacy by Design - The 7 Foundational Principles - Implementation and Mapping of Fair Information Practices, Office of the Privacy Commissioner of Ontario, 2009. [link]
Annie I. Antón and J. B. Earp, "A requirements taxonomy for reducing Web site privacy vulnerabilities," Requir. Eng., vol. 9, pp. 169-185, 2004. [link]
Seda Gürses, Carmela Troncoso, and Claudia Diaz: Engineering Privacy by Design, KU Leuven report, 2011 [link]
Lothar Fritsch, "State of the Art of Privacy-enhancing Technology (PET) - Deliverable D.2.1 of the PET Web project," Norsk Regnesentral, Oslo, Norway 1013, 22-nov-2007 [link].

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.