# Gdpr Dpa

> Generate a GDPR-compliant Data Processing Agreement (DPA) for a project. Use when asked to create, generate, or write a DPA or data processing agreement. Autonomously scans the project to identify all sub-processors (third-party services that handle personal data), then generates a minimal Article 28-compliant DPA covering actual data flows — no compliance theater, no unnecessary boilerplate. Works with any language or framework.

- Skill: `mikkelkrogsholm/gdpr-dpa` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add mikkelkrogsholm/gdpr-dpa`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mikkelkrogsholm/gdpr-dpa/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: mikkelkrogsholm (https://skillmd.com/u/mikkelkrogsholm)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mikkelkrogsholm/gdpr-dpa

---


# GDPR DPA Generator

Generate a minimal, accurate DPA by scanning the project rather than interviewing the user.

## Workflow

### Step 1: Discover Sub-processors

Scan the project for service fingerprints. Check ALL of the following (not just package.json — this must work for any language):

**Dependency files** (read whichever exist):
- Node.js: `package.json`, `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`
- Python: `requirements.txt`, `pyproject.toml`, `Pipfile`, `setup.py`
- Ruby: `Gemfile`
- Go: `go.mod`
- Rust: `Cargo.toml`
- PHP: `composer.json`
- Dart/Flutter: `pubspec.yaml`

**Infrastructure and config files:**
- `docker-compose.yml`, `Dockerfile`
- `.env.example`, `.env.sample`, `.env.template`
- `coolify.yaml`, `render.yaml`, `railway.toml`, `fly.toml`
- Any `*.config.*`, `*.toml`, `*.yaml`, `*.ini`

**Source code signals:**
- Import/require statements for known SDK packages
- Direct HTTP calls to known API endpoints (`api.stripe.com`, `sentry.io`, `api.resend.com`, etc.)
- Environment variable names that reveal services (`STRIPE_SECRET_KEY`, `SENTRY_DSN`, `RESEND_API_KEY`, etc.)

Cross-reference every discovered service against `references/sub-processors.md` to get GDPR metadata.

### Step 2: Identify Personal Data Types

Scan schema files, models, and form handlers to identify what personal data is actually processed:
- User identity: name, email, username, phone
- Location: address, IP address, coordinates
- Financial: payment methods, transaction history
- Behavioral: activity logs, session data, analytics events
- Device: user agent, device ID
- Sensitive: health data, biometrics (flag these — Article 9 requires explicit consent)

### Step 3: Flag Issues

Before generating, list any issues found:
- Services detected but NOT in sub-processors.md (unknown sub-processor — user must add manually)
- Services using non-EU regions when EU region is available (flag with recommended config)
- Sensitive data (Article 9) detected without evidence of explicit consent mechanism
- Services where DPA URL could not be confirmed (mark as "verify link")
- No `.env.example` found — sub-processor list may be incomplete

### Step 4: Generate the DPA

Use `references/dpa-template.md` as the template. Fill in:
- **Annex A (Sub-processors)**: list every identified sub-processor with their role and DPA link
- **Data types section**: the personal data categories found in Step 2
- **Purpose of processing**: inferred from the project (auth, payments, error tracking, etc.)
- Leave `[YOUR COMPANY NAME]` and `[CUSTOMER COMPANY NAME]` as placeholders
- Leave `[DATE]` as a placeholder
- Add a note at the top: "Generated from project scan — review before use. Not legal advice."

Output the DPA as a Markdown document ready to save as `DPA.md` in the project root.