Gdpr Compliant
Ship user-rights APIs, DSR workflows, and cross-store erasure so a solo SaaS can answer GDPR audits before and after launch.
Overview
GDPR-compliant is an agent skill most often used in Ship (also Validate, Build, Operate) that gives solo builders implementation-oriented GDPR patterns for user rights APIs, DSR timing, RoPA, consent, and multi-store era
Install
npx skills add https://github.com/github/awesome-copilot --skill gdpr-compliantWhat is this skill?
- Maps Articles 15–22 to concrete API patterns (export, rectify, delete, restrict, portability, object, automated-decision
- 30 calendar-day response window called out for verified data-subject requests
- Erasure checklist spans primary DB, replicas, search index, cache, and object storage
- Covers RoPA and consent management as governance references alongside engineering endpoints
- 30 calendar days for verified DSR responses
- Articles 15–22 user rights table
- Erasure checklist across DB, replicas, search, cache, and object storage
Adoption & trust: 1.1k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are storing user data across databases, search, and caches but lack tested endpoints and a repeatable erasure path before going live.
Who is it for?
Indie SaaS or API products handling EU personal data who need a concrete engineering checklist before production.
Skip if: Teams wanting turnkey legal counsel, enterprise GRC tooling only, or products with no personal data processing.
When should I use this skill?
Load when implementing user rights endpoints, DSR workflow, RoPA, consent management, or cross-store erasure before or after go-live.
What do I get? / Deliverables
You leave with a rights-and-erasure engineering map—endpoint shapes, 30-day DSR discipline, and a store-by-store deletion checklist ready to implement in your stack.
- Rights endpoint specification
- Erasure pipeline checklist
- DSR handling notes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship → Security because the skill centers on live-ready rights endpoints, 30-day DSR SLA, and pre-launch erasure coverage. Compliance implementation (Articles 15–22, RoPA, consent) is security-governance work you gate before production traffic.
Where it fits
List which tables and third parties hold PII before you commit to a pricing page with signup.
Shape GET /me/data-export and DELETE /me routes with downstream propagation rules.
Verify every rights endpoint and erasure store is covered in pre-launch security review.
Extend the erasure pipeline when you add a new search index or analytics vendor.
How it compares
Use as a procedural compliance checklist for builders, not as a substitute for a privacy lawyer or a dedicated GRC platform.
Common Questions / FAQ
Who is gdpr-compliant for?
Solo and indie builders shipping web apps or APIs that process personal data and need engineering-aligned GDPR implementation notes.
When should I use gdpr-compliant?
During Validate when scoping data flows; during Build when designing /me export and delete routes; at Ship for security launch gates; in Operate when extending stores or answering access requests.
Is gdpr-compliant safe to install?
Review the Security Audits panel on this Prism page and treat the skill as reference guidance you validate against your jurisdiction and counsel.
SKILL.md
READMESKILL.md - Gdpr Compliant
# GDPR Reference — Data Rights, Accountability & Governance Load this file when you need implementation detail on: user rights endpoints, Data Subject Request (DSR) workflow, Record of Processing Activities (RoPA), consent management. --- ## User Rights Implementation (Articles 15–22) Every right MUST have a tested API endpoint or documented back-office process before the system goes live. Respond to verified requests within **30 calendar days**. | Right | Article | Engineering implementation | |---|---|---| | Right of access | 15 | `GET /api/v1/me/data-export` — all personal data, JSON or CSV | | Right to rectification | 16 | `PUT /api/v1/me/profile` — propagate to all downstream stores | | Right to erasure | 17 | `DELETE /api/v1/me` — scrub all stores per erasure checklist | | Right to restriction | 18 | `ProcessingRestricted` flag on user record; gate non-essential processing | | Right to portability | 20 | Same as access endpoint; structured, machine-readable (JSON) | | Right to object | 21 | Opt-out endpoint for legitimate-interest processing; honor immediately | | Automated decision-making | 22 | Expose a human review path + explanation of the logic | ### Erasure Checklist — MUST cover all stores When `DELETE /api/v1/me` is called, the erasure pipeline MUST scrub: - Primary relational database (anonymize or delete rows) - Read replicas - Search index (Elasticsearch, Azure Cognitive Search, etc.) - In-memory cache (Redis, IMemoryCache) - Object storage (S3, Azure Blob — profile pictures, documents) - Email service logs (Brevo, SendGrid — delivery logs) - Analytics platform (Mixpanel, Amplitude, GA4 — user deletion API) - Audit logs (anonymize identifying fields — do not delete the event) - Backups (document the backup TTL; accept that backups expire naturally) - CDN edge cache (purge if personal data may be cached) - Third-party sub-processors (trigger their deletion API or document the manual step) ### Data Export Format (`GET /api/v1/me/data-export`) ```json { "exportedAt": "2025-03-30T10:00:00Z", "subject": { "id": "uuid", "email": "user@example.com", "createdAt": "2024-01-15T08:30:00Z" }, "profile": { ... }, "orders": [ ... ], "consents": [ ... ], "auditEvents": [ ... ] } ``` - MUST be machine-readable (JSON preferred, CSV acceptable). - MUST NOT be a PDF screenshot or HTML page. - MUST include all stores listed in the RoPA for this user. ### DSR Tracker (back-office) Implement a **Data Subject Request tracker** with: - Incoming request date - Request type (access / rectification / erasure / portability / restriction / objection) - Verification status (identity confirmed y/n) - Deadline (received date + 30 days) - Assigned handler - Completion date and outcome - Notes Automate the primary store scrubbing; document manual steps for third-party stores. --- ## Record of Processing Activities (RoPA) Maintain as a living document (Markdown, YAML, or JSON) version-controlled in the repo. Update with **every** new feature that introduces a processing activity. ### Minimum fields per processing activity ```yaml - name: "User account management" purpose: "Create and manage user accounts for service access" legalBasis: "Contract (Art. 6(1)(b))" dataSubjects: ["Registered users"] personalDataCategories: ["Name", "Email", "Password hash", "IP address"] recipients: ["Internal engineering team", "Brevo (email delivery)"] retentionPeriod: "Account lifetime + 12 months" transfers: outside_eea: true safeguard: "Brevo — Standard Contractual Clauses (SCCs)" securityMeasures: ["TLS 1.3", "AES-256 at rest", "bcrypt password hashing"] dpia_required: false ``` ### Legal basis options (Art. 6) | Basis | When to use | |---|---| | `Contract (6(1)(b))` | Processing necessary to fulfill the service contract | | `Legitimate interest (6(1)(f))` | Fraud prevention, security, analytics (requires balancing test) | | `Consent (6(1)(a))` | Marketing, non-essential cookies, optiona