What does control A.1.2.6 require?
The organisation shall assess the need for, and implement where appropriate, a privacy impact assessment whenever new processing of PII or changes to existing processing of PII is planned.
This control sits within the Conditions for collection and processing objective (A.1.2). Unlike the preceding controls that focus on lawful basis and consent, A.1.2.6 introduces a risk assessment requirement. It mandates a two-stage approach: first, assess whether a PIA is needed (a screening step), and second, if it is needed, carry it out before processing begins.
What does the implementation guidance say?
Annex B (section B.1.2.6) provides the following guidance:
- Timing is critical — PIAs should be conducted before processing begins. They are a preventive measure, not a retrospective justification
- The PIA should assess:
- Necessity and proportionality — Is the processing necessary for the stated purpose, and is the amount of PII collected proportionate to what is needed?
- Risks to PII principals — What potential harms could arise from the processing, including unauthorised access, loss, discrimination or reputational damage?
- Proposed mitigations — What controls, safeguards or design choices will reduce the identified risks to an acceptable level?
- See also A.1.2.4: Determine When and How Consent Is to Be Obtained for related requirements
- See also A.1.2.5: Obtain and Record Consent for related requirements
- Results should be documented and used to inform processing decisions — the PIA is not a tick-box exercise but a decision-making tool
- The guidance references ISO/IEC 29134 (Guidelines for privacy impact assessment) as the detailed methodology standard for conducting PIAs
Practically, this means organisations need both a screening process (to decide when a PIA is required) and a PIA methodology (to conduct the assessment when triggered).
How does this map to GDPR?
Control A.1.2.6 maps to a substantial block of GDPR provisions:
- Article 35(1)–(11) — The Data Protection Impact Assessment (DPIA) requirements. The GDPR mandates DPIAs where processing is “likely to result in a high risk to the rights and freedoms of natural persons” and sets out minimum content requirements including: a systematic description of processing, assessment of necessity and proportionality, assessment of risks, and measures to address risks
- Article 36(1) (not mapped in Annex D but closely related)–(5) — Prior consultation with the supervisory authority. Where a DPIA indicates high residual risk that cannot be mitigated, the controller must consult the supervisory authority before processing begins
The GDPR’s DPIA requirement is more prescriptive than the ISO 27701 control — it mandates assessment for high-risk processing, whereas A.1.2.6 requires organisations to assess the need for a PIA for any new or changed processing. In practice, implementing A.1.2.6 will satisfy the GDPR DPIA requirement provided the screening criteria capture all Article 35 trigger scenarios.
How does this relate to ISO 29100 privacy principles?
This control supports multiple ISO 29100 privacy principles:
- Consent and choice — PIAs help identify where consent mechanisms need to be designed or strengthened
- Collection limitation — The necessity and proportionality assessment directly addresses whether too much PII is being collected
- Privacy compliance — PIAs are a mechanism for verifying and demonstrating compliance with privacy requirements before processing begins
Get started easily with a personal product demo
One of our onboarding specialists will walk you through our platform to help you get started with confidence.
What evidence do auditors expect?
When assessing compliance with A.1.2.6, auditors will typically look for:
- PIA screening criteria — A documented threshold or checklist used to determine whether a full PIA is required for a given processing activity or change
- Screening records — Evidence that the screening process was applied to new and changed processing activities, including cases where a full PIA was not deemed necessary (with documented rationale)
- Completed PIA reports — Full assessment documents covering necessity, proportionality, risk analysis and proposed mitigations
- Risk treatment decisions — Evidence that PIA findings were acted upon — mitigations implemented, processing modified, or in some cases processing abandoned
- Sign-off records — Approval from appropriate stakeholders (e.g. DPO, senior management) that the PIA was reviewed and the residual risk accepted
- Prior consultation records — Where residual risk remained high after mitigation, evidence that the supervisory authority was consulted (GDPR Article 36)
What are the related controls?
| Control | Relationship |
|---|---|
| A.1.2.2 Identify and document purpose | Purpose documentation is an input to the PIA — you cannot assess necessity without knowing the purpose |
| A.1.2.3 Identify lawful basis | The PIA should verify that a valid lawful basis exists for the planned processing |
| A.1.4.3 Limit processing | The proportionality assessment in the PIA informs data minimisation decisions |
| A.1.4.6 PII De-identification and Deletion | PIAs may identify de-identification or deletion as a risk mitigation measure |
| A.1.2.7 Contracts with PII processors | Where processing involves third-party processors, the PIA should assess processor-related risks |
| ISO/IEC 29134 | The referenced standard providing detailed PIA methodology and guidelines |
What changed from ISO 27701:2019?
For a step-by-step approach, see the Transition from 2019 to 2025.
In the 2019 edition, this requirement appeared as Clause 7.2.5 (privacy impact assessment). The core requirement is unchanged — assess the need for a PIA and conduct one where appropriate. The 2025 restructuring into Table A.1 provides clearer separation between the control statement (A.1.2.6) and guidance (B.1.2.6). The reference to ISO/IEC 29134 as the detailed PIA methodology standard has been retained, reinforcing that organisations should follow a structured approach rather than an ad hoc assessment. See the Annex F correspondence table for the full mapping.
Manage all your compliance, all in one place
ISMS.online supports over 100 standards and regulations, giving you a single platform for all your compliance needs.
Why choose ISMS.online for privacy impact assessments?
ISMS.online provides an end-to-end PIA workflow that takes you from screening to sign-off:
- PIA screening tool — A built-in questionnaire that determines whether a full assessment is needed, with documented rationale for every decision
- Structured PIA templates — Pre-built assessment templates aligned to ISO/IEC 29134, guiding assessors through necessity, proportionality, risk identification and mitigation planning
- Risk scoring and heat maps — Visual risk analysis with likelihood and impact scoring, making it easy to prioritise mitigations and communicate findings to stakeholders
- Mitigation tracking — Assign risk treatment actions to owners with deadlines, and track implementation progress within the same platform
- Approval workflows — Route completed PIAs to the DPO or senior management for review and sign-off, with full audit trail of the approval process
- Linked evidence — Connect PIAs to the processing activities, lawful bases and consent records they relate to, creating a complete compliance picture
FAQs
When is a privacy impact assessment mandatory?
Under ISO 27701:2025, a PIA is not automatically mandatory for every processing activity — the control requires you to assess the need for one. However, under GDPR Article 35, a DPIA is mandatory where processing is likely to result in a high risk to individuals’ rights. The European Data Protection Board has published criteria including: systematic evaluation of personal aspects (profiling), large-scale processing of special categories, and systematic monitoring of publicly accessible areas. Organisations should build these triggers into their screening criteria.
Can a PIA be done after processing has already started?
The standard and GDPR both expect PIAs to be conducted before processing begins. However, if you discover that a PIA should have been done and was not, conducting one retrospectively is better than not doing one at all. The retrospective PIA may identify risks that require immediate mitigation or even cessation of processing. Auditors will note the timing gap but will view a late PIA more favourably than no PIA.
How often should existing PIAs be reviewed?
PIAs should be reviewed whenever there is a material change to the processing they cover — such as new data categories, new recipients, changes in technology, or changes in the regulatory environment. Best practice is also to set a periodic review schedule (e.g. annually) to catch incremental changes that may not have triggered an individual review. The review should assess whether the original risk analysis and mitigations remain valid.
