Privacy Engineering: Privacy-by-Policy vs. Privacy-by-Architecture

A number of regulatory requirements and consumer concerns are driving organizations to consider how to make their policies more privacy-friendly. Companies are also coming up against the conflicts between privacy protection and the business need to leverage data. In light of privacy scandals and the resulting increase in public interest in privacy protection, this issue is becoming more significant for decision-makers in organizations of all sizes. This article takes a look at how privacy can be engineered into organizational systems and practices in two ways: privacy-by-policy and privacy-by-architecture.

Privacy-by-policy and privacy-by-architecture are two concrete approaches to privacy engineering. While they are often seen as separate practices, privacy researchers Sarah Spiekermann and Lorie Faith Cranor argue that they may actually be complementary, where a privacy-by-policy approach comes in to fill the gaps where a privacy-by-architecture strategy cannot be implemented.


The privacy-by-policy approach to privacy protection is mainly a “notice and choice” approach, with a foundation in the FTC’s Fair Information Practice Principles (FIPs). These principles are focused more on end user notice and choice, rather than other strategies, such as minimizing collection of data, or limiting acceptable uses of data. This approach acknowledges that companies are unlikely to stop collecting or using customer data, while at the same time recognizing that individuals want to retain control over how their data is being used. For this reason, the privacy-by-policy approach has been implemented by many businesses, as it is largely non-intrusive.

The objectives of the FIPs are summarized below:

- Inform users on data being collected

- Present choices for sharing data (e.g. secondary uses of data)

- Give users access to data for review/correction/removal purposes

- Protect security of data

Criticisms of a Privacy-by-Policy Approach

The privacy-by-policy approach is founded on trust-based mechanisms that protect sensitive data from accidental disclosure or misuse. However, this is based on the assumptions that companies can be trusted to handle individuals’ personal information and that privacy policies/regulations are enforceable. Policies and regulations can fail to deter stronger attackers, for instance, malicious hackers, or companies that may financially benefit from data mining. Critics have also pointed out that privacy-by-policy approaches can sometimes amount to privacy promises that a company may or may not keep.

Another shortcoming of the FIPs and the privacy-by-policy approach is that they are effective only in systems that collect personal data. The FIPs lose relevance as soon as they are introduced into systems that collect little or no personal data, or in systems that were designed with privacy-friendly architectures.

Finally, critics argue that not all individuals will share the same privacy preferences. Some variables include place, social context (i.e. situation, identity, time) and culture, which all influence the way an individual will value and give meaning to the notion of privacy.


While a privacy-by-policy approach fails to consider the potential for strong attacks (e.g. identity thieves, hackers, etc.), a privacy-by architecture approach is designed with such risks in mind. The goal of a privacy-by-architecture approach is to design for the non-identifiability of users and provide strong guarantees of privacy. In this model, even if attackers gain access to the data, no personally identifiable information can be created with reasonable effort. The privacy-by-architecture approach offers users higher levels of privacy, in a more reliable manner.

The privacy-by-architecture approach relies on the following techniques:

a) Anonymity-based techniques – Such techniques are focused on making an individual’s identity or personal information not identifiable. However, these techniques do not guarantee that pseudonyms cannot be linked back to the individual with some effort.

b) Obfuscation-based techniques – In order to make it more difficult to link de-identified information back to individuals, obfuscation-based techniques disguise location and time information by decreasing precision/accuracy and adding confusion to the data.

Characteristics of a system designed with a privacy-by-architecture approach include:

- No unique identifiers across databases

- No common attributes across databases

- Random identifiers

- Contact information is not stored with profile/transaction information

- Collection of long-term person characteristics on a low level of granularity

- Technically-enforced deletion of profile details at regular intervals


This article takes a look at two approaches to privacy protection: privacy-by-policy and privacy-by-architecture. The former approach relies on the Fair Information Practice principles (FIPs) to offer users privacy information and privacy choices. Privacy-by-architecture approaches utilize stronger privacy protections and technologies based on anonymity and obfuscation techniques to secure user data. While these approaches have their differences, experts suggest that hybrid solutions may be practical, satisfying the needs of businesses, while minimizing the privacy risks of individuals.

CIPP Exam Preparation

In preparation for the Certified Information Privacy Professional/Information Technology (CIPP/IT) exam, a privacy professional should be comfortable with topics related to this post, including:

  • Fair Information Practice Principles in System Design (I.G.)
  • Privacy Protection Mechanisms: Privacy by Policy (III.A.)
  • Notice and Choice (III.A.a.)
  • Privacy Protection Mechanisms: Privacy by Architecture (III.B.)
  • Anonymization (III.B.a.i.)
  • Pseudonymization (III.B.a.ii.)
  • Privacy-Enhancing Technologies (III.B.c.)

Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>