ISO/IEC 29100:2011

Information technology - Security techniques - Privacy framework

ISO/IEC 29100:2011 provides a privacy framework which specifies a common privacy terminology; defines the actors and their roles in processing personally identifiable information (PII); describes privacy safeguarding considerations; and provides references to known privacy principles for information technology. ISO/IEC 29100:2011 is applicable to natural persons and organizations involved in specifying, procuring, architecting, designing, developing, testing, maintaining, administering, and operating information and communication technology systems or services where privacy controls are required for the processing of PII.

Technologies de l'information — Techniques de sécurité — Cadre privé

La présente Norme internationale fournit un cadre pour la protection de la vie privée qui: — spécifie une terminologie commune relative à la protection de la vie privée; — définit les acteurs et leurs rôles dans le traitement de données à caractère personnel (DCP); — décrit les éléments à prendre en considération pour la protection de la vie privée; et — fournit des références à des principes connus de protection de la vie privée pour les technologies de l'information. La présente Norme internationale s'applique aux personnes physiques et aux organismes participant à la spécification, à la fourniture, à l'architecture, à la conception, au développement, aux essais, à la maintenance, à l'administration et à l'exploitation des systèmes ou services de technologies de l'information et de la communication dans lesquels des mesures de protection de la vie privée sont requises pour le traitement de DCP.

General Information

• Status: Withdrawn
• Publication Date: 04-Dec-2011
• ICS: 35.030 - IT Security
• ICS: 35.040 - Information coding
• Technical Committee: ISO/IEC JTC 1/SC 27 - Information security, cybersecurity and privacy protection
• Drafting Committee: ISO/IEC JTC 1/SC 27/WG 5 - Identity management and privacy technologies
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 16-Feb-2024
• Completion Date: 30-Oct-2025

Relations

• Amended By: ISO/IEC 29100:2011/Amd 1:2018 - Information technology - Security techniques - Privacy framework - Amendment 1: Clarifications
• Effective Date: 29-Aug-2020
• Revised: ISO/IEC 29100:2024 - Information technology - Security techniques - Privacy framework
• Effective Date: 29-Oct-2022

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 29100
First edition
2011-12-15
Information technology — Security
techniques — Privacy framework
Technologies de l'information — Techniques de sécurité — Cadre privé

Reference number
©
ISO/IEC 2011
©  ISO/IEC 2011
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2011 – All rights reserved

Contents Page
Foreword . v
Introduction . vi
1  Scope . 1
2  Terms and definitions . 1
3  Symbols and abbreviated terms . 4
4  Basic elements of the privacy framework . 5
4.1  Overview of the privacy framework . 5
4.2  Actors and roles . 5
4.2.1  PII principals . 5
4.2.2  PII controllers . 5
4.2.3  PII processors . 5
4.2.4  Third parties . 6
4.3  Interactions . 6
4.4  Recognizing PII . 7
4.4.1  Identifiers . 7
4.4.2  Other distinguishing characteristics . 7
4.4.3  Information which is or might be linked to a PII principal . 8
4.4.4  Pseudonymous data . 9
4.4.5  Metadata . 9
4.4.6  Unsolicited PII . 9
4.4.7  Sensitive PII . 9
4.5  Privacy safeguarding requirements . 10
4.5.1  Legal and regulatory factors . 11
4.5.2  Contractual factors . 11
4.5.3  Business factors . 12
4.5.4  Other factors . 12
4.6  Privacy policies . 13
4.7  Privacy controls . 13
5  The privacy principles of ISO/IEC 29100 . 14
5.1  Overview of privacy principles . 14
5.2  Consent and choice . 14
5.3  Purpose legitimacy and specification . 15
5.4  Collection limitation . 15
5.5  Data minimization . 16
5.6  Use, retention and disclosure limitation . 16
5.7  Accuracy and quality . 16
5.8  Openness, transparency and notice . 17
5.9  Individual participation and access . 17
5.10  Accountability . 18
5.11  Information security . 18
5.12  Privacy compliance . 19
Annex A (informative) Correspondence between ISO/IEC 29100 concepts and ISO/IEC 27000
concepts . 20
Bibliography . 21

© ISO/IEC 2011 – All rights reserved iii

Figures
Figure 1 – Factors influencing privacy risk management . 11

Tables
Table 1 – Possible flows of PII among the PII principal, PII controller, PII processor and a third party and their
roles 7
Table 2 – Example of attributes that can be used to identify natural persons 8
Table 3 – The privacy principles of ISO/IEC 29100 14
Table A.1 – Matching ISO/IEC 29100 concepts to ISO/IEC 27000 concepts 20

iv © ISO/IEC 2011 – All rights reserved

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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
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.
ISO/IEC 29100 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, IT Security techniques.

© ISO/IEC 2011 – All rights reserved v

Introduction
This International Standard provides a high-level framework for the protection of personally
identifiable information (PII) within information and communication technology (ICT) systems. It is
general in nature and places organizational, technical, and procedural aspects in an overall privacy
framework.
The privacy framework is intended to help organizations define their privacy safeguarding
requirements related to PII within an ICT environment by:
- specifying a common privacy terminology;
- defining the actors and their roles in processing PII;
- describing privacy safeguarding requirements; and
- referencing known privacy principles.
In some jurisdictions, this International Standard’s references to privacy safeguarding requirements
might be understood as being complementary to legal requirements for the protection of PII. Due to
the increasing number of information and communication technologies that process PII, it is
important to have international information security standards that provide a common understanding
for the protection of PII. This International Standard is intended to enhance existing security
standards by adding a focus relevant to the processing of PII.
The increasing commercial use and value of PII, the sharing of PII across legal jurisdictions, and the
growing complexity of ICT systems, can make it difficult for an organization to ensure privacy and to
achieve compliance with the various applicable laws. Privacy stakeholders can prevent uncertainty
and distrust from arising by handling privacy matters properly and avoiding cases of PII misuse.
Use of this International Standard will:
- aid in the design, implementation, operation, and maintenance of ICT systems that handle and protect
PII;
- spur innovative solutions to enable the protection of PII within ICT systems; and
- improve organizations’ privacy programs through the use of best practices.
The privacy framework provided within this International Standard can serve as a basis for additional
privacy standardization initiatives, such as for:
- a technical reference architecture;
- the implementation and use of specific privacy technologies and overall privacy management;
- privacy controls for outsourced data processes;
- privacy risk assessments; or
- specific engineering specifications.
Some jurisdictions might require compliance with one or more of the documents referenced in
ISO/IEC JTC 1/SC 27 WG 5 Standing Document 2 (WG 5 SD2) — Official Privacy Documents
References [3] or with other applicable laws and regulations, but this International Standard is not
intended to be a global model policy, nor a legislative framework.

vi © ISO/IEC 2011 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 29100:2011(E)

Information technology — Security techniques — Privacy
framework
1 Scope
This International Standard provides a privacy framework which
- specifies a common privacy terminology;
- defines the actors and their roles in processing personally identifiable information (PII);
- describes privacy safeguarding considerations; and
- provides references to known privacy principles for information technology.
This International Standard is applicable to natural persons and organizations involved in specifying,
procuring, architecting, designing, developing, testing, maintaining, administering, and operating
information and communication technology systems or services where privacy controls are required
for the processing of PII.
2 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
NOTE In order to make it easier to use the ISO/IEC 27000 family of International Standards in the specific context of
privacy and to integrate privacy concepts in the ISO/IEC 27000 context, the table in Annex A provides the ISO/IEC 27000
concepts that correspond with the ISO/IEC 29100 concepts used in this International Standard.
2.1
anonymity
characteristic of information that does not permit a personally identifiable information principal to be
identified directly or indirectly
2.2
anonymization
process by which personally identifiable information (PII) is irreversibly altered in such a way that a
PII principal can no longer be identified directly or indirectly, either by the PII controller alone or in
collaboration with any other party
2.3
anonymized data
data that has been produced as the output of a personally identifiable information anonymization
process
2.4
consent
personally identifiable information (PII) principal’s freely given, specific and informed agreement to
the processing of their PII
© ISO/IEC 2011 – All rights reserved 1

2.5
identifiability
condition which results in a personally identifiable information (PII) principal being identified, directly
or indirectly, on the basis of a given set of PII
2.6
identify
establish the link between a personally identifiable information (PII) principal and PII or a set of PII
2.7
identity
set of attributes which make it possible to identify the personally identifiable information principal
2.8
opt-in
process or type of policy whereby the personally identifiable information (PII) principal is required to
take an action to express explicit, prior consent for their PII to be processed for a particular purpose
NOTE A different term that is often used with the privacy principle ‘consent and choice’ is “opt-out”. It describes a
process or type of policy whereby the PII principal is required to take a separate action in order to withhold or withdraw
consent, or oppose a specific type of processing. The use of an opt-out policy presumes that the PII controller has the right
to process the PII in the intended way. This right can be implied by some action of the PII principal different from consent
(e.g., placing an order in an online shop).
2.9
personally identifiable information
PII
any information that (a) can be used to identify the PII principal to whom such information relates, or
(b) is or might be directly or indirectly linked to a PII principal
NOTE To determine whether a PII principal is identifiable, account should be taken of all the means which can
reasonably be used by the privacy stakeholder holding the data, or by any other party, to identify that natural person.
2.10
PII controller
privacy stakeholder (or privacy stakeholders) that determines the purposes and means for
processing personally identifiable information (PII) other than natural persons who use data for
personal purposes
NOTE A PII controller sometimes instructs others (e.g., PII processors) to process PII on its behalf while the
responsibility for the processing remains with the PII controller.
2.11
PII principal
natural person to whom the personally identifiable information (PII) relates
NOTE Depending on the jurisdiction and the particular data protection and privacy legislation, the synonym “data
subject” can also be used instead of the term “PII principal”.
2.12
PII processor
privacy stakeholder that processes personally identifiable information (PII) on behalf of and in
accordance with the instructions of a PII controller
2.13
privacy breach
situation where personally identifiable information is processed in violation of one or more relevant
privacy safeguarding requirements
2 © ISO/IEC 2011 – All rights reserved

2.14
privacy controls
measures that treat privacy risks by reducing their likelihood or their consequences
NOTE 1 Privacy controls include organizational, physical and technical measures, e.g., policies, procedures, guidelines,
legal contracts, management practices or organizational structures.
NOTE 2 Control is also used as a synonym for safeguard or countermeasure.
2.15
privacy enhancing technology
PET
privacy control, consisting of information and communication technology (ICT) measures, products,
or services that protect privacy by eliminating or reducing personally identifiable information (PII) or
by preventing unnecessary and/or undesired processing of PII, all without losing the functionality of
the ICT system
NOTE 1 Examples of PETs include, but are not limited to, anonymization and pseudonymization tools that eliminate,
reduce, mask, or de-identify PII or that prevent unnecessary, unauthorized and/or undesirable processing of PII.
NOTE 2 Masking is the process of obscuring elements of PII.
2.16
privacy policy
overall intention and direction, rules and commitment, as formally expressed by the personally
identifiable information (PII) controller related to the processing of PII in a particular setting
2.17
privacy preferences
specific choices made by a personally identifiable information (PII) principal about how their PII
should be processed for a particular purpose
2.18
privacy principles
set of shared values governing the privacy protection of personally identifiable information (PII) when
processed in information and communication technology systems
2.19
privacy risk
effect of uncertainty on privacy
NOTE 1 Risk is defined as the “effect of uncertainty on objectives” in ISO Guide 73 and ISO 31000.
NOTE 2 Uncertainty is the state, even partial, of deficiency of information related to, understanding or knowledge of, an
event, its consequence, or likelihood.
2.20
privacy risk assessment
overall process of risk identification, risk analysis and risk evaluation with regard to the processing of
personally identifiable information (PII)
NOTE This process is also known as a privacy impact assessment.
2.21
privacy safeguarding requirements
set of requirements an organization has to take into account when processing personally identifiable
information (PII) with respect to the privacy protection of PII
2.22
privacy stakeholder
natural or legal person, public authority, agency or any other body that can affect, be affected by, or
perceive themselves to be affected by a decision or activity related to personally identifiable
information (PII) processing
© ISO/IEC 2011 – All rights reserved 3

2.23
processing of PII
operation or set of operations performed upon personally identifiable information (PII)
NOTE Examples of processing operations of PII include, but are not limited to, the collection, storage, alteration,
retrieval, consultation, disclosure, anonymization, pseudonymization, dissemination or otherwise making available, deletion
or destruction of PII.
2.24
pseudonymization
process applied to personally identifiable information (PII) which replaces identifying information with
an alias
NOTE 1 Pseudonymization can be performed either by PII principals themselves or by PII controllers. Pseudonymization
can be used by PII principals to consistently use a resource or service without disclosing their identity to this resource or
service (or between services), while still being held accountable for that use.
NOTE 2 Pseudonymization does not rule out the possibility that there might be (a restricted set of) privacy stakeholders
other than the PII controller of the pseudonymized data which are able to determine the PII principal’s identity based on the
alias and data linked to it.
2.25
secondary use
processing of personally identifiable information (PII) in conditions which differ from the initial ones
NOTE Conditions that differ from the initial ones could involve, for example, a new purpose for processing PII, a new
recipient of the PII, etc.
2.26
sensitive PII
category of personally identifiable information (PII), either whose nature is sensitive, such as those
that relate to the PII principal’s most intimate sphere, or that might have a significant impact on the
PII principal
NOTE In some jurisdictions or in specific contexts, sensitive PII is defined in reference to the nature of the PII and can
consist of PII revealing the racial origin, political opinions or religious or other beliefs, personal data on health, sex life or
criminal convictions, as well as other PII that might be defined as sensitive.
2.27
third party
privacy stakeholder other than the personally identifiable information (PII) principal, the PII controller
and the PII processor, and the natural persons who are authorized to process the data under the
direct authority of the PII controller or the PII processor
3 Symbols and abbreviated terms
The following abbreviations are common to ISO/IEC 29100.
ICT Information and Communication Technology
PET Privacy Enhancing Technology
PII Personally Identifiable Information
4 © ISO/IEC 2011 – All rights reserved

4 Basic elements of the privacy framework
4.1 Overview of the privacy framework
The following components relate to privacy and the processing of PII in ICT systems and make up
the privacy framework described in this International Standard:
- actors and roles;
- interactions;
- recognizing PII;
- privacy safeguarding requirements;
- privacy policies; and
- privacy controls.
For the development of this privacy framework, concepts, definitions and recommendations from
other official sources have been taken into consideration. These sources can be found in
ISO/IEC JTC 1/SC 27 WG 5 Standing Document 2 (WG 5 SD2) — Official Privacy Documents
References [3].
4.2 Actors and roles
For the purposes of this standard, it is important to identify the actors involved in the processing of
PII. There are four types of actors who can be involved in the processing of PII: PII principals, PII
controllers, PII processors and third parties.
4.2.1 PII principals
PII principals provide their PII for processing to PII controllers and PII processors and, when it is not
otherwise provided by applicable law, they give consent and determine their privacy preferences for
how their PII should be processed. PII principals can include, for example, an employee listed in the
human resources system of a company, the consumer mentioned in a credit report, and a patient
listed in an electronic health record. It is not always necessary that the respective natural person is
identified directly by name in order to be considered a PII principal. If the natural person to whom the
PII relates can be identified indirectly (e.g., through an account identifier, social security number, or
even through the combination of available attributes), he or she is considered to be the PII principal
for that PII set.
4.2.2 PII controllers
A PII controller determines why (purpose) and how (means) the processing of PII takes place. The
PII controller should ensure adherence to the privacy principles in this framework during the
processing of PII under its control (e.g., by implementing the necessary privacy controls). There
might be more than one PII controller for the same PII set or set of operations performed upon PII
(for the same or different legitimate purposes). In this case the different PII controllers shall work
together and make the necessary arrangements to ensure the privacy principles are adhered to
during the processing of PII. A PII controller can also decide to have all or part of the processing
operations carried out by a different privacy stakeholder on its behalf. PII controllers should carefully
assess whether or not they are processing sensitive PII and implement reasonable and appropriate
privacy and security controls based on the requirements set forth in the relevant jurisdiction as well
as any potential adverse effects for PII principals as identified during a privacy risk assessment.
4.2.3 PII processors
A PII processor carries out the processing of PII on behalf of a PII controller, acts on behalf of, or in
accordance with the instructions of the PII controller, observes the stipulated privacy requirements
© ISO/IEC 2011 – All rights reserved 5

and implements the corresponding privacy controls. In some jurisdictions, the PII processor is bound
by a legal contract.
4.2.4 Third parties
A third party can receive PII from a PII controller or a PII processor. A third party does not process
PII on behalf of the PII controller. Generally, the third party will become a PII controller in its own
right once it has received the PII in question.
4.3 Interactions
The actors identified in the previous clause can interact with each other in a variety of ways. As far
as the possible flows of PII among the PII principal, the PII controller and the PII processor are
concerned, the following scenarios can be identified:
a) the PII principal provides PII to a PII controller (e.g., when registering for a service provided by
the PII controller);
b) the PII controller provides PII to a PII processor which processes that PII on behalf of the PII
controller (e.g., as part of an outsourcing agreement);
c) the PII principal provides PII to a PII processor which processes that PII on behalf of the PII
controller;
d) the PII controller provides the PII principal with PII which is related to the PII principal (e.g.,
pursuant to a request made by the PII principal);
e) the PII processor provides PII to the PII principal (e.g., as directed by the PII controller); and
f) the PII processor provides PII to the PII controller (e.g., after having performed the service for
which it was appointed).
The roles of the PII principal, PII controller, PII processor and a third party in these scenarios are
illustrated in Table 1.
There is a need to distinguish between PII processors and third parties because the legal control of
the PII remains with the original PII controller when it is sent over to the PII processor, whereas a
third party can become a PII controller in its own right once it has received the PII in question. For
instance, where a third party makes the decision to transfer PII it has received from a PII controller to
yet another party, it will be acting as a PII controller in its own right and will therefore no longer be
considered a third party.
As far as the possible flows of PII among the PII controllers and PII processors on the one hand, and
third parties on the other hand are concerned, the following scenarios can be identified:
g) the PII controller provides PII to a third party (e.g., in the context of a business agreement); and
h) the PII processor provides PII to a third party (e.g., as directed by the PII controller).
The roles of the PII controller and a third party in these scenarios are also illustrated in Table 1.
6 © ISO/IEC 2011 – All rights reserved

Table 1 – Possible flows of PII among the PII principal, PII controller, PII processor and a third
party and their roles
PII principal PII controller PII processor Third party
－ －
Scenario a) PII provider PII recipient
Scenario b) － PII provider PII recipient －
Scenario c) PII provider － PII recipient －
－ －
Scenario d) PII recipient PII provider
－ －
Scenario e) PII recipient PII provider
－ －
Scenario f) PII recipient PII provider
Scenario g) － PII provider － PII recipient
Scenario h) － － PII provider PII recipient

4.4 Recognizing PII
To determine whether or not a natural person should be considered identifiable, several factors need
to be taken into account. In particular, account should be taken of all the means which can
reasonably be used by the privacy stakeholder holding the data, or by any other party, to identify that
natural person. ICT systems should support mechanisms that will make the PII principal aware of
such PII and provide the natural person with appropriate controls over the sharing of that information.
The following sub-clauses provide additional clarification on how to determine whether or not a PII
principal should be considered identifiable.
4.4.1 Identifiers
In certain instances, identifiability of the PII principal might be very clear (e.g., when the information
contains or is associated with an identifier which is used to refer to or communicate with the PII
principal). Information can be considered to be PII in at least the following instances:
- if it contains or is associated with an identifier which refers to a natural person (e.g., a social security
number);
- if it contains or is associated with an identifier which can be related to a natural person (e.g., a
passport number, an account number);
- if it contains or is associated with an identifier which can be used to establish a communication with
an identified natural person (e.g., a precise geographical location, a telephone number); or
- if it contains a reference which links the data to any of the identifiers above.
4.4.2 Other distinguishing characteristics
Information does not necessarily need to be associated with an identifier in order to be considered
PII. Information will also be considered PII if it contains or is associated with a characteristic which
distinguishes a natural person from other natural persons (e.g., biometric data).
Any attribute which takes on a value which uniquely identifies a PII principal is to be considered as a
distinguishing characteristic. Note that whether or not a given characteristic distinguishes a natural
person from other natural persons might change depending on the context of use. For instance, while
the last name of a natural person might be insufficient to identify that natural person on a global
scale, it will often be sufficient to distinguish a natural person on a company scale.
© ISO/IEC 2011 – All rights reserved 7

In addition, there can also be situations in which a natural person is identifiable even if there is no
single attribute that uniquely identifies him or her. This is the case where a combination of several
attributes taken together distinguishes this natural person from other natural persons. Whether or not
a natural person is identifiable on the basis of a combination of attributes might also be dependent
on the specific domain. For instance, the combination of the attributes “female”, “45” and “lawyer”
can be sufficient to identify a natural person within a particular company, but will often be insufficient
to identify that natural person outside of that company.
Table 2 provides some examples of attributes that could be PII, depending on the domain. These
examples are informative.
Table 2 – Example of attributes that can be used to identify natural persons
Examples
Age or special needs of vulnerable natural persons
Allegations of criminal conduct
Any information collected during health services
Bank account or credit card number
Biometric identifier
Credit card statements
Criminal convictions or committed offences
Criminal investigation reports
Customer number
Date of birth
Diagnostic health information
Disabilities
Doctor bills
Employees’ salaries and human resources files
Financial profile
Gender
GPS position
GPS trajectories
Home address
IP address
Location derived from telecommunications systems
Medical history
Name
National identifiers (e.g., passport number)
Personal e-mail address
Personal identification numbers (PIN) or passwords
Personal interests derived from tracking use of internet web sites
Personal or behavioural profile
Personal telephone number
Photograph or video identifiable to a natural person
Product and service preferences
Racial or ethnic origin
Religious or philosophical beliefs
Sexual orientation
Trade-union membership
Utility bills
4.4.3 Information which is or might be linked to a PII principal
If the information in question does not identify a PII principal, it should be determined whether the
information is or can be linked to an identity of a natural person.
Once the relationship with an identifiable natural person is established, it needs to be decided
whether the information says something about this natural person, for instance if it refers to her or
his characteristics or behaviour. Examples include medical records, financial profiles, or the personal
interests derived from tracking use of internet websites. Also, simple attribute statements about a
natural person such as age or gender of a natural person can qualify the linked information as PII.
Regardless, if the relationship with an identifiable natural person can be established, such
information must also be treated as PII.
8 © ISO/IEC 2011 – All rights reserved

4.4.4 Pseudonymous data
In order to restrict the ability of PII controllers and processors to identify the PII principal, identity
information can be replaced by aliases. This replacement is usually performed by a PII provider
before transmitting the PII to a PII recipient, in particular in scenarios a, b, c, g and h of Table 1.
Certain business processes rely on designated processors who perform the substitution and control
the assignment table or function. This is often the case wherever sensitive data needs to be
processed by privacy stakeholders that did not collect them.
The substitution is considered pseudonymization provided:
(a) the remaining attributes linked to the alias do not suffice to identify the PII principal to whom they
relate; and
(b) the alias assignment is such that it cannot be reversed by reasonable efforts of the privacy
stakeholders other than those that performed them.
Pseudonymization retains linkability. Different data associated with the same pseudonym can be
linked. The larger the set of data associated with a given pseudonym, the larger is the risk that
property (a) is violated. Moreover, the smaller the group of natural persons to which a set of
pseudonymous data relates, the greater the likelihood of a PII principal being identifiable. Attributes
contained directly in the information in question and attributes that can be easily linked to this
information (e.g., by using a search engine or cross-referencing with other databases) should be
taken into account when determining whether or not the information relates to an identifiable natural
person.
Pseudonymization contrasts with anonymization. Anonymization processes also fulfil properties (a)
and (b) above, but destroy linkability. During anonymization, identity information is either erased or
substituted by aliases for which the assignment function or table is destroyed. Thus, anonymized
data is no longer PII.
4.4.5 Metadata
PII can be stored in an ICT system in such a way that it is not readily visible to the system user (i.e.
to the PII principal). Examples include the PII principal’s name stored as metadata in the properties
of a document, and comments or tracked changes stored as metadata in a word processing
document. If the PII principal became aware of the existence of the PII or the processing of the PII
for such a purpose, he or she might prefer that the PII not be processed in such a way or be shared
publicly.
4.4.6 Unsolicited PII
PII that was unsolicited by a PII controller or PII processor (i.e. unintentionally obtained) might also
be stored in an ICT system. For example, a PII principal could potentially provide PII to a PII
controller that was not requested or sought by the PII controller (e.g., additional PII provided in the
context of an anonymous feedback form on a website). The risk of collecting unsolicited PII can be
reduced by considering privacy safeguarding measures at the time of the design of the system (also
referred to as the concept of “privacy by design”).
4.4.7 Sensitive PII
Sensitivity extends to all PII from which sensitive PII can be derived. For instance, medical
prescriptions can reveal detailed information about the PII principal’s health. Even if PII does not
contain direct information about the PII principal’s sexual orientation or health, if it could be used to
infer such information, the PII could be sensitive. For purposes of this standard, PII must be treated
as sensitive PII where such inference and knowledge of the identity of the PII principal is reasonably
possible.
© ISO/IEC 2011 – All rights reserved 9

In some jurisdictions, what constitutes sensitive PII is also defined explicitly in legislation. Examples
include information revealing race, ethnic origin, religious or philosophical beliefs, political opinions,
trade union membership, sexual lifestyle or orientation, and the physical or mental health of the PII
principal. In other jurisdictions, sensitive PII might include information that could facilitate identity
theft or otherwise result in significant financial harm to the natural person (e.g., credit card numbers,
bank account information, or government-issued identifiers such as passport numbers, social
security numbers or drivers’ license numbers), and information that could be used to determine the
PII principal’s real time location.
The processing of sensitive PII requires special precautions. In some jurisdictions, the processing of
sensitive PII might be prohibited by applicable law even with the PII principal’s opt-in consent. Some
jurisdictions might require implementation of specific controls where certain types of sensitive PII are
processed (e.g., a requirement to encrypt medical PII when transmitting it over a public network).
4.5 Privacy safeguarding requirements
Organizations are motivated to protect PII for a variety of reasons: to protect the PII principal’s
privacy, to meet legal and regulatory requirements, to practice corporate responsibility, to enhance
consumer trust, etc. The purpose of this clause is to provide an overview of the different factors that
can influence the privacy safeguarding requirements that are relevant to a particular organization or
privacy stakeholder processing PII.
Privacy safeguarding requirements can relate to many different aspects of PII processing, e.g., the
collection and retention of PII, the transfer of PII to third parties, the contractual relationship among
PII controllers and PII processors, the international transfer of PII, etc. Privacy safeguarding
requirements can also vary in specificity. They might be very general in nature, e.g., consisting of an
enumeration of high-level privacy principles which an organization is expected to take into account
when processing PII. However, privacy safeguarding requirements can also involve very specific
restrictions on the processing of certain types of PII, or mandate the implementation of specific
privacy controls.
The design of any ICT system that involves the processing of PII should be preceded by an
identification of relevant privacy safeguarding requirements. The privacy implications of new or
substantially modified ICT systems involving the processing of PII should be resolved before those
ICT systems are implemented. Organizations routinely perform broad risk management activities and
develop risk profiles related to their ICT systems.
Risk management is defined as “coordinated activities to direct and control an organization with
regard to risk” (ISO Guide 73:2009). The privacy risk management process comprises the following
processes:
- establishing the context, by understanding the organization (e.g., PII processing, responsibilities), the
technical environment and the factors influencing privacy risk management (i.e. legal and regulatory
factors, contractual factors, business factors and other factors);
- risk assessment, by identifying, analysing and evaluating risks to PII principals (risks that they can be
adversely affected);
- risk treatment, by defining privacy safeguarding requirements, identifying and implementing privacy
controls to avoid or reduce the risks to PII principals;
- communication and consultation, by getting information from interested parties, obtaining consensus
on each risk management process, and informing PII principals and communicating about risks and
controls; and
- monitoring and review, by following up risks and controls, and improving the process.
One deliverable can be a privacy impact assessment, which is the component of risk management
that focuses on ensuring compliance with privacy and data protection legislation requirements and
assessing the privacy implications of new or substantially modified programs or activities. Privacy
impact assessments should be framed within an organization's broader risk management framework.
10 © ISO/IEC 2011 – All rights reserved

Privacy risk management
Examples
Legal and
Contractual factors Business factors Other factors
regulatory factors
• International, • Agreements between • Specific • Privacy preferences
national and local and among several characteristics of an of PII principal
laws different actors envisaged
application or its
context of use
• Industry guidelines, • Internal control
• Regulations • Company policies
codes of conduct, systems
and binding
best practices or
corporate rules
• Judicial decisions
standards
• Technical standards
• Agreements with
work councils or
other labour
organizations
Figure 1 – Factors influencing privacy risk management
Privacy safeguarding requirements are identified as part of the overall privacy risk management
process which is influenced by the following factors (as depicted in Figure 1 above and described
below):
- legal and regulatory factors for the safeguarding of the natural person’s privacy and the protection of
their PII;
- contractual factors such as industry guidelines, professional standards, company policies;
- business factors predetermined by a specific business application or in a specific use case context;
and
- other factors that can affect the design of ICT systems and the associated privacy safeguarding
requirements.
4.5.1 Legal and regulatory factors
Privacy safeguarding requirements are often reflected in (1) international, national and local laws,
(2) regulations, (3) judicial decisions or (4) negotiated agreements with work councils or other labour
organizations. Some examples of local and na
...

NORME ISO/IEC
INTERNATIONALE 29100
Première édition
2011-12-15
Technologies de l'information —
Techniques de sécurité — Cadre privé
Information technology — Security techniques — Privacy framework
Numéro de référence
©
ISO/IEC 2011
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO/IEC 2011
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.: [phone]
Fax: [phone]
E-mail: [e-mail]
Web: www.iso.org
Publié en Suisse
ii © ISO/IEC 2011 – Tous droits réservés

Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d'application . 1
2 Termes et définitions . 1
3 Symboles et abréviations . 5
4 Éléments de base du cadre pour la protection de la vie privée . 5
4.1 Vue d'ensemble du cadre pour la protection de la vie privée . 5
4.2 Acteurs et rôles . 5
4.2.1 Personnes concernées . . 5
4.2.2 Responsables de traitement de DCP . 5
4.2.3 Sous-traitants de DCP . 6
4.2.4 Tiers . 6
4.3 Interactions . 6
4.4 Reconnaissance des DCP . 7
4.4.1 Identifiants . 7
4.4.2 Autres caractéristiques distinctives . 8
4.4.3 Données reliées ou pouvant être reliées à une personne concernée . 9
4.4.4 Données pseudonymes . . . 9
4.4.5 Métadonnées .10
4.4.6 DCP non sollicitées .10
4.4.7 DCP sensibles .10
4.5 Exigences de protection de la vie privée.11
4.5.1 Facteurs légaux et réglementaires .12
4.5.2 Facteurs contractuels .13
4.5.3 Facteurs commerciaux .13
4.5.4 Autres facteurs .13
4.6 Politiques de protection de la vie privée .14
4.7 Mesures de protection de la vie privée .15
5 Les principes de protection de la vie privée de l'ISO/IEC 29100 .15
5.1 Vue d'ensemble des principes de protection de la vie privée .15
5.2 Consentement et choix .16
5.3 Licéité et spécification de la finalité .17
5.4 Limitation de la collecte .17
5.5 Minimisation des données .17
5.6 Limitation de l'utilisation, de la conservation et de la divulgation .18
5.7 Exactitude et qualité .18
5.8 Ouverture, transparence et information .19
5.9 Participation et accès individuels .19
5.10 Responsabilité .20
5.11 Sécurité de l'information .21
5.12 Conformité aux règles de protection de la vie privée .21
Annexe A (informative) Correspondance entre les concepts de l'ISO/IEC 29100 et les
concepts de l'ISO/IEC 27000 .22
Bibliographie .23
© ISO/IEC 2011 – Tous droits réservés iii

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 Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/
IEC, Partie 2.
La tâche principale du comité technique mixte est d'élaborer les Normes internationales. Les projets de
Normes internationales adoptés par le comité technique mixte sont soumis aux organismes nationaux
pour vote. Leur publication comme Normes internationales requiert l'approbation de 75 % au moins
des organismes nationaux votants.
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.
L'ISO/IEC 29100 a été élaborée par le comité technique mixte ISO/IEC JTC 1, Technologies de l'information,
sous-comité SC 27, Techniques de sécurité des technologies de l'information.
iv © ISO/IEC 2011 – Tous droits réservés

Introduction
La présente Norme internationale propose un cadre de haut niveau pour la protection des données à
caractère personnel (DCP) au sein des systèmes de technologies de l'information et de la communication
(TIC). Elle est d'une portée générale par nature, et place les aspects organisationnels, techniques et
procéduraux dans un cadre global pour la protection de la vie privée.
Le cadre pour la protection de la vie privée a pour but d'aider les organismes à définir leurs exigences
de protection de la vie privée associées aux DCP dans un environnement TIC:
— en établissant une terminologie commune relative à la protection de la vie privée;
— en définissant les acteurs et leurs rôles dans le traitement de DCP;
— en décrivant les exigences de protection de la vie privée; et
— en faisant référence à des principes connus de protection de la vie privée.
Dans certaines juridictions, les références de la présente Norme internationale aux exigences
de protection de la vie privée peuvent être considérées comme complémentaires aux exigences
légales de protection des DCP. Au vu du nombre croissant des technologies de l'information et de la
communication traitant des DCP, il est important de disposer de Normes internationales sur la sécurité
de l'information qui garantissent une compréhension commune pour la protection des DCP. La présente
Norme internationale a pour but d'améliorer les normes de sécurité existantes en attirant l’attention
sur le traitement de DCP.
L'utilisation et la valeur commerciales croissantes des DCP, le partage des DCP entre plusieurs
juridictions légales, et la complexité grandissante des systèmes TIC, peuvent rendre difficile, pour
un organisme, la tâche d'assurer la protection de la vie privée et la conformité avec les différentes
lois applicables. Les parties prenantes en matière de protection de la vie privée peuvent éviter toute
incertitude et méfiance en gérant correctement les questions de vie privée et en évitant les cas
d'utilisation abusive des DCP.
L'utilisation de la présente Norme internationale permet:
— d'aider à la conception, la mise en œuvre, l'exploitation et la maintenance de systèmes TIC qui
traitent des DCP et les protègent;
— de favoriser des solutions innovantes pour mettre en place la protection des DCP au sein des
systèmes TIC; et
— d'améliorer les programmes de protection de la vie privée des organismes via l’utilisation des
meilleures pratiques.
Le cadre pour la protection de la vie privée défini dans la présente Norme internationale peut servir
de base à des initiatives complémentaires de normalisation dans le domaine de la protection de la vie
privée, comme:
— une architecture de référence technique;
— la mise en œuvre et l'utilisation de technologies spécifiques pour la protection de la vie privée, ainsi
que le management global de la protection de la vie privée;
— des mesures de protection de la vie privée pour les processus de traitement de données qui sont
sous-traités;
— l'étude des risques sur la vie privée; ou
— des spécifications d'ingénierie spécifiques.
Certaines juridictions peuvent exiger la conformité avec un ou plusieurs des documents référencés dans
l‘ISO/IEC JTC 1/SC 27 WG 5 Standing Document 2 (WG 5 SD2) — Official Privacy Documents References
© ISO/IEC 2011 – Tous droits réservés v

[3] ou avec d’autres lois et règlements applicables, mais la présente Norme internationale ne vise pas à
constituer un modèle mondial de politique, ni un cadre législatif.
vi © ISO/IEC 2011 – Tous droits réservés

NORME INTERNATIONALE ISO/IEC 29100:2011(F)
Technologies de l'information — Techniques de sécurité —
Cadre privé
1 Domaine d'application
La présente Norme internationale fournit un cadre pour la protection de la vie privée qui:
— spécifie une terminologie commune relative à la protection de la vie privée;
— définit les acteurs et leurs rôles dans le traitement de données à caractère personnel (DCP);
— décrit les éléments à prendre en considération pour la protection de la vie privée; et
— fournit des références à des principes connus de protection de la vie privée pour les technologies de
l'information.
La présente Norme internationale s'applique aux personnes physiques et aux organismes participant
à la spécification, à la fourniture, à l'architecture, à la conception, au développement, aux essais, à
la maintenance, à l'administration et à l'exploitation des systèmes ou services de technologies de
l'information et de la communication dans lesquels des mesures de protection de la vie privée sont
requises pour le traitement de DCP.
2 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s'appliquent.
NOTE Pour faciliter l'utilisation de la famille de Normes internationales ISO/IEC 27000 dans le contexte
spécifique de la protection de la vie privée, et pour intégrer les concepts de protection de la vie privée dans le
contexte de l'ISO/IEC 27000, les concepts de l'ISO/IEC 27000, qui correspondent aux concepts de l'ISO/IEC 29100
utilisés dans la présente Norme internationale, sont indiqués dans le tableau à l'Annexe A.
2.1
anonymat
caractéristique d'une donnée qui ne permet pas d'identifier directement ou indirectement la personne
concernée par des données à caractère personnel
2.2
anonymisation
processus par lequel des données à caractère personnel (DCP) sont altérées irréversiblement, de telle
façon que la personne concernée ne puisse plus être identifiée, directement ou indirectement, par le
responsable du traitement des DCP, seul ou en collaboration avec une autre partie
2.3
données anonymisées
données générées en sortie d'un processus d'anonymisation de données à caractère personnel
2.4
consentement
accord spécifique et éclairé accordé librement par la personne concernée pour le traitement de ses
données à caractère personnel (DCP)
2.5
identifiabilité
condition ayant pour conséquence l'identification, directe ou indirecte, d'une personne concernée par
des données à caractère personnel (DCP), sur la base d'un ensemble donné de données à caractère
personnel
© ISO/IEC 2011 – Tous droits réservés 1

2.6
identifier
établir un lien entre une personne concernée par des données à caractère personnel (DCP) et des
données à caractère personnel (DCP) ou un ensemble de DCP
2.7
identité
ensemble d'attributs qui permettent d'identifier la personne concernée par des données à caractère
personnel
2.8
accord préalable
processus ou type de politique par lequel la personne concernée par des données à caractère personnel
(DCP) doit activement exprimer son consentement explicite et préalable au traitement de ses données à
caractère personnel (DCP), pour une finalité donnée
Note 1 à l'article: Un terme différent, «acceptation par défaut», est souvent utilisé dans le contexte du principe
«consentement et choix» de protection de la vie privée. Il décrit un processus ou un type de politique par lequel
la personne concernée doit effectuer une démarche séparée afin de refuser d'accorder son consentement, ou de
le retirer, ou de s'opposer à un type de traitement spécifique. L'adoption d'une politique d'acceptation par défaut
implique que le responsable de traitement de DCP a le droit de traiter les DCP de la manière prévue. Ce droit peut
être signifié par une certaine action de la personne concernée différente du consentement (par exemple, le fait de
passer commande dans une boutique en ligne).
2.9
données à caractère personnel
DCP
toute donnée qui (a) peut être utilisée pour identifier la personne à laquelle cette donnée se rapporte,
ou qui (b) est ou peut être directement ou indirectement associée à une personne concernée
Note 1 à l'article: Pour déterminer si une personne concernée est identifiable, il convient de tenir compte de tous
les moyens pouvant être raisonnablement utilisés par la partie prenante en matière de protection de la vie privée
qui détient les données, ou par toute autre partie, pour identifier cette personne physique.
2.10
responsable de traitement de DCP
partie(s) prenante(s) en matière de protection de la vie privée qui détermine(-nt) les finalités et les
moyens pour le traitement de données à caractère personnel (DCP), autre(s) que les personnes
physiques qui utilisent des données à des fins personnelles
Note 1 à l'article: Un responsable de traitement de DCP demande parfois à des tiers (par exemple, des sous-
traitants de DCP) de traiter des DCP en son nom, bien qu'un tel traitement relève toujours de la responsabilité du
responsable de traitement de DCP.
2.11
personne concernée
personne physique à qui se rapportent les données à caractère personnel (DCP)
Note 1 à l'article: Selon la juridiction et la loi applicable en matière de protection des données et de la vie privée,
en anglais, le terme «data subject» peut également être employé en lieu et place de «PII principal».
2.12
sous-traitant de DCP
partie prenante en matière de protection de la vie privée qui traite des données à caractère personnel
(DCP) pour le compte d'un responsable de traitement de DCP et conformément à ses instructions
2.13
violation de données à caractère personnel
situation dans laquelle des données à caractère personnel sont traitées en violation d'une ou de
plusieurs exigences applicables en matière de protection de la vie privée
2 © ISO/IEC 2011 – Tous droits réservés

2.14
mesures de protection de la vie privée
mesures de traitement des risques sur la vie privée destinées à réduire leur probabilité ou leurs
conséquences
Note 1 à l'article: Les mesures de protection de la vie privée comprennent des mesures organisationnelles,
physiques et techniques, telles que, par exemple, les politiques, les procédures, les lignes directrices, les contrats
juridiques, les pratiques de management ou les structures organisationnelles.
Note 2 à l'article: Le terme «mesure de protection» est également utilisé comme synonyme de «mesure de
sauvegarde» ou «contre-mesure».
2.15
technologie contribuant à la protection de la vie privée
(Privacy Enhancing Technologies – PET)
mesure de protection de la vie privée constituée de mesures, produits ou services des technologies de
l'information et de la communication (TIC) qui protègent la vie privée en éliminant ou en réduisant les
données à caractère personnel (DCP) ou en empêchant tout traitement inutile et/ou indésirable des
DCP, tout cela sans perte de la fonctionnalité du système TIC
Note 1 à l'article: Les exemples de technologies contribuant à la protection de la vie privée comprennent, sans s'y
limiter, les outils d'anonymisation et de pseudonymisation qui éliminent, réduisent, masquent ou désidentifient
les DCP, ou qui empêchent tout traitement inutile, non autorisé et/ou indésirable des DCP.
Note 2 à l'article: Le masquage est le processus qui consiste à obscurcir des éléments de DCP.
2.16
politique de protection de la vie privée
intention et orientation générales, règles et engagement, tels qu'ils sont formellement exprimés par un
responsable de traitement de données à caractère personnel (DCP), en relation avec le traitement de
données à caractère personnel DCP dans un contexte particulier
2.17
préférences relatives à protection de la vie privée
choix spécifiques faits par une personne concernée par des données à caractère personnel (DCP) et relatifs
à la manière dont il convient de traiter ses données à caractère personnel DCP pour une finalité donnée
2.18
principes de protection de la vie privée
ensemble de valeurs partagées qui régissent la protection des données à caractère personnel (DCP)
quand elles sont traitées par des systèmes de technologies de l'information et de la communication
2.19
risque sur la vie privée
effet de l'incertitude sur la protection de la vie privée
Note 1 à l'article: Le risque est défini comme «l'effet de l'incertitude sur l'atteinte des objectifs» dans le
Guide ISO 73 et l'ISO 31000.
Note 2 à l'article: L'incertitude est l'état, même partiel, de défaut d'information concernant la compréhension ou
la connaissance d'un événement, de ses conséquences ou de sa vraisemblance.
2.20
étude des risques sur la vie privée
processus général d'identification des risques, d'analyse du risque et d'évaluation du risque par rapport
au traitement de données à caractère personnel (DCP)
Note 1 à l'article: Ce processus est également appelé études d'impacts sur la vie privée.
© ISO/IEC 2011 – Tous droits réservés 3

2.21
exigences de protection de la vie privée
ensemble d'exigences qu'un organisme doit prendre en compte lorsqu’il traite des données à caractère
personnel (DCP), eu égard à la protection des DCP
2.22
partie prenante en matière de protection de la vie privée
personne physique ou morale, autorité publique, service ou tout autre organisme susceptible d'affecter,
d'être affecté ou de se sentir lui-même affecté par une décision ou une activité associée au traitement
de données à caractère personnel (DCP)
2.23
traitement de DCP
opération ou ensemble d'opérations exécutées sur des données à caractère personnel (DCP)
Note 1 à l'article: Les opérations de traitement des DCP incluent par exemple, sans toutefois s'y limiter, la collecte,
le stockage, l'altération, la récupération, la consultation, la divulgation, l'anonymisation, la pseudonymisation, la
distribution ou toute autre mise à disposition, la suppression ou la destruction de DCP.
2.24
pseudonymisation
processus appliqué aux données à caractère personnel (DCP) qui remplace les données d'identification
par un alias
Note 1 à l'article: La pseudonymisation peut être effectuée soit par les personnes concernées elles-mêmes, soit
par les responsables de traitement de DCP. La pseudonymisation peut permettre aux personnes concernées
d'utiliser régulièrement une ressource ou un service sans divulguer leur identité à cette ressource ou ce service
(ou entre services), tout en restant responsable de cette utilisation.
Note 2 à l'article: La pseudonymisation n'exclut pas la possibilité qu'il puisse y avoir (un nombre restreint de)
parties prenantes en matière de protection de la vie privée, autres que le responsable de traitement de DCP des
données pseudonymisées, capable de déterminer l'identité de la personne concernée d'après l'alias et les données
qui y sont rattachées.
2.25
utilisation secondaire
traitement de données à caractère personnel (DCP) dans des conditions qui diffèrent des conditions
initiales
Note 1 à l'article: Les conditions qui diffèrent des conditions initiales pourraient mettre en jeu, par exemple, une
nouvelle finalité de traitement des DCP, un nouveau destinataire des DCP, etc.
2.26
DCP sensibles
catégorie de données à caractère personnel (DCP), soit qui sont sensibles par nature, comme celles
qui concernent la sphère la plus privée de la personne concernée, soit qui pourraient avoir un impact
significatif sur la personne concernée
Note 1 à l'article: Dans certaines juridictions ou dans des contextes spécifiques, les DCP sensibles sont définies
suivant leur nature et peuvent être des DCP qui révèlent l'origine raciale, les opinions politiques ou les convictions
religieuses ou autres, les données personnelles sur la santé, la vie sexuelle ou les antécédents judiciaires, ainsi
que d'autres DCP qui pourraient être considérées comme sensibles.
2.27
tiers
partie prenante en matière de protection de la vie privée, autre que la personne concernée par les
données à caractère personnel, le responsable de traitement de DCP et le sous-traitant de DCP, et
les personnes physiques autorisées à traiter les données sous l'autorité directe du responsable de
traitement de DCP ou du sous-traitant de DCP
4 © ISO/IEC 2011 – Tous droits réservés

3 Symboles et abréviations
Les abréviations suivantes sont communes à l'ISO/IEC 29100.
TIC Technologies de l'information et de la communication
PET Technologie contribuant à la protection de la vie privée
DCP Données à caractère personnel
4 Éléments de base du cadre pour la protection de la vie privée
4.1 Vue d'ensemble du cadre pour la protection de la vie privée
Les éléments suivants concernent la protection de la vie privée et le traitement de DCP dans les systèmes
TIC, et constituent le cadre de protection de la vie privée décrit dans la présente Norme internationale:
— acteurs et rôles;
— interactions;
— reconnaissance des DCP;
— exigences de protection de la vie privée;
— politique de protection de la vie privée; et
— mesures de protection de la vie privée.
Des concepts, des définitions et des recommandations d'autres sources officielles ont été prises
en compte pour le développement de ce cadre pour la protection de la vie privée. Ces sources sont
répertoriées dans l'ISO/IEC JTC 1/SC 27 WG 5 Standing Document 2 (WG 5 SD2) — Official Privacy
Documents References [3].
4.2 Acteurs et rôles
Pour les besoins de la présente norme, il est important d'identifier les acteurs qui interviennent dans le
traitement de DCP. Quatre types d'acteurs peuvent intervenir dans le traitement de DCP: les personnes
concernées, les responsables de traitement de DCP, les sous-traitants de DCP et les tiers.
4.2.1 Personnes concernées
Les personnes concernées fournissent leurs DCP pour traitement par les responsables de traitement
de DCP et les sous-traitants de DCP et, en l'absence de toutes dispositions contraires dans les lois
applicables, elles donnent leur consentement et déterminent leurs préférences relatives à la protection
de la vie privée sur la manière dont il convient que leurs DCP soient traitées. Les personnes concernées
peuvent inclure, par exemple, un employé mentionné dans le système de ressources humaines d'une
société, un consommateur mentionné dans un rapport d'antécédents de crédit, et un patient mentionné
dans un dossier médical informatisé. Il n'est pas toujours nécessaire que la personne physique respective
soit identifiée directement sous son nom pour être considérée comme une personne concernée. Si la
personne concernée à laquelle se rapportent les DCP peut être identifiée indirectement (par exemple au
moyen d'un identifiant de compte, un numéro de sécurité sociale, ou éventuellement par le biais d'une
combinaison d'attributs accessibles), elle est considérée comme personne concernée pour l'ensemble de
ces DCP.
4.2.2 Responsables de traitement de DCP
Un responsable de traitement de DCP détermine pourquoi (finalité) et comment (moyens) le traitement
de DCP a lieu. Il convient que le responsable de traitement de DCP garantisse le respect des principes de
© ISO/IEC 2011 – Tous droits réservés 5

protection de la vie privée portés par le présent cadre durant le traitement de DCP sous sa responsabilité
(par exemple en mettant en œuvre les mesures de protection de la vie privée requises). Il peut y avoir
plus d'un responsable de traitement de DCP pour le même ensemble de DCP ou ensemble d'opérations
réalisées sur les DCP (pour des finalités légitimes identiques ou différentes). Dans ce cas, les différents
responsables de traitement de DCP doivent travailler ensemble et prendre les dispositions nécessaires
afin de garantir le respect des principes de protection de la vie privée durant le traitement de DCP. Un
responsable de traitement de DCP peut également décider de faire effectuer en son nom la totalité ou
une partie des opérations de traitement par une partie prenante en matière de protection de la vie
privée différente. Il convient que les responsables de traitement de DCP déterminent soigneusement
si les DCP qu'ils traitent sont sensibles ou non, et mettent en œuvre des mesures de protection de la
vie privée et des mesures de sécurité raisonnables et appropriées, sur la base des exigences énoncées
dans la juridiction applicable ainsi que de tout effet néfaste potentiel pour les personnes concernées, tel
qu'identifié au cours d'une étude des risques sur la vie privée.
4.2.3 Sous-traitants de DCP
Un sous-traitant de DCP réalise le traitement de DCP pour le compte d'un responsable de traitement de
DCP, agit pour le compte d'un responsable de traitement de DCP ou conformément à ses instructions,
observe les exigences relatives à la protection de la vie privée stipulées, et met en œuvre les mesures de
protection de la vie privée correspondantes. Sous certaines juridictions, le sous-traitant de DCP est lié
par un contrat juridique.
4.2.4 Tiers
Un tiers peut recevoir des DCP d'un responsable de traitement de DCP ou d'un sous-traitant de DCP. Un
tiers ne traite pas de DCP pour le compte d'un responsable de traitement de DCP. En général, le tiers
deviendra un responsable de traitement de DCP en titre une fois qu'il aura reçu les DCP en question.
4.3 Interactions
Les acteurs identifiés dans le paragraphe ci-dessus peuvent interagir de différentes manières. Pour ce
qui est des flux possibles de DCP entre les personnes concernées, le responsable de traitement de DCP
et le sous-traitant de DCP, les scénarios suivants peuvent être identifiés:
a) la personne concernée fournit des DCP à un responsable de traitement de DCP (par exemple lors de
l'enregistrement pour un service assuré par le responsable de traitement de DCP);
b) le responsable de traitement de DCP fournit des DCP à un sous-traitant de DCP, qui traite ces
DCP pour le compte du responsable de traitement de DCP (par exemple dans le cadre d'un accord
d'externalisation);
c) la personne concernée fournit des DCP à un sous-traitant de DCP qui traite ces DCP pour le compte
du responsable de traitement de DCP;
d) le responsable de traitement de DCP fournit à la personne concernée des DCP qui se rapportent à
celle-ci (par exemple suite à une demande faite par la personne concernée);
e) le sous-traitant de DCP fournit des DCP à la personne concernée (par exemple suivant les
instructions du responsable de traitement de DCP); et
f) le sous-traitant de DCP fournit des DCP au responsable de traitement de DCP (par exemple après
avoir effectué le service pour lequel il a été désigné).
Les rôles de la personne concernée, du responsable de traitement de DCP, du sous-traitant de DCP et du
tiers dans ces scénarios sont illustrés dans le Tableau 1.
Il est nécessaire de faire une distinction entre les sous-traitants de DCP et les tiers, car le contrôle
juridique des DCP relève toujours de la responsabilité du responsable de traitement de DCP d'origine
quand elles sont envoyées au sous-traitant de DCP, alors qu'un tiers peut devenir un responsable de
traitement de DCP en titre une fois qu'il a reçu les DCP en question. Par exemple, quand un tiers décide
6 © ISO/IEC 2011 – Tous droits réservés

de transférer des DCP qu'il a reçues d'un responsable de traitement de DCP à un autre tiers, il agit en
tant que responsable de traitement de DCP en titre, et ne sera donc plus considéré comme un tiers.
Pour ce qui est des flux possibles de DCP entre d'une part les responsables de traitement de DCP et les
sous-traitants de DCP, et les tiers d'autre part, les scénarios suivants peuvent être identifiés:
g) le responsable de traitement de DCP fournit des DCP à un tiers (par exemple dans le contexte d'un
accord commercial); et
h) le sous-traitant de DCP fournit des DCP à un tiers (par exemple suivant les instructions du
responsable de traitement de DCP).
Les rôles du responsable de traitement de DCP, et du tiers dans ces scénarios sont également illustrés
dans le Tableau 1.
Tableau 1 — Flux possibles de DCP entre la personne concernée, le responsable de traitement
de DCP, le sous-traitant de DCP et un tiers, et leurs rôles
Personne concernée Responsable de Sous-traitant de Tiers
traitement de DCP DCP
Scénario a) Fournisseur de DCP Destinataire de DCP — —
Scénario b) — Fournisseur de DCP Destinataire de DCP —
Scénario c) Fournisseur de DCP — Destinataire de DCP —
Scénario d) Destinataire de DCP Fournisseur de DCP — —
Scénario e) Destinataire de DCP — Fournisseur de DCP —
Scénario f) — Destinataire de DCP Fournisseur de DCP —
Scénario g) — Fournisseur de DCP — Destinataire de DCP
Scénario h) — — Fournisseur de DCP Destinataire de DCP
4.4 Reconnaissance des DCP
Il est nécessaire de prendre plusieurs facteurs en compte pour déterminer s'il convient de considérer
une personne physique comme étant identifiable ou non. NOTE Il convient en particulier de tenir
compte de tous les moyens pouvant être raisonnablement utilisés par la partie prenante en matière
de protection de la vie privée qui détient les données, ou par toute autre partie, pour identifier cette
personne physique. Il convient que les systèmes TIC prennent en charge des mécanismes qui porteront
ces DCP à la connaissance de la personne concernée, et fourniront à la personne physique les moyens
appropriés de contrôler le partage de ces données. Le paragraphe suivant donne des précisions
supplémentaires sur la manière de déterminer s'il convient de considérer une personne concernée
comme étant identifiable ou non.
4.4.1 Identifiants
Dans certains cas, l'identifiabilité de la personne concernée peut être très claire (par exemple, quand
les données contiennent ou sont associées à un identifiant permettant de faire référence à, ou de
communiquer avec, la personne concernée). Des données peuvent être considérées comme DCP au
moins dans les cas suivants:
— si elles contiennent ou sont associées à un identifiant permettant de faire référence à une personne
physique (par exemple un numéro de sécurité sociale);
— si elles contiennent ou sont associées à un identifiant qui peut être relié à une personne physique
(par exemple un numéro de passeport ou un numéro de compte);
— si elles contiennent ou sont associées à un identifiant qui peut être utilisé pour établir une
communication avec une personne physique identifiée (par exemple un emplacement géographique
précis ou un numéro de téléphone); ou
© ISO/IEC 2011 – Tous droits réservés 7

— si elles contiennent une référence qui relie les données à n'importe lequel des identifiants ci-dessus.
4.4.2 Autres caractéristiques distinctives
Il n'est pas forcément nécessaire que les données soient associées à un identifiant pour qu'elles soient
considérées comme DCP. Les données seront également considérées comme DCP si elles contiennent ou
sont associées à une caractéristique qui distingue une personne physique d'autres personnes physiques
(par exemple les données biométriques).
Tout attribut prenant une valeur qui identifie une personne concernée de manière unique est à
considérer comme une caractéristique distinctive. À noter que le fait qu'une caractéristique donnée
distingue une personne physique d'autres personnes physiques peut changer suivant le contexte
d'utilisation. Par exemple, si le nom de famille d'une personne physique peut être insuffisant pour
identifier cette personne physique à l'échelle mondiale, il suffira souvent pour distinguer une personne
physique à l'échelle d'une société.
En outre, il peut également y avoir des situations dans lesquelles une personne physique est identifiable,
même s’il n’y a aucun attribut qui l'identifie de manière unique. C'est le cas quand une combinaison
de plusieurs attributs pris ensemble distingue cette personne physique d'autres personnes physiques.
Le fait qu'une personne physique soit identifiable ou non d'après une combinaison d'attributs peut
aussi dépendre du domaine spécifique. Par exemple, la combinaison des attributs «sexe féminin», «45»
et «avocat» peut suffire à identifier une personne physique dans une société particulière, mais sera
souvent insuffisante pour identifier cette personne physique à l'extérieur de cette société.
Le Tableau 2 donne des exemples d'attributs qui pourraient être des DCP, suivant le domaine. Ces
exemples sont donnés à titre indicatif.
8 © ISO/IEC 2011 – Tous droits réservés

Tableau 2 — Exemple d'attributs pouvant être utilisés pour identifier des personnes physiques
Exemples
Âge ou besoins particuliers des personnes physiques vulnérables
Allégations de conduite criminelle
Toute donnée recueillie dans le cadre de services de santé
Numéro de compte en banque ou de carte de crédit
Identifiant biométrique
Relevés de carte de crédit
Antécédents judiciaires ou délits commis
Rapports d'enquête criminelle
Numéro client
Date de naissance
Données de diagnostic
Handicaps
Honoraires de médecin
Salaires des employés et fichiers des ressources humaines
Profil financier
Sexe
Position GPS
Trajectoires GPS
Adresse personnelle
Adresse IP
Emplacement dérivé de systèmes de télécommunications
Antécédents médicaux
Nom
Identifiants nationaux (par exemple numéro de passeport)
Adresse e-mail personnelle
Codes d'identification personnels (PIN) ou mots de passe
Intérêts personnels dérivés du suivi de l'utilisation de sites web
Profil personnel ou comportemental
Numéro de téléphone personnel
Photographie ou vidéo identifiable à une personne physique
Préférences de produit et de service
Origine raciale ou ethnique
Convictions religieuses ou philosophiques
Orientation sexuelle
Appartenance à un syndicat
Factures de services publics
4.4.3 Données reliées ou pouvant être reliées à une personne concernée
Si les données en question n'identifient pas une personne concernée, il convient de déterminer si ces
données sont ou peuvent être reliées à l'identité d'une personne physique.
Une fois que la relation avec une personne physique identifiable est établie, il est nécessaire de
déterminer si les données révèlent des informations sur cette personne physique, par exemple si elles
font référence à ses caractéristiques ou à son comportement. À titre d'exemple, on peut citer les dossiers
médicaux, les profils financiers ou les intérêts personnels dérivés du suivi de la consultation de sites
web. Également, de simples déclarations d'attribut au sujet d'une personne physique, telles que l'âge ou
le sexe d'une personne physique, peuvent donner le statut de DCP aux données reliées. Quoi qu'il en soit,
si la relation avec une personne physique identifiable peut être établie, ces données sont également à
traiter comme des DCP.
4.4.4 Données pseudonymes
Afin de limiter la capacité des responsables de traitements de DCP et des sous-traitants de DCP
d'identifier la personne concernée, les données d'identité peuvent être remplacées par des alias. Ce
remplacement est généralement effectué par un fournisseur de DCP avant transmission des DCP au
destinataire de DCP, en particulier dans les scénarios a, b, c, g et h du Tableau 1.
© ISO/IEC 2011 – Tous droits réservés 9

Certains processus commerciaux font appel à des sous-traitants désignés qui effectuent la substitution
et gèrent le tableau ou la fonction de correspondance. C'est souvent le cas dès que des données sensibles
doivent être traitées par des parties prenantes en matière de protection de la vie privée qui ne les ont
pas recueillies.
La substitution est considérée comme une pseudonymisation à condition que:
a) les attributs qui restent associés à l'alias ne suffisent pas à identifier la personne concernée à
laquelle ils se rapportent; et
b) l'attribution d'alias est telle qu'elle ne peut pas être inversée par des efforts raisonnables de la part
des parties prenantes en matière de protection de la vie privée autres que celles qui les ont fournis.
La pseudonymisation préserve la corrélation. Les différentes données associées au même pseudonyme
peuvent être reliées. Plus l'ensemble de données associées à un pseudonyme particulier est important,
plus le risque que la propriété (a) puisse être compromise est élevé. En outre, plus le groupe de personnes
physiques auxquelles un ensemble de données pseudonymes se rapportent est petit, plus la probabilité
que la personne concernée soit identifiable est élevée. Il convient que les attributs contenus directement
dans les informations en question et les attributs qui peuvent être facilement reliés à ces informations
(par exemple à l'aide d'un moteur de recherche ou par renvois à d'autres bases de données) soient pris en
compte pour déterminer si les informations se rapportent à une personne physique identifiable ou non.
La pseudonymisation contraste avec l'anonymisation. Les processus d'anonymisation satisfont
également aux propriétés (a) et (b) ci-dessus, mais détruisent la corrélation. Durant l'anonymisation,
les données d'identité sont soit supprimées soit remplacées par des alias pour lesquels la fonction ou le
tableau de correspondance est détruit. Les données anonymisées ne sont donc plus des DCP.
4.4.5 Métadonnées
Les DCP peuvent être stockées dans un système TIC d’une manière qui n’est pas facilement visible par
l'utilisateur du système (c'est-à-dire par la personne concernée). Les exemples comprennent le nom
de la personne concernée stocké sous forme de métadonnées dans les propriétés d'un document, et
les commentaires ou le suivi de modifications stockés sous forme de métadonnées dans un document
de traitement de texte. Si la personne concernée prenait connaissance de l'existence des DCP ou du
traitement des DCP dans un tel but, elle pourrait préférer que le
...