GDPR compliance audit of code, plans, schemas, or IaC. Produces a findings report with article citations, severity, confidence, and fixes; flags evidence gaps. Not a substitute for a DPO/lawyer.
Instrucciones de origen · Vista previa de solo lectura
name
gdpr-audit
description
GDPR compliance audit of code, plans, schemas, or IaC. Produces a findings report with article citations, severity, confidence, and fixes; flags evidence gaps. Not a substitute for a DPO/lawyer.
GDPR Audit
A detection-guide-driven audit skill. Reads code / plan / schema / IaC artifacts and returns a structured findings report with GDPR article citations, severity, confidence, evidence, and recommended fixes.
Output is "technical GDPR audit of provided materials" — never "GDPR compliant" or "non-compliant". Compliance is a legal determination; this skill provides technical evidence and gap analysis. Always include the disclaimer at the end of the report.
When to use
Auditing an existing codebase, repo, or directory tree
Reviewing an implementation plan, design doc, or RFC for GDPR implications
Reviewing a database schema or data model for personal data handling
Reviewing IaC (Terraform / Pulumi / CDK / k8s manifests) for transfers, encryption, region constraints
Pre-DPIA technical scoping
Vendor onboarding (auditing the integration code of a new processor / SDK)
When NOT to use
Drafting privacy notices, DPAs, or DPIAs from scratch — that's a writing task, not an audit
Compliance certification, regulatory filings, or DPA correspondence — needs a qualified DPO / lawyer
Org-maturity assessment (training, governance, DPO independence) — not visible from code / plan input
Auditing non-GDPR jurisdictions (CCPA, LGPD, PIPL) — citations and triggers will be wrong
Audit workflow
Run these phases in order. Do not skip phases.
Phase 1 — Scope statement
State explicitly what was reviewed and what wasn't, before any findings.
## Scope
- Materials reviewed: <repo, commit/SHA, branch, paths or "full tree">
- Date of audit: <YYYY-MM-DD>
- Excluded: <e.g., binary assets, vendored deps, test fixtures, .git history>
- Assumptions: <e.g., "controller role assumed unless evidence indicates processor role">
- Missing context: <list of org/policy artifacts not provided to the audit>
This protects the audit from being misread as exhaustive.
Phase 2 — Processing map (build first, find against second)
Before scanning for issues, build a processing map. Every later finding ties back to a row here.
Sources for the map: API routes, DB schemas, env vars, IaC region constraints, third-party SDK invocations (Stripe, Auth0, Segment, GA, Sentry, Datadog, Supabase, AWS clients), background jobs, cron, queue consumers, ML / AI training pipelines.
If no processing map can be built (truly opaque artifact), say so and stop. A findings report without a processing map is unfounded. See references/01-data-discovery.md for detection signals.
Phase 3 — Detection sweep using the reference guides
For each row in the processing map, walk the relevant guides in references/. Each guide is a detection guide with: what to look for, signals, severity rules, false-positive controls, stack-specific examples, evidence needed.
Guides to walk for every audit: 01, 02, 06, 07, 09, 10, 14, 15.
Conditional guides (see Trigger overlays below): 03, 04, 05, 08, 11, 12, 13.
Phase 4 — Findings emission
Emit findings using the schema below. One finding per discrete gap.
Phase 5 — Report assembly
Order: Scope → Processing map → Findings table (sorted Critical → Low within each finding type) → Finding details → Summary of finding-type distribution → Recommended next actions → Disclaimer.
Phase 6 — Drill-down offer
After the report, offer:
"I can draft concrete patches for any of these findings on request. Tell me the finding number(s) and I'll generate the actual code / SQL / IaC / markdown changes."
Do not produce patches in the initial report — they bury the audit signal.
Finding schema
Every finding has these fields. Missing fields = finding is incomplete.
id:F-NN# sequential within reporttitle:<shortnounphrase>severity:Critical|High|Medium|Lowfinding_type:confirmed_issue|likely_issue|evidence_gap|advisoryconfidence:High|Medium|Lowrisk_to_rights:<whatcouldhappentoadatasubject—not"fines">location:<file:line|sectionheading|"(absence)">articles: [Art.5(1)(c), Art.25(2), Recital39]
guidance: [EDPBGuidelines4/2019onArticle25, ICORightofAccessguidance] # optionalaffected_data: [email, IP, payment, health, children, employees, ...]
affected_subjects: [endusers, employees, vendorstaff, ...]
processing_activity:<signup|billing|analytics|recommendation|support_export|...>evidence:|
<verbatim snippet from code / plan, with file:line>
recommended_fix:|
<1–3 sentences. Not a patch.>
verification_needed:|
<what specific evidence would close this finding>
Severity rubric
Severity
Meaning
Critical
Direct violation with high risk to rights AND high confidence. Examples: clear-text PII in public logs; consumer EU data sent to third country with no transfer mechanism; high-risk profiling without DPIA.
High
Direct violation OR high-risk gap with material confidence. A supervisory authority would likely act if discovered.
Medium
Material gap with rectifiable design choice. Would be remediation in a real audit.
Low
Best-practice deviation. No immediate risk.
Severity is not likelihood × impact — that pseudo-precision misleads. Severity captures the audit-judgment call; confidence is the separate axis.
finding_type
Type
Meaning
Example
confirmed_issue
Positive evidence shows a violation
analytics.track(user.email) fires before consent is recorded
Stripe SDK detected; DPA evidence not found in provided materials
advisory
Technically defensible, design-level improvement
Pseudonymization could replace direct identifiers in analytics_events
Discipline rule for evidence_gap: only flag absence when there is positive evidence of processing AND a reasonably expected control. "No docs/ropa.md" is not a finding. "Stripe SDK + cross-border data flow + no DPA artifact in provided materials"is an evidence_gap. The skill does not invent organizational policy gaps from thin air.
confidence
Level
Meaning
High
Direct code evidence, no plausible alternative interpretation
Medium
Strong inference from signals; alternative interpretations exist but are less likely
Low
Pattern-based suspicion; needs human verification
Trigger overlays
Apply these when their triggers fire. They escalate severity, force chapter walks, and add national context.
Children's data overlay
Trigger: schema/forms accept date of birth, age, school, parent contact; product is consumer/social/educational; signup form lacks age gate.
Effect: every finding involving children's data goes up one severity tier. Cite Art. 8 + Recital 38. Member State age threshold (13–16) flagged for verification. Data minimization scrutinized harder.
Special category overlay (Art. 9, 10)
Trigger: schema fields suggest health, biometric, genetic, racial/ethnic, political, religious, trade-union, sex life, sexual orientation, criminal convictions; medical/HR/insurance domain.
Effect: severity floor of High for any unprotected processing. Art. 9(2) basis must be explicitly cited. Security expectations rise (Art. 32 + Art. 9 combined). DPIA almost certainly required (force ch14).
Profiling / automated decision overlay (Art. 22)
Trigger: code performs scoring, ranking, fraud detection, recommendation, embeddings on personal data, automated KYC, automated employment decisions.
Effect: force walk of ch13 and ch14. Flag Art. 22 even if the system is not "solely automated" but is being used that way in practice (humans rubber-stamping the model output count as solely automated under EDPB guidance).
Cross-border / vendor overlay
Trigger: SDK or HTTP client points to non-EU endpoint; AWS region outside eu-*; GCP region outside europe-*; external SaaS without obvious EU data residency.
Effect: force walk of ch11 and ch12.
National context overlay
Trigger: user mentions a specific Member State, repo contains DE/FR/IT/ES/NL locale, employment context, or healthcare/insurance/finance domain.
Add notes per jurisdiction:
Germany (BDSG): DPO mandatory ≥ 20 employees doing automated PII processing (§ 38); § 26 employment data; § 4 video surveillance; § 31 credit scoring; works council co-determination on monitoring tools.
UK (UK GDPR + DPA 2018): ICO guidance; international transfers use UK IDTA or Addendum to EU SCCs.
Italy (Garante): opinions issued on AI/training data sources; cookie enforcement.
Other Member States: flag for verification — derogations vary.
DPIA routing rule (mandatory regardless of which chapter triggers)
Before the report ships, check whether the processing activities crossed any DPIA threshold. If two or more of the EDPB 9 criteria apply, emit a finding for ch14 even if the rest of the audit found nothing wrong:
Evaluation or scoring (including profiling and predicting)
Automated decision-making with legal/significant effect
Sensitive data or data of a highly personal nature
Data processed on a large scale
Matching or combining datasets
Data concerning vulnerable subjects (children, employees, patients)
Innovative use or new technological/organizational solutions (AI, IoT, biometric)
Processing that prevents data subjects from exercising a right or using a service/contract
EDPB adopted (April 2026) a DPIA template for consultation — cite that, not legacy WP29 templates.
Output format
# GDPR Audit Report
## Scope
<Phase 1 block>
## Processing map
<Phase 2 table>
## Findings — confirmed issues (Critical → Low)
| ID | Sev | Conf | Article(s) | Activity | Title |
## Findings — likely issues
| ID | Sev | Conf | Article(s) | Activity | Title |
## Findings — evidence gaps
| ID | Sev | Conf | Article(s) | Activity | Title |
## Findings — advisory
| ID | Sev | Conf | Article(s) | Activity | Title |
## Finding details
F-01
Severity: Critical / Confidence: High / Type: confirmed_issue
Articles: Art. 5(1)(f), Art. 32(1)
Risk to rights: <...>
Location: src/auth/login.py:42
Affected data: email, IP address
Affected subjects: end users
Processing activity: signup
Evidence:
logger.info(f"login attempt: {email} from {request.client_host}")
Recommended fix:
Hash the user identifier in log output; mask IP to /24 for security analytics if needed; configure structured-logging redaction.
Verification needed:
Show the redaction config and a sample log line after change.
F-02 ...
## Summary
- Confirmed issues: <N>
- Likely issues: <N>
- Evidence gaps: <N>
- Advisory: <N>
- DPIA recommended: yes/no — <reason>
## Recommended next actions
1. <ranked list, highest-leverage first>
## Disclaimer
This is a technical GDPR audit of the provided materials. It is not legal advice and does not constitute a compliance determination. Consult a qualified DPO or data protection lawyer for legal questions, supervisory authority engagement, or material decisions.
Reference guide index
The detection guides live in references/, numbered 01–15 (referred to as ch01–ch15 in the overlays above).
