ISO/IEC 29100: ISO/IEC 29100 – Tutorial (about 60 minutes)

ISO/IEC 29100 is the international privacy framework. It gives everyone who builds or runs IT systems the same basic language for personal data: who the actors are, what counts as personally identifiable information, where privacy requirements come from and which eleven principles should guide the processing. Engineers, architects, privacy officers, security staff and auditors use it as the shared foundation for privacy work and for other ISO privacy standards. After this tutorial you will be able to use its vocabulary correctly, identify PII and the roles in a real system, derive privacy requirements and apply the eleven principles to a service of your own.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is ISO/IEC 29100:2024, the second edition, published in February 2024 by ISO and IEC through their joint subcommittee ISO/IEC JTC 1/SC 27 (Information security, cybersecurity and privacy protection). Its title is "Information technology – Security techniques – Privacy framework". It cancels and replaces the first edition, ISO/IEC 29100:2011, and incorporates its Amendment 1:2018 (clarifications). The foreword calls the 2024 edition a minor revision rather than a rewrite: a normative references clause was added, cross-references were updated, the term "secondary use" became "secondary purpose" and the bibliography was refreshed. The standard is listed as published (stage 60.60) and no revision of it had been announced; in Europe a draft (prEN ISO/IEC 29100:2026) to adopt the 2024 edition was out for enquiry in 2026, to replace the older EN ISO/IEC 29100:2020 adoption of the 2011 text. Verified 2026-10-29 on the Standard Norge catalogue entry, the publisher's official preview of the 2024 edition (foreword and contents) and the DIN draft listing.

Who this is for: software engineers, architects and product owners who design systems that handle personal data; security and IT people who are asked to "add privacy" to existing controls; privacy, legal and compliance staff who want a technology-neutral reference; and auditors or consultants who meet ISO/IEC 29100 because other standards, such as ISO/IEC 27701 or ISO/IEC 27018, are built on it.

Prerequisites: none. A general idea of what a database or an online service is will help, but every privacy term is explained when it first appears. You do not need a copy of the standard to follow this tutorial. If you implement or audit against it, obtain an official copy from ISO, IEC or your national standards body: standards text is copyrighted, and this course explains it in its own words.

By the end of this tutorial:

You will be able to explain why ISO/IEC 29100 exists, what it covers and what it deliberately does not do.
You will be able to use its core vocabulary, including PII, PII principal, PII controller, PII processor, third party and sensitive PII.
You will be able to recognise PII in a real data set, including identifiers, linkable information, pseudonymous data and metadata.
You will be able to derive privacy safeguarding requirements from legal, contractual, business and other factors and turn them into policies and controls.
You will be able to apply each of the eleven privacy principles to a concrete service.
You will be able to explain how conformity with the framework is shown, given that it is not a certifiable standard on its own.
You will be able to place ISO/IEC 29100 among related standards and frameworks such as ISO/IEC 27701, ISO/IEC 29134, the OECD Privacy Guidelines and the GDPR.

Lesson 1 – Origins, purpose and scope

Why a privacy framework was needed

Before ISO/IEC 29100, people who worked on privacy in IT often talked past each other. A lawyer in Europe spoke of "data subjects" and "personal data", an American engineer of "PII" and "users", a security specialist of "assets" and "confidentiality". Laws differed from country to country, and every company wrote its own privacy vocabulary. That made it hard to write technical standards for privacy, hard to compare products, and hard to give a supplier in another country clear instructions.

ISO and IEC, through the security subcommittee SC 27, therefore set out to write a high-level, technology-neutral and jurisdiction-neutral framework. The goal was not to replace privacy laws, but to give a common reference that could sit underneath them: a set of terms, a model of the actors, an explanation of where privacy requirements come from, and a list of widely recognised privacy principles. The first edition appeared in 2011. It drew on long-standing international work, especially the OECD Guidelines on the protection of privacy, which had shaped privacy laws since 1980, and on the privacy laws and practices of many countries.

What the framework does

In short, ISO/IEC 29100 does four things. First, it fixes a common privacy terminology. Second, it defines the actors that take part in processing personal data and the roles they can play. Third, it describes the considerations that lead to privacy safeguards: what requirements exist, where they come from and how they translate into policies and controls. Fourth, it presents eleven privacy principles that should guide the design, implementation and operation of any system that processes personal data.

Because it stays at this level, the standard is a foundation for other work. ISO/IEC 27701 (privacy information management systems) uses it as its normative reference. ISO/IEC 27018 (PII protection in public clouds) frames its additional controls with its principles. ISO/IEC 29134 (privacy impact assessment), ISO/IEC 29151 (a code of practice for PII protection) and ISO/IEC 29101 (a privacy architecture framework) all reuse its vocabulary. Learning ISO/IEC 29100 is therefore the shortest path into the whole family of ISO privacy standards.

Scope: who it applies to

The standard addresses anyone, individual or organisation, who takes part in the life of an information and communication technology (ICT) system or service that needs privacy controls because it processes PII: from specifying and buying it, through architecture, design, development and testing, to day-to-day administration and operation. That is a very wide group. It includes a start-up building a mobile app, a hospital buying a patient system, a cloud provider running a platform for others, and a government agency commissioning a citizen portal. The framework applies to large and small organisations, in the public and private sector, in any country.

What it does not do

It is just as important to know the limits of the framework. ISO/IEC 29100 does not contain "shall" requirements against which an organisation can be certified. It does not tell you which law applies to you, and it does not override any law. It does not list specific technical controls in the way ISO/IEC 27002 lists security controls. It does not prescribe a management system with clauses on leadership, internal audit and management review; that is the job of ISO/IEC 27701. Instead, it provides the concepts and principles that make all of those other things possible. Think of it as the grammar and core vocabulary of privacy engineering, not as a rulebook.

Its focus is ICT systems that process information about identifiable people; it is not about the confidentiality of company information.

Why the 2024 edition matters little for learners

If you learnt the 2011 text, almost everything still holds. The second edition kept the structure, actors and the eleven principles. The main visible changes are housekeeping: a new Clause 2 for normative references (it simply states that there are none, but it shifts the numbering of the later clauses by one, so the terms move from Clause 2 to Clause 3 and the principles from Clause 5 to Clause 6), updated cross-references, the change from "secondary use" to "secondary purpose" and a refreshed bibliography. When you read older articles, books and training material about ISO/IEC 29100, you can rely on their explanation of the concepts, but check the clause numbers they quote.

Lesson 2 – Key concepts and vocabulary

A large part of the value of ISO/IEC 29100 is its vocabulary. Using the terms correctly makes conversations between legal, product, security and engineering staff much clearer. The definitions below are paraphrased, not quoted.

Personally identifiable information (PII) – information that identifies a living individual, or that could be connected to one directly or indirectly. Many laws say "personal data" for practically the same idea.
PII principal – the natural person to whom the PII relates, such as a customer, patient, employee or website visitor. In the GDPR the same person is called the data subject.
PII controller – the party (alone or jointly with others) that decides why PII is processed and how; a person handling data only for private, household reasons is excluded. A controller may process the data itself or have others do it.
PII processor – a party that handles PII for a controller and follows that controller's instructions, for example a payroll bureau or a hosting provider.
Third party – anyone involved other than the principal, the controller, the processor and the staff working directly under their authority. A partner company that receives data to use for its own purposes is a typical example.
Privacy stakeholder – any person or body whose decisions influence PII processing, or who is, or feels, affected by it.
Processing of PII – anything done with PII, from collecting and storing it to changing, looking up, sharing, de-identifying or destroying it.
Sensitive PII – PII whose nature, or the harm its misuse could cause, makes it especially important for the person, so it needs extra protection. Laws often name categories such as health, religion, political opinions, sexual life or criminal records.
Consent – an individual's agreement to the processing of their PII that is given freely, for a specific purpose and with an understanding of what it means.
Opt-in – processing happens only after the person actively agrees, such as ticking an empty box.
Opt-out – not a defined term in the standard, but the usual contrast: processing happens by default unless the person acts to refuse it.
Identifiability – the condition in which a given set of PII makes it possible to identify a particular person, directly or indirectly.
Anonymisation – changing PII permanently so that nobody, neither the controller nor anyone working with it, can any longer tell whom it is about. The result is anonymised data, which is no longer PII.
Pseudonymisation – replacing identifying attributes with aliases (pseudonyms) so that the data cannot be linked to a person without additional information kept separately. Pseudonymous data is still PII, because re-identification is possible.
Privacy breach – any case where PII is handled against the privacy requirements that apply to it, for example lost, disclosed without authority or used for an unannounced purpose.
Privacy safeguarding requirements – everything an organisation has to respect when it processes PII, whether it comes from law, contracts, business needs or elsewhere.
Privacy controls – organisational, physical or technical measures that make privacy harm less likely or less severe.
Privacy enhancing technology (PET) – a technical control that protects people by cutting down the PII a system holds or blocking processing nobody needs, while the system still does its job. Examples are pseudonymisation tools and privacy-preserving analytics.
Privacy risk – the possibility that processing harms the people the data is about; privacy risk management is the organised work of finding, judging and treating that risk.
Privacy policy – the controller's formally stated intentions, rules and commitments for how PII is processed in a given setting.
Privacy preferences – the choices an individual has made about how their PII may be used for a given purpose.
Secondary purpose – any purpose other than the one the PII was originally collected for. The 2011 edition said "secondary use".

Controllers, processors and third parties are roles, not company types

Beginners often think "processor" is a kind of company, such as a cloud provider. It is better to think of these terms as roles that an organisation plays for a particular processing activity. The same company can be a PII controller for its own employee records and its marketing list, and a PII processor for the customer data it hosts on behalf of its clients. A partner that receives PII and starts using it for its own purposes is acting as a third party towards the original controller, and as a controller in its own right for its new processing. Always ask: "Who decides why and how this particular data is processed?" The answer tells you who the controller is.

PII is broader than names and ID numbers

The second key idea is that identifiability is a matter of context. A phone number, an IP address, a loyalty-card number or a device identifier may not show a name, but they can be linked to a person by the organisation or by someone else. A combination of age, postcode and job title might single out one person in a small town. The framework asks you to consider whether information can be used to identify a person, taking into account the means reasonably likely to be used, including by other parties. When in doubt, treat the data as PII.

Lesson 3 – Structure of the standard

ISO/IEC 29100 is a short document compared with management system standards, and its structure is easy to learn. The 2024 edition is organised as follows:

Part	What it covers
Clause 1 – Scope	What the framework provides and for whom it is intended.
Clause 2 – Normative references	New in 2024; it states that the document has no normative references.
Clause 3 – Terms and definitions	The privacy vocabulary summarised in Lesson 2.
Clause 4 – Abbreviated terms	Short forms such as PII and ICT.
Clause 5 – Basic elements of the privacy framework	An overview, then actors and roles, interactions, recognising PII, privacy safeguarding requirements, privacy policies and privacy controls.
Clause 6 – The privacy principles of this document	An overview, then the eleven principles in subclauses 6.2 to 6.12, each with a short description of what it involves.
Annex A (informative)	A correspondence between the privacy concepts of ISO/IEC 29100 and the information security concepts of the ISO/IEC 27000 family.
Bibliography	Sources and related standards, refreshed in 2024.

Figure 1 – The framework moves from vocabulary through six basic elements to the eleven principles, with an annex that links privacy concepts to security concepts.

The basic elements

Actors and roles. The framework names four types of actor: PII principals, PII controllers, PII processors and third parties. It explains what each is and stresses that one organisation can hold more than one role, and that several controllers may decide jointly.

Interactions. The standard shows how PII typically flows between the actors, for example from a principal to a controller when someone registers for a service, from a controller to a processor when work is outsourced, or from a controller to a third party when data is shared. For each flow it clarifies which party is in which role. This helps teams draw accurate data-flow diagrams.

Recognising PII. The standard explains several ways in which information can be PII: identifiers (such as a name, account number or national ID), other distinguishing characteristics (such as a combination of attributes that singles a person out), information that is or might be linked to a principal, pseudonymous data, metadata (information about data, such as the time and location of a photograph), unsolicited PII (data a principal sends without being asked, such as a CV attached to a general enquiry), and sensitive PII.

Privacy safeguarding requirements. These are the requirements an organisation has to meet. The standard groups their sources into legal and regulatory factors, contractual factors, business factors and other factors, and it links them to privacy risk management. Lesson 4 looks at this in detail.

Privacy policies. The controller expresses its intentions and rules in policies. In practice this usually means internal policies, which guide staff, and external notices, which inform principals and the public.

Privacy controls. Finally, the requirements and policies are put into effect through controls: organisational, physical and technical measures chosen to treat privacy risks. The framework explains the role of controls but leaves the detailed catalogue to other standards such as ISO/IEC 27701, ISO/IEC 29151 and ISO/IEC 27002.

The eleven principles

The principles are the heart of the document and the part people quote most often. They are not numbered as levels and they do not form a sequence: they apply together, and a design that satisfies some of them but ignores others is not privacy-respecting.

Figure 2 – The eleven privacy principles apply together to every processing activity; none is optional.

Here is what each principle means in practice, in plain words.

Consent and choice. Where consent is the basis for processing, give people a real choice, explain what they are agreeing to, make the choice freely, and let them withdraw it easily. Where the law allows processing without consent, the controller still has to be clear about it. Consent is not the only legitimate basis, and the framework does not pretend it is.
Purpose legitimacy and specification. Make sure each purpose is lawful, define it clearly and tell people before you collect their data or use it for a new purpose. For sensitive PII, explain why it is needed.
Collection limitation. Collect only the PII that is lawful and necessary for the specified purposes, and no more "just in case".
Data minimisation. Design processing so that it uses as little PII as possible, involves as few people with access as possible, uses non-identifying interactions by default where they work, and deletes or disposes of PII when the purpose has expired. Collection limitation is about what enters the system; minimisation is about how little of it is used, seen and kept inside the system.
Use, retention and disclosure limitation. Use and disclose PII only for the specified, legitimate purposes, keep it only as long as needed for those purposes or required by law, and then delete it or keep it locked where retention is legally required.
Accuracy and quality. Keep PII accurate, complete, up to date, adequate and relevant for the purpose, check the reliability of sources, and pay extra attention where wrong data could harm people.
Openness, transparency and notice. Give people clear, easily accessible information about the controller's policies and practices: purposes, kinds of recipients, retention, choices available and how to contact the controller. Tell them when practices change significantly.
Individual participation and access. Allow people to see the PII held about them, to challenge its accuracy and to have it corrected, completed or removed, in a simple, timely way and without excessive cost.
Accountability. Take responsibility and be able to show it: document policies, assign a person responsible, train staff, use contracts with recipients, handle complaints, give redress, and notify the appropriate people when a privacy breach occurs.
Information security. Protect PII with appropriate controls for confidentiality, integrity and availability, chosen on the basis of risk, including when processors are involved, and review them regularly.
Privacy compliance. Check and demonstrate that processing meets the privacy safeguarding requirements, for example through periodic internal or external audits and privacy risk assessments.

Annex A

The informative annex helps security people who already know the ISO/IEC 27000 family. It sets the framework's privacy concepts side by side with their nearest ISO/IEC 27000 counterparts, so that, for example, a privacy breach can be related to an information security incident and privacy controls to security controls. The key message is that the two fields overlap but are not the same: security protects information in general, while privacy protects people from harm caused by processing information about them.

Lesson 4 – How it works in practice

ISO/IEC 29100 does not prescribe a step-by-step method, but its basic elements fall naturally into a sequence that teams can follow. Here is a practical way to put the framework to work on a system or service.

Step 1 – Map the processing and the actors

Start with a simple inventory: which processing activities exist, what PII each uses, where it comes from, where it goes and who does what with it. For each activity, assign the roles. Who is the principal? Who decides the purpose and means (the controller)? Who acts on the controller's instructions (processors, including sub-processors that a processor engages)? Who receives data for their own purposes (third parties)? A data-flow diagram with these roles marked is the most useful single artefact you can produce early on.

Figure 3 – PII flows between the four actors; a processor acts on the controller's instructions, while a third party that uses data for its own purposes becomes a controller itself.

Step 2 – Recognise the PII

Go through each data set with the categories from Lesson 3 in mind. Mark direct identifiers, linkable attributes, pseudonymous data, metadata and any sensitive PII. Pay attention to logs, analytics events, support tickets, backups and test data, which often contain PII nobody planned for. Also plan for unsolicited PII: a free-text field or a file upload will eventually receive data you did not ask for, so decide how you will handle it.

Step 3 – Derive the privacy safeguarding requirements

The framework names four groups of factors that produce requirements. Each one is a question you can ask.

Legal and regulatory factors: Which laws apply, in which jurisdictions? Privacy laws, sector rules (for health, finance or telecoms), employment law and rules on international transfers all count. Where laws conflict or are unclear, legal advice is needed; the framework does not settle that.
Contractual factors: What have we promised in contracts? Customer agreements, data processing agreements, industry schemes and commitments to partners can add obligations beyond the law.
Business factors: What does our own strategy require? The nature of the service, the expectations of customers, the brand, the organisation's risk appetite and its own privacy policy all shape the requirements.
Other factors: What else matters? The preferences of PII principals, good practice in the industry, guidance from regulators and technical standards are typical examples.

Step 4 – Assess the privacy risk

With requirements identified, look at the risk to the principals. The framework expects privacy risks to be managed in a structured way, in line with general risk management practice such as ISO 31000: establish the context, identify how processing could harm people, analyse and evaluate those risks, decide on treatment, and keep monitoring. The dedicated method for this is the privacy impact assessment described in ISO/IEC 29134. The important shift for security people is the point of view: the main question is not "what does a breach cost the company?" but "what harm could this processing cause to the individuals?"

Figure 4 – Four groups of factors produce the privacy safeguarding requirements, which risk assessment turns into policies and controls that are monitored and revisited.

Step 5 – Write policies and select controls

Turn the requirements and risk decisions into internal policies (for example, a retention schedule, an access policy, a rule for handling access requests) and an external privacy notice. Then select privacy controls. Controls can be organisational (roles, training, procedures, contract clauses), physical (locked archives, secure disposal of paper and drives) or technical (access control, encryption, pseudonymisation, automated deletion, consent management). A useful exercise is to walk through the eleven principles one by one and ask, for each processing activity, "Which control shows that we respect this principle?" Gaps in that table are your work list.

Step 6 – Build privacy into the life cycle

The principles apply across the whole life of PII, not only at collection. Think of each stage: collection, use, storage, disclosure and disposal. At collection, purpose specification, consent and collection limitation dominate. During use, minimisation and use limitation matter most. In storage, information security and accuracy. At disclosure, the limits on disclosure, contracts and transparency. At the end, retention limits and secure disposal. Designing these into requirements, user stories and architecture from the start is far cheaper than retrofitting them.

Step 7 – Monitor, demonstrate and improve

Finally, the accountability and privacy compliance principles ask the controller to keep evidence and to check regularly that practice matches policy: records of processing, access-request logs, training records, deletion reports, audit results. When the law, the business or the technology changes, go back to Step 3. Organisations that want a formal, auditable system for this cycle usually implement a privacy information management system under ISO/IEC 27701.

Who does what

The framework does not define job titles, but the work tends to divide like this. A privacy lead or data protection officer owns the requirements, policies and notices. Product owners and architects own the data flows and design decisions. Engineers implement technical controls such as deletion jobs and access restrictions. Security teams operate the information security controls and the incident process. Legal teams interpret laws and draft contracts. Internal audit or an external assessor checks compliance. What matters for the standard is that responsibility is clearly assigned and documented, as the accountability principle asks.

Lesson 5 – Assessment, certification and compliance

There is no ISO/IEC 29100 certificate for organisations

ISO/IEC 29100 is a framework: it provides terms, concepts and principles, not auditable requirements. As a result, there is no accredited certification of an organisation "to ISO/IEC 29100". Any claim that a company is "ISO/IEC 29100 certified" should be read carefully; most likely the company means that its privacy programme is based on the framework, or that it holds a certificate for a different standard that uses it.

How organisations show they apply it

There are three common ways to demonstrate the framework in practice.

ISO/IEC 27701 certification. ISO/IEC 27701:2025 specifies requirements for a privacy information management system (PIMS) and uses ISO/IEC 29100 as its normative reference. Accredited certification bodies audit organisations against ISO/IEC 27701, and the audit implicitly tests whether roles, PII and principles are handled the way the framework describes. This is the main route to a certificate.
Assessment against related standards. Cloud providers often have ISO/IEC 27018 included in the scope of their ISO/IEC 27001 certification; the extended controls in ISO/IEC 27018 are framed by the ISO/IEC 29100 principles. Organisations can also use ISO/IEC 29190, a privacy capability assessment model, to rate how mature their privacy processes are.
Internal and second-party assessment. Many organisations use the eleven principles directly as an assessment checklist: an internal audit team, a customer performing supplier due diligence, or a consultant reviews each processing activity against each principle and records gaps. This produces evidence for the privacy compliance principle without any formal certificate.

Relationship with legal compliance

Applying the framework is not the same as complying with a law. A privacy law such as the GDPR, Brazil's LGPD or India's Digital Personal Data Protection Act sets binding obligations with specific details (lawful bases, deadlines, rights, transfer rules, fines). ISO/IEC 29100's principles overlap strongly with these laws, which makes the framework an excellent organising tool, but only the law and the regulator decide what compliance means. In the framework's own terms, laws are one source of privacy safeguarding requirements; they always take precedence.

Qualifications for people

Where a training provider offers a course on ISO/IEC 29100 with an exam or a certificate, that certificate says something about an individual who completed the course; it is not certification of an organisation and it is not issued by ISO. For a formal professional qualification in privacy, people more often look at ISO/IEC 27701 implementer or auditor courses or at general privacy credentials.

What an assessor looks for

Whether the assessment is internal, by a customer or part of an ISO/IEC 27701 audit, reviewers tend to ask the same questions. Is there an inventory of processing with roles assigned? Are purposes documented and communicated before collection? Is collection limited, and is there evidence of minimisation and retention limits in practice (for example, deletion logs)? Can principals exercise access and correction, and how long does it take? Are processors bound by contracts and checked? Is there a breach process with notification? Are audits and risk assessments performed and acted upon? Answers backed by records count far more than well-written policies alone.

Lesson 6 – Worked example

To see how the pieces fit together, follow a fictional company, CityCycle, as it applies ISO/IEC 29100 to a new service. CityCycle runs a bike-sharing scheme in a mid-sized city. It is launching a mobile app with which people register, unlock bikes, pay per ride and see their ride history. The city council, which subsidises the scheme, wants statistics on how the bikes are used.

Mapping roles and flows

The product team draws a data-flow diagram. Riders are the PII principals. CityCycle decides why and how the app's data is processed, so it is the PII controller. It uses a cloud platform to host the app and database, and a customer-support desk run by an outside company; both act only on CityCycle's instructions, so they are PII processors. The cloud platform itself uses a data centre operator, a sub-processor. A payment service provider handles card payments; the team checks the contracts and finds that the provider also processes card data under its own legal obligations, for example for fraud prevention, so for that part it acts as a controller in its own right. The city council receives usage statistics. The team realises that if the council received ride-level data it would be a third party using PII for its own planning purposes, which raises questions about legitimacy and notice.

Recognising the PII

The team lists the data. Name, email address, phone number and payment token are obvious identifiers. Ride records contain start and end stations with times; together they reveal where a person lives and works, so they are PII even without the name attached. The app sends device identifiers and crash logs, which are linkable to accounts. Photos riders upload to report damaged bikes contain metadata, including location and time, and sometimes faces of bystanders. The support channel receives unsolicited PII: a rider wrote that she cannot cycle for a while after surgery, which is health information and therefore sensitive PII. The team adds a rule that support agents must not copy such details into tickets beyond what is needed.

Deriving the safeguarding requirements

Legal and regulatory: the national data protection law, consumer law, rules on electronic marketing and on location data, and accounting rules that require keeping payment records for a set period.
Contractual: the subsidy contract with the council, which requires monthly usage statistics; the processing agreements with the cloud platform and support desk; the payment provider's terms.
Business: CityCycle wants to be trusted in a small city where word travels fast, and its board has a low appetite for privacy incidents.
Other: a user survey shows riders are uneasy about being tracked; the regulator has published guidance on location data; the city's open-data policy expects statistics to be published.

Assessing the risk

A privacy impact assessment identifies the main risks to riders: their movement patterns could be exposed by a breach or misused by staff; a detailed trip history shared with the council could be used to monitor individuals; marketing based on location could feel intrusive; and wrong account data could lead to unfair charges. The most serious is the exposure of movement patterns, because it could reveal home addresses, routines and visits to sensitive places such as clinics or places of worship.

Applying the eleven principles

Principle	CityCycle decision
Consent and choice	Ride processing is needed to deliver the service, so it is not based on consent. Marketing emails and the optional "ride statistics badge" feature are opt-in, off by default, and can be switched off in the app.
Purpose legitimacy and specification	Purposes documented: provide rides, bill, support, keep bikes safe, produce aggregated statistics for the council. Riders are told before registration.
Collection limitation	Date of birth dropped from the sign-up form; only an age confirmation is needed. GPS is recorded only at docking stations, not continuously during rides.
Data minimisation	Support agents see only the last five rides; analytics use pseudonymous rider keys; ride histories older than a set period are reduced to station-level counts.
Use, retention and disclosure limitation	Detailed ride records deleted after the dispute period; payment records kept only as long as accounting law requires; nothing shared with the council except aggregated statistics.
Accuracy and quality	Riders can correct profile data; disputed charges trigger a check of the station logs before a refund decision.
Openness, transparency and notice	A short layered notice in the app, with a full notice online listing purposes, categories of recipients, retention and contact details.
Individual participation and access	A "download my data" function and a simple form for correction and account deletion, answered within the legal deadline.
Accountability	An operations manager is named privacy lead; staff receive training; processing agreements signed; a breach procedure includes notifying the regulator and riders where required.
Information security	Encryption in transit and at rest, role-based access, logging of access to ride histories, regular security testing of the app.
Privacy compliance	An annual internal privacy audit and a repeat privacy impact assessment before each major feature release.

Following the data through its life cycle

Figure 5 – In the worked example, PII moves from collection through use and storage to aggregation and deletion, with a principle-based decision at every stage.

Dealing with the council's request

Six months after launch, the council asks for trip-level data with rider IDs to study commuting. The privacy lead goes back to the framework. Sharing identifiable trips would be a new purpose for a new recipient acting as a third party. It was not announced to riders, and the risk assessment flagged movement data as the most serious risk. CityCycle offers instead a set of aggregated origin-destination statistics with small counts suppressed, and explains that it can consider an opt-in research programme if the council has a clear legitimate purpose. The council accepts. Applying the principles has turned a potentially damaging decision into a defensible one, and the reasoning is documented as evidence of accountability.

What the example teaches

Notice that CityCycle did not need a certificate or a large programme to use ISO/IEC 29100. It used the framework's vocabulary to clarify roles, its PII categories to find hidden personal data, its four groups of factors to collect requirements and its principles to make concrete design choices. If CityCycle later wants independent proof for customers or the council, it can build those practices into an ISO/IEC 27701 privacy information management system and seek certification.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 29100 is most useful when you understand how it connects to the documents around it. Some build directly on it, some cover the same ground from a different angle, and some are laws that it is designed to complement.

Standard or framework	Type	Main content	Relationship to ISO/IEC 29100
ISO/IEC 27701:2025	Certifiable management system standard	Requirements for a privacy information management system, with control sets for controllers and processors	Uses ISO/IEC 29100 as its normative reference for terms and principles; the main route to certification.
ISO/IEC 27018:2025	Guidelines	PII protection guidance for public cloud providers acting as processors, built on ISO/IEC 27002:2022	Organises its additional controls (Annex A) in line with the ISO/IEC 29100 principles.
ISO/IEC 29134	Guidelines	How to conduct a privacy impact assessment and write the report	Provides the detailed method for the privacy risk assessment that the framework calls for.
ISO/IEC 29151	Code of practice	Controls and guidance for protecting PII	Turns the principles into a catalogue of controls.
ISO/IEC 29101	Framework	Privacy architecture: components and views for ICT systems processing PII	Applies the actors and principles to system architecture.
ISO/IEC 29184	Guidelines	Online privacy notices and obtaining consent	Details how to meet the openness and consent principles online.
OECD Privacy Guidelines	Intergovernmental recommendation (1980, revised 2013)	Eight basic principles for national privacy policy and cross-border data flows	A major source of the ISO/IEC 29100 principles; ISO/IEC 29100 splits and extends them for ICT.
NIST Privacy Framework	Voluntary framework	A core of privacy outcomes, profiles and implementation tiers for managing privacy risk	Covers similar ground with a risk-outcome structure; the two are often mapped and used together.
GDPR (EU)	Law	Binding rules on personal data processing, rights, enforcement and fines	One source of legal privacy safeguarding requirements; its principles overlap strongly with the framework's.

ISO/IEC 29100 and the OECD principles

The OECD Guidelines contain eight principles: collection limitation, data quality, purpose specification, use limitation, security safeguards, openness, individual participation and accountability. ISO/IEC 29100 keeps the same spirit but makes some ideas explicit that the OECD text implies: it separates data minimisation from collection limitation, gives consent and choice a principle of its own, and adds privacy compliance as a distinct principle about checking and demonstrating conformity. That is why people who know the OECD Guidelines find ISO/IEC 29100 familiar.

ISO/IEC 29100 and the GDPR

The vocabulary maps closely: PII is roughly personal data, the PII principal is the data subject, and controller and processor have very similar meanings. The GDPR principles of lawfulness, fairness and transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, and accountability all have counterparts among the eleven principles. Differences matter, though. The GDPR defines specific lawful bases, detailed rights such as data portability and objection, deadlines and penalties; the framework does not. Use ISO/IEC 29100 to organise and explain, and the law to decide.

ISO/IEC 29100 and information security standards

ISO/IEC 27001 and ISO/IEC 27002 protect information of all kinds against threats to confidentiality, integrity and availability. ISO/IEC 29100 includes information security as one of its principles, but privacy needs more: a perfectly secure system can still collect too much, use data for unannounced purposes, keep it forever or deny people access to their own records. The framework's Annex A helps security teams bridge the two vocabularies, and ISO/IEC 27701 brings both together in one management system.

ISO/IEC 29100 and de-identification standards

The framework introduces anonymisation and pseudonymisation as concepts. More detailed guidance lives elsewhere: ISO/IEC 20889 describes de-identification techniques, and ISO/IEC 27559 gives a framework for assessing and managing re-identification risk. These help when you want to share or publish data, as CityCycle did with the council statistics.

Common pitfalls and best practices

Common pitfalls

Treating roles as fixed labels. Assuming a supplier is always "just a processor" hides the moments when it starts using data for its own purposes and becomes a controller or a third party.
Too narrow a view of PII. Looking only for names and ID numbers misses device identifiers, location trails, metadata, logs and combinations of attributes that single out a person.
Calling pseudonymised data anonymous. Replacing names with keys reduces risk but does not take data outside the scope of privacy protection while re-identification remains possible.
Equating privacy with security. Encrypting everything while collecting excessive data, keeping it indefinitely or ignoring access requests satisfies one principle and fails several others.
Relying on consent for everything. Asking for consent where the service cannot work without the processing creates choices that are not real; consent should be used where people genuinely can say no.
Claiming "ISO/IEC 29100 certification". The framework has no organisational certification; such claims mislead customers and auditors.
Writing policies without evidence. Retention schedules and notices that are never implemented or checked do not meet the accountability and compliance principles.

Best practices

Start with a data-flow map marked with roles. It is the single most effective way to make the framework concrete for engineers and lawyers alike.
Use the eleven principles as a design checklist. Review each new feature against every principle and record the decision, as CityCycle did.
Collect requirements from all four groups of factors. Law is only one source; contracts, business needs and people's preferences often add the decisive requirements.
Assess risk from the individual's point of view. Use a privacy impact assessment method such as ISO/IEC 29134 and ask what harm processing could do to people.
Build deletion and minimisation into the system. Automated retention jobs, default-off optional features and need-to-know access are more reliable than manual promises.
Bind processors and recipients by contract and check them. Accountability follows the data, so make obligations explicit and review them.
Use the framework as a bridge to formal assurance. When customers need proof, move from the principles to an ISO/IEC 27701 management system rather than inventing your own certificate.

Summary and key takeaways

ISO/IEC 29100:2024 is the current, second edition of the international privacy framework from ISO/IEC JTC 1/SC 27; it is a modest revision of the 2011 text and keeps the same concepts and eleven principles.
The framework provides a common vocabulary, a model of actors and roles, guidance on recognising PII and on deriving privacy safeguarding requirements, and eleven privacy principles.
The four actors are the PII principal, PII controller, PII processor and third party; they are roles for a given processing activity, not fixed types of organisation.
PII includes anything that identifies a person or can be linked to one, including pseudonymous data, metadata and combinations of attributes; sensitive PII needs extra protection.
Privacy safeguarding requirements come from legal and regulatory, contractual, business and other factors, and risk assessment turns them into policies and controls.
The eleven principles apply together across the whole life cycle of PII, from collection to disposal.
There is no certification of organisations to ISO/IEC 29100; conformity is shown through ISO/IEC 27701 certification, related assessments or documented internal reviews.
The framework complements privacy laws and underpins other ISO privacy standards such as ISO/IEC 27701, 27018, 29134 and 29151.

Reflection questions

Pick one service your organisation runs. For each processing activity in it, who is the PII controller, who are the processors and are there any third parties? Where might a role change over time?
Look at a log file or analytics event stream in a system you know. Which fields are PII under the framework's broad view, and which would remain PII after pseudonymisation?
For a new feature you are planning, list one privacy safeguarding requirement from each of the four groups of factors. Which group produced the requirement that will most affect your design?
Which of the eleven principles does your organisation find hardest to put into practice, and what control or evidence would show that it is being respected?
A customer asks whether your company is "certified to ISO/IEC 29100". How would you answer, and what evidence would you offer instead?