Generate Gdpr Ropa

/generate-gdpr-ropa

Generates a draft GDPR Article 30 ROPA from code context files. The output is a draft — it requires legal review before use as a compliance document. Your job is to make that review fast by capturing everything that can be derived from the code without asking a lawyer.

What you're doing and why

MODULE_MANIFEST.md and BEHAVIORAL_CONTRACTS.md already document what data each module handles, where it flows, who receives it, and what security measures are in place. A ROPA is largely this same information presented in the specific format regulators and DPOs need to inspect. Without this skill, someone has to manually trace data flows across every module and interview every team. With it, the draft is generated in one session and the lawyer review focuses on legal analysis rather than archaeology.

The risk is overconfidence — a ROPA that looks complete but is missing processing activities because some modules lack context files. Flag every gap explicitly so the reviewer knows what to verify.

Arguments

• (none) — scans the entire repo
• --module path/to/module — generates a ROPA entry for one module only

Phase 1: Discover PII-processing modules

Scan all MODULE_MANIFEST.md files in the repo (use Glob for **/MODULE_MANIFEST.md). For each, look for:

• Data classification sections mentioning: PII, personal data, user data, personal information, GDPR, health data, financial data, identity, email, name, address, phone
• Retention or residency constraints

Scan all BEHAVIORAL_CONTRACTS.md files for interfaces whose input or output fields include user-identifiable data.

Track which modules were found with and without context files. A source directory that handles data but has no MODULE_MANIFEST.md is a gap — flag it explicitly at the end.

Phase 2: Group into processing activities

ROPA entries map to processing activities, not to modules. Multiple modules often participate in one activity. Group by logical purpose:

• "User authentication" might involve auth module, session module, and audit log module
• "Payment processing" might involve billing module, payment gateway client, and transaction log module
• "Analytics" might involve event ingestion, aggregation, and reporting modules

Present the proposed groupings to the user before proceeding:

I've identified the following processing activities from context files:

1. User account management — modules: auth/, profile/, audit-log/
2. Payment processing — modules: billing/, payment-gateway/, transactions/
3. Analytics and reporting — modules: events/, aggregations/, reporting/

Modules with no context files (these activities may be incomplete):
- recommendations/ — handles user_id but has no MODULE_MANIFEST.md

Do these groupings look right? Should I split or combine any?

Wait for confirmation before continuing.

Phase 3: Auto-populate from context layers

For each confirmed processing activity, extract:

If a field cannot be populated, mark it [REQUIRED — see Open Questions] rather than leaving it blank or guessing.

Phase 4: Interview for human-judgment fields

For each processing activity, ask these questions. Batch them — don't ask one at a time for every activity:

Legal basis (required by Article 30):

What is the legal basis for processing in [activity name]? Options: Consent / Contractual necessity / Legal obligation / Vital interests / Public task / Legitimate interests. If legitimate interests, what are those interests and has a balancing test been performed?

Processing purpose (must be specific):

What specifically does [activity name] accomplish for the data subject or the organization? "To provide services" is not specific enough — what would be missing if this processing stopped?

International transfers (Article 30(1)(e)):

Does data in [activity name] flow to processors or recipients outside the EU/EEA (including SaaS providers, cloud regions, or analytics platforms)? If yes: what transfer mechanism is in place — adequacy decision, SCCs, or BCRs?

Controller / processor distinction:

For [activity name], is [organization] the data controller, a processor acting on behalf of another controller, or both?

If the user cannot answer a question, mark it [OPEN QUESTION — requires DPO/legal input] and add it to the Open Questions section.

Phase 5: Write the ROPA document

Write to docs/compliance/gdpr-ropa-YYYY-MM-DD.md (where YYYY-MM-DD is today's date). Create the docs/compliance/ directory if it doesn't exist.

Use this structure exactly:

# Records of Processing Activities (ROPA)
Article 30(1), GDPR  
Organization: [ask user if not obvious from codebase]  
Last updated: [today's date]  
Status: DRAFT — requires legal review before submission

> **This document was generated from code context files and requires legal review before use
> as a compliance document.** It may be incomplete, inaccurate, or missing processing activities
> not documented in MODULE_MANIFEST.md. Engage your DPO or legal counsel before submitting this
> as a GDPR Article 30 record.

---

## Processing Activity: [Name]

| Field | Value |
|-------|-------|
| Controller | |
| DPO contact | |
| Purpose of processing | |
| Legal basis | |
| Categories of data subjects | |
| Categories of personal data | |
| Recipients / categories of recipients | |
| International transfers | None identified / [transfer + mechanism] |
| Transfer mechanism (if applicable) | |
| Retention period | |
| Technical and organisational security measures | |

### Modules involved

| Module | Role in this activity |
|--------|----------------------|
| [module path] | [e.g., stores user records, processes payment tokens] |

### Open questions

[Fields that could not be populated — require DPO or legal review before submission]

---

One section per processing activity.

Phase 6: Flag documentation gaps

After writing the ROPA, append a gaps section:

## Documentation Gaps

The following modules appear to process personal data but have incomplete or missing context files.
These activities may be underrepresented in this ROPA.

| Module | Issue |
|--------|-------|
| recommendations/ | No MODULE_MANIFEST.md — data flows unknown |
| [module] | MODULE_MANIFEST.md present but data classification not populated |

**Action required before submitting this ROPA:** Run /context-layer-generator on each module
listed above and re-run /generate-gdpr-ropa.

After writing

Report:

• How many processing activities were documented
• How many open questions remain
• How many modules have documentation gaps
• Path to the generated file

Remind the user that legal review is required before this document is used as a compliance submission.