diff --git a/.github/skills/project-planning/privacy-by-design/SKILL.md b/.github/skills/project-planning/privacy-by-design/SKILL.md new file mode 100644 index 000000000..89b7fa8c1 --- /dev/null +++ b/.github/skills/project-planning/privacy-by-design/SKILL.md @@ -0,0 +1,40 @@ +--- +name: privacy-by-design +description: Privacy assessment reference set for PbD principles, retention/disposal verification, cross-jurisdictional mapping, and codebase signal detection. +license: MIT +user-invocable: false +--- + +# Privacy-by-Design Assessment + +This skill packages the durable privacy-by-design assessment material used by the Privacy Reviewer and Privacy Planner: 7 Foundational Principles assessment criteria, retention and disposal verification checks, cross-jurisdictional obligation mappings (GDPR/APP/CCPA), codebase signal patterns, and structured finding formats with mandatory legal citations. + +## When to use + +Use this skill when you need to: + +* Assess codebases against the 7 Foundational Principles of Privacy by Design with PASS/FAIL/PARTIAL findings and severity ratings. +* Verify data retention periods are purpose-linked and disposal methods meet regulatory requirements under Principle 05. +* Map privacy findings to enforceable obligations across GDPR Art. 25, Australian Privacy Principles (APP 1, 3, 6, 8, 11), and CCPA/CPRA in a single pass. +* Detect applicable codebase signals (consent flows, collection endpoints, storage configs, deletion handlers) to determine skill applicability. +* Emit structured findings with verbatim legal citations for compliance reviewer traceability. + +> [!NOTE] +> This skill complements (does not replace) `privacy-standards`. Load both skills simultaneously: use `privacy-standards` for data-flow reasoning, DPIA thresholds, and the NIST/GDPR/CCPA/OWASP backbone; use THIS skill for principle-by-principle assessment depth and APP coverage. + +## Skill layout + +Load the reference file that matches the assessment phase or topic you need. + +| Reference | Topic | +| :--- | :--- | +| [references/00-index.md](references/00-index.md) | Navigation catalog and consolidated attribution | +| [references/pbd-seven-principles.md](references/pbd-seven-principles.md) | 7 PbD Principles with PASS/FAIL/PARTIAL criteria and severity guidance | +| [references/retention-and-disposal.md](references/retention-and-disposal.md) | Principle 05 lifecycle verification: retention, secure deletion, legal holds | +| [references/cross-jurisdictional-mapping.md](references/cross-jurisdictional-mapping.md) | Principle-to-obligation mapping table for GDPR, APP, and CCPA/CPRA | +| [references/codebase-signals.md](references/codebase-signals.md) | Profiler trigger patterns for consent, collection, storage, and deletion | +| [references/finding-formats.md](references/finding-formats.md) | Structured output schema with mandatory verbatim citation requirements | + +## Attribution + +The durable reference content in this skill is organized by reference file and summarized in [references/00-index.md](references/00-index.md). See that index for consolidated attribution, legal source provenance, and delegation notes. diff --git a/.github/skills/project-planning/privacy-by-design/references/00-index.md b/.github/skills/project-planning/privacy-by-design/references/00-index.md new file mode 100644 index 000000000..a2023296f --- /dev/null +++ b/.github/skills/project-planning/privacy-by-design/references/00-index.md @@ -0,0 +1,28 @@ +--- +title: Privacy-by-Design Assessment Reference Index +--- + +# Privacy-by-Design Assessment Reference Index + +This index is the entry point for the reusable privacy-by-design skill. It summarizes the durable reference files that carry the detailed assessment knowledge consumed by the Privacy Reviewer and Privacy Planner agents. + +## Reference catalog + +| File | Purpose | Source basis | +| :--- | :--- | :--- | +| [pbd-seven-principles.md](pbd-seven-principles.md) | 7 PbD Principles with PASS/FAIL/PARTIAL criteria and severity guidance | Ann Cavoukian’s 7 Foundational Principles of Privacy by Design | +| [retention-and-disposal.md](retention-and-disposal.md) | Principle 05 lifecycle verification: retention, secure deletion, legal holds | GDPR Art. 5(1)(e)/17/32; APP 11.2; CCPA §1798.105(d) | +| [cross-jurisdictional-mapping.md](cross-jurisdictional-mapping.md) | Principle-to-obligation mapping table for GDPR, APP, and CCPA/CPRA | GDPR Art. 25; Australian Privacy Principles 1,3,6,8,11; CCPA/CPRA | +| [codebase-signals.md](codebase-signals.md) | Profiler trigger patterns for consent, collection, storage, and deletion | Codebase signal detection requirements from Issue #2594 | +| [finding-formats.md](finding-formats.md) | Structured output schema with mandatory verbatim citation requirements | Standards-cited findings requirement from Issue #2594 | + +## Usage notes + +- Use this skill for durable assessment knowledge, not for orchestration logic. +- Keep instruction files thin and delegate detailed reference lookups to the skill references. +- Always load `privacy-standards` alongside this skill for data-flow reasoning, DPIA thresholds, and the NIST/GDPR/CCPA/OWASP backbone. +- Every finding emitted MUST include a verbatim legal citation from `cross-jurisdictional-mapping.md`. + +## Attribution + +This skill consolidates Privacy by Design assessment content aligned with Ann Cavoukian’s foundational principles and intentionally complements (does not duplicate) the existing `privacy-standards` skill maintained elsewhere in the repository. Legal source provenance for all citations is documented in `cross-jurisdictional-mapping.md`. diff --git a/.github/skills/project-planning/privacy-by-design/references/codebase-signals.md b/.github/skills/project-planning/privacy-by-design/references/codebase-signals.md new file mode 100644 index 000000000..cc1e3d15e --- /dev/null +++ b/.github/skills/project-planning/privacy-by-design/references/codebase-signals.md @@ -0,0 +1,35 @@ +--- +title: Codebase Signal Detection Patterns +description: Codebase signal framing and profiler trigger guidance for privacy-by-design assessment applicability. +--- + +# Codebase Signal Detection Patterns + +This reference summarizes the codebase signal patterns the Codebase Profiler subagent uses to determine when the privacy-by-design skill is applicable. + +## Signal category framing + +Common signal categories to detect during profiling include: + +- **Consent & Collection** — UI consent flows, opt-in/opt-out toggles, data ingestion endpoints +- **Storage & Retention** — Database schemas with TTL/expiry fields, IaC lifecycle policies, backup configs +- **Deletion & DSR** — Erasure endpoints, anonymization functions, right-to-be-forgotten handlers +- **Transparency & Audit** — Privacy notice files, processing record logs, audit trail configurations +- **Cross-Border Transfer** — Geo-routing logic, data residency configs, international transfer mechanisms + +## Profiler overlay + +When assessing AI/ML components or AI-integrated systems, also consider privacy-specific AI signals such as: + +- Training data provenance and PII presence in datasets +- Model memorization risk indicators (e.g., verbatim training data reproduction) +- Inference endpoint input/output logging containing PII +- RAG pipeline vector store retention and purge mechanisms +- Content filter bypass patterns that may expose sensitive data + +## Mapping usage + +Use the signal-category references to align skill activation with actual codebase evidence. The Profiler should auto-load this skill when ANY signal from any category is detected. Signals are additive; detection of one signal does not exclude others. + +> [!NOTE] +> Signal detection determines *applicability*, not compliance. A detected signal triggers the full PbD assessment pipeline; absence of signals means this skill is not loaded. Always cross-reference detected signals with `pbd-seven-principles.md` for actual PASS/FAIL/PARTIAL assessment. diff --git a/.github/skills/project-planning/privacy-by-design/references/cross-jurisdictional-mapping.md b/.github/skills/project-planning/privacy-by-design/references/cross-jurisdictional-mapping.md new file mode 100644 index 000000000..eaf95ce39 --- /dev/null +++ b/.github/skills/project-planning/privacy-by-design/references/cross-jurisdictional-mapping.md @@ -0,0 +1,50 @@ +--- +title: Cross-Jurisdictional Obligation Mapping +description: Principle-to-obligation mapping patterns and verbatim citation references used by the privacy-by-design skill. +--- + +# Cross-Jurisdictional Obligation Mapping + +This reference captures the enforceable obligation mapping and verbatim citation patterns used in the Privacy Reviewer workflow. + +## Mapping Approach + +Map each PbD principle finding to the most relevant enforceable obligations across GDPR, Australian Privacy Principles (APP), and CCPA/CPRA. Every finding MUST carry at least one verbatim citation from this table. + +Preferred references: + +- GDPR Article 25 (Data Protection by Design and by Default) as primary anchor +- Australian Privacy Principles 1, 3, 6, 8, 11 for APAC coverage +- CCPA/CPRA sections for US consumer privacy rights +- Existing `privacy-standards` skill references for NIST PF and OWASP Privacy Risks backbone + +## Suggested Mapping Output + +Use a compact mapping table like this: + +| PbD Principle | Finding | Jurisdiction | Verbatim Citation | +| :--- | :--- | :--- | :--- | +| 2. Default | Opt-out default for secondary processing | GDPR | gdpr_article_25_2 | +| 5. Lifecycle | No automated deletion after purpose fulfilled | APP | app_11_2 | +| 7. User-Centric | DSR fulfillment exceeds 45-day limit | CCPA | ccpa_1798_105_c | +| 6. Transparency | Processing purposes not disclosed at collection | Multi | gdpr_article_13; app_5_1 | + +## Full Obligation Matrix + +| PbD Principle | GDPR | Australian APP | CCPA/CPRA | +| :--- | :--- | :--- | :--- | +| 1. Proactive | Art. 25(1), Art. 35 | APP 1.2, APP 11.1 | §1798.100(a) | +| 2. Default | Art. 25(2) | APP 3.1, APP 3.2 | §1798.100(b) | +| 3. Embedded | Art. 25(1) | APP 1.2 | §1798.105(d) | +| 4. Positive-Sum | Art. 5(1)(c), Art. 25 | APP 3.1 | §1798.100(a) | +| 5. Lifecycle | Art. 5(1)(e), Art. 17, Art. 32 | APP 11.2 | §1798.105(d) | +| 6. Transparency | Art. 5(1)(a), Art. 12-14 | APP 1.3, APP 5 | §1798.100(a), §1798.110 | +| 7. User-Centric | Art. 7, Art. 15-22 | APP 6, APP 8, APP 12 | §1798.105, §1798.110, §1798.115 | + +## Guidance + +- Keep mappings tied to the actual codebase evidence and principle being assessed. +- Prefer existing `privacy-standards` references over re-embedding full legal text. +- Use the mapping to support compliance reviewer traceability and backlog prioritization. +- When a finding spans multiple jurisdictions, cite ALL applicable obligations separated by semicolon in the finding’s `Citation` field. +- Never paraphrase legal references; use the EXACT verbatim citation format from this table. diff --git a/.github/skills/project-planning/privacy-by-design/references/finding-formats.md b/.github/skills/project-planning/privacy-by-design/references/finding-formats.md new file mode 100644 index 000000000..47f927027 --- /dev/null +++ b/.github/skills/project-planning/privacy-by-design/references/finding-formats.md @@ -0,0 +1,42 @@ +--- +title: Privacy Finding Formats and Citation Requirements +description: Structured finding schema, severity prioritization, and mandatory citation formats for the privacy-by-design skill. +--- + +# Privacy Finding Formats and Citation Requirements + +This reference captures the structured finding formats and citation requirements used to emit privacy assessment results from the Privacy Reviewer agent. + +## Prioritization posture + +Privacy findings should be grouped by: + +- PbD Principle number and name +- Severity rating (CRITICAL/HIGH/MEDIUM/LOW/INFO) +- Affected jurisdiction(s) and legal obligation(s) +- Whether the finding is a direct violation or a gap in evidence/documentation + +## Finding categories + +Use the following categories when classifying or refining findings: + +- Principle violation (active non-compliance) +- Evidence gap (missing documentation or audit trail) +- Configuration drift (policy exists but not enforced in code/config) +- Cross-jurisdictional conflict (compliance in one jurisdiction creates risk in another) +- Lifecycle protection failure (retention/disposal specific; always cite Principle 05) + +## Handoff format + +Every finding MUST use this exact JSON-compatible structure: + +```json +{ + "id": "PBD-{PRINCIPLE_NUMBER}-{NNN}", + "principle": "{Principle X: Name}", + "status": "PASS | FAIL | PARTIAL", + "severity": "CRITICAL | HIGH | MEDIUM | LOW | INFO", + "evidence": "{file:line, config key, or infrastructure resource ID}", + "citation": "{verbatim_legal_reference}; {additional_if_multi_jurisdiction}", + "recommendation": "{actionable remediation with technical specificity}" +} diff --git a/.github/skills/project-planning/privacy-by-design/references/pbd-seven-principles.md b/.github/skills/project-planning/privacy-by-design/references/pbd-seven-principles.md new file mode 100644 index 000000000..b11a4e116 --- /dev/null +++ b/.github/skills/project-planning/privacy-by-design/references/pbd-seven-principles.md @@ -0,0 +1,58 @@ +--- +title: Privacy-by-Design Seven Foundational Principles +description: PbD principle definitions, PASS/FAIL/PARTIAL assessment criteria, severity guidance, and finding ID conventions for privacy assessment. +--- + +# Privacy-by-Design Seven Foundational Principles + +This reference captures the 7 Foundational Principles of Privacy by Design (Dr. Ann Cavoukian), structured assessment criteria, severity guidance, and finding table conventions used during privacy review. + +## PbD Principles + +- **Principle 1: Proactive not Reactive; Preventative not Remedial** — Privacy risks identified and mitigated before deployment +- **Principle 2: Privacy as the Default Setting** — PII protected automatically without user action required +- **Principle 3: Privacy Embedded into Design** — Privacy integral to architecture, not bolted on +- **Principle 4: Full Functionality – Positive-Sum, Not Zero-Sum** — Privacy and functionality coexist without false trade-offs +- **Principle 5: End-to-End Security – Full Lifecycle Protection** — Data secured from collection through secure disposal +- **Principle 6: Visibility and Transparency – Keep it Open** — Processing visible to users and auditors +- **Principle 7: Respect for User Privacy – Keep it User-Centric** — Meaningful consent and full data subject rights support + +## Assessment Criteria + +For each principle, assign exactly one status with supporting evidence: + +| Status | Definition | Severity Default | +| :--- | :--- | :--- | +| PASS | Principle fully satisfied with documented evidence | INFO | +| PARTIAL | Principle partially satisfied; gaps identified but mitigations in progress | MEDIUM | +| FAIL | Principle not satisfied; no evidence or active violation | HIGH | + +> [!WARNING] +> Principle 5 failures default to HIGH severity. Indefinite retention without legal justification escalates to CRITICAL. Always consult `retention-and-disposal.md` for Principle 5 verification. + +## Finding ID Pattern + +Use `PBD-{PRINCIPLE_NUMBER}-{NNN}` for standard findings and `PBD-{PRINCIPLE_NUMBER}-XJ-{NNN}` for cross-jurisdictional findings that map to multiple legal obligations. + +Examples: + +- `PBD-02-001`: Privacy as Default failure in consent flow +- `PBD-05-XJ-003`: Lifecycle protection gap violating both GDPR Art. 17 and APP 11.2 + +## Finding Table Format + +| ID | Principle | Status | Severity | Evidence | Citation | Recommendation | +| :--- | :--- | :--- | :--- | :--- | :--- | :--- | +| PBD-02-001 | 2. Default | FAIL | HIGH | `src/components/CookieBanner.tsx:42` defaults to opt-out | gdpr_article_25_2 | Change default to opt-in; require explicit consent toggle | +| PBD-05-XJ-003 | 5. Lifecycle | PARTIAL | MEDIUM | S3 bucket lacks lifecycle policy; manual deletion only | gdpr_article_17; app_11_2 | Implement automated TTL; add cryptographic erasure for backups | + +## Cross-Jurisdictional Assessment Guidance + +When assessing any principle, always consult `cross-jurisdictional-mapping.md` to identify all applicable legal obligations. A single codebase gap may violate multiple jurisdictions simultaneously — cite ALL applicable sources separated by semicolon in the `Citation` field. + +### Mandatory Verification Points + +- **Principle 2**: Verify opt-in (not opt-out) for all secondary data uses +- **Principle 5**: Always load `retention-and-disposal.md` for detailed checklist +- **Principle 6**: Confirm audit logs exist AND are accessible to compliance reviewers +- **Principle 7**: Test consent withdrawal end-to-end; verify DSR fulfillment within regulatory timelines diff --git a/.github/skills/project-planning/privacy-by-design/references/retention-and-disposal.md b/.github/skills/project-planning/privacy-by-design/references/retention-and-disposal.md new file mode 100644 index 000000000..c951e9952 --- /dev/null +++ b/.github/skills/project-planning/privacy-by-design/references/retention-and-disposal.md @@ -0,0 +1,89 @@ +--- +title: Retention and Disposal Verification (Principle 05) +description: Lifecycle protection checks, retention validation, secure disposal methods, legal hold exceptions, and failure severity guidance for PbD Principle 5. +--- + +# Retention and Disposal Verification (Principle 05) + +This reference captures the detailed verification checklist for Privacy-by-Design Principle 5: End-to-End Security – Full Lifecycle Protection. It is the authoritative source for assessing data retention, secure disposal, and legal hold compliance. + +## Verification Categories + +Principle 05 assessment uses four mandatory check categories: + +- **Retention Period Validation** — Purpose-linked, documented, and enforced +- **Secure Disposal Methods** — Regulatory-compliant deletion across all copies +- **Legal Hold Exception Handling** — Suspension of disposal during active holds +- **Indefinite Retention Justification** — Documented legal basis for no expiry + +## Classification Guidance + +Use this decision order when determining which verification checks apply: + +1. Contains PII or sensitive personal data? → Apply ALL four categories +2. Contains non-PII business data with regulatory retention requirements? → Apply Retention + Disposal + Legal Hold +3. Contains transient/ephemeral data with <24h TTL? → Apply Disposal only +4. Anonymous/aggregated data with no re-identification risk? → Skip Principle 05 entirely + +## Mandatory Checklist + +### Retention Period Validation + +- [ ] Retention period explicitly documented in policy OR code/config +- [ ] Retention period directly linked to stated processing purpose +- [ ] Automated enforcement mechanism exists (TTL, scheduled purge, lifecycle rule) +- [ ] Retention period reviewed and updated within last 12 months +- [ ] No indefinite retention without documented legal justification + +### Secure Disposal Methods + +- [ ] Deletion method matches data sensitivity and storage medium: + - Cryptographic erasure for encrypted-at-rest data + - NIST SP 800-88 compliant overwrite for unencrypted block storage + - Secure API deletion calls for cloud-managed services + - Anonymization/aggregation where physical deletion is infeasible +- [ ] Disposal verified across ALL copies: primary store, backups, caches, replicas, logs +- [ ] Audit trail of disposal actions maintained and tamper-evident +- [ ] Disposal completion confirmed within regulatory timeframe + +### Legal Hold Exception Handling + +- [ ] Mechanism exists to suspend automated disposal on demand +- [ ] Legal hold scope precisely targets affected records/data sets +- [ ] Hold release triggers resumption of normal disposal schedule +- [ ] Hold activation/release logged with authorized approver attribution +- [ ] Held data remains protected under Principle 05 security controls + +### Indefinite Retention Justification + +- [ ] Written legal opinion or regulatory citation supporting indefinite retention +- [ ] Business necessity documented and approved by privacy officer +- [ ] Periodic re-evaluation scheduled (minimum annual) +- [ ] Data minimization applied even under indefinite retention (no excess fields) + +## Failure Severity Matrix + +| Check Category | Missing Check | Default Severity | Escalation Condition | +| :--- | :--- | :--- | :--- | +| Retention Validation | Any unchecked item | HIGH | No documented retention period at all → CRITICAL | +| Secure Disposal | Wrong method or incomplete coverage | HIGH | PII disposed insecurely → CRITICAL | +| Legal Hold | No suspension mechanism | MEDIUM | Active hold ignored; data deleted → CRITICAL | +| Indefinite Retention | No legal justification | CRITICAL | N/A (always CRITICAL) | + +> [!WARNING] +> ANY failure in Principle 05 MUST cite at least one legal obligation from `cross-jurisdictional-mapping.md`. Common citations: `gdpr_article_5_1_e`, `gdpr_article_17`, `gdpr_article_32`, `app_11_2`, `ccpa_1798_105_d`. + +## Assessment Output Template + +Use this format when documenting each Principle 05 finding: + +```markdown +### Principle 05 Finding: {brief-description} + +Status: PASS | PARTIAL | FAIL +Severity: INFO | LOW | MEDIUM | HIGH | CRITICAL +Evidence: {file:line, config key, or infrastructure resource ID} +Citation: {verbatim_legal_reference}; {additional_if_multi_jurisdiction} +Failed Checks: +* {specific unchecked item from Mandatory Checklist} +Recommendation: {actionable remediation with technical specificity}