/cs:gdpr-audit-prep <scope> — GDPR audit 6-question Article-cited forcing interrogation. Use before annual internal GDPR review, post-breach internal audit, DPA investigation readiness, or acquisition due diligence.
cd ~/.claude/skills
git clone https://github.com/alirezarezvani/claude-skills.git claude-skills mkdir -p ~/.claude/skills/gdpr-audit-prep
curl -fsSL https://raw.githubusercontent.com/alirezarezvani/claude-skills/HEAD/.gemini/skills/gdpr-audit-prep/SKILL.md \
-o ~/.claude/skills/gdpr-audit-prep/SKILL.md Command: /cs:gdpr-audit-prep <scope>
The GDPR DPO auditor pressure-tests any privacy compliance work. Six Article-cited questions before any internal audit, breach response, DPA investigation, or acquisition due diligence.
Most-cited finding area.
Article 6 is exclusive — pick ONE basis per purpose.
Required for high-risk; sample 3-5 activities.
Articles 15-22 operational workflow.
Schrems II discipline.
Article 33(5) requires logging ALL breaches.
# 1. Compliance posture
python ra-qm-team/skills/gdpr-dsgvo-expert/scripts/gdpr_compliance_checker.py compliance_state.json
# 2. DPIA for high-risk activities
python ra-qm-team/skills/gdpr-dsgvo-expert/scripts/dpia_generator.py processing_activity.json
# 3. DSAR workflow validation
python ra-qm-team/skills/gdpr-dsgvo-expert/scripts/data_subject_rights_tracker.py dsar_log.json
# 4. Cross-framework reuse with ISO 27001 + SOC 2 + ISO 42001
python ../../skills/compliance-os/scripts/cross_framework_mapper.py program.json
# GDPR Audit Prep: <scope>
**Date:** YYYY-MM-DD
**Article Citations:** Every finding cites Article + paragraph; no paraphrase.
## The Decision Being Made
[RoPA-refresh | DPIA-required | DSAR-workflow | transfer-risk | breach-followup | DPA-readiness]
## Article 30 RoPA Status
- Last refresh: YYYY-MM-DD
- Required elements present: yes/no per processing activity
- Joint controller arrangements: documented/missing
## Article 6 Lawful Basis Discipline
- Activities reviewed: N
- Legitimate-interests claims without LIA: <list>
- Article 9 special categories with documented exception: yes/no
## Article 35 DPIA Quality
- High-risk activities requiring DPIA: <list>
- DPIAs complete per Article 35(7): pass/fail per activity
- Article 36 prior consultation triggered: <list>
## Data Subject Rights (Articles 12-22)
- DSARs in last 90 days: N
- Average response time: X days (target: ≤ 30)
- Right to erasure backup-processor flow: complete/incomplete
## Article 28 Processor Management
- Processors reviewed: N
- Contracts with all Article 28(3)(a)-(j) clauses: % complete
- Sub-processor flow-down notification mechanism: yes/no
## Schrems II Transfer Status
- Non-EU transfers: <list>
- Mechanism per transfer: adequacy / SCCs / derogation
- TIA on file: yes/no per transfer
- Supplementary measures where needed: <list>
## Article 33-34 Breach Discipline
- Breach log last 12 months: N
- Article 33 notification timing: ≤ 72h ratio
- Article 34 data subject notification (where high risk): on-time ratio
## Cross-Framework Impact
- ISO 27001 Article 32 alignment: clean / gaps
- EU AI Act Article 27 FRIA integration: applicable / not
- SOC 2 Privacy TSC alignment (if scope): clean / gaps
## Verdict
🟢 DPA-READY | 🟡 GAPS-IDENTIFIED | 🔴 NOT-READY
## Top 3 Actions
[3 concrete next steps with owner + Article-cited timeline]
## Outside Counsel Required
[Article-level ambiguities flagged: Schrems II supplementary measure adequacy, EU AI Act ↔ GDPR interaction, sectoral derogation interpretation, novel DPA enforcement]
/cs:compliance-readiness — for multi-framework view/cs:iso27001-audit-prep — for Article 32 organizational measures/cs:ai-act-readiness — for EU AI Act Article 27 FRIA integration/cs:soc2-audit-prep — for SOC 2 Privacy TSC overlap/cs:gc-review — for novel-case legal reviewcs-dpo-gdprgdpr-dsgvo-expert../iso27001-audit-prep/, ../ai-act-readiness/, ../soc2-audit-prep/, ../compliance-readiness/Version: 1.0.0
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback
Use when starting any conversation - establishes how to find and use skills, requiring skill invocation before ANY response including clarifying questions