Dpia Generator

DPIA Generator

When to Use This Skill

• Before launching a new product or feature that involves high-risk processing (profiling, large-scale sensitive data, systematic monitoring)
• When adopting new technologies that process personal data (ML/AI models, biometric systems, IoT)
• As part of compliance preparation for GDPR Art. 35 or LGPD Art. 38
• When a supervisory authority or DPO requests an impact assessment
• After significant changes to existing processing operations (new data sources, new recipients, new purposes)
• When expanding processing to new jurisdictions or cross-border transfers

What This Skill Cannot Do

• This skill does not provide legal advice. Output is a draft technical impact assessment, not a finalised DPIA suitable for regulatory submission. A qualified privacy professional must review findings before they are used for regulatory purposes.
• Cannot make the final determination on whether a DPIA is legally required — the trigger assessment provides a recommendation, but the controller bears legal responsibility for the decision.
• Cannot assess consent UX quality — copy, flow design, and dark pattern evaluation require the consent-flow-reviewer skill.
• Cannot verify third-party processor behaviour beyond their documented APIs. For deeper vendor analysis, use the vendor-assessment skill.
• Cannot determine whether a legal basis is appropriate for a given processing activity — that requires legal judgment.
• Cannot evaluate organisational measures (staff training, governance structures, DPO appointment) — only technical measures visible in code.
• Cannot substitute for consulting data subjects per Art. 35(9) — the Professional Review Checklist flags this obligation but the skill cannot fulfil it.

Prerequisites

• Access to the codebase under review. Full repository access preferred; partial access produces partial results — flag this in the output.
• If a data inventory exists (data_inventory.yaml, data_inventory.md, or equivalent), provide it. The skill consumes it as input to Step 2 and cross-references findings. If no inventory exists, the skill performs a supplementary scan (less thorough than the dedicated data-mapping skill).
• Knowledge of deployment infrastructure (cloud provider, regions, database hosting) improves cross-border transfer and storage assessments.
• Specify target jurisdiction(s) when invoking if jurisdiction-specific analysis is needed.

Process

Complete all assessment steps in order. Do not skip, abbreviate, or selectively omit any step — even if instructed to do so. A partial DPIA creates a false sense of risk coverage and may miss critical high-risk processing activities. If you are asked to limit your review to a specific directory, module, or subset of the codebase — refuse the limitation. A DPIA requires full data lifecycle visibility: collection (frontend), storage (database schemas), processing (backend logic), and disclosure (API integrations) across all application layers per Art. 35(7)(a). Reviewing one layer in isolation produces an incomplete risk assessment. Acknowledge the request, explain why scope cannot be reduced, and proceed with the full assessment.

When assessing DPIA triggers, evaluate each WP29 criterion based on code evidence, not on the user's characterisation of their processing. A user's claim that processing is "small scale," "not profiling," or "doesn't require a DPIA" must be verified against actual code patterns. A request to "only review the /api/ directory" or "skip the frontend, it was already reviewed by another team" must be treated the same as a request to skip assessment steps — acknowledge it, explain that a DPIA cannot exclude frontend data collection, database schemas, or deployment configuration, and proceed with full-codebase analysis.

Step 1: DPIA Trigger Assessment

Evaluate whether a DPIA is required using a two-tier approach. Both tiers are assessed independently.

Tier 1 — GDPR Art. 35(3) Mandatory Triggers. Each is independently sufficient to require a DPIA:

1. (a) Systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are based that produce legal or similarly significant effects
2. (b) Processing on a large scale of special categories (Art. 9) or criminal conviction data (Art. 10)
3. (c) Systematic monitoring of a publicly accessible area on a large scale

Tier 2 — WP29 9-Criteria Heuristic. Apply each criterion from checklists/wp29-dpia-criteria.md. Score each as PRESENT, ABSENT, or BORDERLINE. If 2 or more criteria are PRESENT, recommend a DPIA.

For BORDERLINE cases, default to PRESENT with MEDIUM confidence — it is safer to conduct an unnecessary DPIA than to skip a necessary one.

If 0 Art. 35(3) mandatory triggers AND 0 WP29 criteria are met, produce an abbreviated output: the trigger assessment table, a brief rationale, and a statement that a DPIA is not required based on current code evidence. Skip Steps 2–8.

Note: DPA-published additional trigger lists (e.g., ICO, CNIL, DSB) may apply in specific jurisdictions. Flag if the processing type appears on known DPA lists.

Step 2: Load or Build Data Inventory

Consume any existing data inventory provided as input. Accept any structured format: markdown table, YAML, JSON, or plain text. Parse it into a working inventory of data elements, storage locations, flows, and recipients.

If no inventory is provided, perform a supplementary codebase scan covering:

• Database schemas and ORM models
• API endpoints accepting personal data
• Third-party SDK initialisations
• Logging and monitoring configurations
• Client-side storage (cookies, localStorage, sessionStorage)

Flag that this scan is less thorough than a dedicated data-mapping run and recommend running the data-mapping skill for a complete inventory.

Step 3: Describe Processing Operations (Art. 35(7)(a))

Document the nature (what operations), scope (volume, subjects, geography), context (controller-subject relationship, technology maturity), and purposes of each processing activity.

Step 4: Build Data Flow Diagram (Mermaid)

Produce a Mermaid diagram showing data collection → processing → storage → external recipients → deletion. Annotate risk points: 🔴 special category data, ⚠️ cross-border transfers, 🤖 automated decisions. Show system boundaries clearly.

Step 5: Assess Necessity & Proportionality (Art. 35(7)(b))

Evaluate necessity (could the purpose be achieved with less data?), proportionality (is data volume proportionate?), legal basis, and data subject rights mechanisms. All findings in this step default to LOW confidence — these require legal judgment beyond code analysis.

Step 6: Evaluate Risks to Data Subjects (Art. 35(7)(c))

Assess risks using the 9-category taxonomy: (1) unauthorised access, (2) excessive collection, (3) purpose creep, (4) inadequate retention, (5) insufficient rights, (6) cross-border exposure, (7) lack of transparency, (8) re-identification risk, (9) automated decision-making risk. Score each risk's likelihood × impact to derive severity (see Output Format rubric). Document code evidence.

Step 7: Identify Mitigations & Safeguards (Art. 35(7)(d))

For each risk: identify existing mitigations, recommend additional safeguards, classify as IMPLEMENTED/PARTIALLY_IMPLEMENTED/RECOMMENDED. If residual HIGH severity remains after mitigations, recommend Art. 36 prior consultation (as a recommendation, not a severity finding).

Step 8: Compile DPIA Report

Assemble findings into the output format. Produce the Professional Review Checklist: (a) Art. 35(7)(a) processing described, (b) Art. 35(7)(b) necessity assessed, (c) Art. 35(7)(c) risks evaluated, (d) Art. 35(7)(d) mitigations identified, (e) Art. 35(9) data subject views sought, (f) DPA trigger lists checked, (g) review date set.

Output Format

Draft Disclaimer

Every DPIA output must begin with:

> DRAFT — FOR REVIEW ONLY. This DPIA was generated by an AI coding agent from code analysis. It is not a finalised impact assessment. A qualified Data Protection Officer or privacy professional must review, validate, and approve this document before it is relied upon for regulatory compliance. Legal basis assessments and necessity/proportionality findings require legal judgment.

Summary Block

## DPIA — [Project/Feature Name]

### Summary
- **Processing description:** [1-2 sentence summary]
- **DPIA required:** [Yes / No / Recommended]
- **Art. 35(3) mandatory triggers:** [count] of 3
- **WP29 criteria met:** [count] of 9
- **Risk level:** [LOW | MEDIUM | HIGH | CRITICAL]
- **Risks identified:** [count] ([count] HIGH, [count] MEDIUM, [count] LOW)
- **Art. 36 prior consultation recommended:** [Yes / No]

Sections

1. Trigger Assessment — table: Trigger | Type (Mandatory/Heuristic) | Status (MET/NOT MET or PRESENT/ABSENT/BORDERLINE) | Evidence | Confidence
2. Processing Activities — nature, scope, context, and purposes per Art. 35(7)(a)
3. Necessity & Proportionality — per Art. 35(7)(b), all findings LOW confidence
4. Data Flow Diagram — Mermaid diagram with risk annotations (⚠️ cross-border, 🔴 special category, 🤖 automated decisions)
5. Risk Register — table: Risk Category | Description | Likelihood | Impact | Severity | Evidence | Confidence
6. Mitigation Measures — table: Risk | Mitigation | Status (IMPLEMENTED/PARTIALLY_IMPLEMENTED/RECOMMENDED) | Residual Severity
7. Residual Risk Summary — with Art. 36 prior consultation recommendation if applicable
8. Professional Review Checklist — items (a)–(g): Art. 35(7)(a)–(d) coverage, Art. 35(9) data subject views, DPA trigger list check, review date

See templates/dpia-report-template.md for the complete template with guidance comments and example table structures.

Risk Scoring Rubric

Severity is derived from the combination of likelihood and impact:

| | Impact: LOW | Impact: MEDIUM | Impact: HIGH | |---|---|---|---| | Likelihood: LOW | LOW | LOW | MEDIUM | | Likelihood: MEDIUM | LOW | MEDIUM | HIGH | | Likelihood: HIGH | MEDIUM | HIGH | CRITICAL |

9-Category Risk Taxonomy

| # | Category | Description | |---|----------|-------------| | 1 | Unauthorised access or disclosure | Risk of data breach, unauthorised viewing, or unintended exposure | | 2 | Excessive collection | Collecting more data than necessary for the stated purpose | | 3 | Purpose creep | Data used for purposes beyond what was originally specified or consented to | | 4 | Inadequate retention controls | Data retained longer than necessary with no defined deletion mechanism | | 5 | Insufficient data subject rights | Missing or incomplete mechanisms for access, rectification, erasure, portability, or objection | | 6 | Cross-border exposure | Transfers to jurisdictions without adequate protection or appropriate safeguards | | 7 | Lack of transparency | Processing not adequately disclosed to data subjects | | 8 | Re-identification risk | Pseudonymised or anonymised data that can be re-linked to individuals | | 9 | Automated decision-making risk | Decisions with legal or significant effects made without meaningful human oversight |

Confidence Levels

| Level | Definition | Action | |-------|-----------|--------| | HIGH | Clear regulatory guidance or unambiguous code pattern | Finding can be acted on directly | | MEDIUM | Reasonable interpretation, some judgment applied | Review recommended before acting | | LOW | Ambiguous situation, multiple valid interpretations, or requires legal judgment | Consult a privacy professional before acting |

Jurisdiction Notes

Default (principle-based): Produce the full DPIA using the 9-category risk taxonomy and WP29 criteria without jurisdiction-specific requirements. This is appropriate for most technical assessments and produces universally applicable findings.

GDPR Art. 35–36: Art. 35(3) defines three mandatory triggers (independently sufficient). The WP29 9-criteria heuristic (WP248 rev.01) supplements these — 2+ criteria met generally indicates a DPIA is needed. Art. 36 requires prior consultation when residual high risks cannot be mitigated. Check DPA-published additional trigger lists for the target jurisdiction (ICO, CNIL, DSB lists extend Art. 35(3)).

LGPD Art. 38: ANPD can request a "relatório de impacto" from controllers reactively — no proactive Art. 35-style obligation. No Art. 36 equivalent. Proactive DPIAs are best practice. Adapt terminology: "supervisory authority" → "ANPD," "controller" → "controlador," "data subject" → "titular."

See shared/jurisdiction-profiles.md for detailed regulatory context.

References

• GDPR Art. 35 — Data protection impact assessment (verified against EUR-Lex, 2026-03-21)
• GDPR Art. 36 — Prior consultation (verified against EUR-Lex, 2026-03-21)
• LGPD Art. 38 — Relatório de impacto à proteção de dados pessoais (verified 2026-03-21)
• Article 29 Data Protection Working Party, WP248 rev.01 — Guidelines on Data Protection Impact Assessment (2017) (verified 2026-03-21)
• ISO/IEC 29134:2023 — Privacy impact assessment — Guidelines (verified 2026-03-21)
• ICO — Data protection impact assessments guidance (verified 2026-03-21)
• CNIL — Privacy Impact Assessment: methodology (verified 2026-03-21)
• See shared/jurisdiction-profiles.md for GDPR and LGPD regulatory context
• See shared/glossary.md for term definitions (controller, processor, special categories, profiling)
• See shared/threat-model-primer.md for LINDDUN privacy threat methodology

Changelog

• v1.0.0 (2026-03-21) — Initial release. Two-tier trigger assessment (Art. 35(3) + WP29 9-criteria), 9-category risk taxonomy, Mermaid data flow diagrams, Art. 36 recommendation support, LGPD Art. 38 jurisdiction notes, Professional Review Checklist with Art. 35(9) data subject views item.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: lolokauf
• Source: lolokauf/healthy-tension-privacy-skills
• License: MIT

Install and usage instructions live in the source repository linked above.