ISO/IEC 29134
guidelines for privacy impact assessment

ISO/IEC 29134 explained for privacy, GRC, and security teams

ISO/IEC 29134:2017 (Information technology, Security techniques, Guidelines for privacy impact assessment) is the international methodology standard for conducting a privacy impact assessment (PIA). It is referenced by GDPR Article 35 DPIA guidance, by the controller and processor annexes of ISO/IEC 27701, by the UK ICO DPIA guidance, and by sector privacy regimes around the world as the methodology that produces the assessment evidence the regulator expects. The standard does not prescribe a tool, a form, or a single template; it names the inputs, the analysis steps, the outputs, the consultation discipline, and the residual risk decision shape so the assessment is reproducible across systems, sectors, and jurisdictions.

For privacy officers and data protection officers accountable for the PIA discipline, GRC and compliance teams producing the assessment evidence, security architects credited as control owners inside the PIA, engineering and product teams whose systems trigger screening, legal counsel reading the consultation record, and CISOs at organisations read against by GDPR supervisory authorities, the ICO, the FTC, sector regulators, customers under data sharing agreements, and certification bodies, ISO/IEC 29134 is the methodology reference the discipline reads against. The standard is the international anchor that the Article 29 Working Party DPIA guidance (WP248 rev.01), the EDPB Guidelines on DPIA, the UK ICO DPIA guidance, the NIST Privacy Framework v1.0, and the privacy-criteria reads inside SOC 2 and ISO 27701 audits all hand off into on the operating-method side.

This page walks through the scope of the standard, the nine-step PIA process the standard names, the operating-record artefacts the programme produces, the failure modes the standard surfaces, the relationship with adjacent regimes (GDPR, UK GDPR, ISO/IEC 27701, ISO/IEC 27001, the NIST Privacy Framework, sector regimes), the audit-grade evidence pack the programme produces, and where ISO/IEC 29134 sits alongside the DPIA template, the compliance audit operating workflow, and the audit fieldwork evidence request workflow. Programmes that adopt ISO/IEC 29134 as the PIA method produce an assessment register that holds up across GDPR Article 35, the ISO 27701 audit, the SOC 2 privacy criteria, sector privacy reviews, customer due diligence, and internal audit reads on one operating record.

What ISO/IEC 29134 covers

The standard is the international methodology anchor for the privacy impact assessment as a structured discipline. It is broader than any single regulator template and narrower than the wider privacy management system; the boundary is the impact-assessment lifecycle from threshold screening through residual risk decision and follow-up. Read sequentially across the document, the standard answers the question of how an organisation operates a PIA as a repeatable method rather than as a system-by-system improvisation.

The nine-step PIA process

ISO/IEC 29134 names a nine-step process. The steps are not separate exercises; they are stages on the same PIA record, each with named outputs the next step reads against. Threshold and screening produces the open-or-close decision; preparation and scoping produces the scope statement; description of the processing produces the data flow; necessity and proportionality produces the prior question of whether the processing should exist in its current shape; risk identification, evaluation, and treatment produce the residual risk picture and the treatment plan; the PIA report and residual risk decision produce the named accountable signature; and implementation and follow-up produce the closure cycle and the material-change discipline.

1. 1

   Step 1: Threshold and screening

   Decide whether a PIA is needed for the processing activity. The screening question set covers the categories of PII, the volume, the geographic scope, the data subject vulnerability, the use of novel technologies, automated decision-making, cross-border transfers, third-party integrations, public surveillance, the necessity and proportionality of the processing, and the residual risk pattern from any prior assessment of the same system. A positive screen opens a PIA record; a negative screen records the rationale on the screening log so the decision is reproducible at audit time.

2. 2

   Step 2: PIA preparation and scoping

   Define the scope of the PIA (which processing operations, which systems, which actors, which jurisdictions), name the PIA owner, name the contributors (privacy, security, engineering, product, legal, business unit, vendor), and document the data flow at a level that lets the next step reason about risk. The scope statement is the artefact every later step reads against; ambiguous scope is the most common cause of a PIA that reaches the residual risk decision and cannot defend the boundary it covered.

3. 3

   Step 3: Description of the processing

   Document the processing operations in structured form: the purposes (each named explicitly), the categories of PII (each named explicitly), the data subjects (each named explicitly), the lawful basis (where the regulation expects one), the recipients (named processors, named sub-processors, named controllers in joint controllership, named third parties under data sharing agreements), the retention periods (per category), the cross-border transfers (the destination country, the transfer mechanism, the recipient role), the security measures envisaged, and the consultation activities. The description is the substrate the privacy risk analysis reasons about.

4. 4

   Step 4: Necessity and proportionality assessment

   Assess whether the processing is necessary for the stated purpose (cannot the purpose be reached with less PII, fewer categories, shorter retention, narrower recipient set), and whether the processing is proportionate (does the benefit justify the impact on the data subjects). This step is the one that surfaces the largest single set of PIA outcomes that change the processing design rather than just adding mitigations. Programmes that skip this step and move straight to risk analysis produce assessments that document risk but not the prior question of whether the processing should exist at all in its current shape.

5. 5

   Step 5: Privacy risk identification

   Identify the privacy risks to data subjects across the established taxonomy: unauthorised access, accidental loss or destruction, unauthorised modification, unauthorised disclosure, unauthorised processing for incompatible purposes, profiling and automated decision-making harms, surveillance harms, discrimination harms, identity harms, financial harms, reputational harms, and psychological harms. Each risk is captured against the affected data subject category, the threat source, the likelihood band, the impact band, and the controls that already exist.

6. 6

   Step 6: Privacy risk evaluation

   Evaluate the residual risk after the controls already in place are credited, against the risk-acceptance criteria the organisation defines (often a likelihood-impact matrix calibrated to the regulatory regime and the contractual environment). The evaluation produces a per-risk decision band (accept, treat, transfer, avoid) the next step operates against.

7. 7

   Step 7: Privacy risk treatment plan

   Define the treatment plan per risk that is not in the accept band: the named control to add or strengthen, the named owner, the implementation date, the verification method, the evidence the verification will produce, and the schedule for revisiting the residual risk decision. The treatment plan is the artefact the operating programme reads against; risks that have no named owner and no named due date stay open in the assessment record but are silently unworked in the operating record.

8. 8

   Step 8: PIA report and residual risk decision

   Produce the PIA report that captures the description, the necessity and proportionality assessment, the risks, the treatment plan, and the residual risk decision. The residual risk decision is the named decision by the named authority (often the data protection officer, the chief privacy officer, the head of GRC, or the controller-side accountable executive) that the remaining risk is acceptable or that the processing will not proceed as scoped. The decision is captured on the PIA record with the named decider, the timestamp, the rationale, and the conditions attached to the acceptance.

9. 9

   Step 9: Implementation and follow-up

   Implement the treatment plan, verify the controls are in place, attach the verification evidence to the PIA record, and schedule the follow-up review. The follow-up cadence is driven by the risk profile of the processing (quarterly for high-residual-risk processing, annually for medium, on material change for low) and by any regulatory or contractual review obligation. Material changes (new processing purpose, new category of PII, new recipient, new cross-border transfer, change of lawful basis, change of retention period, new automated decision-making) trigger a re-opening of the PIA rather than an addendum.

The operating-record artefact set

The standard expects a defined artefact set rather than a single document. The pack below is the minimum durable set most programmes maintain when they adopt ISO/IEC 29134 as the PIA method. Each artefact has a named owner, a refresh cadence, and a version history so reconstruction at audit time is replaced with a continuous operating trail.

Failure modes the standard surfaces

The standard is forgiving on the choice of tooling, the wording of the screening questions, and the exact thresholds the programme uses. It is unforgiving about a small number of patterns that turn the PIA programme cosmetic rather than operational. The patterns below recur across PIA adoptions and are the ones that erode supervisory confidence, audit defensibility, and customer due-diligence credibility most reliably.

How ISO/IEC 29134 relates to adjacent regimes

ISO/IEC 29134 sits in a busy privacy regulatory and assurance neighbourhood. The relationships below are the ones programmes encounter most often when they read 29134 against the rest of the operating regime. Programmes operating across regions and sectors use 29134 as the PIA method and read GDPR, UK GDPR, ISO/IEC 27701, ISO/IEC 27001, the NIST Privacy Framework, SOC 2, HIPAA, PCI DSS, and the sector privacy regimes as the contextual layers around it.

Where SecPortal fits in an ISO/IEC 29134 programme

SecPortal is the operating layer for the privacy impact assessment case lifecycle, not a replacement for the privacy programme strategy, the data protection officer accountability, the legal counsel relationship, or the supervisory authority dialogue the regulation expects. The platform handles the assessment-side workstreams (screening, scoping, data flow description, necessity and proportionality reasoning, risk identification, treatment planning, residual risk decision, supervisory consultation record, verification evidence, follow-up cadence, material-change tracking) so the artefacts the standard expects are produced as structured records rather than reconstructed across email threads, document drives, and ticketing systems at audit time. The same workspace that hosts the PIA record hosts the security finding evidence, the credential lifecycle, the continuous monitoring results, and the policy and procedure artefacts that the technical security measures section of the PIA credits.

The PIA evidence (screening, scoping, description, necessity and proportionality, risk identification, evaluation, treatment, decision, follow-up) reads against operational workflows that already exist as named use cases. The compliance audit operating workflow carries the audit-cycle discipline the PIA register reads against when the wider audit cycle reaches the privacy programme. The audit fieldwork evidence request fulfillment workflow carries the supervisory consultation and fieldwork-day evidence packaging the PIA record feeds. The exception management workflow carries the residual risk acceptance discipline the PIA decision step records against.

For GRC and compliance teams operating ISO/IEC 29134 as part of the wider audit cadence, the GRC and compliance teams workspace covers the policy hierarchy, the evidence pack, and the audit cadence the standard expects. For internal security teams supporting the PIA discipline as the control-owner side, the internal security teams workspace bundles the platform with the engagement structure the PIA cadence reads against. For CISOs and security leaders carrying the programme-level reporting on the privacy programme posture and the named-decision accountability for residual risk, the CISOs and security leaders workspace covers the executive-layer reporting model that sits on top of the PIA operating record.

For deeper reading on the disciplines this standard reads against, the DPIA template tool provides a structured form the screening, scoping, and risk identification steps of the method can be operated against. The ISO/IEC 27701 framework page covers the privacy information management system the PIA register is a required artefact of (control B.7.2.5 in the controller annex and B.8.2.1 in the processor annex). The GDPR framework page covers the regulatory text Article 35 (DPIA) and Article 36 (prior consultation) name and the EDPB Guidelines the supervisory authorities read DPIAs against. The ISO/IEC 27001 framework page covers the information security risk management discipline that pairs with the privacy risk management discipline 29134 names so the joint risk register reads against both. The ISO/IEC 27005 framework page covers the information security risk management method that the security-risk facets of a PIA share heritage with so the assessment vocabulary is consistent across the two disciplines. The SEC cybersecurity disclosure framework page covers the disclosure-decision discipline US public companies operate alongside any privacy-incident materiality determination that flows from a PIA-credited control failure. The ISO/IEC 29147 framework page and the ISO/IEC 30111 framework page cover the vulnerability disclosure and handling standards that pair with 29134 for organisations whose products process PII and need to coordinate privacy and security assessment evidence on one operating record.