ISO/IEC TR 27550:2019 Information technology — Security techniques — Privacy engineering for system life cycle processes

Foreword

ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.

The procedures used to develop this document and those intended for its further maintenance are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details of any patent rights identified during the development of the document will be in the Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents) or the IEC list of patent declarations received (see http://patents.iec.ch).

Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.

For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions related to conformity assessment, as well as information about ISO's adherence to the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.

This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 27, Information security, cybersecurity and privacy protection.

Introduction

Privacy engineering is often associated with terms such as:

In recent years, a number of concepts, principles and approaches have been proposed for privacy engineering. In a paper on privacy engineering^[20], Spiekermann and Cranor contrast privacy-by-architecture from privacy-by-policy. The former focuses on data minimization, anonymization and client-side data processing and storage while the latter focuses on enforcing policies in data processing. In a paper on engineering privacy-by-design^[21], Gürses, Troncoso, and Diaz state that data minimization should be the foundational principle for engineering privacy-respecting systems. In a paper on privacy-by-design in intelligent transport systems^[22], Kung, Freytag and Kargl define three principles, minimization, enforcement and transparency. In a paper on protection goals for privacy engineering^[23], Hansen, Jensen, and Rost identify three goals: unlinkability, transparency and intervenability. In two papers on privacy design strategies^[29][30], Hoepman identifies four data oriented strategies (minimize, separate, abstract, hide), as well as four process oriented strategies (inform, control, enforce, demonstrate).

A number of global papers have been published. A privacy threat framework was defined by KU Leuven^[24] that led to the LINDDUN methodology^[25]. Two OASIS technical committees published specifications focusing on the implementation of privacy in systems: the Privacy Management Reference Model and Methodology (July 2013, updated in May 2016)^[27] and the Privacy by Design Documentation for Software Engineers and Companion committee note published in June 2014^[28]. The December 2014 ENISA report entitled Privacy and Data Protection by Design — from Policy to Engineering^[26] provides a good overview on privacy policies and their influence on the definition of privacy engineering concepts. The December 2015 privacy and security-by-design methodology handbook from PRIPARE^[31] provides a methodology which covers the whole engineering lifecycle integrating existing concepts, principles and methods. Joyee De and Le Métayer published in 2016 a book on privacy risk analysis^[32]. The January 2017 NIST internal report^[19] introduces a definition of privacy engineering, a privacy risk model and three privacy engineering objectives: predictability, manageability and disassociability.

Privacy engineering practice is supported by a growing body of standards on privacy, on security, and on software and system engineering.

Examples of useful privacy standards are:

When the security of personally identifiable information (PII) is at stake, privacy engineering can be supported by security standards such as:

When the engineering of software products and systems is involved, privacy engineering can be supported by software and system engineering standards such as:

This document takes into account principles and concepts for privacy engineering as well as standards and practices related to privacy, security and system and software engineering. It extends ISO/IEC/IEEE 15288 by adding specific guidelines that will help organizations integrate advances in privacy engineering in their engineering practices.

Privacy engineering practice is also influenced by the following factors:

This document also contains guidance on how an organization can adapt its privacy engineering practices to take into account these specific factors. Since this document is intended to encourage good privacy practice in the development of a wide range of ICT systems and applications, it does not contain system specific or application specific content.

1 Scope

This document provides privacy engineering guidelines that are intended to help organizations integrate recent advances in privacy engineering into system life cycle processes. It describes:

The intended audience includes engineers and practitioners who are involved in the development, implementation or operation of systems that need privacy consideration, as well as managers in organizations responsible for privacy, development, product management, marketing, and operations.

2 Normative references

There are no normative references in this document.

3 Terms and definitions

For the purposes of this document, the following terms and definitions apply.

ISO and IEC maintain terminological databases for use in standardization at the following addresses:

3.1 activity

3.2 availability

3.3 confidentiality

3.4 disassociability

3.5 integrity

3.6 intervenability

3.7 manageability

3.8 personally identifiable information

3.9 PII controller

3.10 PII principal

3.11 PII processor

3.12 predictability

3.13 privacy breach

3.14 privacy engineering

3.15 privacy principles

3.16 privacy risk

3.17 privacy risk source

3.18 process

3.19 process outcome

3.20 processing of PII

3.21 risk

3.22 task

3.23 touch point

3.24 transparency

3.25 unlinkability

4 Abbreviated terms

5.1 General

Privacy engineering deals with the integration of privacy concerns into engineering practices for systems and software engineering life cycle processes.

5.2 Relationship with system and software engineering

System and software engineering deal with the building of capabilities throughout a system and software's life cycle. A life cycle is defined as an abstract functional model that represents the conceptualization of a need for the system, its realization, utilization, evolution and disposal^[1]. A life cycle model is described as a set of processes, their outcomes, relationships and sequence. Examples of life cycle models are the waterfall model or the agile programming model.

System and software engineering practice relies on conformance with a selected life cycle model and its associated processes. Privacy engineering practice extends system and software engineering practice through the integration of privacy concerns into the life cycle processes. It therefore has an impact on the description of the life cycle processes.

ISO/IEC/IEEE 15288 describes thirty processes structured into four categories:

This document, in particular Clause 6, focuses on the ISO/IEC/IEEE 15288 processes where the need for privacy engineering guidance has been identified.

5.3 Relationship with security engineering

The relationship between security and privacy (see Figure 1) is as follows:

Figure 1

Security engineering focuses on objectives associated with attributes such as confidentiality, integrity, availability, and protection of ICT assets. Privacy engineering focuses on objectives associated with the operationalization of privacy principles listed in ISO/IEC 29100:

Annex A provides further guidance on privacy engineering objectives.

5.4 Relationship with risk management

Risk management deals with the systematic application of management policies, procedures and practices to the tasks of communication, consultation, establishing the context, identifying, analysing, evaluating, treating, monitoring and reviewing risk.

Risk models¹

¹ From NIST 800-30^[33].

A widely used risk model consists in expressing the risk level as a function of the likelihood that an adverse outcome occurs multiplied by the magnitude of the adverse outcome if it occurs:

Risk management practice in the engineering of a system needs to take into account several types of risks:

An integrated approach is needed as shown in Figure 2. For instance, poor health data management can lead to privacy risks (e.g., PII is made public), to security risks (e.g., health data has been compromised and the health system is no longer accessible), or to safety risk (e.g., urgent medical treatment is not possible).

Figure 2

Privacy risk sources and consequences

Figure 3³

³ Called bow-tie diagram in risk management.

Figure 3

Privacy risk sources include:

Consequences that can arise as a result of privacy risks include:

Annex D provides examples of risk models and associated methodologies.

Guidelines for privacy risk management are provided in ISO/IEC 29134^[11]. This document extends ISO/IEC 29134 by adding considerations on the integration of the privacy impact assessment process in ISO/IEC/IEEE 15288 processes.

6.1 General

ISO/IEC/IEEE 15288 ^[1] covers the following categories of process:

ISO/IEC/IEEE 15288 describes a process as follows:

The relationship between process, purpose, outcome, activity and task is shown in Figure 4 on the left. The specific dependencies between processes, activities and tasks are shown on the right.

Figure 4

This document provides additional descriptions of processes, purposes, outcomes, activities and tasks concerning privacy engineering where appropriate. Covered ISO/IEC/IEEE 15288 processes are shown in Table 1.

The rationale for covering the above processes is as follows:

6.2 Acquisition and supply processes

Purpose in ISO/IEC/IEEE 15288

The purpose of the acquisition process is to obtain a product or service in accordance with the acquirer's requirements.

The purpose of the supply process is to provide an acquirer with a product or service that meets agreed requirements.

Additional purposes for privacy engineering

These processes need to include requirements related to privacy. The acquirer can be either a PII controller or a PII processor. The supplier can also be a PII processor when it provides a service to a PII controller or to another PII processor.

Additional outcomes for privacy engineering

Successful implementation of these processes should result in an agreement on respective privacy obligations being established between the acquirer and the supplier, for instance the delivery of a product or a service which meets the privacy obligations and requirements.

Guidelines for privacy engineering

The content of the agreement depends on the role of the acquirer and of the supplier:

The following elements can be integrated into the agreement:

Specific obligations on suppliers and acquirers can exist in certain jurisdictions with respect to the processing of PII. These obligations should be taken into account in the development of any agreements between these two entities.

NOTE

As part of these processes, the agreement is modified when a change request is agreed to by both the acquirer and supplier, including concerning privacy requirements.

6.3 Human resources management process

Purpose in ISO/IEC/IEEE 15288

The purpose of the human resource management process is to provide the organization with necessary human resources and to maintain their competencies, consistent with business needs.

This process provides a supply of skilled and experienced personnel qualified to perform life cycle processes to achieve organization, project, and stakeholder objectives.

Additional outcomes for privacy engineering

Successful implementation of the human resources management process should result in:

1. a) skills for privacy engineering required by projects being identified;
2. b) necessary human resources for privacy engineering being provided to projects; and
3. c) skills of personnel for privacy engineering being developed, maintained or enhanced.

Guidelines for privacy engineering

The human resources management process depends on:

Skills needed for privacy engineering include, but are not limited to:

The process should include a program for privacy engineering skill development. This involves training and education (internal and/or external), the creation and maintenance of training material, and the monitoring of skills development within the organization.

The process can also be associated with an assessment and competency/skill certification process (e.g., certified privacy engineers).

6.4 Knowledge management process

Purpose in ISO/IEC/IEEE 15288

The purpose of the knowledge management process is to create the capability and assets that enable the organization to exploit opportunities to re-apply existing knowledge.

Additional purposes for privacy engineering

This process should be applied to knowledge resulting from privacy engineering practice.

Additional outcomes for privacy engineering

Successful implementation of the knowledge management process should result in:

1. a) the requirements for privacy engineering knowledge being defined and the elements of a privacy engineering knowledge repository being identified and specified;
2. b) a privacy engineering knowledge repository being available; and
3. c) knowledge management usage data being gathered and analysed.

Guidelines for privacy engineering

Privacy engineering necessitates multidisciplinary knowledge: technical, legal as well as socio-cultural and ethical knowledge.

The resulting knowledge can take various forms including, but not limited to:

Figure 5 shows the two activities that are involved:

Figure 5

The knowledge repository may be structured in a number of different ways. For instance, the organization normative framework (defined as an organization-wide internal structure containing a set of normative application security processes and elements) described in ISO/IEC 27034^[9] on application security can be used for privacy as shown in Figure 6, resulting in the following components:

Figure 6

Annex C contains information on a number of catalogues that are of interest in a privacy engineering knowledge repository:

A privacy engineering repository will also include reference documents such as:

6.5 Risk management process

Purpose in ISO/IEC/IEEE 15288

The purpose of the risk management process is to identify, analyse, treat and monitor risks continually.

The risk management process is a continual process for systematically addressing risk throughout the life cycle of a system product or service. It can be applied to risks related to the acquisition, development, maintenance, operation and eventual disposition (e.g., decommissioning) of a system.

Additional purposes for privacy engineering

The risk management process is applied to privacy risk sources and consequences.

Additional outcomes for privacy engineering

Successful implementation of the risk management process⁴

⁴ Note that this process is iterative.

1. a) privacy risks being identified;
2. b) privacy risks and consequences being analysed and a privacy impact assessment having been carried out;
3. c) privacy risk treatment options being identified, prioritized, and selected;
4. d) appropriate treatment being implemented; and
5. e) privacy risks being evaluated to assess changes in status and progress in treatment.

Additional guidelines for privacy engineering

Guidelines provided by ISO/IEC 29134 should be followed. The text below shows how ISO/IEC 29134 can be integrated in the ISO/IEC/IEEE 15288 risk management process.

Additional activities and tasks for privacy engineering

ISO/IEC/IEEE 15288 describes the following risk management activities:

The analyse risk activity for privacy engineering includes the following tasks:

1. 1) identify risks associated with PII processing and identify threats to and vulnerabilities of the system(s) processing PII;

   NOTE 1

   See C.2 for a catalogue of risks associated with PII processing.

   NOTE 2

   The identification of threats to and vulnerabilities of the security of PII assets should be integrated into the organization’s overall security risk management process. See ISO/IEC 27005 for guidelines on information security risk management^[8].

   NOTE 3

   See C.3 for a catalogue of privacy threats, as well as ISO/IEC 29134:2017^[11].

2. 2) estimate the likelihood and consequences of each identified risk;

   NOTE 4

   Organizations can support the assessment of likelihood in a number of ways: using information on customer demographics to estimate likelihood; extrapolating from information available about privacy risks in similar scenarios; or conducting focus groups or surveys to glean more thorough and specific information from users about privacy concerns.

   NOTE 5

   The consequences include the impact on the PII principals' privacy and the impact on the organizations' business and operations. For consequences on PII principals' privacy, see C.4. For consequences on the organizations' business and operation, the impact may be felt in terms of penalties for non-compliance, operational costs, and reputational and internal culture damage.

   NOTE 6

   ISO/IEC 29134:2017^[11] provides guidelines on how to estimate privacy risk likelihood.

3) evaluate and prioritize privacy risks; and

NOTE 7

See Annex D for examples of privacy risk analysis approaches.

NOTE 8

ISO/IEC 29134:2017^[11] provides guidelines on how to estimate the impact.

NOTE 9

Prioritization helps organizations to align mission priorities and resources. Addressing PII processing with low likelihood and low impact of being problematic can be of a lower priority, while addressing those with high likelihood and high impact is of the highest priority. However, likelihood and impact do not always align. For example:

—   low likelihood/high impact: While certain PII processing can be less likely to become problematic, they can have a severe impact. In these cases, an organization can prioritize mitigation of these problems because any incidence of this severe problem would have unacceptable consequences. For example, if researchers had access to a data set of individuals’ health information, the likelihood that the researchers would use the information improperly cannot be low, but the consequences for individuals, and therefore, for the mission and reputation of the organization, can be severe if misuse did occur, given the sensitive nature of health information; or

—   high likelihood/low impact: Alternatively, a problematic PII processing with a small impact can have a very high likelihood, leading an organization to prioritize controls for those problems in order to avoid negatively affecting such a large portion of their constituents, even if the impact is low. For instance, an organization can use a web analytics tool that raises concerns among users of the website. In this case, the impact for each customer can be very limited, but given that the tool affects all users, the likelihood would be high.

These prioritization decisions vary by organization and PII processing, but are much better informed if both likelihood and impact are systematically assessed for each PII processing. In many cases, a determination of likelihood and impact is not be a simple process; just as implementing controls requires investment, properly assessing risk requires investment. In some cases, research can be necessary to better understand the likelihood of a privacy problem occurring. In others, it can be more appropriate to rely on the knowledge of experts in the organization.

1. 4) prepare documentation for privacy impact assessment based on ISO/IEC 29134^[11], as well as other reference documents.

6.6 Stakeholder needs and requirements definition process

Purpose in ISO/IEC/IEEE 15288

The purpose of the stakeholder needs and requirements definition process is to define the stakeholder requirements for a system that can provide the capabilities needed by users and other stakeholders in a defined environment.

Additional purposes for privacy engineering

This includes defining requirements for system privacy capabilities.

Additional outcomes for privacy engineering

Successful implementation of the stakeholder needs and requirements definition process should result in:

1. a) the privacy role of the organization being defined;
2. b) stakeholders with a privacy interest being identified; and
3. c) privacy capabilities being defined.

Guidelines for privacy engineering

The following tasks can be carried out in this process:

Table 2 provides more information on roles for organizations. It also makes a distinction between systems and subsystems. The reason is that privacy engineering for subsystems is not the same as privacy engineering for systems, as suppliers of subsystems are generally not aware of the privacy requirements of the system in which the subsystem will be integrated. While this can be true, the owner/operator of the system should be aware of the privacy requirements and should specify these to the sub-system suppliers in any specification, design or contractual documents.

6.7 System requirements definition process

Purpose in ISO/IEC/IEEE 15288

The purpose of the system requirements definition process is to transform the stakeholder, user-oriented view of desired capabilities into a technical view of a solution that meets the operational needs of the user.

Additional purposes for privacy engineering

This includes an operationalization activity that transforms privacy principles into system requirements, ensuring that all privacy principles in ISO/IEC 29100 are effectively taken into account.

Additional outcomes for privacy engineering

Successful implementation of the system requirements definition process should result in:

1. a) system privacy requirements being defined;
2. b) privacy management services and any other privacy related services being identified; and
3. c) a preliminary privacy risk analysis having been carried out.

Guidelines for privacy engineering

The operationalization of privacy principles is a requirements analysis activity that includes goal-oriented as well as risk-oriented activities:

Figure 7

The set of privacy control requirements derived from the requirements analysis are jointly referred to as operational requirements. As depicted in Figure 7, the risk-oriented activities are also part of the privacy engineering risk management activity.

Additional tasks and activities for privacy engineering

The system requirements definition process includes the following activities and tasks:

1. a) frame organization system objectives:
   1. 1) describe the functionality of the system;

      NOTE 1

      A use case description can be used as recommended in OASIS PMRM^[27] as well as in NISTIR 8062^[18].

   2. 2) describe the business needs that the system serves; and
   3. 3) describe what privacy-preserving functionality the system will have.
2. b) frame privacy governance:
   1. 1) identify any privacy‐related statutory, regulatory, contractual and/or other frameworks within which the system needs to operate. List any specific privacy requirements arising from these sources;
   2. 2) identify any privacy‐related principles (e.g., ISO 29100) or other commitments to which the organization adheres (e.g., industry code of practice);
   3. 3) identify any privacy goals that are explicit or implicit in the organization’s vision and/or mission; and
   4. 4) identify any privacy‐related policies or statements within the organization.
3. c) develop a privacy analysis:
   1. 1) describe stakeholders, systems, business processes, data elements and data flows;

      NOTE 2

      Data elements and data flows are associated with PII processing such as collection, retention/logging, generation/transformation, disclosure/transfer, and/or disposal. The description can consist of a system map with associated tags. The description can use the model and methodology provided by OASIS PMRM^[27].

      NOTE 3

      The description involves the identification of touch points (i.e., intersections between two domains). The objective is to clarify the data flows and ensure a complete picture of all domains, systems, and processes in which PII is used. OASIS PMRM^[27] allows for the specification of privacy controls associated with PII. It includes not only the internal privacy controls created within the domain/sub domain, but also identifies privacy controls inherited and exported to/from other domains/subdomains.

      NOTE 4

      The description can use the data flow diagram as proposed by LINDDUN^[25] (see C.3).

   2. 2) describe general contextual factors;

      NOTE

      Contextual factors have considerable influence on impact analysis. They can be at the organization level (e.g., the role of the organization in the supply chain), at the system level (e.g., a cloud provider will be involved), or at the PII principal level (e.g., PII is collected in a certain context); and

   3. 3) describe specific PII, PII processing and unique contextual factors.

      NOTE 5

      Unique contextual factors can include mandated privacy controls (inherited from a domain, imposed internally, or exported to another domain).

   4. 4) iterate the "analyse risk activity" of the risk management process;
   5. 5) evaluate the objectives for privacy engineering (see Annex A); and
   6. 6) prepare documentation for privacy impact assessment based on ISO/IEC 29134^[11] as well as other reference documents.
4. d) define the system requirements concerning privacy:
   1. 1) identify services and functions to support privacy controls.

      NOTE 6

      Services and functions refer to privacy capabilities.

      NOTE 7

      A catalogue of privacy services, as defined in the OASIS PMRM, is presented in C.6.

6.8 Architecture definition process

Purpose in ISO/IEC/IEEE 15288

The purpose of the architecture definition process is to generate system architecture alternatives, to select one or more alternative(s) that frame stakeholder concerns and meet system requirements, and to express this in a set of consistent views.

Additional outcomes for privacy engineering

Successful implementation of the architecture definition process should result in:

1. a) identified stakeholder privacy concerns being addressed by the architecture;
2. b) system elements and their interfaces being identified;
3. c) the impact of privacy related concerns on the architecture being assessed; and
4. d) privacy risk analysis being updated.

Additional activities and tasks for privacy engineering

ISO/IEC/IEEE 15288 describes the following activities:

The following additional guidelines are provided:

1. a) develop architecture viewpoints:
   1. 1) apply privacy design strategies to develop architecture viewpoints;

      NOTE 1

      This task can be guided by privacy design strategies^[26][29][30]. Four data-oriented strategies (minimize, separate, abstract, hide) as well as four process-oriented strategies (inform, control, enforce, demonstrate) are identified. Table 3 provides examples of privacy controls associated with each privacy design strategy.

      NOTE 2

      This task can be guided by privacy threat analysis (see C.3) and mitigation strategies (see C.7).

2. b) assess architecture candidates:
   1. 1) iterate the "analyse risk activity" of the risk management process;
   2. 2) evaluate the objectives for privacy engineering; and
   3. 3) prepare documentation for privacy impact assessment based on ISO/IEC 29134^[11] as well as other reference documents.

6.9 Design definition process

Purpose in ISO/IEC/IEEE 15288

The purpose of the design definition process is to provide sufficiently detailed data and information about the system and its elements to enable an implementation that is consistent with the architectural entities as defined in models and views of the system architecture.

Additional outcomes for privacy engineering

Successful implementation of the design definition process should result in:

1. a) privacy risk analysis being updated; and
2. b) privacy controls being identified and specified.

Additional activities and tasks for privacy engineering

ISO/IEC/IEEE 15288 describes the following activities:

The following additional guidelines are provided:

1. a) establish design characteristics and design enablers related to each system element:
   1. 1) apply privacy design strategies to develop architecture viewpoints; and
   2. 2) identify the privacy capabilities to be provided by the system.

      NOTE 1

      The guidelines provided in ISO/IEC 29151 or ISO/IEC 27018 apply.

      NOTE 2

      The selection of privacy measures can be based on catalogues of privacy controls. See C.7 for an example.

      NOTE 3

      Each activity can be supported by a task to reuse knowledge from the repository maintained by the privacy engineering knowledge management process.

      NOTE 4

      OASIS PMRM^[27] can be used in the design definition process. It provides for the development of privacy controls; the definition of the functions and services required to implement the privacy control; and the packaging of the controls into mechanisms that will implement the privacy controls. The mechanisms are also part of the repository maintained by the privacy engineering knowledge management process

2. b) assess alternatives for obtaining system elements:
   1. 1) iterate the "analyse risk activity" of the risk management process;
   2. 2) evaluate the objectives for privacy engineering (see Annex A);
   3. 3) select privacy and security controls; and
   4. 4) prepare documentation for privacy impact assessment based on ISO/IEC 29134^[11] as well as other reference documents.

Figure 8 shows that the design of privacy controls [some controls can be referred to as privacy enhancing technologies (PETs)] is the outcome of three processes:

It also shows that privacy engineering can involve architecture change decisions.

Figure 8

All the processes leading to the design of privacy controls include risk management activities as shown in Figure 9. Note that the outcome of the three processes can lead to modifications as to how the initial privacy control requirements will be met.

Figure 9

A.1.1 General

The following privacy engineering objectives are defined by NIST^[18] for the purpose of facilitating the development and operation of privacy-preserving systems:

These objectives are designed to enable system designers and engineers to build systems that are capable of implementing an organization’s privacy goals and support the management of privacy risk.

A.1.2 Predictability

Predictability is about providing a reliable understanding about what is occurring with PII processing within a system. To achieve predictability, organizations need to consider:

Predictability provides organizations with both precision (in trust) and flexibility (in privacy preserving capability) so that they can design their information systems to support privacy-preserving user relationships.

A.1.3 Manageability

Manageability is about the administration of PII with sufficient granularity so that the right level of control can be applied: only necessary information can be collected or disclosed, inaccurate information can be identified and corrected, and obsolete information can be deleted. To achieve manageability, organizations need to consider the integration of:

Manageability provides organizations with the fine-grained control over data that allows them to implement key privacy principles, including maintaining data quality and integrity, achieving data minimization, and implementing individuals’ privacy preferences.

A.1.4 Disassociability

Disassociability is about the ability to actively protect or “blind” an individual’s identity or associated activities from unnecessary exposure during transactions. Unlike confidentiality, which is focused on preventing unauthorized access to information, disassociability recognizes that privacy risks can result from exposures even when access is authorized or as a by-product of a transaction. To achieve disassociability, organizations need to consider the integration of:

Disassociability advances the capabilities of a privacy-preserving system by engaging system designers and engineers in a deliberate consideration of the risks to an individual’s identity or associated activities.

A.2.1 General

Privacy protection goals are defined by ULD^[23] with a rationale to extend the classic security protection goals of confidentiality, integrity and availability⁶

⁶ ULD work on privacy protection goals has been influenced by earlier terminology work on data minimization^[39].

The resulting privacy and security protection goals (unlinkability, transparency, intervenability, confidentiality, integrity and availability) are attributes that can be used to guide a number of privacy engineering processes such as privacy impact assessment, or the design of privacy controls.

A.2.2 Unlinkability

Unlinkability ensures that a PII principal can make multiple uses of resources or services without others being able to link these uses together. The objective of unlinkability is to minimize the risk to privacy created by the potential linking of separate sets of PII, for instance:

Unlinkability is a key property:

When full unlinkability cannot be achieved, measures should be taken so that linking requires disproportionate effort for the entity establishing such linkage. Examples of measures for achieving and enhancing unlinkability comprise data avoidance, separation of contexts by different identifiers, pseudonymization mechanisms, anonymization mechanisms, and early erasure.

A.2.3 Transparency

Transparency ensures that an adequate level of clarity of the processes in privacy-relevant data processing is reached so that the processing of the information can be understood and reconstructed at any time. The objective is to allow involved parties (e.g., PII principals, PII controllers and PII processors) to know the risks to privacy (e.g., the processing of health data or location data) and have sufficient information on countermeasures, how to employ them and what limitations they have.

Transparency covers the entire system life cycle. It needs to cover not only the actual processing, but also the planned processing (ex-ante transparency) and the time after the processing has taken place to know what exactly happened (ex-post transparency). Transparency also involves all parties (i.e., PII principals, PII controllers, PII processors as well as supervisory authorities):

Examples for achieving or enhancing transparency comprise reporting mechanisms, understandable documentation covering technology, organization and responsibilities, source code, privacy policies, and communication with the PII principal.

A.2.4 Intervenability

Intervenability ensures that PII principals, PII controllers, PII processors and supervisory authorities can intervene in all privacy-relevant data processing. Note there can be legislative or regulatory limitations on the extent to which a data subject or supervisory authority can intervene in data processing. Intervenability can involve the application of corrective measures and counterbalances where necessary, including:

Mechanisms for achieving or enhancing intervenability include processes for influencing or stopping the data processing fully or partially, manually overturning an automated decision, data portability precautions to prevent lock-in at a PII processor, breaking glass policies, single points of contact for data subjects’ intervention requests, switches for users to change a setting (e.g., changing to a non-personalized, empty-profile version of a search engine or recommendation system), or deactivating an auto pilot or a monitoring system for some time.

A.2.5 Confidentiality

Confidentiality ensures that information is not made available or disclosed to unauthorized individuals, entities, or processes. The objective of confidentiality is to prevent PII from reaching the wrong people, for instance preventing banking account data or location data being accessed by potential burglars.

Examples of measures for achieving or enhancing confidentiality include protected transmission of collected data, protected access with suitable authentication schemes, protected processing of data, and protected storage.

A.2.6 Integrity

Integrity ensures the accuracy and completeness of data over its entire life cycle. The objective of integrity is to prevent PII from being altered in unauthorized ways or by unauthorized entities, for instance the transfer of erroneous health data.

Examples of measures for achieving or enhancing integrity include schemes such as digital signatures.

A.2.7 Availability

Availability ensures accessibility and usability if an authorized entity requires it. The objective of availability is to provide information when it is needed, for instance the next arrival at a bus stop.

Examples of measures for achieving or enhancing availability include preventing service disruptions due to power outages, hardware failures, or security denial of service attacks using schemes such as redundant systems.

B.1 Applicability to domains and ecosystems

Practicing privacy engineering properly is a challenge. Figure B.1 shows examples of ecosystems (e.g., smart cities, IoT, big data), domains (e.g., smart grids, health, transport) and concerns (privacy, security, safety) that need to be taken into account.

Figure B.1

The following stakeholders can be involved:

Examples of the privacy management duties of these stakeholders are described in Table B.1.

Suppliers of systems and subsystems should follow the guidelines provided in Clause 6. Further guidance is provided in Table B.2 and Table B.3.

B.2.1 Agile programming

The term agile has been used in the last 15 years in software development to promote adaptive planning, evolutionary development, early delivery, and continuous improvement. Agile development encourages rapid and flexible response to change. As stated by Jim Highsmith⁷

⁷ http://agilemanifesto.org/history.html

The Agile movement is not anti-methodology, in fact many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modelling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.

Figure B.2

Figure B.2 shows the principles of agile programming: product development is carried out in short periods called sprints. The objectives of sprints are agreed by the agile programming team (e.g., engineers who apply the agile approach), the product manager and the product owner. The result of a sprint is executable and can be demonstrated. It can therefore be assessed by both the product owners and managers. Pending work that is not mature and therefore not yet integrated in the product is managed through project and iteration backlogs.

Figure B.3 shows the difference between conventional programming and agile programming. Lifecycle processes in conventional programming are carried out in sequence (e.g., A followed by B followed by C), while in agile programming each sprint process can contribute to an incremental outcome of A, B and C.

Consequently, processes described in Clause 6 can be applied to both conventional programming and to agile programming by clearly identifying the incremental outcome that has been achieved during a given sprint process.

Figure B.3

Figure B.4 shows how privacy engineering can be integrated into agile programming:

Figure B.4

It should be noted that ISO/IEC/IEEE 15288 does not necessarily call for sequential processes. For instance, the privacy risk management process shown in Figure 9 runs parallel to three technical processes: the privacy principle operationalization process, the privacy architecture definition process and the privacy design definition process. Additional guidelines for agile programming are shown in Table B.4.

B.2.2 Support for small organizations

The ISO/IEC 29110 series^[4] is of particular interest when small enterprises are involved. A very small entity (VSE) is an entity (enterprise, organization, department or project) having up to 25 people.

The ISO/IEC 29110 series is intended for organizations which view ISO/IEC/IEEE 15288 as too complex. ISO/IEC/IEEE 15288 defines 30 processes while in contrast, ISO/IEC 29110 defines two processes:

To cope with the large diversity of VSEs, the following options are defined:

The resulting integration of privacy engineering in ISO/IEC 29110 is described in Table B.5.

C.1 General

The purpose of this annex is to provide examples of catalogues that can be useful to carry out privacy engineering activities. The catalogues are not meant to be comprehensive and other references including future standards can augment or replace them. These catalogues should be maintained within the knowledge management process described in 6.4.

C.2 PII processing risks

This catalogue of PII processing risks is based on NISTIR 8062^[18]. It should be used in the privacy risk management process to identify privacy risk sources.

NOTE

NISTIR 8062^[18] uses the term data action instead of PII processing

C.3 Privacy threats

LINDDUN^[25] provides a catalogue of privacy threats⁸

⁸ The most recent version of this catalogue is available on the LINDDUN website^[25].

Figure C.1 shows an example of a DFD for a social network where the social network user is a DFD entity, the social network data is a DFD data store, and the social network portal and associated service are processes.

In the social network example of Figure C.1, one threat associated with the "user" entity can be its "linkability". In the "[linkability, entity]" tree of Figure C.2 the "untrusted communication" threat is either:

Figure C.1

Figure C.2

C.4 Risks to individuals

This catalogue of risks to individuals is based on NISTIR 8062^[18]. It is used in the privacy risk management process to identify the consequences of privacy risks to the PII principals' privacy.

C.5 Examples of privacy controls

A reference catalogue which can be used is found in ISO/IEC 27552. The catalogue of privacy controls below is based on NIST Special Publication 800-53 rev4^[34]. Such catalogues, including those provided in ISO/IEC 29100, ISO/IEC 27018, and ISO/IEC 29151 should be used in the design definition process to identify and specify privacy controls.

C.6 Privacy management services

This catalogue of privacy management services is based on OASIS PMRM^[27]. It is used in operationalization of privacy principles operationalization and privacy control requirements.

C.7 Mitigation strategies and privacy measures

This catalogue of mitigation strategies and privacy measures is based on LINDDUN^[40]. It is used in the privacy engineering design process to identify potential privacy and security controls.

The catalogue is based on the taxonomy of privacy risk treatments shown in Figure C.3. The taxonomy is based on two main categories:

Figure C.3

In the taxonomy, concealing the association is further divided into two categories:

In the taxonomy, minimizing the association is further divided into two categories:

D.1 General

This annex provides a description of the risk models developed by NIST^[18] and by CNIL^[35]. The two risk models are described using Figure 3

NOTE

The described risk models include a series of assumptions and mappings from qualitative to quantitative scales, including an arbitrary numerical transformation from a multidimensional to a one-dimensional scale, which means they are a priori not comparable. Other models can be adopted by organizations.

D.2 NIST privacy risk analysis

NIST uses a risk model where the focus in terms of risk source⁹

⁹ Or risk factor.

¹⁰ NISTIR 8062^[18] uses the term data action instead of PII processing. Table C.1 provides a non-exhaustive set of problematic data actions.

The risk assessment includes the following steps:

NOTE

An organization can request to add other factors. In that case, the range of values can change (e.g., from 1 to 50)

Figure D.1

Here is an example based on a messaging service:

D.3 CNIL privacy risk analysis

CNIL uses a risk model where the privacy risk level is based on the impact on PII principals’ rights and freedoms:

It is composed by two distinct factors that should be combined where:

The risk assessment follows the following steps:

Figure D.2

Here is an example based on a messaging service:

Bibliography