gdpr-audit

What this skill does

# 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.

```
| Activity | Data categories | Subjects | Purpose | Lawful basis (claimed / inferred / unclear) | Recipients / processors | Country / region | Retention (claimed / inferred / unclear) |
```

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.

```yaml
id: F-NN                       # sequential within report
title: <short noun phrase>
severity: Critical | High | Medium | Low
finding_type: confirmed_issue | likely_issue | evidence_gap | advisory
confidence: High | Medium | Low
risk_to_rights: <what could happen to a data subject — not "fines">
location: <file:line | section heading | "(absence)">
articles: [Art. 5(1)(c), Art. 25(2), Recital 39]
guidance: [EDPB Guidelines 4/2019 on Article 25, ICO Right of Access guidance]   # optional
affected_data: [email, IP, payment, health, children, employees, ...]
affected_subjects: [end users, employees, vendor staff, ...]
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 |
| `likely_issue` | Strong signal but missing context to be certain | High-risk profiling code present; lawful basis claim unclear |
| `evidence_gap` | A control SHOULD be visible but isn't | 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 "solel