Managing PIA Review and Update Cadence
Overview
Art. 35(11) requires controllers to carry out a review to assess whether processing is performed in accordance with the DPIA, at least when there is a change in the risk represented by processing operations. A DPIA is not a one-time compliance exercise but a living document that must be maintained throughout the processing lifecycle. This skill establishes the governance framework for DPIA reviews, including trigger event identification, scheduled review cadence, version control, stakeholder sign-off, and DPIA register management.
Art. 35(11) Review Obligation
"Where necessary, the controller shall carry out a review to assess if processing is performed in accordance with the data protection impact assessment at least when there is a change in the risk represented by processing operations."
This means:
- Reviews are mandatory when risk changes
- The controller should proactively monitor for risk changes
- Regular periodic reviews are a best practice even without identified changes
- The DPIA must be updated to reflect the current state of processing
Review Trigger Categories
Category 1: Regulatory Triggers
| Trigger |
Assessment Action |
| New GDPR guidance from EDPB or national supervisory authority |
Assess whether guidance changes the interpretation of lawful basis, proportionality, or risk level for the processing |
| Adequacy decision adopted, renewed, or invalidated |
Reassess international transfers documented in the DPIA |
| National supervisory authority DPIA list updated (Art. 35(4)) |
Check if processing now appears on the mandatory DPIA list |
| New Member State employment, health, or sector-specific law |
Assess impact on lawful basis and proportionality for affected processing |
| Enforcement decision against similar processing by same or different SA |
Assess whether the enforcement rationale applies to the organisation's processing |
| AI Act obligations becoming applicable |
For AI-related DPIAs, assess conformity requirements |
Category 2: Processing Change Triggers
| Trigger |
Assessment Action |
| New personal data category added |
Reassess data minimisation, proportionality, and risk levels |
| New category of data subjects |
Reassess impact on new data subject group; check for vulnerable subjects |
| New recipient or processor |
Update data flow map; reassess sub-processor chain; verify DPA |
| Change in lawful basis |
Full reassessment of lawful basis justification and proportionality |
| Change in retention period |
Reassess storage limitation compliance |
| New purpose identified for existing data |
Art. 6(4) compatibility assessment; update DPIA purpose description |
| Processing volume significantly increased |
Reassess whether processing now qualifies as "large scale" |
| Geographic scope expanded |
Assess new jurisdictions for data protection requirements and international transfers |
Category 3: Technology Change Triggers
| Trigger |
Assessment Action |
| New system or platform deployment |
Full technical risk reassessment; update system description and data flow maps |
| System upgrade or migration |
Assess whether changes affect security measures, data flows, or processing scope |
| New algorithm or AI model deployed |
Reassess algorithmic fairness, Art. 22 applicability, and AI Act classification |
| New tracking or monitoring technology |
Reassess proportionality and ePrivacy compliance |
| Security vulnerability discovered |
Immediate risk reassessment; assess whether existing mitigations remain effective |
| End-of-life for system component |
Assess impact of reduced vendor support on security posture |
Category 4: Incident Triggers
| Trigger |
Assessment Action |
| Personal data breach involving the processing activity |
Mandatory DPIA review; reassess risk levels and mitigation effectiveness |
| Near-miss security incident |
Assess whether existing mitigations prevented the near-miss or were bypassed |
| Data subject complaint about the processing |
Investigate whether complaint reveals processing not documented in DPIA |
| Supervisory authority enquiry about the processing |
Review DPIA for completeness and accuracy before responding |
| Internal audit finding |
Address audit findings and update DPIA accordingly |
Category 5: Organisational Change Triggers
| Trigger |
Assessment Action |
| Merger, acquisition, or divestiture |
Reassess controller identity, data sharing arrangements, and international transfers |
| DPO change |
New DPO to review and approve existing DPIAs |
| Significant staff restructuring |
Verify processing owners, access controls, and organisational measures remain appropriate |
| New business unit using the processing |
Assess whether new use case was documented in the DPIA |
Scheduled Review Cadence
| Processing Risk Level |
Recommended Review Interval |
Justification |
| Very High (prior consultation was required) |
Every 6 months |
Processing that required Art. 36 prior consultation needs frequent monitoring |
| High (biometric, large-scale special category, AI decision-making) |
Every 6-12 months |
High-risk processing warrants at least annual review |
| Medium (standard employee monitoring, marketing profiling) |
Every 12 months |
Annual review is the standard best practice |
| Low (routine processing with low residual risk) |
Every 24 months |
Extended review interval acceptable for stable, low-risk processing |
Review Process
Step 1: Trigger Detection and Triage
- DPIA register manager monitors for trigger events continuously.
- When a trigger is detected, it is logged in the DPIA register against the affected DPIA(s).
- DPO triages the trigger to determine whether a full or targeted review is needed:
- Full review: Re-examine all DPIA sections (new system, major regulatory change, data breach)
- Targeted review: Update only the affected section (new recipient, retention change, minor system update)
Step 2: Review Execution
- Assemble the review team: processing owner, DPO, IT security (for technology changes), legal (for regulatory changes).
- For full reviews: re-execute the complete DPIA methodology from screening through risk assessment.
- For targeted reviews: update the affected section and reassess overall risk level.
- Document all changes from the previous version.
- Update the risk register with any new or modified risks.
Step 3: Stakeholder Sign-Off
| Stakeholder |
Role in Review |
Sign-Off Required? |
| Processing Owner |
Validates accuracy of processing description and confirms mitigations are implemented |
Yes |
| DPO |
Provides independent advice on risk assessment and proportionality per Art. 35(2) |
Yes |
| IT Security / CISO |
Validates technical measures and security risk assessment |
Yes (for technology-related reviews) |
| Legal Counsel |
Validates lawful basis and regulatory compliance |
Yes (for regulatory trigger reviews) |
| Senior Management |
Approves residual risk acceptance |
Yes (for full reviews or risk level changes) |
| Works Council |
Consulted on employee monitoring changes (jurisdiction-dependent) |
Yes (for employee monitoring DPIAs) |
Step 4: Version Control and Registration
- Create a new version of the DPIA document.
- Use version numbering: major changes increment the first digit (v2.0); minor changes increment the second digit (v1.1).
- Include a change log documenting:
- Date of change
- Trigger event that prompted the review
- Sections modified
- Summary of changes
- Reviewer and approver names
- Archive the previous version (do not delete; maintain audit trail).
- Update the DPIA register with the new version, review date, and next review date.
DPIA Register Management
The DPIA register is the central index of all DPIAs conducted by the organisation. It must contain:
| Field |
Description |
| DPIA Reference |
Unique identifier (DPIA-[ORG]-[YEAR]-[SEQ]) |
| Processing Activity Name |
Name of the processing operation |
| Version |
Current version number |
| Status |
Draft, Under Review, Approved, Expired, Superseded |
| Date Created |
Date of initial DPIA |
| Last Review Date |
Date of most recent review |
| Next Review Date |
Scheduled date for next review |
| Processing Owner |
Name and role of the processing owner |
| DPO Reviewer |
Name of the DPO who reviewed |
| Risk Level (Current) |
Current overall risk level after mitigation |
| Prior Consultation Required |
Whether Art. 36 was triggered |
| Related Processing Activities |
Cross-references to related DPIAs |
| Change Log |
Summary of version history |
Common Review Process Deficiencies
- No trigger monitoring: Organisation relies solely on scheduled reviews without monitoring for change events.
- Stale DPIAs: Reviews conducted on paper without verifying actual processing matches the DPIA description.
- No version control: Edits made to the original document without maintaining previous versions.
- Incomplete stakeholder engagement: DPO reviews without consulting the processing owner or IT security.
- No change log: Updates made without documenting what changed and why.
- Expired review dates: DPIA register shows overdue reviews without remediation.
Enforcement Context
Supervisory authorities have increasingly scrutinised DPIA currency:
- Swedish DPA vs Karolinska (2019): Noted that DPIA had not been conducted at all, let alone reviewed.
- CNIL vs Clearview AI (2022): The absence of any DPIA was an aggravating factor in the fine determination.
- Austrian DPA vs Austrian Post (2019): Inadequate ongoing review of profiling DPIA was a contributing factor.
1---2name: pia-review-cadence3description: Guides the periodic DPIA review lifecycle including trigger identification for regulatory changes, new data categories, technology changes, and breach incidents. Covers version control, stakeholder sign-off procedures, and DPIA register management per Art. 35(11). Keywords: DPIA review, PIA update, review cadence, version control, Art. 35(11), periodic review, trigger events, stakeholder sign-off.4license: Apache-2.05---67# Managing PIA Review and Update Cadence89## Overview1011Art. 35(11) requires controllers to carry out a review to assess whether processing is performed in accordance with the DPIA, at least when there is a change in the risk represented by processing operations. A DPIA is not a one-time compliance exercise but a living document that must be maintained throughout the processing lifecycle. This skill establishes the governance framework for DPIA reviews, including trigger event identification, scheduled review cadence, version control, stakeholder sign-off, and DPIA register management.1213## Art. 35(11) Review Obligation1415"Where necessary, the controller shall carry out a review to assess if processing is performed in accordance with the data protection impact assessment at least when there is a change in the risk represented by processing operations."1617This means:181. Reviews are mandatory when risk changes192. The controller should proactively monitor for risk changes203. Regular periodic reviews are a best practice even without identified changes214. The DPIA must be updated to reflect the current state of processing2223## Review Trigger Categories2425### Category 1: Regulatory Triggers2627| Trigger | Assessment Action |28|---------|-------------------|29| New GDPR guidance from EDPB or national supervisory authority | Assess whether guidance changes the interpretation of lawful basis, proportionality, or risk level for the processing |30| Adequacy decision adopted, renewed, or invalidated | Reassess international transfers documented in the DPIA |31| National supervisory authority DPIA list updated (Art. 35(4)) | Check if processing now appears on the mandatory DPIA list |32| New Member State employment, health, or sector-specific law | Assess impact on lawful basis and proportionality for affected processing |33| Enforcement decision against similar processing by same or different SA | Assess whether the enforcement rationale applies to the organisation's processing |34| AI Act obligations becoming applicable | For AI-related DPIAs, assess conformity requirements |3536### Category 2: Processing Change Triggers3738| Trigger | Assessment Action |39|---------|-------------------|40| New personal data category added | Reassess data minimisation, proportionality, and risk levels |41| New category of data subjects | Reassess impact on new data subject group; check for vulnerable subjects |42| New recipient or processor | Update data flow map; reassess sub-processor chain; verify DPA |43| Change in lawful basis | Full reassessment of lawful basis justification and proportionality |44| Change in retention period | Reassess storage limitation compliance |45| New purpose identified for existing data | Art. 6(4) compatibility assessment; update DPIA purpose description |46| Processing volume significantly increased | Reassess whether processing now qualifies as "large scale" |47| Geographic scope expanded | Assess new jurisdictions for data protection requirements and international transfers |4849### Category 3: Technology Change Triggers5051| Trigger | Assessment Action |52|---------|-------------------|53| New system or platform deployment | Full technical risk reassessment; update system description and data flow maps |54| System upgrade or migration | Assess whether changes affect security measures, data flows, or processing scope |55| New algorithm or AI model deployed | Reassess algorithmic fairness, Art. 22 applicability, and AI Act classification |56| New tracking or monitoring technology | Reassess proportionality and ePrivacy compliance |57| Security vulnerability discovered | Immediate risk reassessment; assess whether existing mitigations remain effective |58| End-of-life for system component | Assess impact of reduced vendor support on security posture |5960### Category 4: Incident Triggers6162| Trigger | Assessment Action |63|---------|-------------------|64| Personal data breach involving the processing activity | Mandatory DPIA review; reassess risk levels and mitigation effectiveness |65| Near-miss security incident | Assess whether existing mitigations prevented the near-miss or were bypassed |66| Data subject complaint about the processing | Investigate whether complaint reveals processing not documented in DPIA |67| Supervisory authority enquiry about the processing | Review DPIA for completeness and accuracy before responding |68| Internal audit finding | Address audit findings and update DPIA accordingly |6970### Category 5: Organisational Change Triggers7172| Trigger | Assessment Action |73|---------|-------------------|74| Merger, acquisition, or divestiture | Reassess controller identity, data sharing arrangements, and international transfers |75| DPO change | New DPO to review and approve existing DPIAs |76| Significant staff restructuring | Verify processing owners, access controls, and organisational measures remain appropriate |77| New business unit using the processing | Assess whether new use case was documented in the DPIA |7879## Scheduled Review Cadence8081| Processing Risk Level | Recommended Review Interval | Justification |82|----------------------|---------------------------|---------------|83| Very High (prior consultation was required) | Every 6 months | Processing that required Art. 36 prior consultation needs frequent monitoring |84| High (biometric, large-scale special category, AI decision-making) | Every 6-12 months | High-risk processing warrants at least annual review |85| Medium (standard employee monitoring, marketing profiling) | Every 12 months | Annual review is the standard best practice |86| Low (routine processing with low residual risk) | Every 24 months | Extended review interval acceptable for stable, low-risk processing |8788## Review Process8990### Step 1: Trigger Detection and Triage91921. DPIA register manager monitors for trigger events continuously.932. When a trigger is detected, it is logged in the DPIA register against the affected DPIA(s).943. DPO triages the trigger to determine whether a full or targeted review is needed:95 - **Full review**: Re-examine all DPIA sections (new system, major regulatory change, data breach)96 - **Targeted review**: Update only the affected section (new recipient, retention change, minor system update)9798### Step 2: Review Execution991001. Assemble the review team: processing owner, DPO, IT security (for technology changes), legal (for regulatory changes).1012. For full reviews: re-execute the complete DPIA methodology from screening through risk assessment.1023. For targeted reviews: update the affected section and reassess overall risk level.1034. Document all changes from the previous version.1045. Update the risk register with any new or modified risks.105106### Step 3: Stakeholder Sign-Off107108| Stakeholder | Role in Review | Sign-Off Required? |109|-------------|---------------|-------------------|110| Processing Owner | Validates accuracy of processing description and confirms mitigations are implemented | Yes |111| DPO | Provides independent advice on risk assessment and proportionality per Art. 35(2) | Yes |112| IT Security / CISO | Validates technical measures and security risk assessment | Yes (for technology-related reviews) |113| Legal Counsel | Validates lawful basis and regulatory compliance | Yes (for regulatory trigger reviews) |114| Senior Management | Approves residual risk acceptance | Yes (for full reviews or risk level changes) |115| Works Council | Consulted on employee monitoring changes (jurisdiction-dependent) | Yes (for employee monitoring DPIAs) |116117### Step 4: Version Control and Registration1181191. Create a new version of the DPIA document.1202. Use version numbering: major changes increment the first digit (v2.0); minor changes increment the second digit (v1.1).1213. Include a change log documenting:122 - Date of change123 - Trigger event that prompted the review124 - Sections modified125 - Summary of changes126 - Reviewer and approver names1274. Archive the previous version (do not delete; maintain audit trail).1285. Update the DPIA register with the new version, review date, and next review date.129130## DPIA Register Management131132The DPIA register is the central index of all DPIAs conducted by the organisation. It must contain:133134| Field | Description |135|-------|-------------|136| DPIA Reference | Unique identifier (DPIA-[ORG]-[YEAR]-[SEQ]) |137| Processing Activity Name | Name of the processing operation |138| Version | Current version number |139| Status | Draft, Under Review, Approved, Expired, Superseded |140| Date Created | Date of initial DPIA |141| Last Review Date | Date of most recent review |142| Next Review Date | Scheduled date for next review |143| Processing Owner | Name and role of the processing owner |144| DPO Reviewer | Name of the DPO who reviewed |145| Risk Level (Current) | Current overall risk level after mitigation |146| Prior Consultation Required | Whether Art. 36 was triggered |147| Related Processing Activities | Cross-references to related DPIAs |148| Change Log | Summary of version history |149150## Common Review Process Deficiencies1511521. **No trigger monitoring**: Organisation relies solely on scheduled reviews without monitoring for change events.1532. **Stale DPIAs**: Reviews conducted on paper without verifying actual processing matches the DPIA description.1543. **No version control**: Edits made to the original document without maintaining previous versions.1554. **Incomplete stakeholder engagement**: DPO reviews without consulting the processing owner or IT security.1565. **No change log**: Updates made without documenting what changed and why.1576. **Expired review dates**: DPIA register shows overdue reviews without remediation.158159## Enforcement Context160161Supervisory authorities have increasingly scrutinised DPIA currency:162- **Swedish DPA vs Karolinska (2019)**: Noted that DPIA had not been conducted at all, let alone reviewed.163- **CNIL vs Clearview AI (2022)**: The absence of any DPIA was an aggravating factor in the fine determination.164- **Austrian DPA vs Austrian Post (2019)**: Inadequate ongoing review of profiling DPIA was a contributing factor.
mukul975