mukul975 Comparing PIA Methodologies
Overview
Multiple established methodologies exist for conducting Privacy Impact Assessments: the CNIL PIA tool, ICO DPIA template, NIST Privacy Framework, and ISO/IEC 29134:2017. Each methodology reflects its originating regulatory context, organisational assumptions, and privacy philosophy. Selecting the appropriate methodology — or combining elements from several — is critical for producing assessments that satisfy regulatory expectations, align with organisational maturity, and address the actual risks of the processing activity. This skill provides a structured comparison framework for methodology selection.
Methodology Profiles
1. CNIL PIA Tool (France)
Origin: Commission Nationale de l'Informatique et des Libertes (CNIL), first published 2015, updated 2018 for GDPR alignment.
Structure:
- Step 1: Context — Describe the processing, its purposes, the data processed, and the actors involved.
- Step 2: Fundamental Principles — Assess compliance with necessity, proportionality, data subject rights, and obligations (Art. 5, 6, 9, 12-22, 28, 44).
- Step 3: Risks — Identify feared events (illegitimate access, unwanted modification, disappearance of data), assess severity and likelihood.
- Step 4: Validation — Map risks against controls. Decide whether to accept residual risk, implement additional measures, or consult the supervisory authority.
Key Features:
- Three feared events model (access, modification, disappearance) structured around CIA triad adapted for privacy.
- Severity scale: Negligible, Limited, Significant, Maximum.
- Likelihood scale: Negligible, Limited, Significant, Maximum.
- Risk matrix: 4x4 grid mapping severity against likelihood.
- Explicit link to Art. 35 and Art. 36 prior consultation threshold.
- Open-source PIA software tool available for download.
Regulatory Acceptance:
- Required format for French supervisory authority submissions.
- Accepted by Belgian DPA (APD/GBA) as compliant methodology.
- Referenced by EDPB as an example of good practice in WP248rev.01.
- Widely used across francophone jurisdictions (Belgium, Luxembourg, Switzerland).
2. ICO DPIA Template (United Kingdom)
Origin: Information Commissioner's Office (ICO), UK. Published as part of ICO GDPR guidance, updated for UK GDPR post-Brexit.
Structure:
- Step 1: Identify the need for a DPIA — Screening checklist against Art. 35(3) triggers and ICO's published list of processing requiring DPIA.
- Step 2: Describe the processing — Nature, scope, context, purposes. Data flows including recipients and transfers.
- Step 3: Consultation process — Record of consultation with data subjects, DPO, and other stakeholders.
- Step 4: Assess necessity and proportionality — Lawful basis, purpose limitation, data minimisation, accuracy, storage limitation, security, international transfers.
- Step 5: Identify and assess risks — Risks to individuals organised by source, nature of harm, severity, likelihood.
- Step 6: Identify measures to mitigate risks — For each risk, identify measures that reduce it to an acceptable level.
- Step 7: Sign off and record outcomes — DPO advice, controller decision, integration with processing register.
Key Features:
- Seven-step linear process designed for practical completion.
- Emphasis on consultation with data subjects (Step 3) — a distinctive feature not prominent in other methodologies.
- Risk assessment focused on harm to individuals rather than CIA triad.
- Explicit requirement to record DPO advice and whether it was followed.
- Template available as downloadable Word document.
- Screening checklist integrated into Step 1.
Regulatory Acceptance:
- Required format for UK ICO submissions and prior consultation.
- Accepted by Irish DPC as compliant methodology for UK-Ireland processing.
- Used as basis for several Member State DPA templates (Denmark, Netherlands).
- Recommended by UK government for public sector processing.
3. NIST Privacy Framework (United States)
Origin: National Institute of Standards and Technology (NIST), Version 1.0 published January 2020. Voluntary framework.
Structure:
- Core: Five functions — IDENTIFY, GOVERN, CONTROL, COMMUNICATE, PROTECT.
- Profiles: Current state and target state assessment for each subcategory.
- Implementation Tiers: Tier 1 (Partial) to Tier 4 (Adaptive) maturity levels.
Key Features:
- Not a PIA methodology per se, but provides the organisational context within which PIAs are conducted.
- IDENTIFY function (ID.RA) maps directly to risk assessment activities in PIA.
- Complementary to NIST Cybersecurity Framework (CSF) — designed for joint deployment.
- Sector-agnostic: applicable across all industries, not limited to specific regulatory context.
- Privacy Engineering objectives: Predictability, Manageability, Disassociability.
- No prescribed risk scale or matrix — organisations define their own.
Regulatory Acceptance:
- Not a regulatory requirement but widely referenced by US federal agencies (FTC, HHS, DOE).
- Accepted as evidence of privacy program maturity by US state regulators (CCPA/CPRA, VCDPA, CPA).
- Referenced by APEC CBPR system for cross-border data flows.
- Increasingly referenced by EU organisations as complementary to GDPR DPIA.
4. ISO/IEC 29134:2017 — Privacy Impact Assessment Guidelines
Origin: International Organization for Standardization, published 2017. International standard.
Structure:
- Clause 6: PIA preparation — Determine necessity, establish PIA team, develop PIA plan, stakeholder engagement.
- Clause 7: PIA execution — Information gathering, data flow analysis, privacy risk analysis (identification, estimation, evaluation), privacy risk treatment.
- Clause 8: PIA follow-up — PIA report, publication of summary, implementation of treatment plan, audit/review.
Key Features:
- Most comprehensive and structured methodology — designed as auditable standard.
- Risk assessment based on ISO 31000 risk management framework.
- Privacy risk = likelihood x consequence (consequence to the data subject, not the organisation).
- Requires formal PIA plan before assessment begins.
- Mandates stakeholder engagement including data subjects.
- PIA report has prescribed structure (Clause 8.2) with 13 required sections.
- Integrates with ISO/IEC 27701 (privacy information management) and ISO/IEC 27001 (information security).
Regulatory Acceptance:
- Accepted by supervisory authorities globally as evidence of systematic approach.
- Referenced by EDPB in WP248rev.01 as an example of PIA methodology.
- Required or recommended by several Asian-Pacific DPAs (Singapore PDPC, South Korea PIPC, Japan PPC).
- Certification bodies use ISO 29134 as assessment framework for Art. 42 GDPR certification schemes.
Methodology Comparison Matrix
| Dimension | CNIL PIA | ICO DPIA | NIST PF | ISO 29134 |
|---|---|---|---|---|
| Regulatory origin | French DPA (CNIL) | UK DPA (ICO) | US NIST | International (ISO/IEC) |
| Legal framework | GDPR | UK GDPR | Sector-agnostic | International |
| Risk model | 3 feared events (CIA-adapted) | Harm to individuals | Organisation-defined | ISO 31000-based |
| Risk scale | 4x4 (Negligible to Maximum) | Qualitative (Low/Medium/High) | Organisation-defined tiers | Likelihood x Consequence |
| Steps/phases | 4 steps | 7 steps | 5 functions | 3 clauses (prep/execute/follow-up) |
| Data subject consultation | Recommended | Explicitly required (Step 3) | COMMUNICATE function | Required (Clause 6.4) |
| DPO involvement | Required | Required with advice recording | N/A (no DPO concept) | Recommended |
| Tool availability | Open-source software | Word template | Excel self-assessment | No official tool |
| Cost | Free | Free | Free | Standard purchase required (~CHF 166) |
| Certification alignment | None | None | NIST CSF alignment | ISO 27701, ISO 27001 |
| Typical completion time | 2-4 weeks | 1-3 weeks | Ongoing (framework) | 4-8 weeks |
| Best suited for | EU/GDPR processing, French-regulated entities | UK processing, practical quick-start | US organisations, framework-based programs | Multinational, auditable, certification-seeking |
Methodology Selection Criteria
Decision Factors
| Factor | Weight | Considerations |
|---|---|---|
| Regulatory jurisdiction | High | Which supervisory authority will review the assessment? Use their preferred methodology. |
| Organisational maturity | Medium | Low maturity → ICO (simplest). Medium → CNIL. High → ISO 29134. |
| Processing complexity | Medium | Simple processing → ICO. Complex/high-risk → CNIL or ISO 29134. |
| International scope | High | Single jurisdiction → local DPA methodology. Multi-jurisdiction → ISO 29134. |
| Certification goals | Medium | Seeking ISO 27701 or Art. 42 certification → ISO 29134. |
| Resource availability | Medium | Limited resources → ICO. Dedicated privacy team → ISO 29134. |
| Existing framework | Low | Already using NIST CSF → add NIST PF. Already ISO 27001 → ISO 29134. |
Selection Decision Tree
- Is the processing subject to a specific supervisory authority that mandates or recommends a methodology?
- Yes → Use that authority's methodology (CNIL for France, ICO for UK).
- No → Continue to step 2.
- Does the organisation operate across multiple jurisdictions?
- Yes → ISO 29134 (internationally recognised).
- No → Continue to step 3.
- What is the organisation's privacy maturity level?
- Low (no formal privacy program) → ICO DPIA template (quickest to adopt).
- Medium (privacy program exists) → CNIL PIA tool (structured but accessible).
- High (mature privacy program, certification goals) → ISO 29134.
- Is the organisation US-based with an existing NIST CSF deployment?
- Yes → NIST PF as organisational framework, supplemented by CNIL or ICO for individual DPIAs.
- No → Use selection from steps 1-3.
Cross-Methodology Mapping
| CNIL Step | ICO Step | NIST PF Function | ISO 29134 Clause |
|---|---|---|---|
| Step 1: Context | Step 2: Describe processing | ID.IM (Inventory & Mapping) | Clause 6: Preparation |
| — | Step 1: Identify need | — | Clause 6.1: Determine necessity |
| — | Step 3: Consultation | CT.PO (Communication Policies) | Clause 6.4: Stakeholder engagement |
| Step 2: Fundamental Principles | Step 4: Necessity & proportionality | GV.PO (Governance Policies) | Clause 7.3: Privacy safeguard analysis |
| Step 3: Risks | Step 5: Identify & assess risks | ID.RA (Risk Assessment) | Clause 7.4: Risk analysis |
| Step 4: Validation | Step 6: Mitigation measures | CT.DM (Data Processing Management) | Clause 7.5: Risk treatment |
| — | Step 7: Sign off & record | GV.AT (Awareness & Training) | Clause 8: Follow-up |
Enforcement and Regulatory Guidance
- EDPB WP248rev.01: References both CNIL and ISO 29134 as acceptable DPIA methodologies. Does not mandate any specific methodology but requires that the chosen approach satisfies Art. 35(7)(a)-(d) minimum content.
- Art. 35(7) Minimum Content: Any methodology must include: (a) systematic description of processing and purposes; (b) necessity and proportionality assessment; (c) risk assessment; (d) measures to address risks. All four methodologies satisfy these requirements.
- CJEU C-175/20 (SS SIA 'Valsts ieņēmumu dienests'): Court confirmed that DPIA must assess risks from the perspective of data subjects, not the controller — aligns with ICO and ISO 29134 harm-based approaches.
- CNIL Deliberation 2018-327: Published criteria for acceptable DPIA methodologies — 10 criteria that any methodology must satisfy, regardless of which tool is used.