From privacy-impact-assessment-skills
Guides periodic DPIA reviews triggered by regulatory changes, new data categories, technology changes, or breach incidents. Manages version control, stakeholder sign-offs, and DPIA register per GDPR Art. 35(11).
npx claudepluginhub mukul975/privacy-data-protection-skills --plugin privacy-impact-assessment-skillsThis skill uses the workspace's default tool permissions.
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 revi...
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Generates original PNG/PDF visual art via design philosophy manifestos for posters, graphics, and static designs on user request.
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.
"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:
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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) |
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 |
Supervisory authorities have increasingly scrutinised DPIA currency: