UitbreidenOS GDPR Expert Skill
When to activate
- Scanning a codebase or system for GDPR compliance risks
- Generating a Data Protection Impact Assessment (DPIA) under Article 35
- Managing data subject rights requests (access, erasure, portability, objection)
- Assessing the lawful basis for a data processing activity
- Reviewing a Data Processing Agreement (DPA) with a vendor
- Preparing for a GDPR audit or regulatory inquiry
When NOT to use
- Cookie consent banners — implementation is a dev task, use the cookie library docs
- CCPA-only (US) compliance — this skill focuses on GDPR; many principles overlap but rules differ
- HIPAA compliance — different framework, use a specialist
- Replacing qualified Data Protection Officer (DPO) advice on novel or high-risk situations
Instructions
Privacy risk scan
Scan this system for GDPR compliance risks.
System description: [describe what the system does, what data it processes]
Tech stack: [languages, frameworks, databases]
Data categories processed: [list — email, name, IP, location, health, financial, biometric]
Users: [EU residents? B2B? B2C?]
GDPR risk checklist by category:
PERSONAL DATA IDENTIFICATION:
□ What personal data is collected? (name, email, IP, device ID, location, behavioural data)
□ What special category data is processed? (health, biometric, political, religious, sexual orientation)
□ Is all collected data actually necessary? (data minimisation — Article 5(1)(c))
LAWFUL BASIS (Article 6):
For each processing activity, identify the lawful basis:
- Consent (Art. 6(1)(a)): freely given, specific, informed, unambiguous — not bundled with ToS
- Contract (Art. 6(1)(b)): processing necessary to perform a contract with the data subject
- Legal obligation (Art. 6(1)(c)): required by EU/member state law
- Legitimate interests (Art. 6(1)(f)): must pass a 3-part LIA test — not a catch-all
🔴 Red flag: using "legitimate interests" without a documented Legitimate Interests Assessment
CONSENT MANAGEMENT:
□ Is consent obtained before data collection (not after)?
□ Is consent granular (separate for each purpose)?
□ Can users withdraw consent as easily as they gave it?
□ Is a consent record maintained with timestamp and version?
DATA RETENTION:
□ Is there a documented retention policy per data category?
□ Is data automatically deleted or anonymised after the retention period?
🔴 Red flag: "we keep data indefinitely" or "until the user deletes their account"
SECURITY (Article 32):
□ Personal data encrypted at rest and in transit?
□ Access controls: only authorised staff can access personal data?
□ Is personal data logged unnecessarily (debugging logs containing PII)?
□ Pseudonymisation in place where possible?
DATA PROCESSORS (Article 28):
□ Is there a signed DPA with every vendor that processes personal data?
□ Sub-processors listed and approved?
□ Vendor in a third country? Standard Contractual Clauses (SCCs) in place?
BREACH NOTIFICATION (Article 33-34):
□ Can you detect a data breach within 72 hours?
□ Is there a documented breach notification process?
□ Who is responsible for notifying the supervisory authority?
Output: risk register with Article reference, severity (🔴/🟡/🟢), and recommended fix.
DPIA generation (Article 35)
Generate a Data Protection Impact Assessment for [processing activity].
Processing activity: [describe — e.g. "AI-driven employee monitoring system", "behavioural ad targeting"]
Controller: [organisation name]
DPO (if appointed): [name or "none appointed"]
Purpose: [why you process the data]
Data categories: [list]
Recipients: [who the data is shared with]
Third-country transfers: [yes/no — where]
DPIA is required (Art. 35(3)) when processing is likely to result in HIGH RISK:
□ Systematic and extensive profiling with significant effects on persons
□ Large-scale processing of special category data (Art. 9) or criminal data (Art. 10)
□ Systematic monitoring of publicly accessible areas
WP29 / EDPB adds 9 criteria — DPIA required if 2+ apply:
□ Evaluation or scoring (profiling, credit scoring)
□ Automated decision-making with legal or similarly significant effects
□ Systematic monitoring
□ Sensitive data or highly personal data
□ Data processed at large scale
□ Matched or combined datasets
□ Data about vulnerable subjects (children, employees, patients)
□ Innovative use or new technological or organisational solutions
□ Processing prevents data subjects from exercising a right or using a service
DPIA structure:
1. DESCRIPTION OF PROCESSING:
- Purposes and lawful basis
- Data categories and data subjects
- Data flows (collection → processing → storage → deletion)
- Processors and sub-processors involved
- Retention periods
2. NECESSITY AND PROPORTIONALITY:
- Is processing necessary for the stated purpose?
- Could the same purpose be achieved with less data?
- Is the chosen lawful basis appropriate?
3. RISK ASSESSMENT:
| Risk | Likelihood | Severity | Residual risk after controls |
|---|---|---|---|
| Unauthorised access to personal data | Medium | High | Low (encryption + access controls) |
| Data breach affecting large number of individuals | Low | Very high | Low (breach detection + 72h notification plan) |
| Profiling leading to discrimination | Medium | High | Medium — needs monitoring |
4. MEASURES TO ADDRESS RISKS:
- Technical measures: [encryption, pseudonymisation, access controls]
- Organisational measures: [training, policies, DPA contracts]
- Privacy by design: [data minimisation, purpose limitation built into architecture]
5. DPO CONSULTATION:
[DPO review and sign-off, or rationale for why DPO not consulted]
6. SUPERVISORY AUTHORITY CONSULTATION:
Required under Art. 36 if residual risk remains HIGH after all measures.
[Decision: consult / not required — rationale]
Generate the DPIA for my processing activity.
[LEGAL REVIEW REQUIRED: DPO or qualified privacy counsel must review before finalising]
Data subject rights handler
Handle a data subject rights request under GDPR Articles 15-22.
Request type:
- Article 15: Right of access (SAR — Subject Access Request)
- Article 16: Right to rectification
- Article 17: Right to erasure ("right to be forgotten")
- Article 18: Right to restriction of processing
- Article 19: Right to data portability
- Article 21: Right to object
- Article 22: Right not to be subject to automated decisions
Requestor: [name, email, or reference]
Date received: [date — response due within 30 days, extendable to 90 for complex]
Identity verified: [yes / no — do not process until identity confirmed]
Response workflow:
STEP 1 — Log and acknowledge (within 72 hours):
"We have received your request under [Article X] of the GDPR. We will respond within 30 days. Your reference number is DSR-[YYYY-MM-DD-NNN]."
STEP 2 — Verify identity:
Do not release personal data or confirm deletion without identity verification.
Acceptable: government ID, account verification, challenge questions.
If in doubt: request additional verification (Art. 12(6) permits this).
STEP 3 — Process the request:
For Article 15 (access): compile all personal data held, including:
- Data categories held
- Purposes of processing
- Recipients and third-country transfers
- Retention period
- Source of data (if not from the subject directly)
- Existence of automated decision-making
For Article 17 (erasure): erase from:
- Primary database
- Backups (within reasonable timeframe — note backup deletion schedule)
- Third-party processors (notify them in writing)
- Anonymise if erasure technically impossible
Exceptions — erasure NOT required if processing is necessary for:
- Legal obligation or legal claims
- Freedom of expression and information
- Public interest archiving
For Article 20 (portability): export data in machine-readable format (JSON, CSV).
Applies only to: data provided by the subject + processed on consent or contract basis.
STEP 4 — Document the response:
Log: request date, type, identity verification, actions taken, response date, exemptions claimed.
STEP 5 — Respond within 30 days:
If unable to act: notify requestor with reason (can extend to 90 days with notification).
If manifestly unfounded or excessive: can charge reasonable fee or refuse (document reasoning).
Draft the response for my specific request type.
Lawful basis assessment
Assess the lawful basis for [processing activity].
Processing activity: [describe precisely — what data, what purpose, what outcome]
Data subjects: [consumers / employees / B2B contacts / minors]
Relationship to data subjects: [customer / employee / prospect / public]
Lawful basis options under Article 6:
CONSENT (Art. 6(1)(a)):
Conditions: freely given, specific, informed, unambiguous, separate from other terms
Best for: newsletter subscriptions, non-essential cookies, marketing communications
Weakness: can be withdrawn at any time → processing must stop
🔴 Not valid if: bundled with contract, pre-ticked boxes, conditional on service access
CONTRACT (Art. 6(1)(b)):
Conditions: processing strictly necessary to perform a contract WITH the data subject
Best for: processing customer's order, delivering a paid service
🔴 Not valid for: marketing to existing customers, analytics, fraud prevention
LEGAL OBLIGATION (Art. 6(1)(c)):
Conditions: an EU or member state law requires the processing
Best for: tax records, employment law requirements, AML/KYC
🔴 Must cite the specific law — "we're legally required to" is insufficient
VITAL INTERESTS (Art. 6(1)(d)):
Conditions: protect life of the data subject or another person
Last resort only — almost never applicable to commercial processing
PUBLIC TASK (Art. 6(1)(e)):
For public authorities and those performing public functions. Rarely applicable to private companies.
LEGITIMATE INTERESTS (Art. 6(1)(f)):
Conditions: three-part LIA test must pass:
1. Purpose test: is the interest legitimate?
2. Necessity test: is processing necessary for that interest?
3. Balancing test: do the interests override the data subject's rights?
Best for: fraud prevention, network security, B2B marketing, intra-group transfers
🔴 CANNOT be used: by public authorities; when fundamental rights override; for employee monitoring
For my activity, assess which basis applies and identify any weaknesses.
[LEGAL REVIEW REQUIRED before relying on the assessment]
Example
User: We're building a SaaS product that uses AI to analyse user behaviour patterns and score customer health for our B2B customers. Their end-users' data flows through our system. What's our GDPR exposure?
Claude's analysis:
You are a data processor (Article 4(8)) — your B2B customers are the controllers. This has immediate implications:
Your obligations as processor (Article 28):
- Signed DPA with every B2B customer before processing their users' data
- Only process data on documented instructions from each controller
- Implement appropriate technical and organisational security measures
- Support controllers in fulfilling their own GDPR obligations (DSARs, DPIAs, breach notification)
- Delete or return all data at contract termination
DPIA trigger check: Your AI behavioural scoring system likely triggers a DPIA requirement because it combines:
- Systematic evaluation/profiling of individuals (WP29 criterion 1)
- Innovative technology (new AI-based scoring) (WP29 criterion 9)
- Potentially large scale (if the B2B customers have many end-users)
The controllers (your B2B customers) are responsible for the DPIA — but they will need your technical documentation about how the AI works to complete it. Prepare a "processor's contribution to DPIA" document proactively.
Highest-risk areas for you:
- 🔴 Sub-processor chain — every tool you use to run the AI (AWS, ML platform, monitoring) is a sub-processor. List them all. Your DPA must name them or describe the approval process.
- 🔴 Third-country transfers — if your servers or ML infrastructure are in the US, you need SCCs or rely on the EU-US Data Privacy Framework.
- 🟡 Transparency — end-users likely don't know their behaviour is being scored. Your customers (controllers) must tell them.