ISO/IEC DIS 27561

Information security, cybersecurity and privacy protection — Privacy operationalisation model and method for engineering (POMME)

This document describes a model and method to operationalize ISO/IEC 29100 privacy principles into sets of controls and functional capabilities. The method is described as a process following ISO/IEC/IEEE It is designed for use with other standards and privacy It supports networked, interdependent applications and This document is intended for engineers and other practitioners developing systems controlling or processing PII.

Titre manque

General Information

• Status: Published
• Publication Date: 25-Mar-2024
• ICS: 35.030 - IT Security
• Technical Committee: ISO/IEC JTC 1/SC 27 - Information security, cybersecurity and privacy protection
• Drafting Committee: ISO/IEC JTC 1/SC 27 - Information security, cybersecurity and privacy protection
• Current Stage: 4060 - Close of voting
• Start Date: 09-Oct-2023
• Completion Date: 10-Oct-2023

Standards Content (Sample)

International
Standard
ISO/IEC 27561
First edition
Information security, cybersecurity
2024-03
and privacy protection — Privacy
operationalisation model and
method for engineering (POMME)
Sécurité de l’information, cybersécurité et protection de la
vie privée — Méthode et modèle d'opérationnalisation de la
confidentialité pour l'ingénierie (POMME)
Reference number
ISO/IEC 27561:2024(en) © ISO/IEC 2024

ISO/IEC 27561:2024(en)
© ISO/IEC 2024
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2024 – All rights reserved
ii
ISO/IEC 27561:2024(en)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms. 7
5 Context of privacy operationalization . 7
5.1 General .7
5.2 Privacy engineering viewpoint.7
5.3 Privacy engineering operationalization model .8
5.4 Privacy engineering operationalization method .8
5.5 POMME processes overview .8
5.6 Privacy and security .9
6 Initial information inventory process . 10
6.1 Purpose .10
6.2 Outcomes .10
6.3 Define and describe the TOA .10
6.4 Participant and information source identification .11
6.5 Systems and processes identification .11
6.6 Domains and domain owners identification .11
6.7 Intra-domain roles and responsibilities identification . 12
6.8 Touch points identification . 12
6.9 Data flows identification . 12
6.10 PII identification . 12
7 Privacy controls, privacy control requirements, capabilities, risk assessment and
iteration process .13
7.1 Purpose . 13
7.2 Outcomes . 13
7.3 Privacy control specification .14
7.4 Privacy control requirement specification .14
7.5 Capabilities specification .14
7.6 Risk assessment . 15
7.7 Iteration . 15
8 Privacy capabilities. 16
8.1 Capabilities overview .16
8.2 Capability details and associated functions .17
8.2.1 Core policy capabilities . . .17
8.2.2 Privacy assurance capabilities .18
8.2.3 Presentation and lifecycle capabilities .18
Annex A (informative) Mapping of the privacy principles from ISO/IEC 29100 to POMME
capabilities . 19
Annex B (informative) Lifecycle process example involving a PII controller and a solution
provider .20
Annex C (informative) POMME capability functions and mechanisms in a consumer application
use case .23
Bibliography .28

© ISO/IEC 2024 – All rights reserved
iii
ISO/IEC 27561:2024(en)
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 or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
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.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Information security, cybersecurity and privacy protection.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.

© ISO/IEC 2024 – All rights reserved
iv
ISO/IEC 27561:2024(en)
Introduction
Privacy principles and associated privacy control requirements face a number of challenges arising from
the need to comply with consumer expectations and global regulations for privacy which are continually
evolving, as well as the complex and rapidly changing ecosystem of devices, networks and applications
through which personally identifiable information (PII) flows. To face these challenges, privacy principles
and associated privacy control requirements are expected to be operationalized into sets of capability
functions and mechanisms. The privacy operationalization model and method for engineering (POMME)
addresses these challenges, particularly in interconnected and interdependent applications and rapid
lifecycle development processes.
Achieving effective operationalization in this environment is a critical responsibility of privacy engineers and
the developers and solution providers who support them. They should not only understand the technology
interfaces and interdependencies among components as they design these systems, but also ensure that the
appropriate privacy controls are selected and implemented across the entire data flow landscape relevant
to their analysis.
POMME provides a structured and extensible analytic model and method to accomplish these objectives.
[1]
It is based on the OASIS Privacy Management Reference Model and Methodology (PMRM), and it reflects
findings expressed in ISO/IEC TR 27550, which provides extensive information on privacy engineering that
organizations can use to integrate privacy engineering into system lifecycle processes. It also describes the
relationship between privacy engineering and other engineering viewpoints (system engineering, security
engineering, and risk management).
POMME supports the operationalization of privacy as it is defined in ISO/IEC 29100, utilizing a process
following ISO/IEC/IEEE 24774. The primary focus of POMME is on the functional architecture and
implementation details of privacy engineering, rather than the “policy” aspects of privacy, such as privacy
principles, privacy impact assessments (PIAs) and privacy control statements. These policy elements are
essential inputs into the engineering process and are already addressed by existing standards, codes of
practice, and guidance listed in the Bibliography. POMME utilizes these elements to support the functional
role of the privacy engineer.
Through the use of POMME, a privacy engineer can define the domain boundaries of a target of analysis
(TOA) and research, document, and organize the information (e.g. standards, privacy policies, and technical
data). By doing so, the capabilities necessary to implement privacy control requirements can be identified.
This enables the privacy engineer to:
a) determine the functions needed to implement privacy control requirements;
b) understand the relationship among controls, particularly when controls are interdependent or
networked or cloud-based;
c) select the specific implementation mechanisms (such as code or product configurations) that deliver the
required privacy controls in their operational state.
An additional benefit of POMME is that its structured processes support improved usage and integration of
privacy management tools, such as privacy-specific open source software.
Figure 1 and Table 1 illustrate the POMME operationalization model and method.

© ISO/IEC 2024 – All rights reserved
v
ISO/IEC 27561:2024(en)
Figure 1 — POMME operationalization model
Table 1 includes an inventory process which consists of eight activities and an operationalization process
which consists of five activities.
Table 1 — POMME method
POMME process Clause Activity
6.3 Define and describe the TOA
6.4 Participant and information source identification
6.5 Systems and processes identification
6.6 Domains and domain owners identification
Initial information inventory pro-
cess
6.7 Intra-domain roles and responsibilities identification
6.8 Touch points identification
6.9 Data flows identification
6.10 PII identification
7.3 Privacy control specification
7.4 Privacy control requirement specification
Privacy controls, privacy control
requirements, capabilities, risk 7.5 Capabilities specification
assessment and iteration
7.6 Risk assessment
7.7 Iteration
© ISO/IEC 2024 – All rights reserved
vi
International Standard ISO/IEC 27561:2024(en)
Information security, cybersecurity and privacy protection —
Privacy operationalisation model and method for
engineering (POMME)
1 Scope
This guidance document describes a model and method to operationalize the privacy principles specified
in ISO/IEC 29100 into sets of controls and functional capabilities. The method is described as a process that
builds upon ISO/IEC/IEEE 24774.
This document is designed for use in conjunction with relevant privacy and security standards and
guidance which impact privacy operationalization. It supports networked, interdependent applications and
systems. This document is intended for engineers and other practitioners developing systems controlling or
processing personally identifiable information.
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 terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
access capability
functionality enabling personally identifiable information (PII) principals (3.27) to access their PII (3.25) and
propose changes, correction, or deletion
3.2
activity
set of cohesive tasks of a process (3.38)
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.3]
3.3
actor
individual, or a digital proxy for an individual, who interacts with a system (3.41) that is processing personally
identifiable information (3.25)
3.4
agreement capability
functionality that defines and documents the rules and options for the handling of personally identifiable
information (3.25), consent documentation, as well as modifications to, and withdrawal of, consent

© ISO/IEC 2024 – All rights reserved
ISO/IEC 27561:2024(en)
3.5
assurance capability
functionality that ensures that any actor (3.3), domain (3.10), system (3.41), or system component has the
functionality necessary to carry out their assigned roles in processing personally identifiable information (3.25)
3.6
audit control
process (3.38) designed to provide reasonable assurance regarding the effectiveness and efficiency of
operations and compliance with applicable policies, laws, and regulations
3.7
availability
property of being accessible and usable upon demand by an authorized entity
[SOURCE: ISO/IEC 27000:2018, 3.7]
3.8
capability
ability of a system (3.41) to deliver a function (3.14), feature, or service
EXAMPLE “Provide confidential communication of PII in transit” is an example of a capability, whereas “encrypt
data communicated to the server using TLS” is an example of a function.
[SOURCE: ISO/TR 4804:2020, 3.4, modified — substituted “product” with “system”; Note 1 to entry has been
replaced by an example.]
3.9
confidentiality
property that information is not made available or disclosed to unauthorized individuals, entities, or
processes (3.38)
[SOURCE: ISO/IEC 27000:2018, 3.10]
3.10
domain
set of assets and resources subject to a common privacy and security policy
[SOURCE: ISO/IEC 27033-1:2015, 3.35, modified — deleted “security” from “security domain”; added
“privacy and” before “security policy”.]
3.11
domain owner
stakeholder (3.40) responsible for ensuring that privacy controls (3.30) are implemented and managed in a
system (3.41)
Note 1 to entry: A domain owner can be a personally identifiable information (PII) controller (3.26), PII processor (3.28),
or PII principal (3.27) depending on the system(s) being analysed.
3.12
enforcement capability
functionality that achieves compliance with accountability requirements
Note 1 to entry: This capability (3.8) can initiate response actions, policy execution, recourse when audit controls and
monitoring indicate operational faults and failures, record and report evidence of compliance to stakeholders, and
provide evidence necessary for accountability.
3.13
exported privacy control
privacy control (3.30) that is transmitted to a personally identifiable information (PII) controller (3.26) or PII
processor (3.28) in another domain (3.10) or system (3.41)
Note 1 to entry: An exported privacy control can be included in a data sharing agreement.

© ISO/IEC 2024 – All rights reserved
ISO/IEC 27561:2024(en)
3.14
function
technical or manual process component of a capability (3.8)
EXAMPLE “Encrypt data communicated to the server using TLS” is an example of a function whereas “provide
confidential communication of PII in transit” is an example of a capability.
Note 1 to entry: A function, feature or service is expressed at a more granular level than a capability.
3.15
incoming PII
personally identifiable information (PII) (3.25) flowing into a domain (3.10), or a system (3.41) or process
(3.38) within a domain
3.16
inherited privacy control
privacy control (3.30) that is received by a personally identifiable information (PII) controller (3.26) or PII
processor (3.28) from another domain (3.10) or system (3.41)
Note 1 to entry: An inherited control can be found in a data sharing agreement.
3.17
integrity
property of accuracy and completeness
[SOURCE: ISO/IEC 27000:2018, 3.36]
3.18
interaction capability
functionality that provides interfaces for presentation, communication, and interaction of personally
identifiable information (PII) (3.25) and relevant information associated with the PII
Note 1 to entry: This can include user interfaces, system-to-system information exchanges, and agents.
3.19
internally generated PII
personally identifiable information (PII) (3.25) created within the domain (3.10) or system (3.41)
3.20
internal privacy control
privacy control (3.30) that is required within a domain (3.10) or system (3.41)
3.21
mechanism
specific implementation method of a function (3.14) in a system (3.41)
EXAMPLE Software, software configurations, firmware, technical products and solutions, technical settings, or
detailed manual procedures.
Note 1 to entry: A mechanism is expressed at a more granular level than a function.
3.22
operationalization
knowledge compilation by conversion from a declarative form into a procedural, that is, operational form
[SOURCE: ISO/IEC 2382:2015, 2123014, modified — notes to entry have been deleted.]
3.23
outgoing PII
personally identifiable information (PII) (3.25) flowing out of a domain (3.10), or out of a system (3.41) within
a domain to another system within the domain

© ISO/IEC 2024 – All rights reserved
ISO/IEC 27561:2024(en)
3.24
participant
stakeholder (3.40) responsible for operational privacy management
3.25
personally identifiable information
PII
personal information
personal data
information that (a) can be used to establish a link between the information and the natural person to whom
such information relates, or (b) is or can be directly or indirectly linked to a natural person
Note 1 to entry: The “natural person” in the definition is the PII principal. To determine whether a PII principal is
identifiable, account should be taken of all the means which can reasonably be used by the privacy stakeholder holding
the data, or by any other party, to identify that natural person.
[SOURCE: ISO/IEC 29100:2024, 3.7, modified — admitted terms have been added; removed “any”; substituted
“can” for “might”.]
3.26
PII controller
personal information controller
data controller
privacy stakeholder (3.40) (or privacy stakeholders) that determines the purposes and means for processing
personally identifiable information (PII) (3.25) other than natural persons who use data for personal purposes
Note 1 to entry: A PII controller sometimes instructs others (e.g. PII processors) to process PII on its behalf while the
responsibility for the processing remains with the PII controller.
[SOURCE: ISO/IEC 29100:2024, 3.8, modified — admitted terms have been added]
3.27
PII principal
natural person to whom the personally identifiable information (PII) (3.25) relates
Note 1 to entry: Depending on the legal jurisdiction and the particular data protection and privacy legislation, the
synonym “data subject” can also be used instead of the term “PII principal”.
[SOURCE: ISO/IEC 29100:2024, 3.9, modified — Note 1 to entry has been added.]
3.28
PII processor
personal information processor
data processor
privacy stakeholder (3.40) that processes personally identifiable information (PII) (3.25) on behalf of and in
accordance with the instructions of a PII controller (3.26)
[SOURCE: ISO/IEC 29100:2024, 3.10, modified — admitted terms have been added.]
3.29
privacy by design
approach in which privacy is considered at the initial design stage and throughout the complete lifecycle of
products, processes (3.38) or services that involve processing personally identifiable information (3.25)
[SOURCE: ISO/IEC TS 27570:2021, 3.21, modified — removed hyphens from the term]
3.30
privacy control
measure that treats privacy risks by reducing their likelihood or their consequences
Note 1 to entry: Privacy controls include organizational, physical, and technical measures, e.g. policies, procedures,
guidelines, legal contracts, management practices or organizational structures.

© ISO/IEC 2024 – All rights reserved
ISO/IEC 27561:2024(en)
Note 2 to entry: Control is also used as a synonym for safeguard or countermeasure.
[SOURCE: ISO/IEC 29100:2024, 3.12]
3.31
privacy control requirement
specification for a system (3.41), product or service functionality to implement a privacy control (3.30) and
operationalize the stakeholders’ (3.40) desired privacy outcomes
Note 1 to entry: A privacy control requirement can be based on legal, regulatory, operational, or business/contractual
requirements.
3.32
privacy engineer
individual with specialized knowledge of privacy engineering (3.33) concepts and practices and the ability to
integrate privacy concerns into engineering practices for systems (3.41) and software engineering lifecycle
processes (3.38)
3.33
privacy engineering
integration of privacy concerns into engineering practices for systems (3.41) and software engineering
lifecycle processes (3.38)
[SOURCE: ISO/IEC TR 27550:2019, 3.14]
3.34
privacy impact assessment
PIA
overall process (3.38) of identifying, analysing, evaluating, consulting, communicating, and planning the
treatment of potential privacy impacts with regard to the processing of personally identifiable information
(PII) (3.25), framed within an organization’s broader risk management framework
[SOURCE: ISO/IEC 29134:2023, 3.7]
3.35
privacy management
collection of policies, processes (3.38) and methods used to protect and manage personally identifiable
information (PII) (3.25)
3.36
privacy policy
overall intention and direction, rules and commitment, as formally expressed by the personally identifiable
information (PII) controller (3.26) related to the processing of PII (3.25) in a particular setting
[SOURCE: ISO/IEC 29100:2024, 3.14, modified – changed term to singular]
3.37
privacy principle
set of shared values governing the protection of personally identifiable information (PII) (3.25) when
processed in information and communication technology systems
[SOURCE: ISO/IEC 29100:2024, 3.16]
3.38
process
interrelated or interacting activities that use inputs to deliver an intended result
[SOURCE: ISO 9000:2015, 3.4.1, modified — deleted “set of”, notes to entry have been deleted]

© ISO/IEC 2024 – All rights reserved
ISO/IEC 27561:2024(en)
3.39
security capability
functionality that provides the procedural and technical mechanisms (3.21) necessary to ensure the
confidentiality (3.9), integrity (3.17), and availability (3.7) of personally identifiable information (PII) (3.25),
and that safeguards privacy operations
3.40
stakeholder
person or organization that can affect, be affected by, or perceive itself to be affected by a decision or
activity (3.2)
[SOURCE: ISO 9000:2015, 3.2.3, modified — note 1 to entry and example have been deleted.]
3.41
system
set of interrelated or interacting elements
[SOURCE: ISO 9000:2015, 3.5.1]
3.42
system-of-interest
system (3.41) whose lifecycle is under consideration
[SOURCE: ISO/IEC/IEEE 15288:2023 3.48]
3.43
target of analysis
defined and bounded system-of-interest (3.42) or process (3.38) that includes personally identifiable
information (PII) (3.25) or in which privacy concerns are identified
Note 1 to entry: Security is integral to the analysis.
3.44
touch point
intersection of data flows with actors (3.3) or systems (3.41) or processes (3.38) within and across domains (3.10)
3.45
usage capability
functionality that ensures that the processing of personally identifiable information (PII) (3.25) complies with
privacy control requirements (3.31)
Note 1 to entry: This capability primarily addresses controls associated with information minimization, linking,
integration, inference, transfer, derivation, aggregation, pseudonymization, anonymization and disposal over the
lifecycle of the PII.
3.46
use case
description of a sequence of interactions used to help identify, clarify, and organize requirements to support
a specific business goal
[SOURCE: ISO/TR 31700-2:2023, 3.2, modified — removed “of a consumer and a consumer product”; notes to
entry have been deleted]
3.47
validation capability
functionality that evaluates and ensures the information quality of personally identifiable information (PII)
(3.25) in terms of accuracy, completeness, relevance, timeliness, provenance, appropriateness for use and
other relevant qualitative factors

© ISO/IEC 2024 – All rights reserved
ISO/IEC 27561:2024(en)
4 Symbols and abbreviated terms
PIA privacy impact assessment
PII personally identifiable information
POMME privacy operationalization model and method for engineering
PMRM privacy management reference model and methodology
TOA target of analysis
5 Context of privacy operationalization
5.1 General
POMME is a method for operationalizing the privacy principles specified in ISO/IEC 29100:2024, 6.1, in
accordance with the terms and concepts expressed in ISO/IEC/IEEE 24774. POMME is based on the OASIS
[1]
Privacy Reference Model and Methodology.
ISO/IEC 29100 includes a set of 11 privacy principles, derived from widely-accepted principles developed
by a number of states, countries, and international organizations. These principles guide the design,
development, and implementation of privacy policies and privacy controls. These principles also serve as a
baseline in the monitoring and measurement of performance, benchmarking, and auditing aspects of privacy
management programmes in an organization.
POMME is also intended to be used in conjunction with privacy and system engineering standards such as
ISO 31700, ISO/IEC/IEEE 15288, and ISO/IEC/IEEE 29148. It is also intended to enable privacy engineers to
identify, analyse, and address issues that arise when operationalization requires the integration of different
standards and policies.
NOTE 1 Annex A illustrates how POMME capabilities directly support the principles specified in ISO/IEC 29100.
NOTE 2 Information security is one of the 11 principles addressed in ISO/IEC 29100.
5.2 Privacy engineering viewpoint
Privacy engineering is applied to a system-of-interest, which can be a system, an application, a product,
a service, or their associated capabilities. A system-of-interest is, in general, under the responsibility of
one organization. There are cases where the system-of-interest is a system of systems, that is, a complex
grouping of multiple systems, or a result of the integration of various systems under the responsibility of
several organisations.
EXAMPLE A connected vehicle system can involve multiple automotive manufacturers, service providers,
applications and networks.
Stakeholders having an interest in privacy engineering are:
— PII principals who are concerned for their privacy, and their ability to intervene in the processing and
control of PII;
— policy makers who are concerned with enforcing privacy regulations and policies;
— business owners who are concerned with ensuring that the system they own is compliant;
— system developers who are concerned with the application of privacy engineering in the development
lifecycle;
— solution providers who are concerned with the expectations of their customer related to privacy; and

© ISO/IEC 2024 – All rights reserved
ISO/IEC 27561:2024(en)
— privacy advocates and experts who are concerned with ensuring that privacy and its implementations in
products and services are correctly understood.
Privacy engineering includes three lifecycle process viewpoints:
— a goal-oriented viewpoint for privacy engineering, i.e. ensuring that business or functional objectives
are met;
— a risk-oriented viewpoint for privacy engineering, i.e. ensuring that a risk assessment analysis has been
carried out and that the corresponding controls for risk treatment are supported; and
— a collaboration-oriented viewpoint for privacy engineering, i.e. ensuring that agreement has been
reached between relevant stakeholders when PII is transferred, shared, or derived.
5.3 Privacy engineering operationalization model
Privacy engineering operationalization refers to activities that take as input the privacy principles
from ISO/IEC 29100, the privacy-by-design principles, all relevant data and information available from
stakeholders and other sources, including supplementary policies and regulations. These activities
ultimately contribute to the selection of functional capabilities that are used throughout the system’s
lifecycle processes.
Using this operationalization model, a system is structured into domains, including interfaces between
domains called touch points. Additional operationalization activities involve the transformation of privacy
management objectives into privacy engineering concepts, including the identification of privacy controls
and privacy control requirements; the transformation of privacy control requirements into functional
capabilities; and the iterative identification of privacy risks associated with the functional capabilities.
When operationalization activities involve multiple organisations, the operational interaction takes
place through touch points. Capabilities that have been identified at the global level are transformed into
capabilities at the organizational level. Additionally, when the deployment of a privacy control requires
participation of an external vendor, the privacy engineer should document this information in their analysis
and associated documentation to help ensure it is incorporated in the vendor’s contractual obligations.
5.4 Privacy engineering operationalization method
The method for privacy engineering operationalization has the following characteristics:
— iterative with exit criteria to terminate the analysis;
— integrated into the system lifecycle processes;
— able to be mapped to existing approaches such as those specified in ISO/IEC/IEEE 15288, ISO/IEC TR 27550,
[19]
ISO 31700, and frameworks, e.g. NIST privacy framework;
— includes supplementary activities when multiple organisations are involved; and
— includes process steps that may be followed in any order and combination, as appropriate for an
engineering analysis.
NOTE Software development lifecycle processes are fully addressed in the POMME. Annex B provides an example
of a privacy engineering interaction involving a PII controller and a solution provider.
5.5 POMME processes overview
POMME incorporates two processes (see Clauses 6 and 7) and associated activities and tasks that enable
privacy engineers to achieve successful operationalization. In summary, these processes:
a) define the use case, system, or entity of interest that is the TOA,
b) identify stakeholders and participants,

© ISO/IEC 2024 – All rights reserved
ISO/IEC 27561:2024(en)
c) research and document all information and data relevant to the TOA using stakeholder and other
relevant sources,
d) document, organize, integrate, and analyse this information and data, following a structured,
repeatable method,
e) determine and document the privacy controls that are relevant to the TOA,
f) define and document the privacy control requirements necessary for the operationalization of the
privacy controls,
g) select or provide advice on the functionality and the technical and procedural mechanisms necessary in
the TOA in order to:
1) implement privacy control requirements,
2) integrate interdependent privacy control requirements, including those relevant to external
systems,
3) submit reusable assets (e.g. engineering components, privacy enhancing features) to the
organization’s reusable repository, whenever possible,
h) assess and address risks associated with operationalization,
i) perform iterative TOA research and analysis, as illustrated in Figure 2.
Figure 2 illustrates the interaction of POMME processes, which are described in Clauses 6 and 7.
Figure 2 — POMME processes
5.6 Privacy and security
POMME treats security controls as integral to the TOA and not as an adjunct. Privacy controls and security
controls should be completely integrated to provide privacy assurance. As explained in ISO/IEC 29100,
adhering to the information security principle requires:
— protecting PII with appropriate controls at the operational, functional and strategic level to ensure the
integrity, confidentiality and availability of the PII;

© ISO/IEC 2024 – All rights reserved
ISO/IEC 27561:2024(en)
— protecting PII against risks such as unauthorized access, destruction, use, modification, disclosure, or
loss throughout the whole of its lifecycle; and
— protecting PII through appropriate controls in proportion to the likelihood and severity of the potential
consequences, the sensitivity of the PII, the number of PII principals that can be affected, the PII processor
involved, and the context in which it is held.
Beyond these determinants, POMME addresses the scope and importance of security controls in managing
security risks associated with the operation of privacy control functionality in system processes, including
processes having multiple interdependencies. For example, security failures affecting the availability of
privacy functionality (e.g. a PII principal is denied access to their current consent agreements because of a
compromised subsystem or cloud provider) extend beyond confidentiality protections.
6 Initial information inventory process
6.1 Purpose
The purpose of the initial information inventory process is to enable the privacy engineer to research and
develop the essential baseline information that is required to define the privacy controls, privacy control
requirements and capabilities that are appropriate for a TOA. This research may be undertaken by the
privacy engineer or provided by external sources. This process includes the information collection and
research necessary to define the requisite security controls and method of integration with the privacy
controls. Since POMME addresses security as fully integrated with privacy (as defined in ISO/IEC 29100),
including security controls, security control requirements, and capabilities, it is essential to identify and
document this relationship in all activities.
This process involves discovering, creating, and documenting the inventory of participants, systems,
business processes, domains, roles and responsibilities, touch points, data flows, PII, and privacy and
security policies, thereby enabling a privacy engineer to define the necessary functions to instantiate control
requirements in the TOA. This process includes information obtained by the privacy engineer through direct
research or from external stakeholders and other sources.
NOTE The activities in this process are not necessarily intended to be followed sequentially. As additional
information becomes available, the engineer contacts additional information sources related to the TOA.
6.2 Outcomes
Successful completion of the initial information inventory process leads to:
— identification of the TOA and its boundaries;
— identification of participants, systems, business processes, domains, roles and responsibilities, touch
points, data flows and PII within the TOA;
— identification of the privacy and security policies applicable to the TOA;
— documentation of these elements for use by the privacy engineer and for further analysis and processes; and
— identification of information gaps or the need for additional research.
6.3 Define and describe the TOA
This activity defines, describes, and names the TOA and establishes the boundaries within which the process
activities and tasks are undertaken.
The tasks of this activity are to:
a) determine the boundaries of the TOA and the scope of analysis,
b) provide a narrative description of the TOA,

© ISO/IEC 2024 – All rights reserved
ISO/IEC 27561:2024(en)
c) provide a label or identifier for the TOA.
NOTE The label or identifier for the TOA provides an anchor usable for processes throughout lifecycle analysis, as
well as for extensions to associated interdependent TOAs and ecosystem components.
6.4 Participant and information source identification
This activity identifies all individuals, entities, and roles (including PII principals, if applicable) that have a
responsibility for operational privacy management in the TOA, as well as the source information used in the TOA.
The tasks of this activity are to:
a) identify and document the sources of information relevant to the TOA,
b) identify and document the privacy policies relevant to the TOA,
c) identify and document data controllers, data processors, sub processors, and other stakeholders such as
privacy officers and security officers with privacy responsibilities relevant to the TOA, and document
why they have been identified,
d) in organizations where naming an individual stakeholder is not possible or appropriate, identify the
specific organizational entity or role with operational privacy responsibility,
e) obtain contact information for each stakeholder individual or role, as appropriate.
6.5 Systems and processes identification
This activity identifies the end-to-end spectrum of systems and processes through which PII is collected,
stored, used, shared, transmitted, transferred across borders, retained, or disposed across the domains
defined in the TOA.
The tasks of this activity are:
a) identify and document the systems and processes and the types or categories of PII that is processed
within a domain,
b) prepare and document an architectural representat
...