ISO/IEC TS 27564:2025

Technical
Specification
ISO/IEC TS 27564
First edition
Privacy protection — Guidance
2025-09
on the use of models for privacy
engineering
Protection de la vie privée — Recommandations relatives à
l'utilisation de modèles pour l'ingénierie de la vie privée
Reference number
© ISO/IEC 2025
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: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2025 – All rights reserved
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 Engineering with models . 3
5.1 Models .3
5.2 MBSSE (model-based systems and software engineering) .5
6 Privacy engineering with models . 7
6.1 Privacy models .7
6.1.1 Guidance on models .7
6.1.2 Model intellectual property rights .8
6.1.3 Models representation, storage and reuse .8
6.1.4 Models for behavioural and policy interoperability .8
6.2 Privacy engineering models of interest .8
6.3 Privacy engineering supported by MBSSE .9
6.4 Initiatives and standards of interest . 12
7 Guidance on the use of privacy models .13
7.1 Engineering privacy capabilities . 13
7.2 Integrating the context of a system of interest .14
7.3 Supporting systems of systems emerging risks .14
7.4 Integration of horizontal standards .16
Annex A (informative) Using models for privacy engineering — Examples . 19
Bibliography .31

© ISO/IEC 2025 – All rights reserved
iii
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 2025 – All rights reserved
iv
Introduction
Systems that process personal information are and continue to become more complex. This is due to an
increasing ability to analyse, use, and store growing volumes of data. This complexity introduces greater
privacy risks for the individuals to whom this data pertains. Embedding privacy into these complex systems
is ever more important and provides an approach that mitigates these risks through system design. Model-
based systems and software-based engineering (MBSSE) provides such an approach to the discipline of
privacy engineering. Adding privacy modelling to the roster of tools to identify and assess privacy risks and
support potential risk mitigation strategies will help connect a concept to reality, i.e. the value of making
privacy and data protection a priority. Incorporating MBSSE into privacy engineering enables a complex
system to achieve both privacy and functionality in an easy-to-understand manner.
This document introduces the concept of MBSSE in the context of privacy engineering and provides technical
guidance on the use of engineering models for privacy engineering. The technical guidance is illustrated by
[1]
sample use cases taken from ISO/IEC TR 31700-2 and a use case on privacy threat modelling.
Clause 5 explains the model-based system and software engineering (MBSSE) and the benefits of using
models as a single source of truth (SSOT), including:
— consistency, ensured throughout the system lifecycle, as models can be transmitted from one lifecycle
stage to another, and used by engineering tools;
— interoperability, as models can be dynamically exchanged between systems in operation.
Clause 6 explains how MBSSE can be applied to privacy engineering by:
— explaining the benefit of privacy models and their management;
— identifying privacy models of interest, taking a system, ecosystem and an engineering perspective;
[2]
— showing how ISO/IEC/IEEE 24641 can be customized for privacy engineering;
— listing initiatives and standards of interest for privacy engineering with models.
Clause 7 elaborates on models by:
— explaining privacy capabilities, considering the relationship between a system of interest (subject to
system engineering) and a privacy capability (subject to privacy engineering);
— explaining the intended context of a system of interest;
— describing emerging behaviour at system engineering level in the case of systems of systems, and
describing associated privacy capabilities at privacy engineering level;
— explaining how to construct models through a profile approach in order to support the interplay with
transversal standards (e.g. technology standards on AI or IoT, or cross-cutting standards on safety or
resilience);
— providing guidance through sample use cases taken from ISO/IEC TR 31700-2, focusing on privacy
threat models.
© ISO/IEC 2025 – All rights reserved
v
Technical Specification ISO/IEC TS 27564:2025(en)
Privacy protection — Guidance on the use of models for
privacy engineering
1 Scope
This document provides guidance on how to use modelling in privacy engineering.
It describes categories of models that can be used, the use of modelling to support engineering, and the
relationships with other references, including International Standards on privacy engineering and on
modelling.
It provides high-level use cases describing how models are used.
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
capability
ability to do something useful under a particular set of conditions
Note 1 to entry: Generally, different kinds of capabilities exist: organizational capability, system capability and
operational capability.
[SOURCE: ISO/IEC/IEEE 24641:2023, 3.1.3, modified — Note to entry simplified.]
3.2
model
abstract representation of an entity or collection of entities that provides the ability to portray, understand
or predict the properties or characteristics of the entity or collection under conditions or situations of
interest
Note 1 to entry: A model can use a formalism that could be based on mathematical or scientific principles and concepts.
A model can be generated using an established metamodel. Metamodels are often used to facilitate development of
accurate, complete, consistent and understandable models.
Note 2 to entry: A model can be used to construct or express architecture views of the entity. Descriptive models
and analytic models are two kinds of models. A model should be governed by a model kind in accordance with
ISO/IEC/IEEE 42010.
Note 3 to entry: A reference model can be used to capture a general case that is used as the basis for creating special
case models for particular conditions or situations. A reference model can be used to encourage and enforce uniformity
of architectures and architecture elements.

© ISO/IEC 2025 – All rights reserved
Note 4 to entry: The model can be an architecture model, architecture entity model, concept model or reference model,
as the case may be.
Note 5 to entry: A physical model is a concrete representation that is distinguished from the mathematical and logical
models, both of which are more abstract representations of the system. The abstract model can be further classified as
descriptive (similar to logical) or analytical (similar to mathematical).
Note 6 to entry: Models can have other models as components.
Note 7 to entry: Models can be presented at different levels of abstraction to facilitate understanding and cooperation
between stakeholders and practioners at different levels.
[SOURCE: ISO/IEC/IEEE 42020:2019, 3.13, modified — Notes 5, 6 and 7 to entry added.]
3.3
model pattern
general, reusable model (3.2) or model part that can be used as a solution to a commonly occurring problem
within a given context in system or software design
[SOURCE: ISO/IEC/IEEE 24641:2023, 3.1.21]
3.4
repository
place where, or receptacle in which, things are or can be stored
[SOURCE: ISO/IEC 19763-1:2023, 3.13, modified — Note to entry deleted.]
3.5
model repository
repository (3.4) where models (3.2) are stored
[SOURCE: ISO/IEC 19763-1:2023, 3.11]
4 Abbreviated terms
AI artificial intelligence
CPRA California Privacy Rights Act
DPIA data protection impact assessment
DPM data privacy management
DPMF data protection modelling framework
DPV data privacy vocabulary
EMT epistimis modelling tool
GDPR general data protection regulation
IPR intellectual property rights
TM 1
JSON JavaScript Object Notation
TM ®
JavaScript is the trademark of a product supplied by Oracle Corporation. This information is
given for the convenience of users of this document and does not constitute an endorsement by
ISO or IEC of the product named. Equivalent products may be used if they can be shown to lead
to the same results.
© ISO/IEC 2025 – All rights reserved
LINDDUN linkability, identifiability, non-repudiation, detectability, disclosure of information, unawareness,
non-compliance
MBSSE model-based system and software engineering
OCL object constraint language
PIA privacy impact assessment
PLOT4AI practical library of threats for artificial intelligence
POMME privacy operationalization model and method for engineering
PII personally identifiable information
RDF resource description framework
SoS system of systems
SSOT single source of truth
XML extensible markup language
UML unified modelling language
5 Engineering with models
5.1 Models
[3]
Models are representations of a topic of interest, e.g. a real-work process, a device or a concept. As shown
in Figure 1, a model is a specification which uses representation conventions, also known as concrete syntax,
following some description language (e.g. UML). The specification references concepts on a topic of interest
following an associated ontology. A model conforms to a given metamodel defining its abstract syntax.
Producing models as digital artefacts facilitates a single source of truth (SSOT) as follows:
— it enables an organization to ensure that everyone in the organization works with the same information, and
— it enables a supply chain or an ecosystem to ensure that every organization works with the same
consistent information.
© ISO/IEC 2025 – All rights reserved
Figure 1 — Conceptual model of models
UML includes the use of diagrams:
— Structural diagrams:
— class diagrams,
— component diagrams,
— composite structure diagrams,
— deployment diagrams,
— object diagrams,
— package diagrams,
— profile diagrams,
— Behavioural diagrams:
— activity diagrams,
— communication diagrams,
— interaction overview diagrams,
— sequence diagrams,
— state diagrams,
© ISO/IEC 2025 – All rights reserved
— timing diagrams,
— use case diagrams.
[4]
ISO/IEC/IEEE 42010 provides a conceptual model of an architecture description (see Figure 2). It consists of:
— a purpose, i.e. defining the environment and the entity of interest for which an architecture description
is needed;
— expectations, i.e. defining the stakeholders, their concerns and their perspective, on aspects of the entity
of interest;
— a resulting architecture description, consisting of architecture views.
Models are therefore one of the main artefacts for system architecture descriptions.
Figure 2 — Conceptual model of an architecture description
5.2 MBSSE (model-based systems and software engineering)
[2]
ISO/IEC/IEEE 24641 identifies four process groups as shown in Figure 3:
a) the plan MBSSE process group, which focuses on managing models at organization and project level. It
includes the following processes:
— defining the scope and objectives of MBSSE;
— planning model development and governance;
— planning resources and assets;

© ISO/IEC 2025 – All rights reserved
— managing knowledge reuse.
b) the build models process group, which focuses on the core modelling activities. It includes the following
processes:
— producing system models;
— producing discipline-specific models;
— verifying models;
— validating models;
— simulating systems using models;
— evaluating alternative models.
c) The support models process group, which focuses on the technical management of models. It includes
the following processes:
— managing technical quality;
— managing configuration;
— managing data and models;
— sharing models for collaboration.
d) The perform MBSSE process group, which focuses on the model-based systems and software engineering
activities using models. It includes the following processes:
— performing business and mission analysis;
— performing operational analysis;
— performing functional analysis;
— performing system structure design;
— performing system analysis;
— performing domain design integration;
— performing system verification and validation.

© ISO/IEC 2025 – All rights reserved
Figure 3 — MBSSE reference model
6 Privacy engineering with models
6.1 Privacy models
6.1.1 Guidance on models
The following guidance is provided on privacy model descriptions.
— Purpose statement: The content of models can change according to the intended purpose of the model.
Various purposes can exist such as compliance, consent management, privacy protection, risk analysis,
or assurance. Models can be dedicated to one purpose and have a statement that details that purpose, the
data, how it is processed and how it is valuable to stakeholders.
— Readability: Models can be used by managers, data protection officers, domain experts, developers,
auditors and citizens. When a model serves more than one purpose, being able to view only the part(s) of
interest allows stakeholders ease of use without being distracted by other parts.
— Maintainability: To be current, it is important for models to be maintained or extended. This can be done
by a single stakeholder or jointly by different stakeholders.
— Correspondence: Being clear about the relationship between models is important because problems of
inconsistencies or incompleteness can arise when models are specified separately.
— Implementation accuracy: The assurance that implementation of a model is accurate is a concern;
therefore the privacy model’s description should detail mechanisms to verify the accuracy of the
impletrementation of the model.
— Common system concepts: As shown in Figure 1, models are based on ontologies. Therefore, privacy
models should be based on common system concepts.

© ISO/IEC 2025 – All rights reserved
[4]
EXAMPLE 1 System concepts based on W3C DPV (data protection vocabulary).
EXAMPLE 2 System concepts based on the DPMF metamodel (see Annex A).
6.1.2 Model intellectual property rights
Intellectual property rights (IPR) are an important consideration in the development and use of a privacy
[6]
model that can involve revealing proprietary systems and software elements. As noted in ISO 56000,
managing IP makes good business sense and this document aligns with this view of IPR. The technical
guidance provided in this document recognizes that the approach to MBSSE can be for an organization’s
internal purpose due to IPR constraints. There can also be situations where organizations willingly and
voluntarily share a privacy engineering model. This can be done under an open source-like license so that
other organizations may evolve a particular model and share the results in a structured format. It can also
be done under a royalty-free license, so the use of a particular model can grow more easily.
6.1.3 Models representation, storage and reuse
Models can follow standardized representations such as UML, allowing for sharing and reuse in an
engineering environment, including the following:
— models can be used as input to engineering tools;
— models can be stored in a model repository for further reuse.
The standardized representation should promote technology neutrality to support the various
representations used by tools such as XML, JSON and RDF.
6.1.4 Models for behavioural and policy interoperability
[7] [8]
ISO/IEC 19941 and ISO/IEC 21823-1 describe two facets of interoperability, behavioural interoperability
and policy interoperability, which are privacy requirements.
— Behavioural interoperability ensures that the actual result of an exchange achieves the expected
outcome.
EXAMPLE 1 When a PII principal has withdrawn consent for personal data collection, the expected behaviour of a
system managed by a PII controller is to stop collecting data.
— Policy interoperability ensures compliance with the legal, organizational and policy frameworks that
are applicable to the participating systems.
EXAMPLE 2 A policy could be that personal data in a domotic system are not transferred to the cloud.
Models can be used to describe privacy policies, and privacy management and processing behaviours. The
resulting models can also be exchanged between systems. Applied to privacy, this will allow interoperating
systems to exchange and agree on information such as privacy preferences and parental controls.
6.2 Privacy engineering models of interest
Table 1 lists a variety of models of interest for privacy engineering.

© ISO/IEC 2025 – All rights reserved
Table 1 — Models of interest for privacy
Models Description
Explains contexts and provides rationales for require-
Use case model
ments
System design System representation Explains architecture and allows for the identification of
model assets
Data flow model Explains where data are exchanged and processed
Governance model Explains roles and responsibilities
Policy and behavioural
Explains policies applied and behaviour
model
Threat model Specifies possible threats, impact and mitigation
a
De-identification model Provides a model of a de-identification technique
Privacy man-
agement
Usage protection model Explains how data usage is protected and enforced
Asset protection model Explains how data assets are protected
Explains how vulnerabilities are monitored and how
Resilience model
incidents are managed and recovered
Communication model Explains how privacy management is communicated
Evidence creation model Explains how evidence for privacy assurance is created
Assurance
Evidence verification
Explains how evidence for privacy assurance is verified
model
Risk management pro- Common approach for privacy risk management (identi-
cess fication of threats and resulting controls)
Design operationalization Common approach for privacy operationalization at
Lifecycle pro-
process design level
cess
Operation process Common approach at operational level
Resilience process Common approach for privacy resilience
Assurance process Common approach for privacy assurance
Set of system Collaboration model Explains how privacy is dealt with in a set of systems
between systems
Regulation Compliance model Explains how compliance constraints are met
a
A de-identification technique transforms a data set with the objective of reducing the extent to
which information can be associated with individual data principals.
6.3 Privacy engineering supported by MBSSE
Figure 4 shows how privacy engineering can be supported by MBSSE:
— the engineering lifecycle includes a project independent phase and a project specific phase;
— during the project independent phase, an organization:
— identifies the modelling language to use,
— specifies regulatory constraints models, and
— tailors the model to its context;
— during the project dependent phase, the organization:
— instantiates models in the project,
— transforms models into privacy compliant models by integrating patterns, and
— validates the transformed model.

© ISO/IEC 2025 – All rights reserved
Figure 4 — Engineering lifecycle context
[2]
Table 2 shows how the MBSSE processes specified in ISO/IEC/IEEE 24641 and shown in Figure 3 can be
customised for privacy engineering.
NOTE The table lists specific privacy engineering outcomes. General outcomes are described in
ISO/IEC/IEEE 24641.
Table 2 — Customization of ISO/IEC/IEEE 24641 to privacy engineering
ISO/IEC/IEEE 24641 processes Application Outcome
Identify privacy engineering concerns coming from
Define the scope Understanding of pri-
regulations, standards, principles, corporate poli-
PL1 and objectives vacy constraints and
cies, manifestos to be addressed and the depth and
of MBSSE risks
breadth of models to be produced.
Plan
MBSSE
Develop a privacy model strategy, schedule and pro-
Integration of privacy
Plan model de-
cedure for model building, reviewing, use and re-use,
engineering activities
PL2 velopment and
risk mitigation, benefit and risk tracking.
in the development and
governance
governance process
Develop a governance model approach.
Plan resources and assets, including tool chains (e.g.
modelling languages, software development tools), Integration of suitable
Plan resources
PL3 and repositories (e.g. for privacy threat models, pri- resources for privacy
and assets
vacy protection models/patterns, privacy preference engineering
management models)
Define approach to reuse existing privacy models
Continuous improve-
Manage knowl-
Define how to build privacy models in a reusable
PL4 ment on privacy engi-
edge reuse
way and how to reuse the knowledge about or from
neering
elements: models/patterns, methods and tools
Produce system Produce relevant system models, e.g. data structural
BM1 Privacy-by-design
models model
Produce relevant privacy models, e.g. data models
Produce disci-
enriched with privacy attributes, threat models, min-
BM2 pline-specific Privacy-by-design
imization models, unlinkability models, transparen-
models
cy models, intervenability models, assurance models
Key
PL  plan
BM  build model
SM  support model
PE  perform
© ISO/IEC 2025 – All rights reserved
TTabablele 2 2 ((ccoonnttiinnueuedd))
ISO/IEC/IEEE 24641 processes Application Outcome
Ensure that privacy models satisfy objectives and
requirements that represent the stakeholders' needs
and comply with conventions described by modelling
BM3 Verify models
guides.
NOTE 1 Modelling guides can be provided by a com-
Build
munity.
models
Ensure that privacy enriched models fulfill the needs
of the relevant stakeholders.
BM4 Validate models
Privacy verification
NOTE 2 Validation can be fully or partially done at a
and validation
community level.
Animate, simulate, execute privacy enriched models
Simulate
BM5 systems using
EXAMPLE 1 Digital twin running a privacy ance-
models
ancing technology using synthetic data.
Using suitable and justified criteria, and simulation
results, examine viable alternatives.
Evaluate alter-
BM6
native models
EXAMPLE 2 Selecting configuration parameters
in a privacy enhancing technology.
Manage techni- Manage and assess privacy enriched model quality Quality assurance on
SM1
cal quality and how to improve the quality of the system privacy engineering
Perform configuration management of privacy en-
Configuration man-
riched models
Manage config-
SM2 agement for privacy
uration
EXAMPLE 3 The same privacy model can have
engineering
different variants.
Manage the consistency of privacy enriched models
used in organization’s project
Privacy enriched mod-
EXAMPLE 4 Keeping track of parameters and
els used for compliance
Support Manage data
version of a privacy model used in a project.
SM3 to foster organisation-
models and models
al rigor and technical
EXAMPLE 5 Composability of abstract and con-
rigor
crete models.
[27]
EXAMPLE 6 Task, knowledge, skills models.
Make available and distribute privacy enriched
models to relevant stakeholders in a distributed
Sharing and distribut-
environment if possible
Share models
ing abstract models on
SM4 for collabora- EXAMPLE 7 A privacy threat model can be devel-
privacy for interoper-
tion oped and published in a system of systems involving
ability
multiple organizations.
EXAMPLE 8 Shared models are patterns.
Define and apply policies for the integration of pri-
vacy models in the operations of the organization,
Perform busi-
including definition of capabilities, monitoring of
PE1 ness and mis- Privacy use cases
model progress and evaluation of model maturity.
sion analys
...