Compliance Audit

---
name: compliance-audit
description: Static compliance audit with regulatory profiles. v1.14 ships GDPR profile (data subject rights, lawful basis, security measures, accountability). SOC 2 and HIPAA profiles scaffolded as future-markers in PROFILES.md - enable in v1.15+. Stack-agnostic.
user-invocable: true
model: sonnet
context: fork
argument-hint: [target:path:<dir>|profile:gdpr|mode:all]
allowed-tools: Read Glob Grep
---

## Scope for v1

- **Static analysis only.** Grep, filesystem reads, configuration parsing. Does not run tests, does not connect to databases, does not validate live policy enforcement.
- **Regulatory scope, not legal advice.** This skill flags mechanical gaps between common regulatory expectations and the codebase. It does not produce legal-grade compliance attestation - that requires human counsel review.
- **Active profile: GDPR only.** SOC 2 and HIPAA are scaffolded in `PROFILES.md` with check-ID placeholders and will be enabled once real enterprise feedback validates the patterns. Enabling before validation risks false confidence.

---

## Configuration (adapt before first run)

> Replace these placeholders:
> - `[APP_SOURCE_PATH]` - application source root (e.g. `src/`, `app/`, `lib/`)
> - `[API_ROUTES_PATH]` - API route handlers (e.g. `src/routes/`, `app/api/`)
> - `[SCHEMA_PATH]` - DB schema or ORM model files (e.g. `prisma/schema.prisma`, `src/models/`, `app/models.py`)
> - `[PRIVACY_DOC_PATH]` - privacy policy and data-handling docs (e.g. `docs/privacy/`, `PRIVACY.md`). Leave empty if none.

---

## Step 0 - Target and profile resolution

Parse `$ARGUMENTS` for `target:` or `profile:` tokens.

| Pattern | Meaning |
|---|---|
| `target:path:<dir>` | Audit only files under a specific directory |
| `profile:gdpr` | Run only the GDPR profile (default in v1) |
| `mode:all` / no argument | **Full GDPR audit. SOC 2 and HIPAA findings reported as `FUTURE - profile scaffolded for v1.15+`.** |

Announce: `Running compliance-audit - scope: [FULL | target: <resolved>] - profile: gdpr`.

Add caveat on first line of output: `This audit produces mechanical findings. Legal compliance attestation requires human counsel review.`

---

## Step 1 - Profile loading

Read `${CLAUDE_SKILL_DIR}/PROFILES.md`. Three profiles defined: GDPR (active), SOC 2 (future), HIPAA (future).

For v1, only GDPR checks execute. SOC 2 and HIPAA sections in the report are emitted with a single row: `Profile scaffolded for v1.15+. No checks run.` This keeps the report shape stable for future releases.

---

## Step 2 - GDPR checks (G1-G10)

The GDPR profile covers four pillars:

- **Data subject rights** (G1-G3): right to delete, right to export, right to rectification
- **Lawful basis + consent** (G4-G5): consent capture, lawful-basis declaration
- **Security measures** (G6-G8): PII identification, encryption-at-rest indicators, PII logging hygiene
- **Accountability** (G9-G10): retention policy declaration, sub-processor (DPA) transparency

Each check records findings as SEVERITY / CHECK / FILE:LINE / EVIDENCE / IMPACT / FIX.

### G1 - Right to delete (Article 17)

**Critical if no delete endpoint for user data exists; High if the endpoint exists but evidence of cascade delete is missing.**

Search `[API_ROUTES_PATH]` for routes matching:
- `DELETE /users/<id>`, `DELETE /me`, `DELETE /account`, `DELETE /profile`
- Handler method names: `delete_user`, `deleteAccount`, `destroyUser`, `anonymize_user`, `forget_user`

If no matching route found: Critical. If found but handler body does not reference associated user records (by common association keywords: `posts`, `comments`, `messages`, `orders`, `sessions`, `tokens`, plus any table from `[SCHEMA_PATH]` with a `user_id` / `userId` FK): High - the delete may leave orphan PII.

### G2 - Right to export (Article 20)

**High if no export endpoint exists.**

Search for routes matching:
- `GET /users/<id>/export`, `GET /me/export`, `GET /account/export`, `GET /data`
- Handler names: `export_user_data`, `export_data`, `download_data`, `gdpr_export`

Flag absence.

### G3 - Right to rectification (Article 16)

**Medium if no update endpoint for user profile data exists.**

Search for routes matching:
- `PATCH /users/<id>`, `PUT /users/<id>`, `PATCH /me`, `PUT /me`, `PATCH /profile`
- Handler names: `update_user`, `updateProfile`, `patch_user`

Most projects have this already via CRUD, so this is typically pass. Flag only if no user-profile-mutation route exists.

### G4 - Consent capture

**High if the application handles PII without evidence of consent flow.**

Search for consent artifacts:
- `consent`, `cookie_consent`, `gdpr_consent`, `privacy_consent` in DB schema, API routes, or frontend components
- Cookie banner files: `CookieBanner`, `cookie-consent`, `gdpr-banner`, components under `components/consent/`
- Consent ledger: a DB table or model named `consent`, `user_consents`, `consent_log`

Flag when:
- G6 detects PII fields in schema AND none of the above artifacts are present: High.
- Consent captures exist but are a single boolean flag with no granularity (one column `accepts_terms: boolean`): Medium. GDPR requires granular consent per purpose.

### G5 - Lawful basis declaration

**Medium if `[PRIVACY_DOC_PATH]` is set but the privacy policy lacks explicit lawful-basis language.**

If `[PRIVACY_DOC_PATH]` is set: grep the docs for one of `consent`, `contractual necessity`, `contract`, `legal obligation`, `legitimate interest`, `vital interest`, `public interest`, `Article 6`.

Flag if none appear: Medium.

If `[PRIVACY_DOC_PATH]` not set: skip with `N/A - no privacy doc configured`.

### G6 - PII field identification

**Medium (informational per match; total count affects severity of G4 / G7 / G8).**

Scan `[SCHEMA_PATH]` for column / field names matching the PII registry:

```
email, phone, phone_number, mobile, ssn, tax_id, fiscal_code,
passport, driver_license, id_document, birthdate, date_of_birth,
address, street, postal_code, zip, city, country,
ip_address, last_ip, user_agent,
credit_card, card_number, bank_account, iban,
gender, ethnicity, religion, health, medical_record, genetic_data,
biometric, face_id, fingerprint,
full_name, first_name, last_name, middle_name,
signature, photo, avatar
```

Also scan for column comments / descriptions containing `PII`, `personal data`, `sensitive`.

Output: list of `table.column → PII category` mappings. Count determines severity multipliers for downstream checks.

### G7 - Encryption-at-rest indicators

**High per sensitive field without encryption marker.**

For fields identified in G6 that fall under GDPR Article 9 (special categories - health, genetic, biometric, religion, ethnicity, sexual orientation): verify encryption declared:

- Column comment or description contains `encrypted`, `aes`, `pgcrypto`, `encrypted_<name>` suffix
- Application layer: `@Encrypted` decorator (TypeORM), `EncryptedString` (Prisma with extensions), `encrypted_field` (Django), field value wrapped in `pgp_sym_encrypt` in queries

Flag special-category fields without any encryption indicator: High.

For non-special PII fields: flag only if the project declares HIPAA-level posture (not in v1 scope; defer).

### G8 - PII logging hygiene

**High per match.**

Grep `[APP_SOURCE_PATH]` for logging calls that directly expand PII fields:

- `log(.*user\.(email|phone|ssn|address|birthdate))`
- `logger\.(info|debug|warn|error).*\$\{\s*user\.email\s*\}`
- `print(f?)(user\.(email|phone|ssn))` (Python)
- `console\.log\(.*user\.(email|phone|ssn)`

Also flag request-logger middleware that logs full request body without redaction hook (Morgan with default format, Winston with raw request capture).

### G9 - Retention policy declaration

**Medium if not declared.**

Search `[PRIVACY_DOC_PATH]` (or `README.md`, `CLAUDE.md`) for explicit retention language:

- `retention`, `retained for`, `deleted after`, `purge`, `archived after`
- Time window: `30 days`, `6 months`, `12 months`, `7 years`, `indefinitely` (the last is a GDPR concern)

Flag when PII is stored (G6 matches) but no retention language found anywhere searchable: Medium.

### G10 - Sub-processor (DPA) transparency

**Low (informational).**

Search for references to third-party data processors in the codebase or docs:

- `.env*` (not committed, but gitignored scaffolds): keys matching `STRIPE_*`, `SENDGRID_*`, `MAILGUN_*`, `TWILIO_*`, `SEGMENT_*`, `POSTHOG_*`, `AMPLITUDE_*`, `MIXPANEL_*`, `SENTRY_*`, `DATADOG_*`, `CLOUDFLARE_*`, `AWS_*`, `GCP_*`, `AZURE_*`, `SUPABASE_*`, `VERCEL_*`
- `package.json` / `requirements.txt`: SDK packages from the above vendors

Cross-reference with `[PRIVACY_DOC_PATH]` or `docs/sub-processors.md` if present. Flag providers in code not listed in docs: Low informational.

---

## Step 3 - Report

```
## Compliance Audit - [DATE] - [SCOPE] - profile: GDPR

> This audit produces mechanical findings. Legal compliance attestation requires human counsel review.

### Executive summary
[2-5 bullets. Critical + High findings only. Concrete facts. If nothing Critical/High: state "No critical GDPR gaps detected (mechanical scan only)".]

### GDPR readiness tier
[ONE of:]
- **Foundational** - one or more Critical findings. Core data-subject rights or consent flow missing.
- **Operational** - no Critical, but High findings present. Core flows exist but refinement needed before regulated go-live.
- **Mature** - no Critical, no High. Medium / Low findings remain. Ready for internal review.

(Tier is mechanical. A `Mature` tier does NOT constitute legal attestation.)

### GDPR pillar assessment
| Pillar | Rating | Notes |
|---|---|---|
| Data subject rights (G1-G3) | strong / adequate / weak | [delete + export + rectify] |
| Lawful basis + consent (G4-G5) | strong / adequate / weak | [consent capture + doc declaration] |
| Security measures (G6-G8) | strong / adequate / weak | [PII count + encryption + logging hygiene] |
| Accountability (G9-G10) | strong / adequate / weak | [retention + sub-processors] |
| Release readiness | ready / conditional / blocked | [blocked = any Critical] |

### Check verdicts
| # | Check | Verdict | Findings |
|---|---|---|---|
| G1 | Right to delete | OK / warn | [N] |
| G2 | Right to export | OK / warn | [present / missing] |
| G3 | Right to rectification | OK / warn | [present / missing] |
| G4 | Consent capture | OK / warn | [present / missing / granularity issue] |
| G5 | Lawful basis declaration | OK / warn / N/A | [declared / missing / no privacy doc] |
| G6 | PII field identification | informational | [N fields across M tables] |
| G7 | Encryption-at-rest | OK / warn | [N special-category fields unencrypted] |
| G8 | PII logging hygiene | OK / warn | [N logging sites] |
| G9 | Retention policy | OK / warn | [declared / missing] |
| G10 | Sub-processor transparency | OK / warn | [N providers not in docs] |

### Other profiles
| Profile | Status |
|---|---|
| SOC 2 | Scaffolded for v1.15+. No checks run. |
| HIPAA | Scaffolded for v1.15+. No checks run. |

### Prioritized findings
For each finding with severity Medium or above:
[SEVERITY] [ID] [check] - [file:line] - [evidence] - [impact] - [fix] - [effort: S / M / L]

### Quick wins
[Findings meeting: (a) Medium or High, (b) effort S, (c) single-file fix]
Format: "GDPR-[n]: [one-line description]"
If none: state explicitly.
```

---

## Step 4 - Backlog decision gate

Present Medium-or-above findings as numbered decision list (Critical → High → Medium):

```
Found N findings at Medium or above. Which to add to backlog?

[1] [CRITICAL] GDPR-? - src/routes/users.ts - no delete endpoint
[2] [HIGH]     GDPR-? - src/middleware/logger.ts:18 - email logged raw
[3] [MEDIUM]   GDPR-? - docs/privacy.md - no retention declared
...

Reply with numbers to include (e.g. "1 2 4"), "all", or "none".
```

**Wait for explicit user response before writing anything.**

Persist approved entries via the backlog write-once protocol (`.claude/rules/backlog-protocol.md`) — session scratch in an active block, direct to `docs/refactoring-backlog.md` standalone:
- Assign ID: `GDPR-[n]` (next available; when SOC 2 / HIPAA enable, they get `SOC2-[n]` / `HIPAA-[n]` prefixes)
- Add row to priority index
- Add full detail: issue, evidence, fix, effort, risk, regulatory reference (GDPR Article N)

### Severity guide

- **Critical**: no right-to-delete endpoint when PII is stored (G1)
- **High**: right-to-delete exists but cascade missing (G1); no export endpoint (G2); consent flow absent when PII handled (G4); special-category PII unencrypted (G7); PII logged raw (G8)
- **Medium**: no rectification endpoint (G3); consent exists but non-granular (G4); no lawful-basis language (G5); no retention declaration (G9)
- **Low**: sub-processor in code not listed in docs (G10); G6 informational rows

---

## Execution notes

- Do NOT modify application code, schema, or docs. Audit only.
- This skill is stack-agnostic - GDPR obligations apply to any EU-facing product regardless of backend language.
- The regulatory reference text uses GDPR article numbers where applicable (Art. 6, 9, 16, 17, 20, 28, 30). Users should consult a data protection officer or legal counsel for binding interpretation.
- This skill complements `/security-audit` (technical security controls) and `/doc-audit` (consistency of existing privacy docs). Run in Phase 5d Track B on every block that touches PII handling, user-data endpoints, or third-party SDK integration.
- After the report, ask: "Do you want me to prepare the corrections for the identified findings?" Reply with `yes` only after user sign-off.