GDPR Compliance Skill

GDPR compliance is mostly bookkeeping you can defend: knowing every place you process personal data, why you're allowed to, how long you keep it, and how a person can get it out or deleted. This skill builds that record (the ROPA), pins a lawful basis to each activity, and flags the high-risk processing that legally requires a DPIA — turning "are we GDPR-compliant?" into a documented, auditable answer.

Required Inputs

Ask for these only if they aren't already provided:

• Processing activities — what personal data you collect, why, and where it flows (this is the spine; everything hangs off it).
• Role — controller (you decide the why/how) or processor (you act on a controller's instructions); your obligations differ.
• Data subjects & data types — whose data, and whether any is special-category (health, biometrics, etc.) or about children.
• Transfers — any processing or storage outside the EEA (triggers transfer-mechanism requirements).

Output Format

GDPR Assessment: [company] ([controller/processor])

1. ROPA — the Record of Processing Activities (Art. 30); one row per activity:

2. Lawful basis — the chosen Art. 6 basis per activity (consent / contract / legal obligation / vital interests / public task / legitimate interests) and why. For special-category data, the additional Art. 9 condition. Don't default everything to "consent" — it's often the weakest, hardest-to-maintain basis.

3. DSAR workflow — how you handle access/erasure/portability/objection requests: intake, identity check, the one-month deadline, and how data is located and exported/deleted.

4. DPIA screen — flag activities that legally require a Data Protection Impact Assessment (large-scale special-category processing, systematic monitoring, profiling with legal effects).

5. Gaps — prioritised: missing lawful basis, no retention period, undocumented transfers, no DSAR process.

Programmatic Helper

scripts/ropa_check.py (stdlib only) validates a ROPA and scores completeness so gaps are found mechanically:

# ropa.json: [{"activity":"...","purpose":"...","lawful_basis":"contract","retention":"3y","recipients":["..."],"special_category":false,"large_scale":true}, ...]
python3 scripts/ropa_check.py ropa.json
python3 scripts/ropa_check.py ropa.json --json

It flags activities missing a lawful basis, purpose, or retention, and marks those that trigger a DPIA.

Quality Checks

• [ ] Every processing activity has a documented lawful basis and a retention period
• [ ] "Consent" isn't used as a lazy default where contract or legitimate interests genuinely apply
• [ ] Special-category data has its additional Art. 9 condition identified
• [ ] DPIA-triggering activities are flagged, not buried
• [ ] Cross-border transfers name a valid mechanism (adequacy, SCCs, etc.)
• [ ] The DSAR workflow names the one-month statutory deadline

Anti-Patterns

• [ ] Do not default every activity to "consent" — it's revocable and high-maintenance; use the basis that actually fits
• [ ] Do not skip the ROPA — without the record of what you process, every other GDPR obligation is unanchored
• [ ] Do not store data with no retention period — "forever" is not a lawful retention policy
• [ ] Do not treat a DPIA as optional for high-risk processing — it's a legal requirement, not best practice
• [ ] Do not give legal advice as settled law — flag where a DPO or counsel must confirm (esp. lawful basis and transfers)

Based On

EU GDPR — Art. 6 (lawful basis), Art. 9 (special category), Art. 30 (ROPA), Art. 35 (DPIA), data-subject rights.

Example Trigger Phrases

• "Get GDPR-compliant."
• "Build a Record of Processing Activities."
• "Decide a lawful basis."
• "Handle data-subject requests."
• "Check whether a DPIA is needed."