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

ISO/IEC 29134 is the international guideline for carrying out a privacy impact assessment (PIA): a structured way to find out, before and during a project, how the processing of personal data could harm the people it is about, and what to do about it. It is used by privacy officers, security and risk teams, product owners, architects and public-sector project managers, and it is often the method behind the "data protection impact assessments" that laws such as the EU GDPR demand. After this tutorial you will be able to decide whether a PIA is needed, plan and run one with the right people, assess and treat privacy risk, and write a PIA report that management can sign and the public can read.

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

Course overview

Edition and status: The current edition is ISO/IEC 29134:2023, the second edition, published in May 2023 by ISO and IEC through joint subcommittee ISO/IEC JTC 1/SC 27 (Information security, cybersecurity and privacy protection). Its title is "Information technology — Security techniques — Guidelines for privacy impact assessment". It cancels and replaces the first edition, ISO/IEC 29134:2017; the foreword describes the changes as minor and editorial, so material written for the 2017 edition is still largely applicable. No newer edition, amendment or revision project was found. The European adoption EN ISO/IEC 29134:2020 was based on the 2017 text; it is being replaced by EN ISO/IEC 29134:2026, which adopts the 2023 text (DIN, for example, published it in August 2026), so check which version your national standards body sells. Verified 2026-10-29 against the ISO catalogue record, the official preview of the 2023 edition and national standards catalogues.

Who this is for: data protection officers and privacy analysts, information security and risk professionals, software and solution architects, product and project managers, compliance and internal audit staff, and anyone in the public sector who has been told "this project needs a PIA" and wants to know what a good one looks like.

Prerequisites: none. A basic idea of what personal data is and how risk is usually scored (likelihood and impact) helps, but every term is explained on first use.

By the end of this tutorial:

You will be able to explain what a PIA is, why ISO/IEC 29134 gives guidance rather than requirements, and how it relates to privacy laws that require impact assessments.
You will be able to use the core vocabulary correctly: PII, PII principal, PII controller, PII processor, privacy risk, risk source, supporting asset, threshold analysis, privacy safeguarding requirements, risk treatment plan and acceptance statement.
You will be able to describe the structure of the standard: preparing the ground, the PIA process, the PIA report and the four informative annexes.
You will be able to run the process from threshold analysis through preparation, performance and follow-up, including stakeholder engagement and information flow mapping.
You will be able to assess privacy risk from the point of view of the people affected, choose treatment options, and record residual risk and management acceptance.
You will be able to explain how a PIA is reviewed and audited, and why there is no certificate for ISO/IEC 29134 itself.
You will be able to place ISO/IEC 29134 alongside ISO/IEC 29100, ISO/IEC 27701, ISO/IEC 27005, ISO/IEC 29151 and the GDPR's data protection impact assessment.

Lesson 1 – Origins, purpose and scope

Why privacy impact assessment exists

Most privacy harm is designed in long before anyone notices it. A team decides to log every search a customer makes "in case it is useful", a supplier's software sends device identifiers to an analytics service by default, or a public agency links two databases that were never meant to meet. By the time the system is live, the cheapest moment to change these decisions has passed. Privacy impact assessment grew out of this observation. Governments in several countries, including Canada, Australia, New Zealand and the United Kingdom, began publishing PIA guidance for public bodies from the late 1990s and 2000s, and regulators started to ask private organisations for the same discipline when they launched new technologies that handle personal data.

Each of these national methods looked a little different, which made life hard for multinational organisations, suppliers and auditors. ISO/IEC 29134 was developed by the international committee that also maintains the ISO/IEC 27000 security family and the ISO/IEC 29100 privacy framework, so that there would be one internationally agreed description of a good PIA process and a good PIA report. The first edition appeared in 2017 and the second, with minor editorial changes, in 2023.

What a PIA is, in the standard's sense

The standard treats a PIA as both an instrument and a process. As an instrument, it helps you assess the possible effects on privacy of anything that processes personal data: a business process, an information system, a programme, a software module, a connected device or any other initiative. As a process, it starts at the earliest stage of the initiative, while there is still a real chance to change its design, and it continues after the system goes live. That second point is the heart of the standard: a PIA is a tool for privacy by design, not a form to fill in the week before launch.

A PIA also has an outward-facing purpose. It produces evidence that an organisation has thought about the people affected, consulted them or their representatives where sensible, and taken responsible decisions. That evidence can be shown to regulators, customers, business partners and, in summary form, the public.

Scope of ISO/IEC 29134

The standard gives guidelines for two things: a process for conducting privacy impact assessments, and the structure and content of a PIA report. It applies to organisations of every type and size, including public and private companies, government bodies and not-for-profit organisations. It is aimed at the people who design or implement projects, including those who operate data processing systems and services that handle personal data.

Three features of the scope are worth understanding from the start:

It is guidance, not a requirement standard. The text uses "should" rather than "shall". You cannot be certified against it, and you are expected to scale the guidance to your situation.
It is law-neutral. It does not interpret any particular statute. Instead it tells you to identify the legal, contractual and organisational requirements that apply to your processing and to assess against them. That is why it fits well with the GDPR, national privacy acts and sector rules alike.
It covers shared responsibility. Its introduction explicitly considers cases where several organisations share delivery of a system, where an organisation builds a privacy risk process as part of an information security management system (ISMS), and even public programmes where the future PII controller is not yet known, so that the treatment plan has to be written into a contract or regulation instead of being implemented directly.

Who does the PIA

The organisation that decides why and how personal data is processed normally carries the responsibility for the PIA. It can ask a service provider that processes data on its behalf to help, and suppliers can run their own PIAs on their products. The standard pays particular attention to suppliers of digitally connected devices: a small shop or a small business that installs a smart camera or a connected payment terminal may have no privacy expertise at all, so the device supplier is in the best position to provide privacy-relevant design information and to assess its product for the expected customer context.

Lesson 2 – Key concepts and vocabulary

ISO/IEC 29134 builds on the vocabulary of three other documents: the ISO/IEC 29100 privacy framework, the ISO/IEC 27000 overview and vocabulary for information security, and ISO Guide 73 for risk management. It adds a few terms of its own. The definitions below are paraphrased explanations, not the official wording.

Personally identifiable information (PII) – any information that can be used to identify the person it relates to, or that is or might be linked, directly or indirectly, to that person. In GDPR language this is "personal data".
PII principal – the natural person the PII relates to: the customer, patient, employee, citizen or passer-by. GDPR calls this person the "data subject".
PII controller – the party that decides the purposes and means of processing PII. It usually owns the PIA and its decisions.
PII processor – a party that processes PII on behalf of, and according to the instructions of, a PII controller, such as a cloud host or a payroll bureau.
Privacy impact assessment (PIA) – the whole effort of finding, analysing and rating the possible privacy effects of processing PII, talking about them with stakeholders and planning how to deal with them, as part of the organisation's normal risk management.
Threshold analysis – a quick, early screening that decides whether a full PIA is needed and, if so, how deep it should go.
Privacy risk – the effect of uncertainty on privacy; in practice, the combination of how likely a harmful event is and how severe its consequences would be for the PII principals.
Risk source – anything (a person, a group, a technical component, a natural event) that alone or in combination can give rise to privacy risk, such as a curious employee, a criminal group or a faulty integration.
Asset – in a PIA, either the PII itself or a supporting asset: the hardware, software, networks, people, paper and premises on which the PII depends. Threats act on supporting assets, and through them on the PII.
Privacy safeguarding requirements – the set of requirements an organisation must or wants to meet when processing PII: legal and regulatory obligations, contractual commitments, internal policies and the privacy expectations of the people concerned.
Information flow – the movement of PII through its life cycle: collection, storage, use, transfer, disclosure, retention and disposal, including who touches it at each step.
Risk treatment plan – the agreed set of actions (controls, design changes, contracts) that will modify, avoid, share or retain each assessed risk, with owners and deadlines.
Residual risk – the risk that remains after the planned treatment has been put in place.
Acceptance statement – management's formal, signed declaration that it owns the risks, the treatment plan and whatever risk remains afterwards. It turns the PIA into an accountable business decision.
PIA public summary – a shortened version of the report written for outsiders, which explains the processing and the main conclusions without exposing security-sensitive details.

Privacy risk is about people first

The most important conceptual shift for newcomers, especially those with a security background, is the point of view. In an ordinary information security risk assessment the question is "what would this do to the organisation?" In a PIA the primary question is "what would this do to the people whose data it is?" A leak of a gym's membership list might cost the company little, yet for a member fleeing domestic violence it could be dangerous. A good PIA considers organisational consequences too, such as fines, lost trust and remediation cost, but it rates impact by looking at harm to PII principals: physical, material, financial, psychological, social and loss of control over their own information.

Security is not the same as privacy

A second key idea is that privacy risk is wider than security risk. A perfectly secure system can still be privacy-hostile if it collects more than it needs, keeps data forever, uses it for a purpose people were never told about, or makes automated decisions about them that they cannot challenge. That is why the standard asks you to assess against privacy safeguarding requirements, which include the privacy principles of ISO/IEC 29100 (such as purpose legitimacy, collection limitation, data minimisation, use and retention limitation, accuracy, openness, individual participation, accountability and security), and not only against confidentiality, integrity and availability.

Lesson 3 – Structure of the standard

ISO/IEC 29134:2023 is a compact document of a little over forty pages. After the usual front matter it has three working clauses and four informative annexes. Knowing this map makes the guidance much easier to use, because each clause answers a different question.

Figure 1 – The four building blocks of ISO/IEC 29134: groundwork, process, report and supporting annexes.

Clauses 1 to 4 – front matter

Clause 1 sets the scope described in Lesson 1. Clause 2 lists the normative references, the documents whose vocabulary the standard relies on: ISO Guide 73, ISO/IEC 27000 and ISO/IEC 29100. Clause 3 adds a short list of definitions, such as the acceptance statement and the meaning of asset in a privacy setting, and clause 4 lists abbreviations.

Clause 5 – Preparing the grounds for a PIA

Clause 5 explains why and at what scale to do a PIA. It covers the benefits of a PIA (early warning of risks, better design decisions, evidence of accountability, trust, lower cost of change), the objectives of PIA reporting, who is accountable for conducting the assessment, and how to scale it. Scale matters: a small change to a newsletter sign-up form deserves a light PIA, while a national digital identity programme deserves a long, formal one with public consultation.

Clause 6 – Guidance on the process

Clause 6 is the core. It opens with a general overview and then walks through four groups of activities, which Lesson 4 explains in detail:

Determine whether a PIA is necessary – the threshold analysis.
Preparation – set up the PIA team and give it direction; prepare a plan and determine resources; describe what is being assessed; plan stakeholder engagement.
Perform the PIA – identify information flows of PII; analyse the implications of the use case; determine the relevant privacy safeguarding requirements; assess privacy risk; prepare for treating privacy risks.
Follow up – prepare the report; publish it (or a summary); implement the risk treatment plans; review and/or audit the PIA; reflect changes to the process.

Clause 7 – The PIA report

Clause 7 describes what the report should contain and in what order. It covers the scope of the PIA (the process under evaluation, the risk criteria, the resources and people involved, and how stakeholders were consulted), the privacy requirements, the risk assessment (risk sources, threats and their likelihood, consequences and their level of impact, risk evaluation, and a compliance analysis), the risk treatment plan, the conclusion and decisions, and a PIA public summary. Because the report structure mirrors the process, a team that follows clause 6 will have most of the report's content ready as a by-product.

The informative annexes

Annex A offers example scale criteria for the level of impact and for likelihood, so that teams can rate risks consistently instead of inventing a new scale each time.
Annex B lists generic threats, grouped so that a team can check it has not overlooked a whole category, for example threats acting on hardware, software, networks, people or paper.
Annex C gives guidance on how terms used in the document should be understood.
Annex D provides illustrated examples supporting the PIA process.

"Informative" means the annexes are help, not instructions. You may use other scales or threat catalogues, such as those published by your regulator, as long as the result is consistent and explainable.

Lesson 4 – How it works in practice

This lesson follows the clause 6 process in the order a real team would experience it. Remember that the standard expects you to scale every step to the size and risk of the initiative.

Figure 2 – The PIA process from threshold analysis to review, looping back when the processing changes.

Step 1 – Threshold analysis

The first question is whether a PIA is needed at all. A threshold analysis is a short questionnaire or workshop, often owned by the privacy office, that looks for triggers such as: new PII is collected; existing PII is used for a new purpose; data is shared with new parties or moved to another country; sensitive categories (health, biometrics, children, financial data, location) are involved; the processing is large in scale; new technology such as artificial intelligence, facial recognition or connected devices is introduced; or decisions about people are automated. If none of the triggers apply, you record the decision and the reason, and that record is itself useful evidence. If some apply, the threshold result also suggests how deep the PIA should be.

Many organisations align their triggers with the law. Under the EU GDPR, for example, a data protection impact assessment is mandatory when processing is likely to result in a high risk to people's rights and freedoms, and the European data protection authorities have published criteria and lists of processing types that help make that call.

Step 2 – Set up the team and give it direction

A PIA is a team effort. The standard suggests appointing someone to lead it and assembling people who between them understand the business purpose, the technology, the data, security, the law and the people affected. Typical members are the project or product owner, a solution architect, a security specialist, the privacy officer or data protection officer (DPO), a legal or compliance adviser and, where relevant, representatives of the processors. Senior management gives the team its direction: the scope, the timeline, the risk criteria to use, and who will take the final decision.

Step 3 – Plan and resource the PIA

The PIA plan states what will be assessed, the tasks, who does what, the time and money needed, the documents to be produced, and how stakeholders will be involved. A useful plan also fixes the risk criteria up front: the impact and likelihood scales and the level of risk that management is willing to accept. Agreeing these before anyone scores a risk avoids the temptation to bend the scale to fit the result.

Step 4 – Describe what is being assessed

Next, the team writes a clear description of the initiative: its purpose and benefits, the business processes and systems involved, the categories of PII and PII principals, the parties involved, the technology used, and the boundaries of the assessment. A PIA of a vague idea gives vague results, so the description should be detailed enough that someone outside the project can understand what will happen to the data.

Step 5 – Engage stakeholders

Stakeholders are anyone who can affect or be affected by the processing: the PII principals or their representatives (customer panels, works councils, patient groups), internal teams, processors and suppliers, regulators and sometimes the wider public. The standard expects a consultation plan that decides whom to consult, when, how and with what information. Consultation often reveals concerns the project team would never have imagined, for example that a feature everyone in the office thought was convenient feels intrusive to the people it tracks.

Step 6 – Identify information flows of PII

The team now maps how PII moves through the life cycle: where it is collected and from whom, where it is stored, who uses it and why, where it is transferred and disclosed, how long it is retained and how it is deleted. The result is usually a data flow diagram plus a table of data elements. This map is the backbone of the assessment, because every risk and every control will be attached to a point in it. It also exposes surprises such as undocumented copies, analytics tags or test environments filled with production data.

Step 7 – Analyse the implications of the use case

With the flows in hand, the team asks what the use case means for the people concerned. Is each data element necessary for the purpose? Would people reasonably expect this use? Could the data be combined with other data to reveal more than intended? Does the processing create new possibilities for monitoring, profiling or discrimination? Can people still exercise choice and their rights? This step is where privacy goes beyond security and where many design improvements first appear.

Step 8 – Determine the privacy safeguarding requirements

The team lists everything the processing must or should comply with: privacy and data protection laws in each relevant country, sector regulations, contractual commitments to clients, industry codes, internal policies, and the privacy principles the organisation has adopted (often based on ISO/IEC 29100). This list becomes the yardstick for the compliance analysis in the report and is a key input to the risk assessment.

Step 9 – Assess privacy risk

Risk assessment follows the familiar pattern of ISO 31000 and ISO/IEC 27005: identify, analyse and evaluate. It deserves the most care, because it is where most teams struggle.

Figure 3 – How a privacy risk is built up from risk source to consequence and then rated and evaluated.

Identification. For each information flow, ask what could go wrong for the people concerned. Two complementary angles work well. The first is the classic security view: a risk source (an outside attacker, a careless employee, a malicious insider, a supplier, a software defect, a fire) exploits a weakness in a supporting asset, leading to illegitimate access, unwanted change or loss of PII. The second is the privacy-specific view: the organisation itself, quite legitimately operating the system, might collect too much, use data for a new purpose, keep it too long, make it impossible to correct, or share it with a party people would not expect. Annex B's generic threats help check coverage.

Analysis. Each risk is described as a short scenario and given a likelihood and a level of impact, using the agreed scales (Annex A shows example criteria). Impact is judged by the consequences for PII principals: how badly and how irreversibly they would be affected, and how many of them. Likelihood takes into account the capability and motivation of the risk source and the controls already in place. Combining the two gives the level of risk.

Evaluation. Each level of risk is compared with the acceptance criteria. Risks above the line need treatment; risks below it may be retained, but they are still documented and monitored. Evaluation also includes the compliance view: any processing that fails a mandatory legal requirement is a problem regardless of its score, because you cannot "accept" breaking the law.

Step 10 – Prepare for treating privacy risks

For each risk that needs it, the team chooses a treatment option, in the vocabulary shared with ISO 31000 and ISO/IEC 27005:

Modify the risk by adding or changing controls – technical (encryption, pseudonymisation, access control, logging), organisational (training, procedures, contracts) or design changes (collect less, delete sooner, process on the device).
Avoid the risk by not carrying out the risky part of the processing at all.
Share the risk with another party, for example by contract or insurance; note that sharing never removes the controller's responsibility towards the people affected.
Retain the risk as a conscious, recorded decision when it is within the acceptance criteria.

The controls can be taken from established catalogues, notably ISO/IEC 27002 for security controls and ISO/IEC 29151 for PII protection controls, or comparable national documents, or designed by the PIA team. The result is a risk treatment plan with an owner, a deadline and a success measure for each action, and an estimate of the residual risk once the plan is complete.

Step 11 – Follow up

Follow-up turns analysis into change. The team prepares the PIA report (Lesson 5 covers its review), decides what to publish, and hands the treatment plan to the people who must implement it. The organisation then checks that the actions are really done, reviews or audits the PIA, and keeps it alive: whenever the processing, the technology, the law or the threat picture changes significantly, the PIA is revisited. Finally, lessons learned from the PIA are fed back into the organisation's own PIA process, for example by updating the threshold questionnaire or the template.

Roles and artefacts at a glance

Figure 4 – Who takes part in a PIA and which artefacts flow between them.

The main artefacts are the threshold analysis record, the PIA plan, the description of the processing, the consultation plan and its results, the information flow map, the list of privacy safeguarding requirements, the risk register, the risk treatment plan, the PIA report with its acceptance statement, and the public summary. In a mature organisation these are templates in a privacy management tool, linked to the project lifecycle so that a new project cannot pass its design gate without a completed threshold analysis.

Lesson 5 – Assessment, certification and compliance

No certificate for ISO/IEC 29134

ISO/IEC 29134 is a guidance document. Its guidance is written as recommendations, not requirements, so there is nothing for a certification body to certify against, and accredited certification against it does not exist. Be wary of any offer to "certify your organisation to ISO/IEC 29134". What organisations can legitimately say is that their PIA methodology is aligned with, or based on, ISO/IEC 29134. Individual training courses on PIA exist, but they certify a person's attendance or knowledge, not an organisation's conformity.

How PIAs are checked in practice

Even without certification, PIAs are scrutinised in several ways:

Internal review and approval. The privacy office or DPO reviews the PIA for completeness and quality before management signs the acceptance statement. Under the GDPR, a controller that has designated a DPO must seek the DPO's advice when carrying out a data protection impact assessment.
Internal audit. Auditors check that the PIA process is followed: that threshold analyses exist for new projects, that high-risk projects have full PIAs, that treatment actions were completed, and that PIAs are reviewed when things change.
Management system certification. If the organisation is certified to ISO/IEC 27701 (privacy information management) or ISO/IEC 27001 (information security management), the certification auditor will look at how privacy and security risks are assessed and treated, and a PIA method based on ISO/IEC 29134 is a common way to provide that evidence. ISO/IEC 27701 explicitly expects PII controllers to assess the privacy impact of new or changed processing.
Regulators. Data protection authorities can ask to see an impact assessment, and under the GDPR the controller must consult the supervisory authority before starting processing when the assessment shows a high risk that the controller cannot reduce enough by its own measures (prior consultation).
Customers and partners. Business clients increasingly ask suppliers for PIA results or summaries during procurement, especially for cloud, analytics and AI services.

ISO/IEC 29134 and the GDPR DPIA

Article 35 of the GDPR requires a data protection impact assessment (DPIA) for processing likely to result in a high risk to people's rights and freedoms. It lists cases where a DPIA is always needed, such as systematic and extensive profiling with legal or similarly significant effects, large-scale processing of special categories of data, and large-scale systematic monitoring of publicly accessible areas. The minimum content is a systematic description of the processing and its purposes, an assessment of necessity and proportionality, an assessment of the risks to people, and the measures planned to address them.

ISO/IEC 29134 does not mention the GDPR by name, but its process covers every one of these elements and adds useful structure: the threshold analysis, the team and plan, stakeholder engagement, information flow mapping and the report format. European regulators publish their own methods and templates as well, for example the CNIL's PIA guides and software in France and the ICO's DPIA guidance and template in the United Kingdom. A sensible approach is to use ISO/IEC 29134 as the backbone of your method and check it against the regulator's expectations in each country where you operate. Where a law imposes specific content or a specific format, the law wins.

What makes a PIA "good" to a reviewer

Reviewers and auditors tend to look for the same qualities: the PIA was started early enough to change the design; the description and data flows match the real system; the people affected were considered, and consulted where reasonable; risks are expressed as concrete scenarios with consequences for people, not only for the company; ratings follow the agreed criteria; necessity and proportionality are argued, not assumed; treatment actions have owners and dates and were actually completed; residual risk was accepted by someone with the authority to do so; and the PIA was revisited when the processing changed.

Lesson 6 – Worked example

This example ties the lessons together. The organisation is fictional, but the situation is typical.

The organisation and the initiative

Peakline Clubs runs 40 fitness clubs in two European countries, with about 120,000 members. It plans a new member app with three features: entry to the clubs by face recognition instead of a plastic card, a heart-rate and workout history synced from members' wearables, and personalised training and nutrition suggestions. The app will be built by an external developer, hosted by a cloud provider, and the face-recognition engine will be licensed from a specialist vendor. The product owner wants to launch in nine months.

Threshold analysis

The privacy office runs its threshold questionnaire during the project's first design review. Several triggers fire at once: biometric data used to identify people, health-related data from wearables, profiling for personalised recommendations, new technology, three new processors and roughly 120,000 people affected. The answer is clear: a full PIA, scaled as "high", with the DPO involved from the start and management sign-off at board level.

Preparation

The chief operating officer sponsors the PIA and appoints the privacy manager as PIA lead. The team includes the product owner, the solution architect from the app developer, the security manager, a lawyer, the club operations manager and a contact from the face-recognition vendor. The plan sets eight weeks for the PIA, aligned with the design phase, and fixes the risk criteria: a four-level impact scale and a four-level likelihood scale adapted from the examples in Annex A, with any risk rated "high" or above needing treatment and any residual "high" risk going to the board and, if it cannot be reduced, to the regulator for prior consultation.

The description of the processing lists the purposes (club access, workout tracking, recommendations), the categories of PII (identity and contact details, membership and payment status, face images and templates, heart-rate and workout data, inferred fitness level and goals), the PII principals (adult members, plus 16- and 17-year-old members in one country), the parties and the systems. The consultation plan includes a survey and two focus groups with members, a briefing for club staff, and questions to each processor.

Performing the PIA

Information flows. The team maps the flows. Face images are captured during enrolment in the app, converted into templates and, in the original design, stored centrally in the cloud for matching at the door cameras. Wearable data flows from the device vendor's platform into the app backend every hour. Recommendations are computed nightly by a model. Logs from door cameras go to the security system. The mapping uncovers two surprises: the app developer's analytics kit sends a device identifier to a third-party analytics service, and the face-recognition vendor's standard contract allows it to use customer images "to improve its products".

Implications of the use case. Focus groups show that many members like keyless entry but are uneasy about a central database of their faces; several say they would leave if face entry were compulsory. Staff point out that some members are celebrities or people who need to keep their whereabouts private. The team notes that the purpose of entry control can be met with far less intrusive means, and that health-related inferences ("member is losing weight fast") could be sensitive.

Privacy safeguarding requirements. The lawyer lists the GDPR, including the rules on special categories of data and the need for explicit consent for biometric identification in this context, national rules on the age at which minors can consent, the clubs' own privacy notice and policy, and payment card security obligations for the stored card tokens.

Risk assessment

The team writes eleven risk scenarios. Its agreed risk matrix gives impact more weight than likelihood, because harm to members matters most. Four examples:

Scenario	Likelihood	Impact on members	Level
Attacker steals the central face-template database through a cloud misconfiguration	Significant	Maximum: biometrics cannot be changed	Very high
Face entry is effectively compulsory, so members cannot freely refuse consent	Maximum	Significant: loss of choice, possible unlawful processing	High
Vendor reuses member face images to train its products	Significant	Significant: unexpected secondary use	High
Staff look up a member's visit times to locate them	Limited	Maximum for people at risk of stalking	High

The compliance analysis flags two mandatory issues regardless of score: consent for biometric entry is not valid if there is no real alternative, and the analytics identifier was collected without the transparency the law requires.

Treatment

The team proposes, and the sponsor agrees:

Modify (design): face entry becomes strictly optional, with the existing card or a phone QR code as an equal alternative; templates are stored only on the member's phone and matched with a short-lived token at the door, so there is no central face database; raw images are deleted right after template creation.
Avoid: the analytics kit is removed from the app; the "weight change" insight is dropped from the recommendation engine.
Modify (contract and organisation): the vendor contract is amended to forbid any secondary use of images and to require deletion and audit rights; visit logs are kept for 30 days, staff access is limited to the duty manager and every lookup is logged and reviewed monthly.
Modify (minors): face entry and recommendations are not offered to members under the local age of digital consent.
Share: the cloud contract includes security obligations and cyber insurance covers response costs, while the team notes that this does not reduce the harm to members.

After treatment, the team re-rates the risks. The central-database scenario disappears because the database no longer exists, and the remaining risks fall to "medium" or "low". One residual "medium" risk, the possibility that a stolen phone exposes a member's on-device template, is retained with a mitigation: the template is protected by the phone's secure hardware and is useless outside the app.

Report, decision and follow-up

The PIA report follows the clause 7 structure: scope and criteria, people and consultation, requirements, risk sources, threats and likelihood, consequences and impact, evaluation and compliance analysis, the treatment plan with owners and dates, the conclusion and the decision. The COO and the managing director sign an acceptance statement taking ownership of the residual risks and the treatment plan. A two-page public summary, without security details, is published on the website and linked from the app's privacy notice. Because no high residual risk remains, prior consultation with the regulator is not needed, a conclusion the DPO records together with the reasoning.

Six months after launch, internal audit checks that every treatment action was completed, finds that the 30-day log deletion was not yet automated, and raises a finding. A year later, when Peakline wants to add a feature that shares workout data with a partner insurer, the threshold analysis is re-run and the PIA is reopened for the new flow.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 29134 sits in a family of privacy and risk documents. It is easiest to understand as the "how to assess a specific processing activity" piece of that family.

Document	What it is	How it relates to ISO/IEC 29134
ISO/IEC 29100	Privacy framework: actors, roles and privacy principles	Supplies the vocabulary (PII, PII principal, controller, processor) and the principles a PIA assesses against
ISO/IEC 27701	Certifiable privacy information management system (PIMS) requirements and guidance	The management system that governs privacy; a 29134-style PIA is a common way to meet its expectation of privacy impact assessment
ISO/IEC 27005	Guidance on managing information security risks	Shares the identify-analyse-evaluate-treat logic; a PIA widens the view from security to all privacy impacts on people
ISO 31000	Generic risk management guidelines	The underlying risk vocabulary and process that ISO/IEC 29134 applies to privacy
ISO/IEC 29151 and ISO/IEC 27002	Catalogues of PII protection and security controls	Sources of controls for the risk treatment plan
GDPR Article 35 DPIA	Legal obligation in the EU and EEA (and the UK GDPR)	Says when an assessment is mandatory and what it must contain; ISO/IEC 29134 offers a detailed method that covers those elements
NIST Privacy Framework	Voluntary US framework for managing privacy risk at enterprise level	Works at organisation level; PIAs provide the project-level assessments that feed it

Choosing the right tool

A simple way to remember the family is by the question each one answers. ISO/IEC 29100 answers "what does privacy mean and which principles apply?" ISO/IEC 27701 answers "how do we run privacy as a managed, auditable system across the organisation?" ISO/IEC 29134 answers "what could this particular processing do to people, and what will we do about it?" ISO/IEC 27005 and ISO 31000 answer "how do we manage risk in general?", and the control catalogues answer "which safeguards could we use?" Laws such as the GDPR answer "when must we do this, and what is the minimum?"

In practice, organisations combine them. A typical setup is a privacy management system aligned with ISO/IEC 27701, a single PIA procedure based on ISO/IEC 29134 that is also accepted as the GDPR DPIA method, risk criteria shared with the security risk process from ISO/IEC 27005 so that the board sees one consistent picture, and control selection from ISO/IEC 27002 and ISO/IEC 29151. Doing this avoids the common situation where the security team, the privacy team and the legal team each run their own, slightly different assessment of the same project.

PIA and other impact assessments

New kinds of impact assessment are appearing, for example for artificial intelligence systems and for fundamental rights. They overlap with PIAs, because AI systems often process PII, but they also consider effects that are not about personal data, such as safety, fairness of outcomes for groups, or environmental impact. Where both apply, many organisations run one combined workshop and produce linked reports, using the PIA for the privacy part and the AI or rights assessment for the rest, so that the same data flows and stakeholder consultation are not done twice.

Common pitfalls and best practices

Common pitfalls:

Starting too late. A PIA begun after the design is frozen can only add paperwork, not change the system. The value of a PIA lies in the design options it still has.
Treating the PIA as a security checklist. Teams that only ask about breaches miss over-collection, purpose creep, excessive retention, lack of transparency and unfair automated decisions.
Rating impact on the company instead of the people. A low business impact can hide a severe impact on an individual; the people concerned come first.
No real stakeholder input. Assuming what users think, instead of asking them or their representatives, produces blind spots that surface later as complaints or headlines.
Copy-and-paste PIAs. Reusing a previous project's text without checking the data flows leads to reports that describe a different system.
Treatment plans without owners or follow-up. Actions that nobody owns are not implemented, and the residual risk accepted on paper is not the real one.
One and done. A PIA that is never reopened becomes wrong as soon as the system, the law or the suppliers change.

Best practices:

Build the threshold analysis into the project lifecycle so that every new or changed processing activity is screened at the first design gate.
Agree the risk criteria, including what level of residual risk management may accept, before any risks are scored.
Map the information flows from the real system, including processors, logs, backups, analytics and test copies, and keep the map current.
Ask "is this necessary?" for every data element and every use, and prefer design changes (collect less, delete sooner, keep on the device) over add-on controls.
Consult the people affected in proportion to the risk, and record what they said and what you changed as a result.
Make management sign an acceptance statement, so that residual risk is owned by someone with the authority to accept it.
Publish a plain-language public summary, which builds trust and forces clarity about what the system really does.
Track treatment actions to completion and schedule reviews, linking the PIA to change management.

Summary and key takeaways

ISO/IEC 29134:2023 is the current international guideline for privacy impact assessment; it gives guidance on the PIA process and on the structure and content of the PIA report.
A PIA is both an instrument and a continuing process that should start early enough to shape the design and continue after go-live.
The standard has three working clauses: preparing the grounds (clause 5), the process (clause 6) and the report (clause 7), supported by four informative annexes on scales, generic threats, terms and examples.
The process runs from threshold analysis through preparation (team, plan, description, stakeholders), performance (flows, use case, requirements, risk assessment, treatment) to follow-up (report, publication, implementation, review).
Privacy risk is judged mainly by its consequences for the PII principals, and it is wider than security risk.
Treatment options are to modify, avoid, share or retain the risk; management signs an acceptance statement for the residual risk.
There is no certification against ISO/IEC 29134; PIAs are checked through internal review and audit, management system audits, customers and regulators.
It combines well with ISO/IEC 29100, ISO/IEC 27701, ISO/IEC 27005 and the GDPR DPIA, and can serve as the single PIA method across an organisation.

Reflection questions

Think of a project in your organisation that started in the last year. Which threshold triggers would it have met, and how deep should its PIA have been?
For a system you know well, sketch the information flows of PII from collection to deletion. Where are the flows you are least sure about, and who could tell you?
Choose one risk scenario from that system and rate it twice: once by its impact on the organisation and once by its impact on the people affected. What changes, and why?
Who in your organisation has the authority to sign an acceptance statement for residual privacy risk, and what information would that person need to decide responsibly?
How would you design a stakeholder consultation for a system used by people who cannot easily speak for themselves, such as children, patients or job applicants?