ISO/IEC 29101:2018
(Main)Information technology - Security techniques - Privacy architecture framework
Information technology - Security techniques - Privacy architecture framework
This document defines a privacy architecture framework that: - specifies concerns for ICT systems that process PII; - lists components for the implementation of such systems; and - provides architectural views contextualizing these components. This document is applicable to entities involved in specifying, procuring, architecting, designing, testing, maintaining, administering and operating ICT systems that process PII. It focuses primarily on ICT systems that are designed to interact with PII principals.
Technologies de l'information — Techniques de sécurité — Architecture de référence pour la protection de la vie privée
Le présent document définit une architecture de référence pour la protection de la vie privée qui: — spécifie les enjeux des systèmes TIC ayant à traiter des DCP; — énumère les éléments nécessaires à la mise en œuvre de tels systèmes; et — fournit des vues de l'architecture contextualisant ces éléments. Le présent document s'applique aux entités participant à la spécification, à la fourniture, à l'architecture, à la conception, aux essais, à la maintenance, à l'administration et à l'exploitation des systèmes TIC qui traitent des DCP. Il se concentre principalement sur les systèmes TIC conçus pour interagir avec les personnes concernées.
General Information
Relations
Overview
ISO/IEC 29101:2018 - Privacy architecture framework defines a high-level architecture for safeguarding personally identifiable information (PII) in information and communication technology (ICT) systems. It specifies the concerns that must be considered when processing PII, lists components for implementing privacy-aware systems, and provides multiple architectural views (component, actor/deployment, interaction) to contextualize those components. The standard is intended for entities involved in specifying, procuring, architecting, designing, testing, maintaining, administering and operating ICT systems that interact with PII principals.
Key technical topics and requirements
- Privacy concerns and principles: Builds on ISO/IEC 29100 by mapping privacy principles and defining privacy safeguarding requirements specific to ICT systems that process PII.
- PII lifecycle coverage: Addresses lifecycle phases including collection, transfer, use, storage, and disposal of PII.
- Architecture layers and components: Organizes privacy-related functionality into layers (for example, privacy settings, identity and access management, and the PII layer) and describes components relevant to each layer.
- Actors and deployment views: Describes ICT systems from the perspectives of the PII principal, PII controller, and PII processor, and shows how PII flows between these actors.
- Interaction view: Illustrates component-to-component interactions and how privacy controls operate across system boundaries.
- Privacy-enhancing technologies (PETs): Shows how PETs can be used as privacy controls within the architecture.
- Correspondence and mapping: Provides mapping tables tying concerns to viewpoints and components to help implementers trace requirements to architecture.
- Standards alignment: Uses ISO/IEC/IEEE 42010 for architecture description and explicitly ties to privacy management practices and information security engineering.
Practical applications - who uses this standard
- System architects and privacy engineers - design privacy-aware ICT architectures and select appropriate components/PETs.
- Security architects and developers - integrate identity, access management and data protection controls into system designs.
- Procurement and vendors - specify and evaluate privacy requirements in product RFPs and procurements.
- Compliance officers and auditors - map organizational privacy safeguarding requirements to technical architecture.
- Operations and IT administrators - implement, test, and maintain privacy controls across deployment environments.
Related standards and further reading
- ISO/IEC 29100 - Privacy framework (principles and stakeholders)
- ISO/IEC/IEEE 42010 - Systems and software engineering - Architecture description
- Use ISO/IEC 29101 to bridge privacy policy/management decisions with concrete architectural controls and PETs when building or evaluating systems that process PII.
Keywords: ISO/IEC 29101:2018, privacy architecture framework, PII, PETs, ICT systems, privacy safeguarding, identity and access management, privacy engineering.
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 29101
Second edition
2018-11
Information technology — Security
techniques — Privacy architecture
framework
Technologies de l'information — Techniques de sécurité —
Architecture de référence de la protection de la vie privée
Reference number
©
ISO/IEC 2018
© ISO/IEC 2018
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
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2018 – All rights reserved
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 1
5 Overview of the privacy architecture framework . 1
5.1 Elements of the framework . 1
5.2 Relationship with management systems . 3
6 Actors and PII . 3
6.1 Overview . 3
6.2 Phases of the PII processing life cycle . 4
6.2.1 Collection . 4
6.2.2 Transfer . 5
6.2.3 Use . 5
6.2.4 Storage . 6
6.2.5 Disposal . 6
7 Concerns . 6
7.1 Overview . 6
7.2 The privacy principles of ISO/IEC 29100 . 6
7.3 Privacy safeguarding requirements . 7
8 Architectural views . 7
8.1 General . 7
8.2 Component view . 8
8.2.1 General. 8
8.2.2 Privacy settings layer . 9
8.2.3 Identity management and access management layer .12
8.2.4 PII layer .14
8.3 Actor view .19
8.3.1 General.19
8.3.2 ICT system of the PII principal .20
8.3.3 ICT system of the PII controller .20
8.3.4 ICT system of the PII processor .21
8.4 Interaction view .22
8.4.1 General.22
8.4.2 Privacy settings layer .22
8.4.3 Identity and access management layer .23
8.4.4 PII layer .23
Annex A (informative) Examples of the PII-related concerns of an ICT system .25
Annex B (informative) A PII aggregation system with secure computation .30
Annex C (informative) A privacy-friendly, pseudonymous system for identity and access
control management .37
© ISO/IEC 2018 – 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. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
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).
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 Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Security techniques.
This second edition cancels and replaces the first edition (ISO/IEC 29101:2013) which has been
technically revised. The main change compared to the previous edition is that old Annex D has been
removed.
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.
iv © ISO/IEC 2018 – All rights reserved
Introduction
This document describes a high-level architecture framework and associated controls for the
safeguarding of privacy in information and communication technology (ICT) systems that store and
process personally identifiable information (PII).
The privacy architecture framework described in this document:
— provides a consistent, high-level approach to the implementation of privacy controls for the
processing of PII in ICT systems;
— provides guidance for planning, designing and building ICT system architectures that safeguard the
privacy of PII principals by controlling the processing, access and transfer of personally identifiable
information; and
— shows how privacy enhancing technologies (PETs) can be used as privacy controls.
This document builds on the privacy framework provided by ISO/IEC 29100 to help an organization
define its privacy safeguarding requirements as they relate to PII processed by any ICT system. In some
countries, privacy safeguarding requirements are understood to be synonymous with data protection/
privacy requirements and are the subject of data protection/privacy legislation.
© ISO/IEC 2018 – All rights reserved v
INTERNATIONAL STANDARD ISO/IEC 29101:2018(E)
Information technology — Security techniques — Privacy
architecture framework
1 Scope
This document defines a privacy architecture framework that:
— specifies concerns for ICT systems that process PII;
— lists components for the implementation of such systems; and
— provides architectural views contextualizing these components.
This document is applicable to entities involved in specifying, procuring, architecting, designing,
testing, maintaining, administering and operating ICT systems that process PII.
It focuses primarily on ICT systems that are designed to interact with PII principals.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 29100, Information technology — Security techniques — Privacy framework
ISO/IEC/IEEE 42010, Systems and software engineering — Architecture description
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 29100 and ISO/IEC/
IEEE 42010 apply.
4 Symbols and abbreviated terms
The following abbreviations apply to this document.
ICT Information and Communication Technology
PET Privacy Enhancing Technology
PII Personally Identifiable Information
5 Overview of the privacy architecture framework
5.1 Elements of the framework
The privacy architecture framework presented in this document is intended as a technical reference
for developers of ICT systems that process PII. This document does not set requirements for privacy
policies; it assumes that a privacy policy is in place and that privacy safeguarding requirements have
been defined and that appropriate safeguards are implemented within the ICT system.
© ISO/IEC 2018 – All rights reserved 1
This architecture framework focuses on the protection of PII. Since this is partly a security goal,
ICT systems processing PII should also follow information security engineering guidelines. This
architecture framework lists some information security components that are critical for safeguarding
PII processed within ICT systems. The architecture framework presented is based on the model used in
ISO/IEC/IEEE 42010.
The stakeholders related to these concerns are the privacy stakeholders defined in ISO/IEC 29100. They
are discussed in more detail in Clause 6.
The concerns for the architecture framework are described in Clause 7 and include the privacy
principles of ISO/IEC 29100 and privacy safeguarding requirements specific to an ICT system.
The architecture framework is presented as follows:
a) the layers of the technical architecture framework in 8.2 show the architecture from a component
viewpoint. Each layer groups components with a common goal or a similar function;
b) the deployment model in 8.3 shows the architecture framework from a standalone ICT system
viewpoint. Each view shows a grouping of the components based on their deployment in the
stakeholders’ ICT systems; and
c) the views in 8.4 show the architecture framework from an interaction viewpoint. The views
illustrate how the components interact between ICT systems of different stakeholders.
The architecture framework also presents correspondence rules between the concerns and viewpoints
through the use of mapping tables.
Figure 1 — Elements of the privacy architecture framework in context
Figure 1 illustrates the relationship between the elements of the privacy architecture framework.
The central element of the architecture framework is the ICT system being built. An ISO/IEC 29101
actor uses the ICT system. The design of the ICT systems is affected by both concerns addressed in this
document and also other concerns. Examples of other concerns include non-functional requirements
that affect the performance, accessibility and design of the ICT system and do not affect the functional
processing of PII. These other concerns are out of the scope of this document.
The ICT system can contain components from the privacy architecture framework of this document as
well as other components. These components do not process PII, but instead handle other functionality
in the ICT system like providing accessibility or rendering special user interfaces. Such components are
out of the scope of this document.
2 © ISO/IEC 2018 – All rights reserved
5.2 Relationship with management systems
The use of a management system enables PII controllers and processors to more effectively meet
their privacy safeguarding requirements using a structured approach. This structured approach also
provides PII controllers and processors the ability to measure outcomes and continuously improve the
management system’s effectiveness.
An effective management system is as transparent as possible but still impacts people, processes
and technology. It should be part of the internal control program and risk mitigation strategy of an
organization and its implementation helps to satisfy compliance with data protection and privacy
regulations.
6 Actors and PII
6.1 Overview
The actors of the ISO/IEC architecture framework are the privacy stakeholders involved in PII
processing described in ISO/IEC 29100. These actors are:
a) the PII principal;
b) the PII controller; and
c) the PII processor.
NOTE The “third party” defined as one of the four categories of the actors in ISO/IEC 29100 is out of the
scope of the architecture framework specified in this document.
From the deployment viewpoint, the architecture framework is divided into three parts. Each part
applies to the ICT system deployed from the viewpoint of each of these actors.
Figure 2 shows the ICT systems of the actors and the flows of PII between these ICT systems. It illustrates
the logical division of functionality for the architecture framework described in this document. It is
not intended as a representation of the physical structure, organisation or ownership of ICT system
hardware.
Figure 2 — Actors and their ICT systems according to this document
An actor can be responsible for building the ICT systems that it uses, or not. For example, the PII principal
can use a system built by and the responsibility of the PII controller or the ICT system of the PII principal
can be a part of the ICT system of the PII controller. Furthermore, the functionality of the ICT system
© ISO/IEC 2018 – All rights reserved 3
of the PII principal can be split across different ICT hardware systems owned by the PII principal and
the PII controller. Similarly, the PII controller can provide the ICT system of the PII processor. Business
processes in which ICT systems are employed use a wide range of communication and trust models. The
architecture framework in this document builds on an abstraction of these models.
If the PII principal is using a privately owned ICT system, the other privacy stakeholders can impose
requirements on this ICT system. For example, the ICT system of the PII principal can have to meet a
minimum baseline of security requirements to be allowed to connect to the other ICT systems. Other
examples include the use of special security components like hardware authentication tokens, certain
operating system versions or special web browser versions.
For example, in ICT systems employing peer-to-peer communications (communication method,
communication model or communication technology featuring communication in between/among the
entities that are peer to each other without central servers), every application can take the roles of
all three listed actors. Information is both sent and received by each peer, so each peer can be a PII
controller or processor for PII transferred by another party in the role of a PII principal.
In social networking applications, PII can be processed by anyone with access to other people's profiles.
Web-based social networking applications allow all the authorized and possible anonymous users of
the service to process PII provided by the PII principals connected to the social network.
6.2 Phases of the PII processing life cycle
6.2.1 Collection
Many organizations collect information from PII principals. This information can contain PII.
When collecting PII, organizations should always consider the privacy preferences and legal rights of
the PII principal and privacy safeguarding requirements as stated by applicable law. Factors such as
the type of PII, consent given, or any privacy preferences stated need to be considered throughout all
stages of processing. PII should only be collected if it is needed for the declared purposes.
Documentation should be associated with the PII. Examples include, but are not limited to:
a) software tags that state the purpose(s) the PII can be used for;
b) records describing the purpose(s) that PII can be used for; and
c) records of the consent given and any specific sensitivities that should be observed (e.g., certain PII
categories should be encrypted or deleted after a certain period of time).
Privacy controls should be implemented wherever data is tagged as PII or wherever PII is marked
with additional information concerning the PII principal. It is also important to preserve tags that are
relevant to processing PII during the usage, transfer, storage and disposal phases. If stored PII are likely
to have been modified, it should be validated for accuracy and currency before use.
In addition, PII collection processes should be designed to collect only the PII that is necessary for
the respective transaction. Organizations should take steps to minimize the inadvertent/unintended
collection of PII through data entry systems (e.g., web application forms that allow the entry of any
information). The entry of arbitrary PII should be minimized through the use of context-specific display
of input fields reducing or eliminating areas in the web form where this information can be entered (e.g.,
removing unnecessary check boxes and free text fields). In addition, the use of fields with predefined
entries (e.g., list boxes and drop-down lists), containing non-PII options, should be considered. When
free form text fields are necessary, the User Interface (UI) should provide:
a) warnings to alert the PII principal not to enter PII other than that which is explicitly asked for and
consented to or required by applicable law;
b) clear indication of those fields where PII is to be entered and what PII should be entered (e.g. name,
address, health information); and
4 © ISO/IEC 2018 – All rights reserved
c) clear indication of those fields where PII should not be entered.
6.2.2 Transfer
Transferring, disseminating, or releasing PII to others means that the PII is no longer under the sole
control of the PII principal. Transfer is usually the term given for dissemination of PII from the PII
controller or PII processor to other PII controllers and processors. If PII is transferred from the PII
controller to another actor, transfer is sometimes also referred to as disclosure.
Accountability and responsibility for the transferred PII should be agreed on and maintained by each
party involved in the PII processing. This agreement should be in writing where required by applicable
law. Furthermore, such agreements need to be compliant with data protection legislation in the source
and destination domains of the transfers. When relevant and appropriate, or when legally required to
do so, the PII principal should be notified that transfer is taking place and should be informed of the
content and purpose of the transfer. If a dispute occurs between the PII principal and the PII controller
or PII processor, records of relevant PII transfer transactions should be available to assist in resolving
any such dispute.
The transfer of sensitive PII should be avoided unless it:
— is necessary to provide a service that the PII principals has requested;
— fulfils a business requirement for offering the requested service; or
— is required by law.
Some jurisdictions have instituted laws that specifically require formal contractual agreements that
include all privacy safeguarding requirements between the involved parties when PII is transferred
outside a jurisdiction that has a prescribed level of privacy protection. Where cross-border transfers
are used, particular attention should be given to protection measures for the PII being transferred.
Appropriate protection mechanisms should be in place during the transfer of PII. In the case of a digital
transfer, PII should be transmitted over a secure channel or in encrypted form if the transmission is
over an insecure channel. If PII is transferred on physical media, it should be encrypted. If encryption is
used, the encryption key should not be stored or transmitted together with the encrypted PII.
6.2.3 Use
Using PII means any form of PII processing that does not include “collect”, “transfer”, “store”, “archive”
or “dispose”. The privacy principles described in ISO/IEC 29100 (Privacy Framework), as well as some
data protection and privacy laws, can limit the processing of PII if that processing is incompatible with
the originally specified purposes. Therefore, PII should only be processed for the declared purposes for
which it was collected.
If the PII is to be processed for any other purpose that is not covered by applicable law, consent should be
obtained from the PII principal or his agent. The PII principal should be provided a means for contacting
the PII controller or processor in the event there are any questions about any activities about which the
PII principals is unclear.
Where such processing is considered necessary the consent of the PII principal should be obtained
unless otherwise permitted by law. PII principals should be provided clear notice about the specific use
of the PII.
Additionally, protection mechanisms appropriate to the usage of PII should be applied as deemed
necessary by a thorough risk analysis. This includes the use of anonymization or pseudonymization
techniques prior to processing and the use of secure computation techniques during processing.
© ISO/IEC 2018 – All rights reserved 5
6.2.4 Storage
When it is necessary to store PII, the consent of the PII principal should be obtained, taking into account
any specific measures that can be required by law. In such cases, the PII should be stored only for the
amount of time necessary to achieve the specific business purpose.
PII should be stored with appropriate controls and mechanisms to prevent unauthorized access,
modification, destruction, removal, or other unauthorized use. Such controls include, but are not limited
to, encryption, secret sharing, pseudonymization and anonymization.
Archived PII needs careful attention. The privacy principles state that PII should be retained only as
long as necessary to fulfil the stated purposes and then be securely destroyed or anonymized. However,
if the PII controller or PII processor is required by applicable law to retain PII after the other purposes
have expired, the PII should be locked (i.e., archived and protected with an access control mechanism
to prevent further usage). The primary considerations in archiving PII should be to ensure that the
appropriate data protection mechanisms are in place, including access management solutions that
provide access to archived PII only to authorized users.
The PII controller should implement controls in storage systems to dispose of PII when it expires or
when the purpose for the storing or processing of the PII is no longer valid.
6.2.5 Disposal
In the final stage of the PII processing life cycle, PII gets deleted, anonymized, destroyed, returned or
disposed of in some other way. Specific PII within PII records can get locked from unauthorized use
by marking it for disposal. It should be noted that deleting PII does not necessarily mean that the PII is
ultimately disposed of because PII deleted in ICT systems can often be recovered. Although it can seem
to be an obvious task in PII handling, procedures concerning disposal of PII sometimes do not comply
with privacy safeguarding requirements. Specifications given by the PII principal (e.g., usage purpose)
or requirements specified by legislation (e.g., expiration date for specific PII) should be considered
before PII is disposed of.
7 Concerns
7.1 Overview
A concern as defined in ISO/IEC/IEEE 42010 is an interest in a system relevant to one or more of its
stakeholders. The privacy architecture framework in this document focuses on concerns of the privacy
stakeholders related to the processing of PII. The concerns in this document include the privacy
principles of ISO/IEC 29100 and any privacy safeguarding requirements derived from and complying
with these principles.
The privacy safeguarding requirements should be determined by following a privacy risk management
process complying with the process described in ISO/IEC 29100:2011, 4.5. Any individual or
organization that is designing an ICT system that processes PII should follow this process. All the
identified privacy safeguarding requirements should conform to applicable privacy legislation.
7.2 The privacy principles of ISO/IEC 29100
The PII controller is responsible for the protection of PII and the fair and lawful handling of it at all
times, throughout the organization, as well as for PII processing outsourced to PII processors.
The PII controller is ultimately responsible for implementing privacy controls in an ICT system. Privacy
controls are intended to ensure that the privacy safeguarding requirements set for a specific PII
principal, transaction, or scenario are addressed and consistently fulfilled. Evidence of implementation
should be provided by properly documenting the privacy controls that are in place and providing audit
documents that verify that the controls exist, that they have been implemented correctly and that
6 © ISO/IEC 2018 – All rights reserved
they are functioning properly. Ultimately, the PII controller should accept and adhere to the privacy
principles that are described in ISO/IEC 29100.
a) consent and choice;
b) purpose legitimacy and specification;
c) collection limitation;
d) data minimization;
e) use, retention and disclosure limitation;
f) accuracy and quality;
g) openness, transparency and notice;
h) individual participation and access;
i) accountability;
j) information security; and
k) privacy compliance.
7.3 Privacy safeguarding requirements
ICT systems should implement privacy controls as a primary element in every phase of the PII
processing life cycle. The privacy safeguarding requirements enable the designer of the ICT system
to operationalize the link between privacy principles and the architectural components laid down in
Clause 8.
In order to implement effective privacy controls in an ICT system, PII processing flows describing the PII
processing should be created. PII processing flow diagrams are a graphical representation of the “flow”
of PII through the ICT system and between the different actors. For example, if an actor transfers PII
to other actors (e.g., PII processors) the PII processing flow diagram should include those PII transfers.
A PII processing flow diagram can also be represented as a PII flow table. This diagram or table follows
the collection, transfer, use, storage or disposal of PII and includes information such as the type of PII,
who collected the PII, the purpose for processing, to whom the PII is going to be transferred, the receipt
of consent by the PII principal, the retention period and at which location it is stored and the resulting
privacy risk level. The PII processing flow information is an input to the privacy risk management
process that outputs the privacy safeguarding requirements.
After the requirements analysis of an ICT system has been completed, the developers should cross-
reference the privacy safeguarding requirements of the ICT system with the list of concerns in this
document. The privacy safeguarding requirements should then be used for choosing the architectural
components that satisfy said requirements.
Annex A contains an example list of concerns and illustrates how to link concerns to the privacy
principles of ISO/IEC 29100 and the architectural components of this document.
8 Architectural views
8.1 General
The architectural views in this clause are structured into three views. First, the component view
describes the ICT system components in detail and separates them into layers based on their
functionality. Each layer groups components that help to contribute to the proper processing of PII.
Limited implementation guidance is given for each component. Actor-specific guidance is given where
© ISO/IEC 2018 – All rights reserved 7
applicable. This view is helpful for understanding the building blocks in the privacy architecture
framework.
Tables showing examples of typical relationships between the privacy principles of ISO/IEC 29100
and the components of the architecture are provided in the component view. Such mapping tables
are helpful for understanding how an ICT system adheres to the privacy principles of ISO/IEC 29100.
Similar tables can be used as examples and updated during system design to describe how a particular
ICT system adheres to the privacy principles in ISO/IEC 29100.
The actor view looks at the components described in the component view from the perspective of the
ICT system of an individual actor. This view is helpful in the design of the architecture of a particular
ICT system. The interaction view looks at the components from a deployment perspective. This view is
helpful for understanding how components in the ICT systems of different actors interact with each other.
8.2 Component view
8.2.1 General
The component view is meant to describe ICT system components that are involved in the
processing of PII.
The choice of components should be guided by the appropriate privacy safeguarding requirements.
The developer of the ICT system for a specific actor(s) (see Figure 2) should use the component view
to determine the components that need to be included in the architecture of the system that they are
developing. This architecture should be based on the privacy safeguarding requirements established
using the guidance given in Clause 7. Note that not all components described in this document are
necessarily appropriate in a particular ICT system.
The component view is presented in three layers. Each layer is a logical group of components that
contribute to a specific goal in the processing of PII. Components in the privacy settings layer handle
the management of metadata about PII processing including, among others, the exchange of information
on the purpose of processing, consent and preferences of the PII principal. Components in the identity
and access management layer are responsible for ensuring that proper identity information is used in
PII processing and access to the PII is controlled according to the privacy safeguarding requirements.
Finally, components in the PII layer perform various tasks to process the PII.
The architecture framework is designed with the assumption that all components interact with several
other components. However, in order to maintain generality and readability, the possible interactions
between components have been omitted from the representation.
Some of the components in the architecture framework are Privacy Enhancing Technologies (PETs).
This selection of PETs is not comprehensive. Other PETs exist, that are not described in this document
and the developer of the ICT system is responsible for choosing appropriate PETs and adapting them to
this architecture framework.
Annex B gives an example of an ICT system architecture that applies PETs for securely processing PII.
Annex C gives an example of how to use attribute-based credentials to build an ICT system that provides
pseudonymous identity and access control management.
The following subclauses describe the layers, the components within them and the actors that interact
with the components. A general description of each component is given and it is followed by actor-
specific guidelines. For some components, no guidance specific to the ICT systems of a particular actor
is given, as the behaviour of the component is similar in the ICT systems of all actors.
8 © ISO/IEC 2018 – All rights reserved
8.2.2 Privacy settings layer
8.2.2.1 General
The privacy settings layer comprises components that communicate the system privacy policy to the
relevant actors and implement the system privacy safeguarding requirements. These components
let the ICT system communicate the system privacy policy and implement the corresponding privacy
safeguarding measures.
In addition, the components in this layer should convey to the PII controller and PII processor any
privacy preferences and consent information that have been collected from the PII principal.
8.2.2.2 Policy and purpose communication
— General: This component is responsible for relaying information, including updates, about the
privacy policy of the PII controller and the purpose of PII collection to the ICT systems of privacy
stakeholders.
The communicated information should contain at least the following:
a) the identities of the PII controllers and any associated PII processors;
b) policies regarding the transfer of PII to PII processors;
c) the use of privacy enhancing technologies (such as anonymization) with their respective goals;
d) the purposes for which the PII is collected;
e) identification of the PII to be collected; and
f) the legal rights of the PII principal to access their PII to determine the extent of the PII stored
and to check for and correct any inaccuracies, and the procedures for doing so.
— PII principal: The policy and purpose communication component of the ICT system of the PII
principal should:
a) receive policy and purpose information from the corresponding component in the ICT system
of the PII controller;
b) interpret the received information and display or otherwise convey to the PII principal in a
clearly comprehensible manner its meaning;
c) offer the PII principal the opportunity to locally store the received information; and
d) confirm to the PII controller that the policy and purpose information has been received by the
PII principal.
— PII controller: The policy and purpose communication component of an ICT system under the control
of the PII controller should:
a) store policy and purpose information that has been conveyed to PII principals;
b) log the acts of conveying policy and purpose information to PII principals in such a way that it
can be established which information was current and was conveyed to PII principals at which
time, along with confirmation of receipt of this information;
c) convey the current policy and purpose information to the corresponding component of the
ICT system of the PII principal in such a manner that it can be used by this system directly to
inform the PII principal in a complete and comprehensible manner, or that it can be mapped by
said component to such a form by some pre-defined mapping;
© ISO/IEC 2018 – All rights reserved 9
d) convey a reference to the displayed policy and purpose information to those components which
handle the storage of consent information and storage of PII itself; and
e) transmit updates about changes to policy and purpose information to the corresponding
components of the ICT systems belonging to those PII principals who have consented to receive
such information.
— PII processor: The ICT system of the PII processor typically should receive digital copies of the
privacy policy and the processing purpose from the ICT system of the PII controller. The ICT system
of the PII processor should present the privacy policy and processing purpose documentation
received from the PII controller in a clearly comprehensible form to everyone with access to PII
governed by that policy.
The PII controller can arrange the processing of PII by various PII processors. The purpose
communication component in the ICT system of the PII controller should transmit the purpose
associated with the PII provided to all relevant PII processors. Each PII processor should be
informed of the purpose(s) for processing the PII.
8.2.2.3 PII categorization
— General: An ICT system processing PII has to be aware of the categories of PII that it processes
so that it can distinguish between different types of data (e.g., sensitive PII, PII and non-PII). This
is necessary for services processing PII differently depending on category. Additionally, the ICT
system should be aware of PII values that contain direct identifiers such as names and social security
numbers. This component should implement the functions that provide such a categorization in the
ICT system.
When dealing with non-PII, the risk of combining non-PII to infer or derive an identity or profile of a
unique user or at least small enough subset of users should be understood and evaluated.
All PII should be categorized correctly in order that it is processed and stored by the ICT system
in accordance with its marked sensitivity. If PII has been unknowingly collected, e.g. as a result
of unsolicited input, it may not be possible to do this and measures should, therefore, be taken to
minimize the possibility of unsolicited PII collection.
While the ICT system should be aware of PII values that contain direct identifiers such as names
and social security numbers, it may not be possible to do this if unsolicited PII has been collected.
— PII principal: The ICT system of the PII principal should be capable of identifying the categorization
marking associated with the PII and should process the PII in accordance with its category. The
categorisation can also be used to identify the PII that should be protected using PETs (e.g. sensitive
PII). The PII categorization component also provides further categorization of the PII into sub-
categories where sub-categories are a requirement of a specific application domain.
— PII controller: The ICT system of the PII controller should contain a comprehensive categorization of
PII used in the ICT systems processing the categorized PII. This information should be transmitted
to PII processors. Also, this categorization can be used by the audit logging, PII pseudonymization,
PII disclosure and PII archiving and retention components so they can determine which parts of the
data contain PII.
— PII processor: The ICT system of the PII processor should be capable of processing the PII
categorization associated with the received PII. The information should be used in PII auditing and
secure PII processing.
8.2.2.4 Consent management
— General: Consent of the PII principal is an important prerequisite
...
NORME ISO/IEC
INTERNATIONALE 29101
Deuxième édition
2018-11
Technologies de l'information —
Techniques de sécurité — Architecture
de référence pour la protection de la
vie privée
Information technology — Security techniques — Privacy
architecture framework
Numéro de référence
© ISO/IEC 2018
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO/IEC 2018
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique,
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
Fax: +41 22 749 09 47
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii
© ISO/IEC 2018 – Tous droits réservés
Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d'application .1
2 Références normatives .1
3 Termes et définitions . 1
4 Symboles et abréviations .1
5 Vue d'ensemble de l'architecture de référence pour la protection de la vie privée .2
5.1 Éléments constitutifs de l'architecture . 2
5.2 Relation avec les systèmes de gestion . 3
6 Acteurs et données à caractère personnel (DCP) . 3
6.1 Vue d'ensemble . 3
6.2 Phases du cycle de vie du traitement des DCP . 4
6.2.1 Collecte . 4
6.2.2 Transfert . 5
6.2.3 Utilisation . 6
6.2.4 Conservation . 6
6.2.5 Élimination . 7
7 Enjeux . 7
7.1 Vue d'ensemble . 7
7.2 Les principes de protection de la vie privée de l'ISO/IEC 29100 . 7
7.3 Exigences de protection de la vie privée . 8
8 Vues de l'architecture . .8
8.1 Généralités . 8
8.2 Vue Éléments . 9
8.2.1 Généralités . 9
8.2.2 Couche Paramètres de protection de la vie privée . 10
8.2.3 Couche Gestion des identités et des accès . 14
8.2.4 Couche DCP . 16
8.3 Vue Acteurs . 22
8.3.1 Généralités .22
8.3.2 Système TIC de la personne concernée . 22
8.3.3 Système TIC du responsable de traitement des DCP .23
8.3.4 Système TIC du sous-traitant de DCP . 24
8.4 Vue Interactions . 25
8.4.1 Généralités . 25
8.4.2 Couche Paramètres de protection de la vie privée . 26
8.4.3 Couche Gestion des identités et des accès . 26
8.4.4 Couche DCP . 26
Annexe A (informative) Exemples d'enjeux liés aux DCP d'un système TIC .28
Annexe B (informative) Système d'agrégation des DCP avec calcul sécurisé .33
Annexe C (informative) Système pseudonyme de gestion des identités et du contrôle
d'accès, respectueux de la vie privée .40
iii
© ISO/IEC 2018 – Tous droits réservés
Avant-propos
L'ISO (Organisation internationale de normalisation) et l'IEC (Commission électrotechnique
internationale) forment le système spécialisé de la normalisation mondiale. Les organismes
nationaux membres de l'ISO ou de l'IEC participent au développement de Normes Internationales
par l'intermédiaire des comités techniques créés par l'organisation concernée afin de s'occuper des
domaines particuliers de l'activité technique. Les comités techniques de l'ISO et de l'IEC collaborent
dans des domaines d'intérêt commun. D'autres organisations internationales, gouvernementales et non
gouvernementales, en liaison avec l'ISO et l'IEC participent également aux travaux. Dans le domaine des
technologies de l'information, l'ISO et l'IEC ont créé un comité technique mixte, l'ISO/IEC JTC 1.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier de prendre note des différents
critères d'approbation requis pour les différents types de documents ISO. Le présent document
a été rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2
(voir www.iso.org/directives).
L'attention est attirée sur le fait que certains des éléments du présent document peuvent faire l'objet
de droits de propriété intellectuelle ou de droits analogues. L'ISO et l'IEC ne sauraient être tenues pour
responsables de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails
concernant les références aux droits de propriété intellectuelle ou autres droits analogues identifiés
lors de l'élaboration du document sont indiqués dans l'Introduction et/ou dans la liste des déclarations
de brevets reçues par l'ISO (voir www.iso.org/brevets).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un
engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions
spécifiques de l'ISO liés à l'évaluation de la conformité, ou pour toute information au sujet de l'adhésion
de l'ISO aux principes de l’Organisation mondiale du commerce (OMC) concernant les obstacles
techniques au commerce (OTC), voir www.iso.org/avant-propos.
Le présent document a été élaboré par le comité technique ISO/IEC JTC 1, Technologies de l'information,
sous-comité SC 27, Sécurité de l'information, cybersécurité et protection de la vie privée.
Cette deuxième édition annule et remplace la première édition (ISO/IEC 29101:2013), qui a fait
l'objet d'une révision technique. La principale modification par rapport à l'édition précédente est que
l'ancienne Annexe D a été supprimée.
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes
se trouve à l’adresse www.iso.org/fr/members.html.
iv
© ISO/IEC 2018 – Tous droits réservés
Introduction
Le présent document décrit une architecture de référence de haut niveau ainsi que les mesures
associées visant à protéger la vie privée dans les systèmes de technologies de l'information et de la
communication (TIC) qui stockent et traitent des données à caractère personnel (DCP).
L'architecture de référence pour la protection de la vie privée décrite dans le présent document:
— fournit une approche cohérente et de haut niveau pour la mise en œuvre de mesures de protection
de la vie privée dans le cadre du traitement des DCP dans les systèmes TIC;
— fournit des recommandations pour la planification, la conception et l'élaboration d'architectures de
systèmes TIC visant à protéger la vie privée des personnes concernées en contrôlant le traitement,
l'accès et le transfert des informations personnelles identifiables; et
— indique comment les technologies renforçant la protection de la vie privée (PET) peuvent être
utilisées comme mesures de protection de la vie privée.
Le présent document s'appuie sur le cadre de protection de la vie privée fourni par l'ISO/IEC 29100 dans
le but d'aider une organisation à définir ses exigences en matière de protection de la vie privée, dans
la mesure où elles concernent les DCP traitées par un système TIC. Dans certains pays, les exigences
applicables en matière de protection de la vie privée sont considérées comme synonymes d'exigences
de protection des données/de protection de la vie privée et font l'objet d'une législation sur la protection
des données/la protection de la vie privée.
v
© ISO/IEC 2018 – Tous droits réservés
NORME INTERNATIONALE ISO/IEC 29101:2018(F)
Technologies de l'information — Techniques de sécurité
— Architecture de référence pour la protection de la vie
privée
1 Domaine d'application
Le présent document définit une architecture de référence pour la protection de la vie privée qui:
— spécifie les enjeux des systèmes TIC ayant à traiter des DCP;
— énumère les éléments nécessaires à la mise en œuvre de tels systèmes; et
— fournit des vues de l'architecture contextualisant ces éléments.
Le présent document s'applique aux entités participant à la spécification, à la fourniture, à l'architecture,
à la conception, aux essais, à la maintenance, à l'administration et à l'exploitation des systèmes TIC qui
traitent des DCP.
Il se concentre principalement sur les systèmes TIC conçus pour interagir avec les personnes concernées.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu’ils constituent, pour tout ou partie de leur
contenu, des exigences du présent document. Pour les références datées, seule l'édition citée s'applique.
Pour les références non datées, la dernière édition du document de référence s'applique (y compris les
éventuels amendements)
ISO/IEC 29100, Technologies de l'information — Techniques de sécurité — Cadre privé
ISO/IEC/IEEE 42010, Ingénierie des systèmes et des logiciels — Description de l’architecture
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions donnés dans l'ISO/IEC 29100 et
l'ISO/IEC/IEEE 42010 s'appliquent.
4 Symboles et abréviations
Les abréviations suivantes s'appliquent au présent document.
DCP Données à caractère personnel
PET Technologie contribuant à la protection de la vie privée (Privacy Enhancing Technology)
TIC Technologies de l'information et de la communication
© ISO/IEC 2018 – Tous droits réservés
5 Vue d'ensemble de l'architecture de référence pour la protection de la vie
privée
5.1 Éléments constitutifs de l'architecture
L'architecture de référence pour la protection de la vie privée présentée dans le présent document est
destinée à servir de référence technique aux développeurs de systèmes TIC devant traiter des DCP. Le
présent document ne fixe pas d'exigences en matière de politique de respect de la vie privée; il suppose
qu'une telle politique est en place, que les exigences de protection de la vie privée ont été définies et que
des mesures de protection appropriées ont été mises en œuvre au sein du système TIC.
Cette architecture de référence traite essentiellement de la protection des DCP. Étant donné qu'il s'agit
en partie d'un objectif de sécurité, il convient que les systèmes TIC ayant à traiter des DCP suivent
également les lignes directrices relatives à l'ingénierie de la sécurité de l'information. La présente
architecture de référence répertorie certains éléments de sécurité de l'information, qui sont essentiels
à la protection des DCP traitées au sein des systèmes TIC. L'architecture de référence présentée est
basée sur le modèle utilisé dans l'ISO/IEC/IEEE 42010.
Les parties prenantes liées à ces enjeux concernent la protection de la vie privée et sont définies dans
l'ISO/IEC 29100. Elles sont discutées plus en détail à l'Article 6.
Les enjeux de l'architecture de référence sont décrits à l'Article 7. Ils incluent les principes de protection
de la vie privée de l'ISO/IEC 29100 et les exigences de protection de la vie privée spécifiques aux
systèmes TIC.
L'architecture de référence est présentée comme suit:
a) les couches de l'architecture technique de référence décrites en 8.2 reflètent l'architecture du
point de vue des éléments. Chaque couche regroupe des éléments ayant un objectif commun ou des
fonctions similaires;
b) le modèle de déploiement exposé en 8.3 présente l'architecture de référence du point de vue
d'un système TIC autonome. Chaque vue illustre un regroupement d'éléments en fonction de leur
déploiement dans les systèmes TIC des parties prenantes; et
c) les vues du paragraphe 8.4 présentent l'architecture de référence d'un point de vue interactionnel.
Ces vues illustrent la manière dont les éléments interagissent entre les systèmes TIC des différentes
parties prenantes.
L'architecture de référence présente également des règles de correspondance entre les enjeux et les
points de vue, établies sur la base de tables de correspondance.
Figure 1 — Éléments de l'architecture de référence pour la protection de la vie privée dans leur
contexte
© ISO/IEC 2018 – Tous droits réservés
La Figure 1 illustre la relation entre les éléments d'une architecture de référence pour la protection de la
vie privée. L'élément central de l'architecture de référence est le système TIC intégré. Un acteur, au sens
de l'ISO/IEC 29101, utilise un système TIC. La conception des systèmes TIC est affectée à la fois par les
enjeux traités dans le présent document et, également, par d'autres enjeux. À titre d'exemples d'autres
enjeux, on peut citer les exigences non fonctionnelles qui affectent les performances, l'accessibilité et
la conception du système TIC, mais qui n'affectent pas le traitement fonctionnel des DCP. Ces autres
enjeux n'entrent pas dans le cadre du présent document.
Le système TIC peut contenir des éléments de l'architecture de référence pour la protection de la vie
privée détaillée dans le présent document ainsi que d'autres éléments. Ces éléments ne traitent pas
les DCP, mais gèrent d'autres fonctionnalités du système TIC, comme l'accessibilité ou le recours à des
interfaces utilisateur spécifiques. Ces éléments ne relèvent pas du domaine d'application du présent
document.
5.2 Relation avec les systèmes de gestion
L'utilisation d'un système de gestion permet aux responsables de traitement des DCP et aux sous-
traitants de DCP de répondre plus efficacement à leurs exigences de protection de la vie privée grâce à
une approche structurée. Cette approche structurée permet également aux responsables de traitement
des DCP et aux sous-traitants de DCP de mesurer les résultats et d'améliorer en permanence l'efficacité
du système de gestion.
Un système de gestion efficace doit être aussi transparent que possible, tout en ayant un impact sur les
personnes, les processus et la technologie. Il convient de l'intégrer au programme de contrôle interne et
à la stratégie d'atténuation des risques d'une organisation. Sa mise en œuvre permet de se conformer
plus facilement aux réglementations en matière de protection des données et de respect de la vie privée.
6 Acteurs et données à caractère personnel (DCP)
6.1 Vue d'ensemble
Les acteurs de l'architecture de référence ISO/IEC sont des parties prenantes en matière de protection
de la vie privée, impliquées dans le traitement des DCP décrit dans l'ISO/IEC 29100. Il s'agit des acteurs
suivants:
a) la personne concernée;
b) le responsable de traitement des DCP; et
c) le sous-traitant de DCP.
NOTE Le terme de «tiers» défini comme l'une des quatre catégories d'acteurs dans l'ISO/IEC 29100 est hors
du domaine d'application de l'architecture de référence spécifiée dans le présent document.
Sur le plan du déploiement, l'architecture de référence est divisée en trois parties. Chaque partie
s'applique au système TIC déployé du point de vue de chacun de ces acteurs.
La Figure 2 représente les systèmes TIC des acteurs ainsi que les flux de DCP entre ces systèmes. Elle
illustre la division logique des fonctionnalités au niveau de l'architecture de référence décrite dans le
présent document. Il ne s'agit pas d'une représentation de la structure physique, de l'organisation ou de
la propriété du matériel des systèmes TIC.
© ISO/IEC 2018 – Tous droits réservés
Figure 2 — Acteurs et leurs systèmes TIC au sens du présent document
Un acteur peut être responsable de la construction des systèmes TIC qu'il utilise, ou non. Par exemple, la
personne concernée peut utiliser un système construit par le responsable de traitement des DCP, ou le
système TIC de la personne concernée peut faire partie du système TIC du responsable de traitement des
DCP. En outre, les fonctionnalités du système TIC de la personne concernée peuvent être réparties entre
différents systèmes matériels TIC appartenant à la personne concernée et au responsable de traitement
des DCP. De même, le responsable de traitement des DCP peut fournir le système TIC du sous-traitant
de DCP. Les processus commerciaux ayant recours à des systèmes TIC utilisent un large éventail de
modèles de communication et de modèles de confiance. L'architecture de référence présentée dans le
présent document s'appuie sur une abstraction de ces modèles.
Si la personne concernée utilise un système TIC privé, les autres parties prenantes en matière de
protection de la vie privée peuvent imposer des exigences à ce système TIC. Par exemple, le système TIC
de la personne concernée peut devoir répondre à un minimum d'exigences de sécurité pour être
autorisé à se connecter aux autres systèmes TIC. On peut également citer l'utilisation d'éléments de
sécurité particuliers, tels que des jetons d'authentification matériels, certaines versions du système
d'exploitation ou des versions spécifiques de navigateur Web.
Par exemple, dans les systèmes TIC utilisant des communications poste-à-poste (méthode, modèle
ou technologie de communication permettant la communication entre des entités P2P sans serveur
central), chaque application peut assumer les rôles des trois acteurs susmentionnés. Les informations
sont à la fois envoyées et reçues par chaque poste, de sorte que chacun d'eux peut être responsable de
traitement de DCP ou sous-traitant de DCP préalablement transmises par une autre partie jouant le rôle
de personne concernée.
Dans les applications de réseaux sociaux, les DCP peuvent être traitées par toute personne ayant accès
au profil d'autres personnes. Les applications de réseaux sociaux utilisant le Web permettent à tous
les utilisateurs autorisés, et éventuellement anonymes, du service de traiter les DCP fournies par les
personnes concernées, connectées au réseau social.
6.2 Phases du cycle de vie du traitement des DCP
6.2.1 Collecte
De nombreuses organisations collectent des informations sur des personnes concernées. Ces
informations peuvent contenir des DCP.
Lorsqu'elles collectent des DCP, il convient que les organisations tiennent toujours compte des
préférences relatives à la vie privée et des droits légaux de la personne concernée, ainsi que des
© ISO/IEC 2018 – Tous droits réservés
exigences de protection de la vie privée, telles que stipulées par la législation en vigueur. Des facteurs
tels que le type de DCP, le consentement donné ou toute préférence exprimée en matière de respect de
la vie privée, doivent être pris en compte à toutes les étapes du traitement. Il ne convient de collecter
des DCP que si cela est nécessaire aux finalités déclarées.
Il convient d'associer une documentation aux DCP. On peut citer, sans s'y limiter, les exemples suivants:
a) balises logicielles indiquant la ou les finalités pour lesquelles les DCP peuvent être utilisées;
b) enregistrements décrivant la ou les finalités pour lesquelles les DCP peuvent être utilisées; et
c) enregistrements du consentement donné et de toute spécificité particulière qu'il convient de
respecter (par exemple, il convient de chiffrer certaines catégories de DCP ou de les supprimer
après un certain temps).
Il convient de mettre en œuvre des mesures de protection de la vie privée, chaque fois que des données
sont identifiées comme DCP ou que des DCP sont caractérisées par des informations supplémentaires
relatives à la personne concernée. Il est également important de préserver les balises pertinentes
pour le traitement des DCP pendant les phases d'utilisation, de transfert, de stockage et d'élimination.
Si des DCP stockées sont susceptibles d'avoir été modifiées, il convient d'en valider l'exactitude et la
pertinence avant de les utiliser.
En outre, il convient que les processus de collecte des DCP soient conçus de manière à ne recueillir
que les DCP nécessaires à la transaction concernée. Il convient que les organisations prennent des
mesures visant à réduire au minimum la collecte non intentionnelle ou involontaire de DCP grâce à des
systèmes de saisie de données (par exemple, formulaires d'applications Web permettant la saisie de
toute information). Il convient de limiter l'introduction de DCP arbitraires en prévoyant un affichage
contextuel des champs de saisie visant à réduire ou à éliminer les zones de formulaire Web où ces
informations peuvent être entrées (par exemple, en supprimant les cases à cocher et les champs de texte
libre inutiles). De même, il convient d'envisager l'utilisation de champs avec des entrées prédéfinies
(par exemple, boîtes à liste et listes déroulantes) contenant des options autres que DCP. Lorsqu'il y a
lieu d'implémenter des champs de texte libre, il convient que l'interface utilisateur prévoie:
a) des avertissements pour prévenir la personne concernée de ne pas saisir de DCP autres que celles
qui sont explicitement demandées et autorisées ou exigées par la loi en vigueur;
b) une indication claire des champs dans lesquels des DCP doivent être saisies et une indication de la
nature des DCP qu'il convient de saisir (par exemple, nom, adresse, informations médicales); et
c) une indication claire des champs où il convient de ne pas introduire de DCP.
6.2.2 Transfert
Le transfert, la diffusion ou la communication de DCP à des tiers signifie que les DCP ne sont plus sous
le contrôle exclusif de la personne concernée. Le transfert est le terme généralement employé pour
désigner la diffusion de DCP, depuis le responsable de traitement des DCP ou le sous-traitant de DCP vers
d'autres responsables de traitement et sous-traitants de DCP. Si les DCP sont transférées, du responsable
de traitement des DCP vers un autre acteur, le transfert est alors parfois appelé «divulgation».
Il convient que l'obligation de rendre compte et la responsabilité du transfert des DCP soient convenues
et assumées par chaque partie impliquée dans le traitement des DCP. Il convient que cet accord soit mis
par écrit lorsque la loi en vigueur l'exige. De plus, ces accords doivent être conformes à la législation sur
la protection des données dans les domaines d'origine et de destination des transferts. Lorsque cela
s'avère pertinent et approprié, ou lorsque la loi l'exige, il convient de notifier à la personne concernée
qu'un transfert est en cours et de l'informer du contenu et de la finalité du transfert. En cas de litige
entre la personne concernée et le responsable de traitement des DCP ou le sous-traitant de DCP, il
convient de pouvoir accéder aux relevés des transferts de DCP pertinents pour aider à résoudre un tel
litige.
© ISO/IEC 2018 – Tous droits réservés
Il convient d'éviter le transfert de DCP sensibles, sauf:
— s'il est nécessaire pour fournir un service que la personne concernée a demandé;
— s'il répond à une nécessité commerciale liée à la fourniture du service demandé; ou
— si la loi l'exige.
Certaines juridictions ont institué des lois qui exigent spécifiquement des accords contractuels formels
incluant toutes les exigences de protection de la vie privée entre les parties concernées, lorsque des
DCP sont transférées en dehors d'une juridiction ayant un niveau prescrit de protection de la vie privée.
En cas de transferts transfrontaliers, il convient d'accorder une attention particulière aux mesures de
protection des DCP transférées.
Il convient de mettre en place des mécanismes de protection appropriés lors du transfert de DCP. En cas
de transfert numérique, il convient que les DCP soient transmises par un canal sécurisé ou sous forme
chiffrée si la transmission se fait par un canal non sécurisé. Si les DCP sont transférées sur un support
physique, il convient alors de les chiffrer. Si l'on utilise un chiffrement, il convient de ne pas stocker, ni
transmettre la clé de chiffrement avec les DCP chiffrées.
6.2.3 Utilisation
L'utilisation de DCP désigne toute forme de traitement des DCP qui n'inclut pas la «collecte», le
«transfert», le «stockage», l'« archivage » ou l'« élimination » de DCP. Les principes de protection de
la vie privée décrits dans l'ISO/IEC 29100 (Cadre privé), ainsi que certaines lois sur la protection
des données et le respect de la vie privée, peuvent limiter le traitement des DCP si ce traitement est
incompatible avec les finalités spécifiées à l'origine. Il convient donc de ne traiter les DCP que dans le
cadre des finalités déclarées pour lesquelles elles ont été collectées.
Si les DCP doivent être traitées à d'autres fins qui ne sont pas couvertes par la loi en vigueur, il convient
d'obtenir le consentement de la personne concernée ou de son agent. Il convient de fournir à la personne
concernée un moyen de contacter le responsable de traitement des DCP ou le sous-traitant de DCP au
cas où la personne aurait des questions sur des activités nécessitant des éclaircissements.
Lorsqu'un tel traitement est jugé nécessaire, il convient d'obtenir le consentement de la personne
concernée, à moins que la loi n'en dispose autrement. Il convient d'informer clairement les personnes
concernées de l'utilisation spécifique de leurs DCP.
En outre, il convient d'appliquer des mécanismes de protection adaptés à l'utilisation des DCP, dans
la mesure où une analyse approfondie des risques les juge nécessaire. Cela inclut l'utilisation de
techniques d'anonymisation ou de pseudonymisation préalablement au traitement ainsi que le recours
à des techniques de calcul sécurisées pendant le traitement.
6.2.4 Conservation
Lorsqu'il est nécessaire de stocker des DCP, il convient d'obtenir le consentement de la personne
concernée, en tenant compte de toute mesure spécifique susceptible d'être exigée par la loi. Dans ces
cas, il convient de ne conserver les DCP que pendant le temps nécessaire à la réalisation de la finalité
professionnelle spécifique.
Il convient de stocker les DCP à l'aide de mesures de sécurité et de mécanismes appropriés afin
d'empêcher toute action non autorisée, qu'il s'agisse d'accès, de modification, de destruction, de
suppression ou de toute autre utilisation indue. De telles mesures de sécurité incluent, sans s'y limiter,
le chiffrement, le secret réparti, la pseudonymisation et l'anonymisation.
Les DCP archivées doivent faire l'objet d'une attention particulière. Les principes de protection de la vie
privée stipulent qu'il convient que les DCP ne soient conservées que le temps nécessaire à la réalisation
des finalités déclarées, puis qu'elles soient détruites par des moyens sûrs ou anonymisées. Toutefois,
si le responsable de traitement des DCP ou le sous-traitant de DCP est contraint, du fait de la loi en
vigueur, de conserver les DCP au-delà de l'expiration des autres finalités, il convient de verrouiller les
© ISO/IEC 2018 – Tous droits réservés
DCP (c'est-à-dire de les archiver et de les protéger par un mécanisme de contrôle d'accès pour éviter
toute utilisation ultérieure). Il convient avant tout, lors de l'archivage des DCP, de s'assurer que les
mécanismes appropriés de protection des données sont en place, y compris les solutions de gestion des
accès qui ne permettent l'accès aux DCP archivées qu'aux utilisateurs autorisés.
Il convient que le responsable de traitement des DCP mette en place des mesures de sécurité dans les
systèmes de stockage afin de pouvoir éliminer les DCP lorsqu'elles expirent ou lorsque la finalité du
stockage ou du traitement des DCP ne se justifie plus.
6.2.5 Élimination
Au cours de la dernière étape du cycle de vie du traitement des DCP, les DCP sont supprimées,
anonymisées, détruites, renvoyées ou éliminées d'une autre manière. Il est possible d'empêcher
toute utilisation non autorisée de certaines DCP dans des relevés de DCP en les marquant pour
élimination. Il convient de noter que la suppression de DCP ne signifie pas nécessairement que celles-
ci sont définitivement éliminées, car les DCP supprimées dans des systèmes TIC peuvent souvent
être récupérées. Bien que cela puisse sembler évident dans le traitement des DCP, les procédures
d'élimination des DCP ne satisfont pas toujours aux exigences de protection de la vie privée. Il convient
que les spécifications fournies par la personne concernée (telles que la finalité d'utilisation) ou les
exigences spécifiées par la législation (telles que la date d'expiration de DCP spécifiques) soient prises
en compte avant que des DCP ne soient éliminées.
7 Enjeux
7.1 Vue d'ensemble
Un enjeu, tel que défini dans l'ISO/IEC/IEEE 42010, est un intérêt au sein d'un système, qui est pertinent
pour une ou plusieurs de ses parties prenantes. L'architecture de référence pour la protection de la vie
privée exposée dans le présent document est essentiellement axée sur les enjeux des parties prenantes
en matière de protection de la vie privée, liés au traitement des DCP. Les enjeux du présent document
comprennent les principes de protection de la vie privée de l'ISO/IEC 29100 ainsi que toute exigence de
protection de la vie privée dérivée de ces principes et conforme à ceux-ci.
Il convient de déterminer les exigences de protection de la vie privée en suivant un processus de gestion
des risques d'atteinte à la vie privée, conforme au processus décrit dans l'ISO/IEC 29100:2011, 4.5. Il
convient que toute personne ou organisation qui conçoit un système TIC manipulant des DCP suive
ce processus. Il convient que toutes les exigences identifiées en matière de protection de la vie privée
soient conformes à la législation applicable en la matière.
7.2 Les principes de protection de la vie privée de l'ISO/IEC 29100
Le responsable de traitement des DCP est chargé, pour l'ensemble de l'organisation, de la protection des
DCP et de la gestion loyale et licite de celles-ci à tout moment, ainsi que du traitement des DCP délégué
aux sous-traitants de DCP.
Le responsable de traitement des DCP a la charge, en dernier ressort, de la mise en œuvre des mesures
de protection de la vie privée au sein d'un système TIC. Les mesures de protection de la vie privée
visent à garantir que les exigences de protection de la vie privée définies pour une personne concernée,
une transaction ou un scénario spécifique sont prises en compte et strictement respectées. Il convient
d'apporter la preuve de la mise en œuvre des mesures de protection de la vie privée, en les documentant
correctement et en fournissant des documents d'audit qui vérifient que ces mesures de sécurité
existent, qu'elles ont été correctement mises en œuvre et qu'elles fonctionnent convenablement. Pour
finir, il convient que le responsable de traitement des DCP accepte et adhère aux principes de protection
de la vie privée décrits dans l'ISO/IEC 29100, à savoir:
a) consentement et choix;
b) licéité et spécification de la finalité;
© ISO/IEC 2018 – Tous droits réservés
c) limitation de la collecte;
d) minimisation des données;
e) limitation de l'utilisation, de la conservation et de la divulgation;
f) exactitude et qualité;
g) ouverture, transparence et information;
h) participation et accès individuels;
i) responsabilité;
j) sécurité de l'information; et
k) conformité aux règles de protection de la vie privée.
7.3 Exigences de protection de la vie privée
Il convient que les systèmes TIC mettent en œuvre des mesures de protection de la vie privée en tant
qu'élément principal de chaque phase du cycle de vie du traitement des DCP. Les exigences de protection
de la vie privée permettent au concepteur du système TIC de concrétiser le lien entre les principes de
protection de la vie privée et les éléments architecturaux présentés à l'Article 8.
Afin de mettre en œuvre des mesures efficaces de protection de la vie privée dans un système TIC,
il convient de créer des flux de traitement décrivant le traitement des DCP. Les diagrammes de flux
de traitement des DCP constituent une représentation graphique du «flux» de DCP circulant au sein
du système TIC et entre les différents acteurs. Par exemple, si un acteur transfère des DCP à d'autres
acteurs (par exemple, des sous-traitants de DCP), il convient d'inclure ces transferts de DCP dans le
diagramme de flux de traitement des DCP.
Un diagramme de flux de traitement des DCP peut également être représenté sous la forme d'un
tableau de flux de DCP. Ce diagramme ou tableau suit la collecte, le transfert, l'utilisation, le stockage
ou l'élimination des DCP et contient des informations telles que le type de DCP, la personne qui a
collecté les DCP, la finalité du traitement, la personne à qui les DCP vont être transférées, l'obtention
du consentement de la personne concernée, la période de conservation et l'endroit où les DCP sont
stockées, ainsi que le niveau de risque d'atteinte à la vie privée, qui en résulte. Les informations sur
les flux de traitement des DCP sont un élément du processus de gestion des risques d'atteinte à la vie
privée, qui génère les exigences de protection de la vie privée.
Une fois l'analyse des exigences d'un système TIC terminée, il convient que les développeurs fassent
correspondre les exigences de protection de la vie privée du système TIC avec la liste des enjeux du
présent document. Il convient alors que les exigences de protection de la vie privée soient utilisées pour
choisir les éléments architecturaux satisfaisant aux dites exigences.
L'Annexe A contient un exemple de liste d'enjeux et illustre comment lier ces enjeux aux principes
de protection de la vie privée de l'ISO/IEC 29100 ainsi qu'aux éléments architecturaux du présent
document.
8 Vues de l'architecture
8.1 Généralités
Le présent article est structuré autour de trois points de vue architecturaux. Tout d'abord, la vue
Éléments décrit en détail les éléments du système TIC et les sépare en couches, selon leur fonctionnalité.
Chaque couche regroupe des éléments qui contribuent au traitement correct des DCP. Des
recommandations de mise en œuvre limitée sont fournies pour chaque élément. Des recommandations
spécifiques aux acteurs sont fournies, le cas échéant. Cette vue est utile pour comprendre les blocs
constitutifs de l'architecture de référence pour la protection de la vie privée.
© ISO/IEC 2018 – Tous droits réservés
Des tableaux présentant des exemples de relations types entre les principes de protection de la vie
privée de l'ISO/IEC 29100 et les éléments de l'architecture sont fournis dans la vue Éléments. De
tels tableaux de correspondance sont utiles pour comprendre comment un système TIC adhère aux
principes de protection de la vie privée de l'ISO/IEC 29100. Des tableaux similaires peuvent être utilisés
à titre d'exemples et mis à jour lors de la conception du système pour décrire comment un système TIC
particulier adhère aux principes de protection de la vie privée de l'ISO/IEC 29100.
La vue Acteurs considère les éléments décrits dans la vue Éléments, du point de vue du système TIC d'un
acteur individuel. Cette vue est utile pour la conception de l'architecture d'un système TIC particulier.
La vue Interactions considère les éléments d'un point de vue du déploiement. Cette vue permet de
comprendre comment les éléments des systèmes TIC des différents acteurs interagissent les uns avec
les autres.
8.2 Vue Éléments
8.2.1 Généralités
La vue Éléments sert à décrire les éléments d'un système TIC qui interviennent dans le traitement des
DCP.
Il convient que le choix des éléments soit guidé par les exigences appropriées de protection de la vie
privée. Il convient que le développeur du système TIC destiné à un ou plusieurs acteurs spécifiques
(voir Figure 2) utilise la vue Éléments pour déterminer les éléments à inclure dans l'architecture du
système qu'il élabore. Il convient que cette architecture soit basée sur les exigences de protection de
la vie privée établies à l'aide des recommandations de l'Article 7. Il est à noter que tous les éléments
décrits dans le présent document ne conviennent pas nécessairement à tout système TIC.
La vue Éléments se décompose en trois couches. Chaque couche correspond à un groupe logique
d'éléments qui contribuent à un objectif spécifique dans le traitement des DCP. Les éléments de la
couche Paramètres de protection de la vie privée gèrent les métadonnées relatives au traitement des
DCP, y compris, entre autres, l'échange d'informations sur la finalité du traitement, le consentement et
les préférences de la personne concernée. Les éléments de la couche Gestion des identités et des accès
doivent pouvoir garantir que des informations d'identité appropriées sont utilisées dans le traitement
des DCP et que l'accès aux DCP est contrôlé conformément aux exigences de protection de la vie privée.
Pour finir, les éléments de la couche DCP exécutent diverses tâches de traitement des DCP.
L'architecture de référence est conçue en partant du principe que tous les éléments interagissent avec
plusieurs autres éléments. Toutefois, afin de préserver le caractère général et la clarté du document, les
possibilités d'interactions entre les éléments n'ont pas été représentées.
Certains des éléments de l'architecture de référence sont des technologies contribuant à la protection
de la vie privée (appelées technologies PET). Cette sélection de technologies PET n'est pas exhaustive.
Il en existe d'autres qui ne sont pas décrites dans le présent document et c'est au développeur du
système TIC qu'il incombe de choisir les technologies PET appropriées et de les adapter à l'architecture
de référence.
L'Annexe B donne un exemple d'architecture de système TIC appliquant des technologies PET pour
garantir un traitement sûr des DCP. L'Annexe C donne un exemple de la manière d'utiliser des données
d'identification basées sur des attributs pour élaborer un système TIC qui assure la gestion des identités
pseudonymes et du contrôle d'accès.
Les paragraphes suivants décrivent les couches, les éléments qui les composent et les acteurs qui
interagissent avec ces éléments. Chaque élément fait l'objet d'une description générale, suivie de lignes
directrices spécifiques aux acteurs. Pour certains éléments, il n'est donné aucune recommandation
spécifique aux systèmes TIC d'un acteur particulier, car le comportement de l'élément est similaire dans
les systèmes TIC de tous les acteurs.
© ISO/IEC 2018 – Tous droits réservés
----------------------
...
Date: 2018-11
ISO/IEC JTC 1/SC 27
Date : 2018-11
ISO/IEC JTC 1/SC 27
Secrétariat : DIN
Technologies de l'information — Techniques de sécurité — Architecture de référence
pour la protection de la vie privée
Information technology — Security techniques — Privacy architecture framework
ICS : 35.030
Type du document: Norme internationale
Sous-type du document:
Stade du document: (50) Approbation
Langue du document: F
DOCUMENT PROTÉGÉ PAR COPYRIGHT
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre,
aucune partie de cette publication ne peut être reproduite ni utilisée sous quelque forme que ce soit
et par aucun procédé, électronique ou mécanique, y compris la photocopie, l’affichage sur l’internet
ou sur un Intranet, sans autorisation écrite préalable. Les demandes d’autorisation peuvent être
adressées à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
CP 401 •• Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél. :.: + 41 22 749 01 11
Fax : + 41 22 749 09 47
E-mail : copyright@iso.org
Web : www.iso.org
Publié en Suisse
Sommaire Page
Avant-propos . 5
Introduction . 6
1 Domaine d'application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Symboles et abréviations . 1
5 Vue d'ensemble de l'architecture de référence pour la protection de la vie privée . 3
5.1 Éléments constitutifs de l'architecture . 3
5.2 Relation avec les systèmes de gestion . 5
6 Acteurs et données à caractère personnel (DCP) . 5
6.1 Vue d'ensemble . 5
6.2 Phases du cycle de vie du traitement des DCP . 7
6.2.1 Collecte . 7
6.2.2 Transfert . 8
6.2.3 Utilisation . 9
6.2.4 Conservation . 9
6.2.5 Élimination . 10
7 Enjeux . 10
7.1 Vue d'ensemble . 10
7.2 Les principes de protection de la vie privée de l'ISO/IEC 29100 . 10
7.3 Exigences de protection de la vie privée . 11
8 Vues de l'architecture . 12
8.1 Généralités . 12
8.2 Vue Éléments . 12
8.2.1 Généralités . 12
8.2.2 Couche Paramètres de protection de la vie privée . 13
8.2.3 Couche Gestion des identités et des accès . 18
8.2.4 Couche DCP . 20
8.3 Vue Acteurs . 29
8.3.1 Généralités . 29
8.3.2 Système TIC de la personne concernée . 29
8.3.3 Système TIC du responsable de traitement des DCP . 30
8.3.4 Système TIC du sous-traitant de DCP . 32
8.4 Vue Interactions. 33
8.4.1 Généralités . 33
8.4.2 Couche Paramètres de protection de la vie privée . 34
8.4.3 Couche Gestion des identités et des accès . 34
8.4.4 Couche DCP . 35
Annexe A (informative) Exemples d'enjeux liés aux DCP d'un système TIC . 38
Annexe B (informative) Système d'agrégation des DCP avec calcul sécurisé . 45
Annexe C (informative) Système pseudonyme de gestion des identités et du contrôle d'accès,
respectueux de la vie privée . 56
Avant-propos
L'ISO (Organisation internationale de normalisation) et l'IEC (Commission électrotechnique
internationale) forment le système spécialisé de la normalisation mondiale. Les organismes nationaux
membres de l'ISO ou de l'IEC participent au développement de Normes Internationales par l'intermédiaire
des comités techniques créés par l'organisation concernée afin de s'occuper des domaines particuliers de
l'activité technique. Les comités techniques de l'ISO et de l'IEC collaborent dans des domaines d'intérêt
commun. D'autres organisations internationales, gouvernementales et non gouvernementales, en liaison
avec l'ISO et l'IEC participent également aux travaux. Dans le domaine des technologies de l'information,
l'ISO et l'IEC ont créé un comité technique mixte, l'ISO/IEC JTC 1.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier de prendre note des différents
critères d'approbation requis pour les différents types de documents ISO. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2
(voir www.iso.org/directives).
L'attention est attirée sur le fait que certains des éléments du présent document peuvent faire l'objet de
droits de propriété intellectuelle ou de droits analogues. L'ISO et l'IEC ne sauraient être tenues pour
responsables de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails
concernant les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors
de l'élaboration du document sont indiqués dans l'Introduction et/ou dans la liste des déclarations de
brevets reçues par l'ISO (voir www.iso.org/brevets).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données pour
information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un
engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions
spécifiques de l'ISO liés à l'évaluation de la conformité, ou pour toute information au sujet de l'adhésion de
l'ISO aux principes de l’Organisation mondiale du commerce (OMC) concernant les obstacles techniques au
commerce (OTC), voir le lien suivant : www.iso.org/iso/fr/avant-proposwww.iso.org/avant-propos.
Le présent document a été élaboré par le comité technique ISO/IEC JTC 1, Technologies de l'information,
sous-comité SC 27, Sécurité de l'information, cybersécurité et protection de la vie privée.
Cette deuxième édition annule et remplace la première édition (ISO/IEC 29101:2013), qui a fait l'objet
d'une révision technique. La principale modification par rapport à l'édition précédente est que l'ancienne
Annexe D a été supprimée.
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes se
trouve à l’adresse www.iso.org/fr/members.html.
Introduction
Le présent document décrit une architecture de référence de haut niveau ainsi que les mesures associées
visant à protéger la vie privée dans les systèmes de technologies de l'information et de la communication
(TIC) qui stockent et traitent des données à caractère personnel (DCP).
L'architecture de référence pour la protection de la vie privée décrite dans le présent document :
— fournit une approche cohérente et de haut niveau pour la mise en œuvre de mesures de protection de
la vie privée dans le cadre du traitement des DCP dans les systèmes TIC ;
— fournit des recommandations pour la planification, la conception et l'élaboration d'architectures de
systèmes TIC visant à protéger la vie privée des personnes concernées en contrôlant le traitement,
l'accès et le transfert des informations personnelles identifiables ; et
— indique comment les technologies renforçant la protection de la vie privée (PET) peuvent être utilisées
comme mesures de protection de la vie privée.
Le présent document s'appuie sur le cadre de protection de la vie privée fourni par l'ISO/IEC 29100 dans le
but d'aider une organisation à définir ses exigences en matière de protection de la vie privée, dans la
mesure où elles concernent les DCP traitées par un système TIC. Dans certains pays, les exigences
applicables en matière de protection de la vie privée sont considérées comme synonymes d'exigences de
protection des données/de protection de la vie privée et font l'objet d'une législation sur la protection des
données/la protection de la vie privée.
PROJET FINAL DE NORME INTERNATIONALE ISO/IEC 29101:2018(F)
Technologies de l'information — Techniques de sécurité —
Architecture de référence pour la protection de la vie privée
1 Domaine d'application
Le présent document définit une architecture de référence pour la protection de la vie privée qui :
— spécifie les enjeux des systèmes TIC ayant à traiter des DCP ;
— énumère les éléments nécessaires à la mise en œuvre de tels systèmes ; et
— fournit des vues de l'architecture contextualisant ces éléments.
Le présent document s'applique aux entités participant à la spécification, à la fourniture, à
l'architecture, à la conception, aux essais, à la maintenance, à l'administration et à l'exploitation des
systèmes TIC qui traitent des DCP.
Il se concentre principalement sur les systèmes TIC conçus pour interagir avec les personnes
concernées.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu’ils constituent, pour tout ou partie de leur
contenu, des exigences du présent document. Pour les références datées, seule l'édition citée s'applique.
Pour les références non datées, la dernière édition du document de référence s'applique (y compris les
éventuels amendements).)
ISO/IEC 29100, Technologies de l'information — Techniques de sécurité — Cadre privé
ISO/IEC/IEEE 42010, Ingénierie des systèmes et des logiciels — Description de l'architecturel’architecture
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions donnés dans l'ISO/IEC 29100 et
l'ISO/IEC/IEEE 42010 s'appliquent.
4 Symboles et abréviations
Les abréviations suivantes s'appliquent au présent document.
DCP Données à caractère personnel
PET Technologie contribuant à la protection de la vie privée (Privacy Enhancing Technology)
TIC Technologies de l'information et de la communication
© ISO/IEC 2018 – Tous droits réservés
5 Vue d'ensemble de l'architecture de référence pour la protection de la vie
privée
5.1 Éléments constitutifs de l'architecture
L'architecture de référence pour la protection de la vie privée présentée dans le présent document est
destinée à servir de référence technique aux développeurs de systèmes TIC devant traiter des DCP. Le
présent document ne fixe pas d'exigences en matière de politique de respect de la vie privée ; il suppose
qu'une telle politique est en place, que les exigences de protection de la vie privée ont été définies et
que des mesures de protection appropriées ont été mises en œuvre au sein du système TIC.
Cette architecture de référence traite essentiellement de la protection des DCP. Étant donné qu'il s'agit
en partie d'un objectif de sécurité, il convient que les systèmes TIC ayant à traiter des DCP suivent
également les lignes directrices relatives à l'ingénierie de la sécurité de l'information. La présente
architecture de référence répertorie certains éléments de sécurité de l'information, qui sont essentiels à
la protection des DCP traitées au sein des systèmes TIC. L'architecture de référence présentée est basée
sur le modèle utilisé dans l'ISO/IEC/IEEE 42010.
Les parties prenantes liées à ces enjeux concernent la protection de la vie privée et sont définies dans
l'ISO/IEC 29100. Elles sont discutées plus en détail à l'Article 6.
Les enjeux de l'architecture de référence sont décrits à l'Article 7. Ils incluent les principes de
protection de la vie privée de l'ISO/IEC 29100 et les exigences de protection de la vie privée spécifiques
aux systèmes TIC.
L'architecture de référence est présentée comme suit :
a) les couches de l'architecture technique de référence décrites en 8.2 reflètent l'architecture du point
de vue des éléments. Chaque couche regroupe des éléments ayant un objectif commun ou des
fonctions similaires ;
b) le modèle de déploiement exposé en 8.3 présente l'architecture de référence du point de vue d'un
système TIC autonome. Chaque vue illustre un regroupement d'éléments en fonction de leur
déploiement dans les systèmes TIC des parties prenantes ; et
c) les vues du paragraphe 8.4 présentent l'architecture de référence d'un point de vue interactionnel.
Ces vues illustrent la manière dont les éléments interagissent entre les systèmes TIC des différentes
parties prenantes.
L'architecture de référence présente également des règles de correspondance entre les enjeux et les
points de vue, établies sur la base de tables de correspondance.
Figure 1 — Éléments de l'architecture de référence pour la protection de la vie privée dans leur
contexte
La Figure 1 illustre la relation entre les éléments d'une architecture de référence pour la protection de
la vie privée. L'élément central de l'architecture de référence est le système TIC intégré. Un acteur, au
sens de l'ISO/IEC 29101, utilise un système TIC. La conception des systèmes TIC est affectée à la fois par
les enjeux traités dans le présent document et, également, par d'autres enjeux. À titre d'exemples
d'autres enjeux, on peut citer les exigences non fonctionnelles qui affectent les performances,
l'accessibilité et la conception du système TIC, mais qui n'affectent pas le traitement fonctionnel des
DCP. Ces autres enjeux n'entrent pas dans le cadre du présent document.
Le système TIC peut contenir des éléments de l'architecture de référence pour la protection de la vie
privée détaillée dans le présent document ainsi que d'autres éléments. Ces éléments ne traitent pas les
DCP, mais gèrent d'autres fonctionnalités du système TIC, comme l'accessibilité ou le recours à des
interfaces utilisateur spécifiques. Ces éléments ne relèvent pas du domaine d'application du présent
document.
© ISO/IEC 2018 – Tous droits réservés
5.2 Relation avec les systèmes de gestion
L'utilisation d'un système de gestion permet aux responsables de traitement des DCP et aux sous-
traitants de DCP de répondre plus efficacement à leurs exigences de protection de la vie privée grâce à
une approche structurée. Cette approche structurée permet également aux responsables de traitement
des DCP et aux sous-traitants de DCP de mesurer les résultats et d'améliorer en permanence l'efficacité
du système de gestion.
Un système de gestion efficace doit être aussi transparent que possible, tout en ayant un impact sur les
personnes, les processus et la technologie. Il convient de l'intégrer au programme de contrôle interne et
à la stratégie d'atténuation des risques d'une organisation. Sa mise en œuvre permet de se conformer
plus facilement aux réglementations en matière de protection des données et de respect de la vie
privée.
6 Acteurs et données à caractère personnel (DCP)
6.1 Vue d'ensemble
Les acteurs de l'architecture de référence ISO/IEC sont des parties prenantes en matière de protection
de la vie privée, impliquées dans le traitement des DCP décrit dans l'ISO/IEC 29100. Il s'agit des acteurs
suivants :
a) la personne concernée ;
b) le responsable de traitement des DCP ; et
c) le sous-traitant de DCP.
NOTE Le terme de « tiers » défini comme l'une des quatre catégories d'acteurs dans l'ISO/IEC 29100 est hors
du domaine d'application de l'architecture de référence spécifiée dans le présent document.
Sur le plan du déploiement, l'architecture de référence est divisée en trois parties. Chaque partie
s'applique au système TIC déployé du point de vue de chacun de ces acteurs.
La Figure 2 représente les systèmes TIC des acteurs ainsi que les flux de DCP entre ces systèmes. Elle
illustre la division logique des fonctionnalités au niveau de l'architecture de référence décrite dans le
présent document. Il ne s'agit pas d'une représentation de la structure physique, de l'organisation ou de
la propriété du matériel des systèmes TIC.
Figure 2 — Acteurs et leurs systèmes TIC au sens du présent document
Un acteur peut être responsable de la construction des systèmes TIC qu'il utilise, ou non. Par exemple,
la personne concernée peut utiliser un système construit par le responsable de traitement des DCP, ou
le système TIC de la personne concernée peut faire partie du système TIC du responsable de traitement
des DCP. En outre, les fonctionnalités du système TIC de la personne concernée peuvent être réparties
entre différents systèmes matériels TIC appartenant à la personne concernée et au responsable de
traitement des DCP. De même, le responsable de traitement des DCP peut fournir le système TIC du
sous-traitant de DCP. Les processus commerciaux ayant recours à des systèmes TIC utilisent un large
éventail de modèles de communication et de modèles de confiance. L'architecture de référence
présentée dans le présent document s'appuie sur une abstraction de ces modèles.
Si la personne concernée utilise un système TIC privé, les autres parties prenantes en matière de
protection de la vie privée peuvent imposer des exigences à ce système TIC. Par exemple, le système TIC
de la personne concernée peut devoir répondre à un minimum d'exigences de sécurité pour être
autorisé à se connecter aux autres systèmes TIC. On peut également citer l'utilisation d'éléments de
© ISO/IEC 2018 – Tous droits réservés
sécurité particuliers, tels que des jetons d'authentification matériels, certaines versions du système
d'exploitation ou des versions spécifiques de navigateur Web.
Par exemple, dans les systèmes TIC utilisant des communications poste-à-poste (méthode, modèle ou
technologie de communication permettant la communication entre des entités P2P sans serveur
central), chaque application peut assumer les rôles des trois acteurs susmentionnés. Les informations
sont à la fois envoyées et reçues par chaque poste, de sorte que chacun d'eux peut être responsable de
traitement de DCP ou sous-traitant de DCP préalablement transmises par une autre partie jouant le rôle
de personne concernée.
Dans les applications de réseaux sociaux, les DCP peuvent être traitées par toute personne ayant accès
au profil d'autres personnes. Les applications de réseaux sociaux utilisant le Web permettent à tous les
utilisateurs autorisés, et éventuellement anonymes, du service de traiter les DCP fournies par les
personnes concernées, connectées au réseau social.
6.2 Phases du cycle de vie du traitement des DCP
6.2.1 Collecte
De nombreuses organisations collectent des informations sur des personnes concernées. Ces
informations peuvent contenir des DCP.
Lorsqu'elles collectent des DCP, il convient que les organisations tiennent toujours compte des
préférences relatives à la vie privée et des droits légaux de la personne concernée, ainsi que des
exigences de protection de la vie privée, telles que stipulées par la législation en vigueur. Des facteurs
tels que le type de DCP, le consentement donné ou toute préférence exprimée en matière de respect de
la vie privée, doivent être pris en compte à toutes les étapes du traitement. Il ne convient de collecter
des DCP que si cela est nécessaire aux finalités déclarées.
Il convient d'associer une documentation aux DCP. On peut citer, sans s'y limiter, les exemples suivants :
a) balises logicielles indiquant la ou les finalités pour lesquelles les DCP peuvent être utilisées ;
b) enregistrements décrivant la ou les finalités pour lesquelles les DCP peuvent être utilisées ; et
c) enregistrements du consentement donné et de toute spécificité particulière qu'il convient de
respecter (par exemple, il convient de chiffrer certaines catégories de DCP ou de les supprimer
après un certain temps).
Il convient de mettre en œuvre des mesures de protection de la vie privée, chaque fois que des données
sont identifiées comme DCP ou que des DCP sont caractérisées par des informations supplémentaires
relatives à la personne concernée. Il est également important de préserver les balises pertinentes pour
le traitement des DCP pendant les phases d'utilisation, de transfert, de stockage et d'élimination. Si des
DCP stockées sont susceptibles d'avoir été modifiées, il convient d'en valider l'exactitude et la
pertinence avant de les utiliser.
En outre, il convient que les processus de collecte des DCP soient conçus de manière à ne recueillir que
les DCP nécessaires à la transaction concernée. Il convient que les organisations prennent des mesures
visant à réduire au minimum la collecte non intentionnelle ou involontaire de DCP grâce à des systèmes
de saisie de données (par exemple, formulaires d'applications Web permettant la saisie de toute
information). Il convient de limiter l'introduction de DCP arbitraires en prévoyant un affichage
contextuel des champs de saisie visant à réduire ou à éliminer les zones de formulaire Web où ces
informations peuvent être entrées (par exemple, en supprimant les cases à cocher et les champs de
texte libre inutiles). De même, il convient d'envisager l'utilisation de champs avec des entrées
prédéfinies (par exemple, boîtes à liste et listes déroulantes) contenant des options autres que DCP.
Lorsqu'il y a lieu d'implémenter des champs de texte libre, il convient que l'interface utilisateur
prévoie :
a) des avertissements pour prévenir la personne concernée de ne pas saisir de DCP autres que celles
qui sont explicitement demandées et autorisées ou exigées par la loi en vigueur ;
b) une indication claire des champs dans lesquels des DCP doivent être saisies et une indication de la
nature des DCP qu'il convient de saisir (par exemple, nom, adresse, informations médicales) ;); et
c) une indication claire des champs où il convient de ne pas introduire de DCP.
6.2.2 Transfert
Le transfert, la diffusion ou la communication de DCP à des tiers signifie que les DCP ne sont plus sous le
contrôle exclusif de la personne concernée. Le transfert est le terme généralement employé pour
désigner la diffusion de DCP, depuis le responsable de traitement des DCP ou le sous-traitant de DCP
vers d'autres responsables de traitement et sous-traitants de DCP. Si les DCP sont transférées, du
responsable de traitement des DCP vers un autre acteur, le transfert est alors parfois appelé
« divulgation ».
Il convient que l'obligation de rendre compte et la responsabilité du transfert des DCP soient convenues
et assumées par chaque partie impliquée dans le traitement des DCP. Il convient que cet accord soit mis
par écrit lorsque la loi en vigueur l'exige. De plus, ces accords doivent être conformes à la législation sur
la protection des données dans les domaines d'origine et de destination des transferts. Lorsque cela
s'avère pertinent et approprié, ou lorsque la loi l'exige, il convient de notifier à la personne concernée
qu'un transfert est en cours et de l'informer du contenu et de la finalité du transfert. En cas de litige
entre la personne concernée et le responsable de traitement des DCP ou le sous-traitant de DCP, il
convient de pouvoir accéder aux relevés des transferts de DCP pertinents pour aider à résoudre un tel
litige.
Il convient d'éviter le transfert de DCP sensibles, sauf :
— s'il est nécessaire pour fournir un service que la personne concernée a demandé ;
— s'il répond à une nécessité commerciale liée à la fourniture du service demandé ; ou
— si la loi l'exige.
Certaines juridictions ont institué des lois qui exigent spécifiquement des accords contractuels formels
incluant toutes les exigences de protection de la vie privée entre les parties concernées, lorsque des
DCP sont transférées en dehors d'une juridiction ayant un niveau prescrit de protection de la vie privée.
En cas de transferts transfrontaliers, il convient d'accorder une attention particulière aux mesures de
protection des DCP transférées.
Il convient de mettre en place des mécanismes de protection appropriés lors du transfert de DCP. En cas
de transfert numérique, il convient que les DCP soient transmises par un canal sécurisé ou sous forme
chiffrée si la transmission se fait par un canal non sécurisé. Si les DCP sont transférées sur un support
© ISO/IEC 2018 – Tous droits réservés
physique, il convient alors de les chiffrer. Si l'on utilise un chiffrement, il convient de ne pas stocker, ni
transmettre la clé de chiffrement avec les DCP chiffrées.
6.2.3 Utilisation
L'utilisation de DCP désigne toute forme de traitement des DCP qui n'inclut pas la « collecte », le
« transfert », le « stockage », l'« archivage » ou l'« élimination » de DCP. Les principes de protection de la
vie privée décrits dans l'ISO/IEC 29100 (Cadre privé), ainsi que certaines lois sur la protection des
données et le respect de la vie privée, peuvent limiter le traitement des DCP si ce traitement est
incompatible avec les finalités spécifiées à l'origine. Il convient donc de ne traiter les DCP que dans le
cadre des finalités déclarées pour lesquelles elles ont été collectées.
Si les DCP doivent être traitées à d'autres fins qui ne sont pas couvertes par la loi en vigueur, il convient
d'obtenir le consentement de la personne concernée ou de son agent. Il convient de fournir à la
personne concernée un moyen de contacter le responsable de traitement des DCP ou le sous-traitant de
DCP au cas où la personne aurait des questions sur des activités nécessitant des éclaircissements.
Lorsqu'un tel traitement est jugé nécessaire, il convient d'obtenir le consentement de la personne
concernée, à moins que la loi n'en dispose autrement. Il convient d'informer clairement les personnes
concernées de l'utilisation spécifique de leurs DCP.
En outre, il convient d'appliquer des mécanismes de protection adaptés à l'utilisation des DCP, dans la
mesure où une analyse approfondie des risques les juge nécessaire. Cela inclut l'utilisation de
techniques d'anonymisation ou de pseudonymisation préalablement au traitement ainsi que le recours
à des techniques de calcul sécurisées pendant le traitement.
6.2.4 Conservation
Lorsqu'il est nécessaire de stocker des DCP, il convient d'obtenir le consentement de la personne
concernée, en tenant compte de toute mesure spécifique susceptible d'être exigée par la loi. Dans ces
cas, il convient de ne conserver les DCP que pendant le temps nécessaire à la réalisation de la finalité
professionnelle spécifique.
Il convient de stocker les DCP à l'aide de mesures de sécurité et de mécanismes appropriés afin
d'empêcher toute action non autorisée, qu'il s'agisse d'accès, de modification, de destruction, de
suppression ou de toute autre utilisation indue. De telles mesures de sécurité incluent, sans s'y limiter,
le chiffrement, le secret réparti, la pseudonymisation et l'anonymisation.
Les DCP archivées doivent faire l'objet d'une attention particulière. Les principes de protection de la vie
privée stipulent qu'il convient que les DCP ne soient conservées que le temps nécessaire à la réalisation
des finalités déclarées, puis qu'elles soient détruites par des moyens sûrs ou anonymisées. Toutefois, si
le responsable de traitement des DCP ou le sous-traitant de DCP est contraint, du fait de la loi en
vigueur, de conserver les DCP au-delà de l'expiration des autres finalités, il convient de verrouiller les
DCP (c'est-à-dire de les archiver et de les protéger par un mécanisme de contrôle d'accès pour éviter
toute utilisation ultérieure). Il convient avant tout, lors de l'archivage des DCP, de s'assurer que les
mécanismes appropriés de protection des données sont en place, y compris les solutions de gestion des
accès qui ne permettent l'accès aux DCP archivées qu'aux utilisateurs autorisés.
Il convient que le responsable de traitement des DCP mette en place des mesures de sécurité dans les
systèmes de stockage afin de pouvoir éliminer les DCP lorsqu'elles expirent ou lorsque la finalité du
stockage ou du traitement des DCP ne se justifie plus.
6.2.5 Élimination
Au cours de la dernière étape du cycle de vie du traitement des DCP, les DCP sont supprimées,
anonymisées, détruites, renvoyées ou éliminées d'une autre manière. Il est possible d'empêcher toute
utilisation non autorisée de certaines DCP dans des relevés de DCP en les marquant pour élimination. Il
convient de noter que la suppression de DCP ne signifie pas nécessairement que celles-ci sont
définitivement éliminées, car les DCP supprimées dans des systèmes TIC peuvent souvent être
récupérées. Bien que cela puisse sembler évident dans le traitement des DCP, les procédures
d'élimination des DCP ne satisfont pas toujours aux exigences de protection de la vie privée. Il convient
que les spécifications fournies par la personne concernée (telles que la finalité d'utilisation) ou les
exigences spécifiées par la législation (telles que la date d'expiration de DCP spécifiques) soient prises
en compte avant que des DCP ne soient éliminées.
7 Enjeux
7.1 Vue d'ensemble
Un enjeu, tel que défini dans l'ISO/IEC/IEEE 42010, est un intérêt au sein d'un système, qui est
pertinent pour une ou plusieurs de ses parties prenantes. L'architecture de référence pour la protection
de la vie privée exposée dans le présent document est essentiellement axée sur les enjeux des parties
prenantes en matière de protection de la vie privée, liés au traitement des DCP. Les enjeux du présent
document comprennent les principes de protection de la vie privée de l'ISO/IEC 29100 ainsi que toute
exigence de protection de la vie privée dérivée de ces principes et conforme à ceux-ci.
Il convient de déterminer les exigences de protection de la vie privée en suivant un processus de gestion
des risques d'atteinte à la vie privée, conforme au processus décrit dans l'ISO/IEC 29100:2011, 4.5. Il
convient que toute personne ou organisation qui conçoit un système TIC manipulant des DCP suive ce
processus. Il convient que toutes les exigences identifiées en matière de protection de la vie privée
soient conformes à la législation applicable en la matière.
7.2 Les principes de protection de la vie privée de l'ISO/IEC 29100
Le responsable de traitement des DCP est chargé, pour l'ensemble de l'organisation, de la protection des
DCP et de la gestion loyale et licite de celles-ci à tout moment, ainsi que du traitement des DCP délégué
aux sous-traitants de DCP.
Le responsable de traitement des DCP a la charge, en dernier ressort, de la mise en œuvre des mesures
de protection de la vie privée au sein d'un système TIC. Les mesures de protection de la vie privée
visent à garantir que les exigences de protection de la vie privée définies pour une personne concernée,
une transaction ou un scénario spécifique sont prises en compte et strictement respectées. Il convient
d'apporter la preuve de la mise en œuvre des mesures de protection de la vie privée, en les
documentant correctement et en fournissant des documents d'audit qui vérifient que ces mesures de
sécurité existent, qu'elles ont été correctement mises en œuvre et qu'elles fonctionnent
convenablement. Pour finir, il convient que le responsable de traitement des DCP accepte et adhère aux
principes de protection de la vie privée décrits dans l'ISO/IEC 29100, à savoir :
a) consentement et choix ;
b) licéité et spécification de la finalité ;
© ISO/IEC 2018 – Tous droits réservés
c) limitation de la collecte ;
d) minimisation des données ;
e) limitation de l'utilisation, de la conservation et de la divulgation ;
f) exactitude et qualité ;
g) ouverture, transparence et information ;
h) participation et accès individuels ;
i) responsabilité ;
j) sécurité de l'information ; et
k) conformité aux règles de protection de la vie privée.
7.3 Exigences de protection de la vie privée
Il convient que les systèmes TIC mettent en œuvre des mesures de protection de la vie privée en tant
qu'élément principal de chaque phase du cycle de vie du traitement des DCP. Les exigences de
protection de la vie privée permettent au concepteur du système TIC de concrétiser le lien entre les
principes de protection de la vie privée et les éléments architecturaux présentés à l'Article 8.
Afin de mettre en œuvre des mesures efficaces de protection de la vie privée dans un système TIC, il
convient de créer des flux de traitement décrivant le traitement des DCP. Les diagrammes de flux de
traitement des DCP constituent une représentation graphique du « flux » de DCP circulant au sein du
système TIC et entre les différents acteurs. Par exemple, si un acteur transfère des DCP à d'autres
acteurs (par exemple, des sous-traitants de DCP), il convient d'inclure ces transferts de DCP dans le
diagramme de flux de traitement des DCP.
Un diagramme de flux de traitement des DCP peut également être représenté sous la forme d'un tableau
de flux de DCP. Ce diagramme ou tableau suit la collecte, le transfert, l'utilisation, le stockage ou
l'élimination des DCP et contient des informations telles que le type de DCP, la personne qui a collecté
les DCP, la finalité du traitement, la personne à qui les DCP vont être transférées, l'obtention du
consentement de la personne concernée, la période de conservation et l'endroit où les DCP sont
stockées, ainsi que le niveau de risque d'atteinte à la vie privée, qui en résulte. Les informations sur les
flux de traitement des DCP sont un élément du processus de gestion des risques d'atteinte à la vie
privée, qui génère les exigences de protection de la vie privée.
Une fois l'analyse des exigences d'un système TIC terminée, il convient que les développeurs fassent
correspondre les exigences de protection de la vie privée du système TIC avec la liste des enjeux du
présent document. Il convient alors que les exigences de protection de la vie privée soient utilisées pour
choisir les éléments architecturaux satisfaisant aux dites exigences.
L'Annexe A contient un exemple de liste d'enjeux et illustre comment lier ces enjeux aux principes de
protection de la vie privée de l'ISO/IEC 29100 ainsi qu'aux éléments architecturaux du présent
document.
8 Vues de l'architecture
8.1 Généralités
Le présent article est structuré autour de trois points de vue architecturaux. Tout d'abord, la vue
Éléments décrit en détail les éléments du système TIC et les sépare en couches, selon leur
fonctionnalité. Chaque couche regroupe des éléments qui contribuent au traitement correct des DCP.
Des recommandations de mise en œuvre limitée sont fournies pour chaque élément. Des
recommandations spécifiques aux acteurs sont fournies, le cas échéant. Cette vue est utile pour
comprendre les blocs constitutifs de l'architecture de référence pour la protection de la vie privée.
Des tableaux présentant des exemples de relations types entre les principes de protection de la vie
privée de l'ISO/IEC 29100 et les éléments de l'architecture sont fournis dans la vue Éléments. De tels
tableaux de correspondance sont utiles pour comprendre comment un système TIC adhère aux
principes de protection de la vie privée de l'ISO/IEC 29100. Des tableaux similaires peuvent être utilisés
à titre d'exemples et mis à jour lors de la conception du système pour décrire comment un système TIC
particulier adhère aux principes de protection de la vie privée de l'ISO/IEC 29100.
La vue Acteurs considère les éléments décrits dans la vue Éléments, du point de vue du système TIC
d'un acteur individuel. Cette vue est utile pour la conception de l'architecture d'un système TIC
particulier. La vue Interactions considère les éléments d'un point de vue du déploiement. Cette vue
permet de comprendre comment les éléments des systèmes TIC des différents acteurs interagissent les
uns avec les autres.
8.2 Vue Éléments
8.2.1 Généralités
La vue Éléments sert à décrire les éléments d'un système TIC qui interviennent dans le traitement des
DCP.
Il convient que le choix des éléments soit guidé par les exigences appropriées de protection de la vie
privée. Il convient que le développeur du système TIC destiné à un ou plusieurs acteurs spécifiques
(voir Figure 2) utilise la vue Éléments pour déterminer les éléments à inclure dans l'architecture du
système qu'il élabore. Il convient que cette architecture soit basée sur les exigences de protection de la
vie privée établies à l'aide des recommandations de l'Article 7. Il est à noter que tous les éléments
décrits dans le présent document ne conviennent pas nécessairement à tout système TIC.
La vue Éléments se décompose en trois couches. Chaque couche correspond à un groupe logique
d'éléments qui contribuent à un objectif spécifique dans le traitement des DCP. Les éléments de la
couche Paramètres de protection de la vie privée gèrent les métadonnées relatives au traitement des
DCP, y compris, entre autres, l'échange d'informations sur la finalité du traitement, le consentement et
les préférences de la personne concernée. Les éléments de la couche Gestion des identités et des accès
doivent pouvoir garantir que des informations d'identité appropriées sont utilisées dans le traitement
des DCP et que l'accès aux DCP est contrôlé conformément aux exigences de protection de la vie privée.
Pour finir, les éléments de la couche DCP exécutent diverses tâches de traitement des DCP.
L'architecture de référence est conçue en partant du principe que tous les éléments interagissent avec
plusieurs autres éléments. Toutefois, afin de préserver le caractère général et la clarté du document, les
possibilités d'interactions entre les éléments n'ont pas été représentées.
© ISO/IEC 2018 – Tous droits réservés
Certains des éléments de l'architecture de référence sont des technologies contribuant à la protection
de la vie privée (appelées technologies PET). Cette sélection de technologies PET n'est pas exhaustive. Il
en existe d'autres qui ne sont pas décrites dans le présent document et c'est au développeur du
système TIC qu'il incombe de choisir les technologies PET appropriées et de les adapter à l'architecture
de référence.
L'Annexe B donne un exemple d'architecture de système TIC appliquant des technologies PET pour
garantir un traitement sûr des DCP. L'Annexe C donne un exemple de la manière d'utiliser des données
d'identification basées sur des attributs pour élaborer un système TIC qui assure la gestion des
identités pseudonymes et du contrôle d'accès.
Les paragraphes suivants décrivent les couches, les éléments qui les composent et les acteurs qui
interagissent avec ces éléments. Chaque élément fait l'objet d'une description générale, suivie de lignes
directrices spécifiques aux acteurs. Pour certains éléments, il n'est donné aucune recommandation
spécifique aux systèmes TIC d'un acteur particulier, car le comportement de l'élément est similaire dans
les systèmes TIC de tous les acteurs.
8.2.2 Couche Paramètres de protection de la vie privée
8.2.2.1 Généralités
La couch
...
Frequently Asked Questions
ISO/IEC 29101:2018 is a standard published by the International Organization for Standardization (ISO). Its full title is "Information technology - Security techniques - Privacy architecture framework". This standard covers: This document defines a privacy architecture framework that: - specifies concerns for ICT systems that process PII; - lists components for the implementation of such systems; and - provides architectural views contextualizing these components. This document is applicable to entities involved in specifying, procuring, architecting, designing, testing, maintaining, administering and operating ICT systems that process PII. It focuses primarily on ICT systems that are designed to interact with PII principals.
This document defines a privacy architecture framework that: - specifies concerns for ICT systems that process PII; - lists components for the implementation of such systems; and - provides architectural views contextualizing these components. This document is applicable to entities involved in specifying, procuring, architecting, designing, testing, maintaining, administering and operating ICT systems that process PII. It focuses primarily on ICT systems that are designed to interact with PII principals.
ISO/IEC 29101:2018 is classified under the following ICS (International Classification for Standards) categories: 35.030 - IT Security. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO/IEC 29101:2018 has the following relationships with other standards: It is inter standard links to ISO 1172:2023, ISO/IEC 29101:2013. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO/IEC 29101:2018 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...