Back to Details

uganda-dppa-compliance

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Skill: Uganda DPPA 2019 Compliance Requirements

技能：乌干达DPPA 2019合规要求

<!-- dual-compat-start -->
<!-- dual-compat-start -->

Use When

使用场景

  • Generate Uganda DPPA 2019 compliance annex for software collecting personal data. Use for any Uganda-based SaaS to produce SRS compliance sections and flag DPIA triggers.
  • The task needs reusable judgment, domain constraints, or a proven workflow rather than ad hoc advice.
  • 为收集个人数据的软件生成乌干达DPPA 2019合规附件。适用于任何乌干达本地SaaS，用于生成SRS合规章节并标记DPIA触发点。
  • 任务需要可复用的判断逻辑、领域约束或成熟工作流，而非临时建议。

Do Not Use When

禁用场景

  • The task is unrelated to 
    uganda-dppa-compliance
    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.
  • 任务与
    uganda-dppa-compliance
    无关，或更适合由更专业的配套技能处理。
  • 请求仅需要简单答案，本技能的约束条件或参考资料无法提供实质性帮助。

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.
  • 先阅读本
    SKILL.md
    文件，再仅加载任务所需的深度参考文件。
  • 应用本技能中的有序指导、检查清单和决策规则，而非零散挑选片段内容。
  • 交付成果需明确说明假设条件、风险点及后续工作（若相关）。

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

生成的证据

CategoryArtifactFormatExample
Data safetyUganda DPPA compliance annexMarkdown annex covering lawful basis, data subject rights, cross-border transfer, and breach notification per DPPA 2019
docs/compliance/uganda-dppa-annex.md
类别工件格式示例
数据安全乌干达DPPA合规附件涵盖DPPA 2019规定的合法依据、数据主体权利、跨境传输及 breach notification的Markdown附件
docs/compliance/uganda-dppa-annex.md

References

参考资料

  • Use the links and companion skills already referenced in this file when deeper context is needed.
<!-- dual-compat-end -->
  • 如需更深入的上下文，使用本文件中已引用的链接和配套技能。
<!-- dual-compat-end -->

Purpose

目标

Generate a complete Uganda Data Protection and Privacy Act 2019 compliance annex for any Uganda-based software system. The output is a standalone SRS section (or standalone compliance document) covering all legally required system behaviours under the DPPA 2019 and the Data Protection and Privacy Regulations 2021.
Use this skill:
  • As an annex to any SRS section that collects personal data in a Uganda-based system
  • As input to 
    dpia-generator
    when DPIA triggers are identified
  • As a cross-cutting compliance check during Skill 08 (Semantic Auditing)
为任何乌干达本地软件系统生成完整的《乌干达2019年数据保护与隐私法案》（DPPA 2019）合规附件。输出内容为独立的SRS章节（或独立合规文档），涵盖DPPA 2019及《2021年数据保护与隐私条例》规定的所有法定系统行为要求。
本技能可用于：
  • 作为乌干达本地系统中任何收集个人数据的SRS章节的附件
  • 识别到DPIA触发点时，作为
    dpia-generator
    的输入
  • 在技能08（语义审计）期间作为跨领域合规检查工具

Inputs Required

必填输入

Before invoking this skill, read:
  • _context/vision.md
    — system scope and user population
  • _context/features.md
    — module list (to identify which modules collect personal data)
  • _context/personas.md
    — user types who supply personal data
  • _context/glossary.md
    — check that DPPA, PDPO, DPO, NIN, special personal data are defined
  • domains/uganda/references/dppa-pii-classification.md
    — PII classification matrix
调用本技能前，请阅读以下文件：
  • _context/vision.md
    — 系统范围与用户群体
  • _context/features.md
    — 模块列表（用于识别哪些模块收集个人数据）
  • _context/personas.md
    — 提供个人数据的用户类型
  • _context/glossary.md
    — 确认DPPA、PDPO、DPO、NIN、特殊个人数据已定义
  • domains/uganda/references/dppa-pii-classification.md
    — PII分类矩阵

Process

流程

Step 1 — PII Inventory

步骤1 — PII清单

Read all context files. Identify every data field collected by the system. Classify each field as:
  • S — Special personal data (financial information, health, medical, religious/political beliefs, sexual life)
  • P — Personal data (identifiable: NIN, name, photo, GPS, contact)
  • N — Non-personal (aggregates, product data, batch data)
Produce a PII inventory table: field name, source module, tier (S/P/N), justification, retention period.
Uganda-specific alert: Financial information is Special personal data under Section 9 DPPA 2019. This includes: mobile money numbers, salary amounts, bank account details, agent commission amounts, staff loan balances, payment histories. This is a key difference from the GDPR — flag it explicitly in the output.
阅读所有上下文文件。识别系统收集的每个数据字段，并将其分类为：
  • S — 特殊个人数据（财务信息、健康医疗数据、宗教/政治信仰、性生活相关数据）
  • P — 个人数据（可识别信息：NIN、姓名、照片、GPS、联系方式）
  • N — 非个人数据（聚合数据、产品数据、批量数据）
生成PII清单表格：字段名称、来源模块、等级（S/P/N）、分类依据、保留期限。
乌干达特定提醒： 根据DPPA 2019第9条，财务信息属于特殊个人数据。包括：移动货币号码、薪资金额、银行账户详情、代理佣金金额、员工贷款余额、支付记录。这是与GDPR的关键区别 — 需在输出中明确标记。

Step 2 — Lawful Basis Mapping

步骤2 — 合法依据映射

For each S and P field, identify the applicable lawful basis from Section 7 DPPA 2019:
  • Consent (must be freely given, specific, informed, unambiguous)
  • Authorised or required by law (cite the specific enactment)
  • Proper performance of a public duty by a public body
  • National security
  • Prevention/detection/investigation/prosecution of an offence
  • Performance of a contract
  • Medical purposes
  • Compliance with a legal obligation
针对每个S级和P级字段，从DPPA 2019第7条中识别适用的合法依据：
  • 同意（必须是自由给予、具体明确、知情且无歧义的）
  • 法律授权或要求（引用具体法规）
  • 公共机构适当履行公共职责
  • 国家安全
  • 预防/侦查/调查/起诉犯罪
  • 履行合同
  • 医疗目的
  • 遵守法律义务

Step 3 — Consent Requirements

步骤3 — 同意要求

For every field where lawful basis = consent, generate FR requirements for:
  • Consent capture at point of collection (before data is recorded)
  • Consent record storage: data subject ID, purpose, data categories, timestamp, collector ID
  • Withdrawal mechanism (as easy as giving consent — Section 7(3))
  • Notice at collection: purpose, right to access/rectify (Section 13)
  • For children's data: age verification and parent/guardian consent (Section 8 + Regulation 11)
针对所有合法依据为“同意”的字段，生成功能需求（FR）：
  • 数据收集时获取同意（记录数据前）
  • 同意记录存储：数据主体ID、用途、数据类别、时间戳、收集者ID
  • 撤回机制（与给予同意同样简便 — 第7(3)条）
  • 收集时的告知：用途、访问/更正权利（第13条）
  • 儿童数据：年龄验证及家长/监护人同意（第8条 + 条例第11条）

Step 4 — Data Subject Rights

步骤4 — 数据主体权利

Generate FRs for all four Section 14–16 rights:
  1. Right of Access (Section 14): Data subject may request a copy of all personal data held
  2. Right to Object (Section 15): Data subject may object to collection/processing; system must stop unless Section 7(2) exception applies
  3. Right to Rectification/Erasure (Section 16): Correct/delete inaccurate, irrelevant, excessive, out-of-date, incomplete, misleading, or unlawfully obtained data; 30-day response window; written rejection with reasons if unable to comply
  4. Notification to third parties: Where data has been rectified/erased, notify third parties to whom data was previously disclosed (Section 28(4))
Generate a data subject rights request log schema (see 
dppa-pii-classification.md
).
针对第14–16条规定的四项权利生成功能需求：
  1. 访问权（第14条）：数据主体可请求获取其所有个人数据副本
  2. 反对权（第15条）：数据主体可反对数据收集/处理；除非适用第7(2)条例外情况，否则系统必须停止处理
  3. 更正/删除权（第16条）：更正/删除不准确、无关、过度、过期、不完整、误导性或非法获取的数据；30天响应窗口；若无法合规需书面拒绝并说明理由
  4. 通知第三方：若数据已被更正/删除，需通知之前披露数据的第三方（第28(4)条）
生成数据主体权利请求日志 schema（参考
dppa-pii-classification.md
）。

Step 5 — Security and Technical Measures

步骤5 — 安全与技术措施

Generate NFRs covering Section 20 requirements:
  • AES-256-GCM for S-tier fields at rest
  • AES-128+ for P-tier fields at rest
  • TLS 1.3 for all data in transit
  • Access control: S-tier fields restricted to named roles; every access logged
  • Risk identification, safeguard establishment, verification, and update cycle
  • Data processor contract clause: written contract requiring confidentiality and security measures (Section 21)
生成涵盖第20条要求的非功能需求（NFR）：
  • 静态存储的S级字段采用AES-256-GCM加密
  • 静态存储的P级字段采用AES-128+加密
  • 所有传输中的数据采用TLS 1.3
  • 访问控制：S级字段仅限指定角色访问；所有访问操作需记录日志
  • 风险识别、防护措施建立、验证及更新周期
  • 数据处理方合同条款：书面合同要求保密及安全措施（第21条）

Step 6 — Retention and Destruction

步骤6 — 保留与销毁

For each data category, generate:
  • Configurable retention period (per data type, not hardcoded)
  • Automated expiry alert to DPO
  • Destruction method: de-identification (preferred) or destruction preventing reconstruction in intelligible form (Section 18(4)-(5))
  • Exception: historical/statistical/research retention with identity protection
针对每个数据类别生成：
  • 可配置的保留期限（按数据类型设置，而非硬编码）
  • 自动向DPO发送过期提醒
  • 销毁方式：去标识化（首选）或无法还原为可理解形式的销毁（第18(4)-(5)条）
  • 例外情况：用于历史/统计/研究目的的保留，需保护身份信息

Step 7 — Breach Notification Workflow

步骤7 — 数据泄露通知流程

Generate FRs for the breach notification procedure (Section 23 + Regulation 33):
  • Trigger: Detection of unauthorised access or acquisition of personal data
  • Immediate action: System shall flag the breach event and surface it to DPO dashboard
  • Notification content required: nature of breach, data categories involved, approximate number of data subjects, likely consequences, remedial measures taken and proposed, DPO contact details
  • Timeline: IMMEDIATE (Uganda Act — no 72-hour window like GDPR)
  • Who is notified: PDPO first; PDPO then decides and directs whether data subjects must be notified and by what method (registered mail, email, website, or mass media)
  • DPO receives guidance from PDPO on managing the breach
Distinguish from GDPR: controller does NOT decide independently whether to notify data subjects — PDPO makes this determination.
针对泄露通知流程生成功能需求（第23条 + 条例第33条）：
  • 触发条件：检测到个人数据被未授权访问或获取
  • 立即行动：系统需标记泄露事件并在DPO仪表板中显示
  • 通知内容要求：泄露性质、涉及的数据类别、受影响数据主体的大致数量、可能的后果、已采取及拟采取的补救措施、DPO联系方式
  • 时间要求：立即（乌干达法案无GDPR的72小时窗口期）
  • 通知对象：首先通知PDPO；由PDPO决定并指导是否及通过何种方式（挂号信、电子邮件、网站或大众媒体）通知数据主体
  • DPO需接受PDPO的指导以管理泄露事件
与GDPR的区别：数据控制者无权独立决定是否通知数据主体 — 该决定权归PDPO所有。

Step 8 — DPIA Trigger Assessment

步骤8 — DPIA触发点评估

Assess whether any processing operation in this system triggers a mandatory DPIA under Regulation 12:
  • Large-scale processing of special personal data
  • Systematic monitoring of individuals
  • Use of new technologies affecting rights and freedoms
If DPIA is triggered: flag with 
[DPIA-REQUIRED: <reason>]
and recommend invoking 
dpia-generator
skill.
评估系统中的任何处理操作是否触发条例第12条规定的强制性DPIA：
  • 大规模处理特殊个人数据
  • 对个人进行系统性监控
  • 使用影响权利与自由的新技术
若触发DPIA：标记
[DPIA-REQUIRED: <reason>]
并建议调用
dpia-generator
技能。

Step 9 — DPO and PDPO Registration Requirements

步骤9 — DPO与PDPO注册要求

Generate system requirements:
  • Store DPO designation: name, role, email, phone (Section 6 + Regulation 47)
  • Store PDPO registration number (Regulation 15-16)
  • DPO dashboard: data subject rights requests overdue (>30 days), consent records, breach events, retention expiry alerts
  • System configuration warning displayed until PDPO registration number is entered
生成系统需求：
  • 存储DPO指定信息：姓名、职位、电子邮件、电话（第6条 + 条例第47条）
  • 存储PDPO注册号（条例第15-16条）
  • DPO仪表板：逾期（>30天）的数据主体权利请求、同意记录、泄露事件、保留期限过期提醒
  • 未输入PDPO注册号时显示系统配置警告

Step 10 — Cross-border Transfer Controls

步骤10 — 跨境传输控制

If the system stores or processes data outside Uganda:
  • Configuration record confirming destination country adequacy, OR
  • Explicit data subject consent recorded for each transfer (Section 19 + Regulation 30)
For on-premise Uganda-only deployments: confirm no data leaves Uganda and document this.
若系统在乌干达境外存储或处理数据：
  • 配置记录确认目标国家的合规性，OR
  • 记录每次传输的明确数据主体同意（第19条 + 条例第30条）
对于仅在乌干达本地部署的系统：确认数据未离开乌干达并记录该情况。

Output Structure

输出结构

Generate the following sections in the target document:
undefined
在目标文档中生成以下章节：
undefined

Section X — Data Protection and Privacy Compliance (DPPA 2019)

第X章 — 数据保护与隐私合规（DPPA 2019）

X.1 PII Inventory and Classification

X.1 PII清单与分类

[Table: field, module, tier S/P/N, lawful basis, retention period]
[表格：字段、模块、等级S/P/N、合法依据、保留期限]

X.2 Special Personal Data Alert

X.2 特殊个人数据提醒

[Uganda-specific: list all S-tier fields; note financial information as special category]
[乌干达特定内容：列出所有S级字段；注明财务信息属于特殊类别]

X.3 Consent Requirements

X.3 同意要求

[FR table: consent capture, notice, children's safeguard, withdrawal]
[FR表格：同意获取、告知、儿童保护措施、撤回机制]

X.4 Data Subject Rights Implementation

X.4 数据主体权利实施

[FR table: access, object, rectify/erase, 30-day SLA, written rejection, third-party notification]
[FR表格：访问、反对、更正/删除、30天SLA、书面拒绝、第三方通知]

X.5 Security and Technical Measures

X.5 安全与技术措施

[NFR table: encryption tiers, TLS, access control, processor contracts]
[NFR表格：加密等级、TLS、访问控制、处理方合同]

X.6 Retention and Destruction Schedule

X.6 保留与销毁计划

[Table: data category, retention period, destruction method]
[表格：数据类别、保留期限、销毁方式]

X.7 Data Breach Notification Procedure

X.7 数据泄露通知流程

[FR: detection trigger → DPO dashboard → immediate PDPO notification → await PDPO direction → notify data subjects if directed]
[FR：检测触发 → DPO仪表板 → 立即通知PDPO → 等待PDPO指导 → 若收到通知则告知数据主体]

X.8 DPIA Assessment

X.8 DPIA评估

[DPIA-REQUIRED flags if triggered; otherwise confirmation that no DPIA is required]
[若触发则标记DPIA-REQUIRED；否则确认无需DPIA]

X.9 DPO and PDPO Registration

X.9 DPO与PDPO注册

[FR: DPO record, PDPO registration number, DPO dashboard]
[FR：DPO记录、PDPO注册号、DPO仪表板]

X.10 Cross-border Transfer Controls

X.10 跨境传输控制

[NFR: confirmation of Uganda-only storage or adequacy documentation]
[NFR：确认仅在乌干达存储或提供合规性文档]

X.11 Human Review Gate

X.11 人工评审节点

[List all [CONTEXT-GAP] flags; list all [DPIA-REQUIRED] flags; confirm legal review status of GAP-004 type items]

---
[列出所有[CONTEXT-GAP]标记；列出所有[DPIA-REQUIRED]标记；确认GAP-004类项目的法律评审状态]

---

Validation Checklist

验证检查清单

Before marking this skill complete, confirm:
  • Every module that collects data has at least one field in the PII inventory
  • Every S-tier field has AES-256-GCM encryption specified in Section X.5
  • Every mobile money number is classified as S-tier (financial information)
  • Breach notification is labelled IMMEDIATE (not 72 hours)
  • Data subject rights response SLA is 30 days (not 1 month — use "30 calendar days")
  • PDPO — not the data controller — decides whether to notify data subjects of a breach
  • DPIA assessment is explicit: either DPIA-REQUIRED flag or confirmed not triggered
  • DPO record requirement is generated
  • PDPO registration requirement is generated
  • Children's data safeguard generated if any persona may be under 18
标记本技能完成前，请确认：
  • 所有收集数据的模块在PII清单中至少有一个字段
  • 所有S级字段在X.5章节中指定了AES-256-GCM加密
  • 所有移动货币号码被分类为S级（财务信息）
  • 数据泄露通知标记为“立即”（非72小时）
  • 数据主体权利响应SLA为30天（使用“30日历天”而非“1个月”）
  • 由PDPO而非数据控制者决定是否通知数据主体泄露事件
  • DPIA评估明确：要么标记DPIA-REQUIRED，要么确认未触发
  • 生成了DPO记录要求
  • 生成了PDPO注册要求
  • 若存在未满18岁的用户角色，生成了儿童数据保护措施

Fail Tags

失败标记

  • [DPPA-FAIL: S-tier field not encrypted]
    — special personal data field without AES-256-GCM specification
  • [DPPA-FAIL: no consent mechanism]
    — personal data collected without lawful basis or consent FR
  • [DPPA-FAIL: breach notification > immediate]
    — breach notification SLA longer than immediate
  • [DPPA-FAIL: no data subject rights FR]
    — module collects personal data but has no corresponding rights FRs
  • [DPIA-REQUIRED: <reason>]
    — processing operation triggers mandatory DPIA
  • [CONTEXT-GAP: GAP-004]
    — Uganda DPPA 2019 legal review not yet commissioned
  • [DPPA-FAIL: S-tier field not encrypted]
    — 特殊个人数据字段未指定AES-256-GCM加密
  • [DPPA-FAIL: no consent mechanism]
    — 收集个人数据但未提供合法依据或同意相关FR
  • [DPPA-FAIL: breach notification > immediate]
    — 数据泄露通知SLA长于“立即”
  • [DPPA-FAIL: no data subject rights FR]
    — 模块收集个人数据但未生成对应的权利FR
  • [DPIA-REQUIRED: <reason>]
    — 处理操作触发强制性DPIA
  • [CONTEXT-GAP: GAP-004]
    — 乌干达DPPA 2019法律评审尚未启动

References

参考资料

  • Uganda Data Protection and Privacy Act 2019 (No. 9 of 2019)
  • Data Protection and Privacy Regulations 2021
  • domains/uganda/references/regulations.md
    — full section reference
  • domains/uganda/references/dppa-pii-classification.md
    — PII classification matrix and schemas
  • domains/uganda/INDEX.md
    — key DPPA differences from GDPR
  • 《乌干达2019年数据保护与隐私法案》（第9号法案）
  • 《2021年数据保护与隐私条例》
  • domains/uganda/references/regulations.md
    — 完整章节参考
  • domains/uganda/references/dppa-pii-classification.md
    — PII分类矩阵与schema
  • domains/uganda/INDEX.md
    — DPPA与GDPR的关键差异