From records-of-processing-skills
Establishes RoPA maintenance workflows with update triggers, change management integration, version control, stakeholder review cycles, and verification procedures for GDPR compliance.
npx claudepluginhub mukul975/privacy-data-protection-skills --plugin records-of-processing-skillsThis skill uses the workspace's default tool permissions.
Creating a RoPA is a point-in-time exercise; maintaining it is a continuous obligation. GDPR Art. 5(2) accountability requires that processing records reflect current reality at all times. The Belgian DPA in Decision 21/2022 sanctioned an organisation whose RoPA had not been updated for over two years despite significant processing changes. This skill establishes the governance framework, trigg...
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Creating a RoPA is a point-in-time exercise; maintaining it is a continuous obligation. GDPR Art. 5(2) accountability requires that processing records reflect current reality at all times. The Belgian DPA in Decision 21/2022 sanctioned an organisation whose RoPA had not been updated for over two years despite significant processing changes. This skill establishes the governance framework, triggers, workflows, and verification procedures to keep the RoPA accurate, current, and audit-ready.
A RoPA update must be initiated when any of the following events occur:
| Trigger Event | Affected Fields | Update Deadline |
|---|---|---|
| New processing activity introduced | All Art. 30(1) fields for new entry | Before processing commences |
| Processing activity discontinued | Entire entry archived | Within 30 days of cessation |
| Change in processing purpose | Art. 30(1)(b) — purposes | Before new purpose is acted upon |
| New category of data subjects added | Art. 30(1)(c) — data subjects | Before data collection from new category |
| New special category data processed | Art. 30(1)(c) — personal data; Art. 9(2) condition | Before processing begins |
| New processor engaged | Art. 30(1)(d) — recipients | Before processor begins processing |
| Processor terminated | Art. 30(1)(d) — recipients | Within 30 days of termination |
| New international transfer | Art. 30(1)(e) — transfers | Before transfer commences |
| Transfer mechanism invalidated | Art. 30(1)(e) — transfers | Immediately (processing must cease or alternative mechanism implemented) |
| Retention period changed (legal or policy) | Art. 30(1)(f) — retention | Within 30 days of change |
| Material change to security measures | Art. 30(1)(g) — security | Within 30 days of change |
| DPO appointment or change | Art. 30(1)(a) — controller identity | Within 14 days of change |
| Organisational restructuring affecting controller identity | Art. 30(1)(a) — controller identity | Within 30 days of effective date |
| Data breach involving the processing activity | Art. 30(1)(g) — security measures; potentially all fields | Within 30 days of remediation completion |
| Review Type | Frequency | Scope |
|---|---|---|
| Full RoPA review | Annually (minimum) | All entries, all fields |
| High-risk processing review | Every 6 months | Entries linked to DPIA, special category data, or large-scale processing |
| Processor/vendor review | Annually, aligned with DPA renewal | Recipient and transfer fields |
| Retention schedule alignment | Annually | Retention fields cross-referenced against retention policy |
| Post-audit remediation review | 30/60/90 days after audit findings | Entries with identified findings |
The RoPA update workflow must be embedded in the organisation's IT change management process (e.g., ITIL change advisory board, DevOps deployment pipeline):
Example workflow for Helix Biotech Solutions:
IT Change Request Submitted
|
v
Privacy Impact Field = "Yes" or "Unsure"?
| \
v (Yes/Unsure) (No) -> Standard IT change process
DPO Office Review (2 business days)
|
v
RoPA Update Required?
| \
v (Yes) (No) -> Document decision, proceed with change
Draft RoPA Amendment
|
v
DPO Approval
|
v
Processing Owner Sign-off
|
v
RoPA System Updated
|
v
Change Approved for Deployment
|
v
Post-Deployment Verification (7 days)
Adopt a structured version numbering system:
Example version history:
| Version | Date | Change Description | Changed By | Approved By |
|---|---|---|---|---|
| 3.0 | 2025-01-15 | Added RPA-048: Genomic data analysis for personalised medicine programme | Dr. Elena Voss | Prof. Schmidt (CEO) |
| 3.1 | 2025-04-22 | Updated RPA-007: Added Veeva Vault CRM as recipient with DPA reference | Anna Berger, Privacy Analyst | Dr. Elena Voss |
| 3.1.1 | 2025-05-10 | Corrected DPO phone number across all entries | System (bulk update) | Dr. Elena Voss |
| 3.2 | 2025-08-01 | Updated RPA-023: Retention period changed from 36 to 24 months per new marketing data retention policy | Julia Richter, Marketing | Dr. Elena Voss |
| 3.3 | 2025-11-20 | Updated RPA-001: Removed former payroll processor, added ADP as replacement | Markus Bauer, HR | Dr. Elena Voss |
| 4.0 | 2026-02-01 | Archived RPA-012: Legacy CRM decommissioned. Added RPA-049: New Salesforce implementation | Dr. Elena Voss | Prof. Schmidt |
Each change must record:
Maintain previous RoPA versions for a minimum of 5 years (or longer if required by sector regulation) to demonstrate accountability and support supervisory authority investigations that may inquire about historical processing activities.
Timeline: 8 weeks
| Week | Activity | Responsible | Deliverable |
|---|---|---|---|
| 1-2 | DPO office distributes current RoPA entries to processing owners for self-review | DPO office | Distribution log |
| 3-4 | Processing owners review and annotate their entries, flagging changes | Processing owners | Annotated entries |
| 5 | DPO office consolidates changes and resolves conflicts | Privacy analyst | Consolidated change list |
| 6 | DPO reviews consolidated changes for legal accuracy | DPO | Reviewed change list |
| 7 | Updated entries submitted for processing owner final sign-off | Processing owners | Signed entries |
| 8 | Updated RoPA published, version incremented, change log updated | DPO office | Updated RoPA v.X.0 |
For entries linked to DPIAs or involving special category data:
Run the RoPA validation script monthly to check:
Calculate a completeness score for supervisory authority readiness:
| Metric | Weight | Scoring |
|---|---|---|
| All mandatory fields populated | 30% | 100% if all entries complete, deduct proportionally |
| No vague terms in purposes or retention | 15% | 100% if none detected, deduct per occurrence |
| All transfers have safeguards documented | 15% | 100% if all documented |
| All entries reviewed within 12 months | 20% | 100% if all current, deduct per stale entry |
| All processors have current DPAs | 10% | 100% if all current |
| All high-risk entries linked to DPIAs | 10% | 100% if all linked |
Target: 95% or above for supervisory authority readiness.