GDPR — Personal-data assessment from the repo...

Scans a repository for evidence of personal data collection, classifies sensitivity under GDPR, decides whether GDPR applies and how critical the obligations are, and reports the required roles, articles to satisfy, and remediation plan.

Activation

When this skill activates, output:

GDPR — Personal-data assessment from the repo...

Then execute the protocol below.

Context Guard

Context	Status
User says "GDPR", "data protection", "privacy compliance"	ACTIVE
User asks "do I need GDPR", "does GDPR apply to this project"	ACTIVE
User says "DSAR", "right to be forgotten", "cookie consent", "DPA"	ACTIVE
User asks about CCPA, LGPD, PIPEDA, UK GDPR	ACTIVE
User wants a generic security audit	DORMANT — use owasp-top10
User wants a service agreement or NDA	DORMANT — use contract-template
User wants RLS / database access policies	DORMANT — use rls-checker

Common Mistakes

Mistake	Why It's Wrong
"We're a US company so GDPR doesn't apply"	GDPR follows the data subject, not the company. Any EU/UK resident's data triggers it.
"Hashed emails aren't personal data"	Hashes are still personal data if reversible or linkable. True anonymisation is irreversible.
"Cookie banner with only Accept"	Reject must be equally prominent. Pre-ticked = invalid consent.
"Legitimate interest covers everything"	Requires a documented balancing test. Cannot be used for special category data or marketing to children.
"We'll get the DPA later"	Article 28 requires a written DPA before processing begins.
"72-hour clock starts after we finish investigating"	The clock starts on awareness of a likely breach.

Disclaimer: Produces a compliance assessment, not legal advice. Engage a qualified DPO or data-protection lawyer before relying on outputs for regulated processing.

Protocol

Step 1: Scan the repo for personal-data signals

Don't ask the user what they collect — find out from the code. Run discovery against every relevant surface:

Database schemas / migrations

find . \( -name "*.sql" -o -name "schema.prisma" -o -name "models.py" -o -name "*.dbml" \) -not -path "*/node_modules/*"
grep -rEin "email|phone|address|first_?name|last_?name|date_?of_?birth|dob|ssn|passport|tax_?id|national_?id|ip_?address|geo|lat|lng|location|gender|race|religion|health|medical|biometric|fingerprint|face|child|minor" --include="*.sql" --include="*.prisma" --include="*.py" --include="*.ts"

Form / UI input fields

grep -rEin "<input[^>]*name=|formField|FormControl|registerField" --include="*.tsx" --include="*.jsx" --include="*.vue" --include="*.svelte"
grep -rEin "type=[\"']email[\"']|type=[\"']tel[\"']|autoComplete=[\"'](name|email|tel|address|cc-|bday)" .

API request schemas / DTOs

grep -rEin "z\.object|class.*BaseModel|interface.*Request|Schema\(" --include="*.ts" --include="*.py"

Auth configuration

find . -iname "auth*" -o -iname "*supabase*" -o -iname "*clerk*" -o -iname "*next-auth*" -o -iname "*firebase*"
grep -rEin "providers:|GoogleProvider|GitHubProvider|EmailProvider|magicLink|phoneSignIn"

Analytics / tracking SDKs

grep -rEin "posthog|mixpanel|amplitude|segment|google-?analytics|gtag|fbq|hotjar|fullstory|datadog.*RUM|sentry" .

Cookies / sessions

grep -rEin "Set-Cookie|cookies\.set|res\.cookie|getServerSession|session\(" .

Logging that may capture PII

grep -rEin "console\.log.*req\.|logger\.(info|debug).*body|print\(.*request" .

Third-party data recipients

cat package.json requirements.txt pyproject.toml composer.json Gemfile 2>/dev/null | grep -Ei "stripe|paypal|sendgrid|mailgun|twilio|openai|anthropic|hubspot|intercom|zendesk|algolia"

Existing privacy artifacts (gap check)

find . \( -iname "privacy*" -o -iname "*dpa*" -o -iname "ropa*" -o -iname "cookie-policy*" -o -iname "data-processing*" \)

Record findings in a working table:

| Source | Field / Signal | Personal Data? | Sensitivity Class |
|--------|---------------|----------------|-------------------|
| db/schema.sql L42 | users.email | Yes | Identifier |
| db/schema.sql L43 | users.phone | Yes | Identifier |
| src/forms/Profile.tsx L18 | dob input | Yes | Identifier (age) |
| src/forms/Health.tsx L7 | medical_conditions | Yes | **Special category (Art 9)** |
| package.json | posthog-js | Yes — behavioral | Behavioral |
| src/api/users.ts L88 | logger.info(req.body) | Possible PII leak | Risk |

If no personal-data signals are found, jump to Step 3 with verdict NO and stop.

Step 2: Classify sensitivity

Bucket every confirmed finding into one or more of:

Class	Examples	GDPR Treatment
Identifier	name, email, phone, address, account ID, IP	Standard personal data — Art 6 lawful basis required
Financial	card number, bank account, billing address	Standard personal data + PCI scope considerations
Location	precise GPS, geo, IP-derived city	Standard personal data; precise location may require explicit consent
Behavioral	clickstream, page views, session recording, fingerprint	Standard personal data; consent for non-essential cookies/tracking
Government ID	passport, SSN, national ID, driver's licence	Standard personal data but elevated risk; often national-law restricted
Special category — Art 9	health, biometric, genetic, race, ethnicity, religion, political, sexual orientation, trade-union	Prohibited unless an Art 9(2) condition applies — almost always explicit consent
Children's data — Art 8	any data from users under 16 (age varies 13–16 by member state)	Requires parental consent for information-society services
Criminal data — Art 10	offences, convictions	Only under official authority or specific national law

Step 3: Verdict — does GDPR apply, and how critical?

| Question | Answer |
|----------|--------|
| Is any personal data collected? | [Yes / No] |
| Are EU/UK data subjects in scope? | [Yes / Probably (global product) / No (closed user base)] |
| Any special category data (Art 9)? | [Yes / No] |
| Any children's data (Art 8)? | [Yes / No] |
| Large-scale or systematic monitoring? | [Yes / No] |
| Third parties / processors involved? | [Yes / No] |
| Cross-border transfers outside EU/UK? | [Yes / No / Unknown] |

Verdict matrix:

Scenario	Verdict	Criticality
No personal data at all	GDPR does not apply	None
Personal data + EU/UK subjects unlikely (e.g. closed internal tool, non-EU user base)	GDPR applies if even one EU/UK subject; treat as best practice	🟩 LOW
Standard identifiers + EU/UK subjects	GDPR applies	🟨 MEDIUM
Identifiers + financial / location / behavioral tracking	GDPR applies, multiple obligations	🟧 HIGH
Any Art 9 special category data	GDPR applies, strict	🟥 CRITICAL
Any children's data	GDPR applies, strict + Art 8 parental consent	🟥 CRITICAL
Large-scale systematic monitoring or profiling	GDPR applies, DPIA required	🟥 CRITICAL

Step 4: Map required roles

Based on the verdict, list which roles the project must staff:

Role	Triggered When	Status
Controller (Art 4(7))	Project decides purposes and means of processing — almost always you	Required
Joint controllers (Art 26)	Shared decisions with another org	Check
Processor (Art 4(8))	You process data on behalf of another controller	Check
DPO (Art 37)	Public authority, OR core activities = large-scale systematic monitoring, OR core activities = large-scale special category	Required if any trigger
Art 27 EU representative	Controller/processor not established in EU but processes EU data, AND processing is not occasional	Required if any trigger
Internal owner	Every project — accountable for GDPR posture day-to-day	Required

Step 5: Map required articles to fulfill

Only list the articles that actually trigger for this project, with a one-line "what to do" for each:

Article	Obligation	Triggered?	Concrete action
Art 5 — Principles	Lawfulness, fairness, transparency, purpose limitation, minimisation, accuracy, storage limitation, integrity, accountability	Always	Document each principle is met
Art 6 — Lawful basis	Pick one of 6 bases per processing activity	Always	Add lawful basis column to ROPA
Art 7 — Conditions for consent	If any basis is consent	If consent	Implement explicit, granular, withdrawable consent UI
Art 8 — Children	If under-16 users	If children	Parental consent flow
Art 9 — Special category	If health/biometric/etc.	If Art 9 data	Explicit consent + extra safeguards
Art 13/14 — Transparency	Privacy notice at collection	Always	Publish privacy policy that mirrors actual processing
Art 15–22 — Subject rights	Access, rectification, erasure, restriction, portability, objection, ADM	Always	Implement DSAR endpoint + 30-day SLA
Art 25 — Privacy by design	Default settings minimise data	Always	Code review checklist
Art 28 — Processors	Written DPA before processing	If any processor	Sign DPAs with every vendor
Art 30 — ROPA	Record of Processing Activities	If 250+ employees OR not occasional OR Art 9	Maintain ROPA
Art 32 — Security	TIA-equivalent technical/organisational measures	Always	Document encryption, access control, backups
Art 33 — Breach to authority	72h notification	Always	Breach runbook
Art 34 — Breach to subjects	Without undue delay if high risk	Always	Subject notification template
Art 35 — DPIA	High-risk processing	If profiling/large scale/Art 9	Run DPIA before launch
Art 37–39 — DPO	If triggered (see Step 4)	If triggered	Appoint and publish
Chapter V — Transfers	International transfers	If any	SCCs / adequacy / BCRs + TIA

Step 6: Gap analysis from the repo

For each triggered article in Step 5, check whether the repo already has evidence of the obligation:

| Obligation | Evidence in repo? | Gap |
|------------|-------------------|-----|
| Privacy policy (Art 13) | ❌ Not found | Draft from ROPA |
| Cookie banner (ePrivacy + Art 6) | ✅ src/components/CookieBanner.tsx | Verify reject is equally prominent |
| DSAR endpoint (Art 15–22) | ❌ Not found | Implement /api/account/export and /api/account/delete |
| DPA with Stripe (Art 28) | ❓ Unknown | Confirm signed, store reference |
| Breach runbook (Art 33) | ❌ Not found | Create docs/security/breach-runbook.md |
| ROPA (Art 30) | ❌ Not found | Draft from Step 1 inventory |
| DPIA (Art 35) | ❌ Required (Art 9 data present) | Run before any launch |

Step 7: Produce the assessment report

## GDPR Assessment — [Project Name]

**Date:** [YYYY-MM-DD]
**Verdict:** GDPR **[APPLIES / DOES NOT APPLY / APPLIES AS BEST PRACTICE]**
**Criticality:** [🟥 CRITICAL / 🟧 HIGH / 🟨 MEDIUM / 🟩 LOW / None]

### Why this verdict
[2–4 sentences referencing the specific data found in Step 1: e.g. "The repo collects user emails, phone numbers, dates of birth, and self-reported medical conditions through src/forms/Health.tsx. The medical_conditions field is special category data under Article 9, which elevates the project to CRITICAL regardless of user geography."]

### Personal data inventory
[Table from Step 1, filtered to confirmed personal data]

### Sensitivity classification
[Counts per class from Step 2]

### Required roles
[Table from Step 4]

### Required articles to satisfy
[Filtered table from Step 5 showing only triggered rows]

### Gaps found in the repo
[Table from Step 6]

### Remediation plan (priority order)
1. **🟥 [Critical fix]** — [what + which file/system + estimated effort]
2. **🟧 [High fix]** — ...
3. **🟨 [Medium fix]** — ...
4. **🟩 [Low / hardening]** — ...

### What to do if you ignore this
[1–3 sentences naming the concrete legal exposure: maximum fines under Art 83 are €20M or 4% of global annual turnover, whichever is higher; supervisory authority enforcement; reputational damage; civil claims under Art 82.]

### Recommended next steps
1. [Owner] — [Action] — [Due]
2. ...

Output Format

Deliver the Step 7 report as markdown. Save under

docs/compliance/gdpr-assessment.md

if a project layout is available. Include the exact discovery commands you ran in an appendix so the user can reproduce the scan.

Completion

GDPR — Assessment complete!

Verdict: [APPLIES / DOES NOT APPLY / BEST PRACTICE]
Criticality: [tier]
Personal data fields found: [N]
Special category fields: [N]
Triggered articles: [N]
Gaps to remediate: [N]

Next steps:
1. Address all 🟥 CRITICAL gaps before any further processing
2. Draft missing artifacts (privacy policy, ROPA, DPA, breach runbook)
3. Implement DSAR endpoints in the codebase
4. Run a DPIA if special-category or large-scale profiling is in scope
5. Have a qualified DPO or data-protection lawyer review before going live

Level History

• Lv.1 — Base: repo-driven scan across schemas/forms/DTOs/auth/analytics/cookies/logging/third parties, sensitivity classification (identifier/financial/location/behavioral/Art 9/Art 8/Art 10), verdict matrix with 7 scenarios, role mapping (Controller/Processor/DPO/Art 27 rep), 16-article obligation map, repo gap analysis, full assessment report with criticality tier, why-this-verdict section, remediation priority list, and exposure summary. (Origin: MemStack Pro v3.6, Apr 2026)