Benefits of Privacy by Design

Privacy is embedded throughout the product or service lifecycle from design to disposal. The benefits of using PbD include:

• increased awareness of privacy and handling of personal information across an agency’s projects, products, services, systems or processes
• early identification and resolution of potential privacy risks and issues (when it’s simpler and less costly to do so)
• greater assurance of meeting the Information Privacy Principles of the Privacy Act.

PbD should be applied to technology and any activity, such as procurement, analysis and evaluation or policy development, where personal information is collected and used. Good practice also recommends that such considerations be given to de-identified or anonymised information derived from personal information.

The 7 principles for Privacy by Design

These principles — and the philosophy and methodology they express — can be applied to specific technologies, business operations, physical architectures, networked infrastructure, and entire information ecosystems.

The key to instilling PbD principles is to undertake ongoing communication and education with senior leadership, colleagues and staff.

1. Proactive not reactive, preventative not remedial

Privacy needs to be part of the planning of any new or updated product, service, system or process. Privacy considerations should help drive the design rather than being bolted on at the end to address a few privacy risks.

2. Privacy as the default

The default setting of any design should protect the individual’s personal information by understanding how the Information Privacy Principles apply in this context.

3. Privacy embedded into design

Privacy should be so integral to the design of the product, service, system or process that it would not function without the privacy-preserving functionality.

4. Full functionality — positive-sum, not zero-sum

Design requirements to protect personal information should be treated as an opportunity to design a better product, service, system or process, not as a trade-off with other functionality.

5. End-to-end security — lifecycle protection

Protection and security of personal information should be considered for every stage of the information lifecycle: collection, storage and security, use, access and correction, disclosure, retention and disposal.

6. Visibility and transparency

How the product, service, system or process will use the personal information needs to be clear to the individual providing the personal information. The accompanying privacy notice should be written in easy-to-understand, audience-appropriate language.

7. Respect for user privacy — keep it user-centric

At the centre of any design for product, service, system or process is a person who will use that product, service, system or process. It’s that person who will bear the harm and impact of any privacy breach or misuse of their personal information.

More information:

• International Association of Privacy Professionals — Privacy by Design the 7 foundational principles (PDF 485 KB)
• International Association of Privacy Professionals — How to operationalise Privacy by Design

Engineering privacy

To implement and embed PbD, an agency’s privacy officer or team needs to work closely with the agency’s teams that develop and implement technology — whether hardware, software or web — that interacts with personal information.

‘ICT and digital teams’ is the term that is used to indicate the variety of teams that could be included. This is the process of engineering privacy into the agency’s systems which is the reason for the term ‘privacy engineering’.

A useful way to approach privacy is to consider the broader ecosystem, which consists of multiple roles that all interact during the development and use of hardware and software. These may include:

• project managers
• business owners
• privacy officer or team
• legal team
• requirements engineers
• designers and programmers
• testers and users.

If this approach is taken, the ICT and digital teams can take a proactive role to integrate privacy in technology development.

ICT and digital teams and privacy requirements

The ICT and digital teams must understand, capture and document privacy requirements (functional and non-functional) and be able to apply them when creating the new system design.

It is important to note that any changes to the system after implementation will be more expensive than addressing privacy during requirements gathering. Standard requirements techniques can be adapted for privacy requirements in the following ways.

Acquiring and eliciting

Privacy requirements need to be acquired from a variety of sources to cover:

• software standards and guidelines
• relevant legislation and regulations.

Managing

Whenever a requirement or system component changes, trace matrices should be consulted to determine the impact of the change on other parts of the system, including privacy policies.

When using trace matrices, a trace link:

• from a privacy requirement to privacy legislation and regulation means the requirement implements the law
• to a design element, such as role-based access control mechanism, means the requirement is implemented by the design element.

Analysing

Privacy, like any other functional or non-functional requirements, should undergo completeness arguments. These ensure all privacy standards, guidelines, legislation and regulations have been traced to a requirement and cover every step in the data life cycle.

Privacy design strategies and their purpose

Having good privacy requirements contributes to planning which privacy strategies should or could be used in the system design. These privacy design strategies can be used as general approaches that ICT and digital teams could put in place as appropriate:

• Minimise and separate — reduces the opportunity for unauthorised access of personal information
• Hide and abstract — makes it more difficult for unauthorised people to use personal information
• Enforce and demonstrate — reduces the probability of unauthorised access and use
• Inform and control — provides individuals with information and choices to reduce the risk to their personal information.

Even if ICT and digital teams do not use these strategies, using the strategies’ design vocabulary to talk about a system’s privacy properties can be helpful.

Embedding privacy in design

The purpose of this section is to help privacy officers or teams learn about some of the appropriate PbD and privacy engineering terms to start a conversation with their ICT and digital teams.

Identify the purpose

When the purpose is fully understood, then ICT teams can create a system that meets privacy goals.

Understand quality attributes

The quality attributes required to improve privacy in design include:

• Identifiability: the extent to which an individual can be identified within a system
• Network centricity: the extent to which personal information remains local to the client
• Availability: the need to ensure that information is available to satisfy business needs
• Integrity: the extent that the system maintains a reliable state, including the quality of the data being free from error:
  • Accuracy: whether information is correct and free from errors
  • Completeness: whether there is any missing information
  • Currency: whether the information is up to date
• Mobility: the extent to which a system moves from one location to another
• Predictability: aims to enable reliable assumptions about a system, particularly its data and the processing of that data by all stakeholders
• Manageability: refers to the ability to granularly administer personal information, including modification, disclosure and deletion
• Dissociability: is the minimisation of connections between data and individuals to the extent compatible with system operational requirements. (That is, the association between the individual and their personal information.)

Source: Bauer, L., Clifton, C., Cranor, L. F., et al. 2.4 High-Level Design — An Introduction to Privacy for Technology Professionals (p.73–77).

Identify information needs

This stage identifies what personal information is required to meet the purpose. Agencies should only collect and use the minimal personal information required.

Imposing controls

Controls minimise privacy risks by:

• reducing access by unauthorised individuals
• reducing unauthorised access by individuals who have access for other purposes
• reducing what personal information is available
• governing user behaviour through technical, administrative and operational means.

Control steps:

1. Architect: reducing the identifiability of data and decentralising operations.
2. Secure: using hide and abstract design strategies.
3. Supervise: enforcing policies through processes and demonstrating compliance with these policies and processes.
4. Balance: using the inform and control design strategies to reduce power imbalances between the individual and the agency by addressing:
   • legitimacy: Is the application useful to the affected population?
   • appropriateness: Is it built with proper technology?