dpia-generator
Generate a Data Protection Impact Assessment (DPIA), Uganda DPPA 2019-compliant. Use when producing or reviewing a data protection impact assessment, a privacy impact assessment, when uganda-dppa-compliance flags [DPIA-REQUIRED], or when processing large-scale or sensitive personal data for a new feature.
Best use case
dpia-generator is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Generate a Data Protection Impact Assessment (DPIA), Uganda DPPA 2019-compliant. Use when producing or reviewing a data protection impact assessment, a privacy impact assessment, when uganda-dppa-compliance flags [DPIA-REQUIRED], or when processing large-scale or sensitive personal data for a new feature.
Teams using dpia-generator should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/dpia-generator/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How dpia-generator Compares
| Feature / Agent | dpia-generator | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Generate a Data Protection Impact Assessment (DPIA), Uganda DPPA 2019-compliant. Use when producing or reviewing a data protection impact assessment, a privacy impact assessment, when uganda-dppa-compliance flags [DPIA-REQUIRED], or when processing large-scale or sensitive personal data for a new feature.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Skill: DPIA Generator (Uganda DPPA 2019) Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178. <!-- dual-compat-start --> ## Use When - Generate Uganda DPPA 2019-compliant DPIA documents. Use when uganda-dppa-compliance flags [DPIA-REQUIRED] or when processing large-scale personal data. - The task needs reusable judgment, domain constraints, or a proven workflow rather than ad hoc advice. ## Do Not Use When - The task is unrelated to `dpia-generator` or would be better handled by a more specific companion skill. - The request only needs a trivial answer and none of this skill's constraints or references materially help. ## Required Inputs - Gather relevant project context, constraints, and the concrete problem to solve. - Confirm the desired deliverable: design, code, review, migration plan, audit, or documentation. ## Workflow - Read this `SKILL.md` first, then load only the referenced deep-dive files that are necessary for the task. - Apply the ordered guidance, checklists, and decision rules in this skill instead of cherry-picking isolated snippets. - Produce the deliverable with assumptions, risks, and follow-up work made explicit when they matter. ## Quality Standards - Keep outputs execution-oriented, concise, and aligned with the repository's baseline engineering standards. - Preserve compatibility with existing project conventions unless the skill explicitly requires a stronger standard. - Prefer deterministic, reviewable steps over vague advice or tool-specific magic. ## Anti-Patterns - Treating examples as copy-paste truth without checking fit, constraints, or failure modes. - Loading every reference file by default instead of using progressive disclosure. ## Outputs - A concrete result that fits the task: implementation guidance, review findings, architecture decisions, templates, or generated artifacts. - Clear assumptions, tradeoffs, or unresolved gaps when the task cannot be completed from available context alone. - References used, companion skills, or follow-up actions when they materially improve execution. ## Evidence Produced | Category | Artifact | Format | Example | |----------|----------|--------|---------| | Data safety | Data Protection Impact Assessment | Markdown doc covering lawful basis, data flows, risks, and mitigations | `docs/compliance/dpia-customer-onboarding.md` | | Data safety | PII / retention register | Markdown doc mapping personal data fields to basis and retention window | `docs/compliance/pii-retention-register.md` | ## References - Use the links and companion skills already referenced in this file when deeper context is needed. <!-- dual-compat-end --> ## Purpose Generate a Uganda Data Protection and Privacy Act 2019 — compliant Data Protection Impact Assessment (DPIA) document for a specific processing operation that has been flagged with `[DPIA-REQUIRED]`. Implements Regulation 12 of the Data Protection and Privacy Regulations 2021. Use this skill when: - The `uganda-dppa-compliance` skill has flagged `[DPIA-REQUIRED: <reason>]` for a processing operation - The consultant is preparing for Phase 3 go-live involving farmer personal data - Any new processing feature involves large-scale, systematic, or special personal data collection - A PDPO auditor requests a DPIA on file --- ## Inputs Required Before invoking this skill, read: - `_context/vision.md` — system scope - `_context/features.md` — the specific processing operation being assessed - `_context/personas.md` — data subjects affected - `_context/gap-analysis.md` — open privacy gaps - The specific `[DPIA-REQUIRED]` flag text and its context in the originating document - `domains/uganda/references/dppa-pii-classification.md` — PII classification matrix Ask the consultant to identify: **Which processing operation is being assessed?** (e.g., "bulk collection of farmer NIN, GPS, photo, and mobile money number during cooperative registration") --- ## DPIA Structure (Regulation 12) ### Section 1 — Processing Operation Description **1.1 Operation name and purpose** Name the specific processing operation. State its purpose. Cite the module and FR identifiers. **1.2 Data controller and DPO** Name the data controller (organisation), designated DPO, and PDPO registration number. **1.3 Categories of data subjects** Describe who is affected: number of individuals, demographics, vulnerability factors (e.g., rural smallholder farmers with limited digital literacy). **1.4 Data categories collected** List every field. Classify each as S (special personal data), P (personal data), or N (non-personal). For S-tier fields, cite the Section 9 category. | Field | Tier | Section 9 Category | Volume | |---|---|---|---| | Mobile money number | S | Financial information | 6,440+ | | NIN | P | Identification number | 6,440+ | | GPS farm coordinates | P | Location/identity | 6,440+ | | Photograph | P | Identity data | 6,440+ | **1.5 Processing activities** Describe what happens to the data: collection, storage, use, disclosure, retention, destruction. **1.6 Lawful basis** For each data category, cite the applicable Section 7 lawful basis. **1.7 Data processors involved** List any third parties processing data (MTN MoMo, Airtel, NIRA, etc.) and confirm written contracts exist per Section 21. **1.8 Cross-border transfer** State whether data is processed or stored outside Uganda. If yes, document adequacy or consent. --- ### Section 2 — Necessity and Proportionality Assessment **2.1 Necessity** Is the data collection necessary for the stated purpose? Could the purpose be achieved with less data or less intrusive means? **2.2 Proportionality** Is the scope of collection proportionate to the legitimate purpose? **2.3 Data minimisation** Confirm that only the minimum necessary data is collected. Flag any field that is not strictly necessary. **2.4 Purpose limitation** Confirm data will not be used for purposes incompatible with the original purpose (Section 17). State research/statistical exceptions if applicable (must not reveal identity). **2.5 Storage limitation** State the retention period and destruction method at expiry. --- ### Section 3 — Risk Assessment Identify and rate each risk using the matrix below. **Risk Rating Matrix:** | Likelihood | Low Impact | Medium Impact | High Impact | |---|---|---|---| | Unlikely | Low | Low | Medium | | Possible | Low | Medium | High | | Likely | Medium | High | Critical | **Risk categories to assess:** | # | Risk | Description | Likelihood | Impact | Rating | |---|---|---|---|---|---| | R-1 | Unauthorised access to S-tier financial data | Mobile money numbers accessed by unauthorised staff | | | | | R-2 | GPS data misuse | Farm location data enables physical targeting of farmers | | | | | R-3 | NIN data breach | Mass NIN exposure creates identity fraud risk | | | | | R-4 | Consent not obtained | Data collected without valid consent; PDPO enforcement risk | | | | | R-5 | Data shared with unauthorised third parties | Farmer data disclosed outside permitted recipients | | | | | R-6 | Breach not notified immediately | PDPO notification delayed; criminal liability for DPO | | | | | R-7 | Data retained beyond retention period | Historical data not destroyed; creates ongoing liability | | | | | R-8 | Children's data collected without guardian consent | Farmers under 18 registered without parental consent | | | | | R-9 | Cross-border storage | Cloud backup transfers data outside Uganda without adequacy or consent | | | | | R-10 | Data subject rights not fulfilled | Requests not responded to within 30 days | | | | Add system-specific risks based on the processing operation being assessed. --- ### Section 4 — Measures to Address Risks For each risk rated Medium, High, or Critical, specify the control measure: | Risk # | Control Measure | FR/NFR Reference | Owner | Status | |---|---|---|---|---| | R-1 | AES-256-GCM encryption + role-based access + access logging | NFR-DPPA-002 | Dev Lead | Planned | | R-2 | GPS stored encrypted; access restricted to Procurement/Finance | NFR-FAR-001 | Dev Lead | Planned | | R-3 | NIN encrypted + masked in display; NIRA validation only via API | NFR-DPPA-002 | Dev Lead | Planned | | R-4 | Consent capture FR at farmer registration; consent record persisted | FR-FAR-xxx | Dev Lead | Planned | | R-5 | API-layer RBAC; data processor contracts signed | NFR-DPPA-005 | Legal | Pending | | R-6 | Breach notification workflow; DPO dashboard alert; auto-generates PDPO notification form | NFR-DPPA-005 | Dev Lead | Planned | | R-7 | Retention schedule enforced; DPO expiry alert; destruction audit log | NFR-DPPA-006 | Dev Lead | Planned | | R-8 | Age verification step in registration; parent/guardian consent prompt for under-18 | FR-FAR-xxx | Dev Lead | Planned | | R-9 | On-premise only; no cloud backup outside Uganda; server location documented | NFR-DPPA-010 | BIRDC IT | Pending | | R-10 | Data subject rights log; 30-day DPO dashboard alert | NFR-DPPA-004 | Dev Lead | Planned | --- ### Section 5 — Residual Risk Assessment After controls: rate residual risk for each item. If any residual risk remains High or Critical, escalate to PDPO consultation (Regulation 12 — high residual risk requires PDPO prior consultation). --- ### Section 6 — PDPO Consultation Determination If any processing operation carries residual high risk that cannot be mitigated internally: - Consult the PDPO before commencing processing - Document the consultation outcome - Obtain PDPO guidance in writing --- ### Section 7 — Sign-off | Role | Name | Date | Signature | |---|---|---|---| | Data Protection Officer | | | | | Consultant / System Architect | Peter Bamuhigire | | | | Client Authorising Officer | | | | --- ## Output Format Generate a `.md` file in `projects/<ProjectName>/09-governance-compliance/dpia/DPIA_<OperationName>_<ProjectName>.md` covering all 7 sections above. Build to `.docx` using: `bash scripts/build-doc.sh projects/<ProjectName>/09-governance-compliance/dpia DPIA_<OperationName>_<ProjectName>` --- ## Validation Checklist Before marking this skill complete: - [ ] Every S-tier field has an explicit control measure - [ ] No residual risk is rated Critical without PDPO consultation recommendation - [ ] Retention period is specified for every data category - [ ] Children's data assessed - [ ] Cross-border transfer status confirmed - [ ] Sign-off table populated (roles at minimum; names/dates pending client) - [ ] `[CONTEXT-GAP: GAP-004]` retained if legal review not yet complete --- ## References - Data Protection and Privacy Act 2019 (No. 9 of 2019) — Section 23 (breach), Section 9 (special data) - Data Protection and Privacy Regulations 2021 — Regulation 12 (DPIA), Regulation 33 (breach notification) - `domains/uganda/references/regulations.md` - `domains/uganda/references/dppa-pii-classification.md` - `uganda-dppa-compliance/SKILL.md` — prerequisite skill
Related Skills
web-app-security-audit
Use when auditing a PHP/JavaScript/HTML web application for security vulnerabilities. Covers configuration, authentication, authorization, input validation, XSS, API security, HTTP headers, and dependency scanning. Produces a severity-rated audit...
vibe-security-skill
Use when designing or reviewing security for a web application, API, or multi-tenant SaaS — produces threat model, abuse case list, auth/authz matrix, and secret handling plan; covers OWASP Top 10 2025 and the AI-code-generation blind spots. Neighbours — api-design-first owns auth model fields, deployment-release-engineering owns secret rotation choreography, ai-security and llm-security own model-specific threats.
network-security
Use when designing, hardening, or auditing network-layer security for self-managed Debian/Ubuntu SaaS infrastructure — firewalls (nftables/UFW), WAF (ModSecurity + OWASP CRS), VPN (WireGuard, OpenVPN, IPsec), TLS/PKI ops, IDS/IPS (Suricata, Fail2ban), zero-trust, SSH hardening, DDoS mitigation, DNS security. Complements web-app-security-audit (app layer) and cicd-devsecops (secrets/CI).
linux-security-hardening
Use when hardening a Debian/Ubuntu server — user/group/sudo hardening, file permission audits, PAM password policy + MFA, AppArmor mandatory access control, auditd system call logging, kernel sysctl hardening, file integrity monitoring (AIDE), rootkit detection (rkhunter/chkrootkit), unattended security patching, GRUB + UEFI + LUKS boot security, and CIS benchmark compliance.
code-safety-scanner
Scan any codebase for 14 critical safety issues across security vulnerabilities, server stability (500 errors), and payment misconfigurations. Use when auditing code before deployment, reviewing AI-generated code for production readiness, or...
world-class-engineering
Use when designing, building, reviewing, or upgrading production software systems that must be secure, performant, maintainable, scalable, and user-centered. Apply before writing specs, code, architecture, APIs, databases, mobile apps, SaaS platforms, or ERP systems.
update-Codex-documentation
Update project documentation files (README.md, PROJECT_BRIEF.md, TECH_STACK.md, ARCHITECTURE.md, docs/API.md, docs/DATABASE.md, AGENTS.md, docs/plans/NEXT_FEATURES.md) when significant changes occur. MANDATORY at end of each work session to...
skill-writing
Use when creating or upgrading skills in this repository. Covers repository-specific frontmatter rules, progressive disclosure, reference-file strategy, validation, and the quality bar required for production-grade engineering skills.
skill-safety-audit
Scan new or updated skills for unsafe or malicious instructions (unknown tools, external installers, credential harvesting) before accepting them into the repository.
skill-composition-standards
Use when authoring a new skill, normalising an older skill, or reviewing a skill PR — defines the repository-wide house style (frontmatter, decision rules, anti-patterns, references), the output contracts each baseline-skill type must produce, and the input contracts each specialist skill must declare. This is the enforcement spine that makes the repository compose as a system, not a library of linked documents.
sdlc-documentation
Use when producing, reviewing, or consolidating SDLC documentation across planning, requirements, design, testing, deployment, user rollout, post-deployment, and maintenance phases. Load absorbed SDLC phase references as needed.
project-requirements
Guided interview to create comprehensive project requirements documentation (requirements.md, business-rules.md, user-types.md, workflows.md) for a new SaaS project. Use before bootstrapping the SaaS Seeder Template.