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..1b41cae55 --- /dev/null +++ b/.github/skills/project-planning/privacy-by-design/SKILL.md @@ -0,0 +1,173 @@ +--- +name: privacy-by-design +description: "Privacy by Design (PbD) knowledge base for assessing proactive privacy practices against the 7 Foundation Principles, with data retention and disposal lifecycle checks and cross-jurisdictional mappings (GDPR, CCPA, APP)." +license: mixed +user-invocable: false +metadata: + authors: "Ann Cavoukian (IPC Ontario — 7 Foundation Principles); GDPR Art. 25 (Data Protection by Design and by Default); OAIC (Australian Privacy Principles); Microsoft (planning synthesis)" + spec_version: "1.0" + framework_revision: "1.0.0" + last_updated: "2026-08-09" + content_based_on: "https://www.ipc.on.ca/wp-content/uploads/resources/7foundationalprinciples.pdf; https://gdpr-info.eu/art-25-gdpr/; https://www.oaic.gov.au/privacy/australian-privacy-principles" +--- + +# Privacy by Design — Skill Entry + +This `SKILL.md` is the **entrypoint** for the Privacy by Design skill. + +The skill encodes the **7 Foundation Principles of Privacy by Design** (Cavoukian, 2009) as structured, machine-readable references that the Privacy Planner and Privacy Reviewer agents can query to identify, assess, and improve adherence to proactive privacy practices across the software lifecycle. It extends the existing `privacy-standards` skill with principle-level assessment criteria, data retention and disposal checklists, cross-jurisdictional regulatory mappings, a structured finding schema, and pragmatic implementation patterns for code-level verification. + +> [!NOTE] +> This skill is a planning aid, not legal advice. Its standards summaries support privacy reasoning and review preparation; they do not substitute for qualified legal counsel or a formal regulatory interpretation. + +## Goal + +Produce a structured, evidence-based assessment of a system, feature, or data flow against the 7 PbD Foundation Principles, yielding per-principle PASS/FAIL/PARTIAL verdicts, severity-rated findings, actionable remediation guidance, and a backlog-ready handoff. + +## Success criteria + +- All 7 principles are assessed with a recorded verdict and severity. +- Each FAIL or PARTIAL finding includes a specific, actionable remediation. +- Findings use the structured schema defined in `finding-schema.md`. +- Cross-jurisdictional obligations are identified for the applicable regulatory scope. +- Retention and disposal are assessed for any system that stores personal data. +- An overall compliance verdict (COMPLIANT / PARTIALLY_COMPLIANT / NON_COMPLIANT) is determined. + +## When to use this skill + +Use when you need to: + +- Assess a system, feature, or data flow against the 7 PbD Foundation Principles +- Verify that privacy is embedded proactively (not bolted on after incidents) +- Check data retention schedules, disposal methods, and legal hold procedures +- Map privacy requirements across GDPR Art. 25, CCPA/CPRA, and Australian Privacy Principles +- Generate per-principle PASS/FAIL/PARTIAL findings with severity ratings +- Identify code-level and configuration-level privacy patterns or anti-patterns +- Produce backlog items from privacy assessment findings + +Do not use for: + +- General privacy standards mapping without principle assessment (use `privacy-standards`) +- Security threat modeling (use `security-planning` or OWASP skills) +- RAI assessment (use `rai-planner`) +- Legal advice or regulatory compliance certification + +## Stop rules + +- Stop the assessment if the system boundary cannot be established. +- Stop and escalate if processing occurs in a jurisdiction not covered by this skill's mappings. +- Do not fabricate evidence; record INSUFFICIENT EVIDENCE and note what is needed. +- Do not provide legal opinions; frame all findings as planning guidance requiring qualified review. +- Do not duplicate security findings that the `security-planning` skill already covers; cross-reference them. + +## Normative references (PbD 7 Foundation Principles) + +1. [00 Principle Index](references/00-principle-index.md) +2. [01 Proactive Not Reactive](references/01-proactive-not-reactive.md) +3. [02 Privacy as the Default](references/02-privacy-as-the-default.md) +4. [03 Privacy Embedded into Design](references/03-privacy-embedded-into-design.md) +5. [04 Full Functionality](references/04-full-functionality.md) +6. [05 End-to-End Security](references/05-end-to-end-security.md) +7. [06 Visibility and Transparency](references/06-visibility-and-transparency.md) +8. [07 Respect for User Privacy](references/07-respect-for-user-privacy.md) + +## Operational references + +- [Assessment Protocol](references/assessment-protocol.md) — step-by-step protocol for conducting a PbD assessment +- [Finding Schema](references/finding-schema.md) — structured output format for findings and backlog handoff +- [Implementation Patterns](references/implementation-patterns.md) — pragmatic code-level and architecture-level verification patterns + +## Supplementary references + +- [Data Retention and Disposal](references/data-retention-and-disposal.md) — Principle 05 deep-dive: retention schedules, disposal methods, legal holds +- [Cross-Jurisdictional Mapping](references/cross-jurisdictional-mapping.md) — regulatory equivalence matrix across GDPR, CCPA/CPRA, and APP +- [Industry Privacy Profiles](references/industry-privacy-profiles.md) — sector-specific principle priorities, checks, and `.pbd-config.yml` customization + +## Skill layout + +- `SKILL.md` — this file (skill entrypoint). +- `references/` — the PbD normative documents, operational guides, and supplementary material. + - `00-principle-index.md` — index of all principle identifiers, categories, source mappings, and cross-references. + - `01` through `07` — one document per PbD Foundation Principle with checklist, controls, anti-patterns, and regulatory mappings. + - `assessment-protocol.md` — phased assessment protocol for agents conducting PbD reviews. + - `finding-schema.md` — YAML-based finding and summary schema for structured output. + - `implementation-patterns.md` — code-level and configuration-level patterns agents can verify. + - `data-retention-and-disposal.md` — Principle 05 deep-dive: retention schedules, disposal methods, legal holds. + - `cross-jurisdictional-mapping.md` — regulatory equivalence matrix across GDPR, CCPA/CPRA, and APP. + - `industry-privacy-profiles.md` — telco, healthcare, financial sector profiles with `.pbd-config.yml` customization schema. + +## Citation-field vocabulary + +Use these fields when capturing a finding so the reviewer can assert a stable source-control reference: + +- `pbd_principle`: Principle number (1–7) with short name, e.g., `PbD-01 Proactive Not Reactive` +- `gdpr_article`: GDPR article reference, e.g., `Art. 25` +- `app_principle`: Australian Privacy Principle number, e.g., `APP 1` +- `ccpa_section`: CCPA/CPRA section reference + +## Finding severity conventions + +| Severity | Meaning | +|----------|---------| +| HIGH | Principle is violated with direct risk to data subjects | +| MEDIUM | Principle is partially met; gaps exist that could lead to non-compliance | +| LOW | Minor gap; principle intent is largely met but documentation or controls could improve | + +## Finding verdict conventions + +| Verdict | Meaning | +|---------|---------| +| PASS | Principle is fully satisfied with observable evidence | +| PARTIAL | Some indicators met but gaps remain | +| FAIL | Principle is not satisfied; corrective action required | + +## Overall assessment verdicts + +| Verdict | Condition | +|---------|-----------| +| COMPLIANT | All 7 principles are PASS | +| PARTIALLY_COMPLIANT | No principles are FAIL but one or more are PARTIAL | +| NON_COMPLIANT | One or more principles are FAIL | + +## Integration with Privacy Planner and Reviewer + +This skill complements `privacy-standards` (which provides NIST PF, GDPR, CCPA, OWASP backbone). The Privacy Reviewer agent loads both skills: + +- `privacy-standards` — standards mapping, data-flow reasoning, DPIA thresholds +- `privacy-by-design` — principle-level assessment, retention/disposal checks, cross-jurisdictional equivalence, implementation pattern verification + +No agent modification is required; the agent loads this skill on demand when PbD assessment is invoked. + +## Interaction with other skills + +| Skill | Relationship | +|-------|--------------| +| `privacy-standards` | Provides data inventory, DPIA thresholds, and standards backbone; PbD builds on top | +| `security-planning` | Security controls overlap with PbD-05; reference rather than duplicate | +| `rai-planner` | RAI data-use concerns feed into PbD-04 (full functionality) and PbD-07 (user respect) | +| `secure-by-design` | SBD-11 (Secure Deprecation) aligns with PbD-05 lifecycle; cross-reference for decommissioning | + +## Attribution and licensing posture + +### Cavoukian PbD Foundation Principles + +- **Author**: Dr. Ann Cavoukian, Information and Privacy Commissioner of Ontario +- **Source**: +- **Modifications**: Principles restructured into agent-consumable assessment checklists with cross-references to GDPR, CCPA, and APP; original principle text paraphrased with attribution +- **Note**: The 7 Foundation Principles are widely referenced in academic and regulatory literature; content here is paraphrased for planning use + +### GDPR Art. 25 (Data Protection by Design and by Default) + +- **Source**: +- **Modifications**: Mapped to PbD principles as regulatory equivalence; paraphrased with attribution + +### Australian Privacy Principles (APP) + +- **Source**: +- **Copyright**: © Commonwealth of Australia +- **Modifications**: Mapped to PbD principles as cross-jurisdictional equivalence; paraphrased with attribution + +### CCPA/CPRA + +- **Source**: +- **Modifications**: Mapped to PbD principles as cross-jurisdictional equivalence; paraphrased with attribution diff --git a/.github/skills/project-planning/privacy-by-design/references/00-principle-index.md b/.github/skills/project-planning/privacy-by-design/references/00-principle-index.md new file mode 100644 index 000000000..c0254026a --- /dev/null +++ b/.github/skills/project-planning/privacy-by-design/references/00-principle-index.md @@ -0,0 +1,84 @@ +--- +title: Index of Privacy by Design Principles +description: Index of PbD principle identifiers, categories, regulatory mappings, and cross-references +--- + +# Index of Privacy by Design Principles + +This document provides the index for the 7 Foundation Principles of Privacy by Design (Cavoukian, 2009). Each entry maps to regulatory equivalents across GDPR, CCPA/CPRA, and Australian Privacy Principles. + +## Principle catalog + +| ID | Title | Category | GDPR Mapping | APP Mapping | CCPA/CPRA Mapping | +|--------|-------------------------------|---------------------------|------------------------|-----------------|---------------------| +| PbD-01 | Proactive Not Reactive | Prevention | Art. 25(1) | APP 1.2 | §1798.100 | +| PbD-02 | Privacy as the Default | Default Settings | Art. 25(2) | APP 3, APP 5 | §1798.100(b) | +| PbD-03 | Privacy Embedded into Design | Architecture | Art. 25(1) | APP 1.2 | §1798.100 | +| PbD-04 | Full Functionality | Positive-Sum | Art. 25(1) | APP 1.2 | §1798.100 | +| PbD-05 | End-to-End Security | Lifecycle Protection | Art. 25(1), Art. 32 | APP 11 | §1798.100(e) | +| PbD-06 | Visibility and Transparency | Openness | Art. 12–14 | APP 1, APP 5 | §1798.100(a) | +| PbD-07 | Respect for User Privacy | User-Centricity | Art. 12–22 | APP 6, APP 12 | §1798.120, §1798.185 | + +## Cross-reference matrix + +Each principle document follows a consistent structure: + +1. Source mapping — Cavoukian original description and regulatory equivalents. +2. Description — what the principle covers and why it matters. +3. Principle checklist — observable indicators that the system adheres to the principle. +4. Controls and mitigations — defensive measures and implementation guidance. +5. Anti-patterns — common violations that indicate non-adherence. +6. Regulatory cross-references — mapped articles and sections from GDPR, APP, and CCPA/CPRA. + +## Category groupings + +### Prevention + +- PbD-01 Proactive Not Reactive + +### Default Settings + +- PbD-02 Privacy as the Default + +### Architecture + +- PbD-03 Privacy Embedded into Design + +### Positive-Sum + +- PbD-04 Full Functionality + +### Lifecycle Protection + +- PbD-05 End-to-End Security + +### Openness + +- PbD-06 Visibility and Transparency + +### User-Centricity + +- PbD-07 Respect for User Privacy + +## Supplementary documents + +- [Data Retention and Disposal](data-retention-and-disposal.md) — deep-dive into Principle 05 lifecycle obligations +- [Cross-Jurisdictional Mapping](cross-jurisdictional-mapping.md) — regulatory equivalence matrix + +## Source framework + +### Cavoukian 7 Foundation Principles (2009) + +Source: Dr. Ann Cavoukian, Information and Privacy Commissioner of Ontario. + +The 7 Foundation Principles represent a proactive approach to privacy that anticipates and prevents privacy-invasive events before they happen, rather than waiting for risks to materialize: + +1. Proactive Not Reactive; Preventative Not Remedial +2. Privacy as the Default Setting +3. Privacy Embedded into Design +4. Full Functionality — Positive-Sum, Not Zero-Sum +5. End-to-End Security — Full Lifecycle Protection +6. Visibility and Transparency — Keep It Open +7. Respect for User Privacy — Keep It User-Centric + +Content paraphrased from the original publication with attribution. Source: diff --git a/.github/skills/project-planning/privacy-by-design/references/01-proactive-not-reactive.md b/.github/skills/project-planning/privacy-by-design/references/01-proactive-not-reactive.md new file mode 100644 index 000000000..6ca8623fa --- /dev/null +++ b/.github/skills/project-planning/privacy-by-design/references/01-proactive-not-reactive.md @@ -0,0 +1,64 @@ +--- +title: 'PbD-01: Proactive Not Reactive; Preventative Not Remedial' +description: Privacy by Design reference for anticipating and preventing privacy-invasive events before they occur +--- + +# 01 Proactive Not Reactive + +Identifier: PbD-01 +Category: Prevention + +## Source mapping + +- **Cavoukian Principle 1** — Proactive Not Reactive; Preventative Not Remedial +- **GDPR Art. 25(1)** — Data protection by design requiring appropriate technical and organisational measures +- **APP 1.2** — Open and transparent management of personal information +- **CCPA §1798.100** — Consumer right to know and business obligation to disclose + +## Description + +Privacy by Design anticipates and prevents privacy-invasive events before they happen. It does not wait for privacy risks to materialize, nor does it offer remedies for resolving privacy infractions once they have occurred. The approach requires organizations to act before the fact — building privacy protections into systems, processes, and business practices from the outset. + +This principle shifts the organizational mindset from reactive incident response to proactive privacy architecture. Privacy risks are identified, assessed, and mitigated during design rather than discovered during post-deployment audits or breach investigations. + +## Principle checklist + +- Privacy impact assessments or reviews are conducted before system design decisions are finalized. +- Privacy risks are identified and documented during requirements gathering, not after deployment. +- A privacy threat model or risk register exists and is maintained throughout the project lifecycle. +- Privacy requirements are included in acceptance criteria for features involving personal data. +- There is a defined process for identifying new privacy risks when functionality changes. +- The team does not rely solely on incident response or breach notification as privacy controls. +- Privacy monitoring and telemetry detect potential issues before they affect data subjects. + +## Controls and mitigations + +1. Conduct a Privacy Impact Assessment (PIA) or Data Protection Impact Assessment (DPIA) before any new processing activity involving personal data. +2. Include privacy criteria in design review checklists and architecture decision records. +3. Maintain a privacy risk register updated at each design milestone. +4. Integrate privacy checks into CI/CD pipelines (e.g., data classification scanning, PII detection). +5. Establish privacy-specific threat modeling sessions alongside security threat modeling. +6. Define privacy acceptance criteria in user stories that involve personal data handling. +7. Monitor for privacy-relevant anomalies (unusual data access patterns, consent rate changes). + +## Anti-patterns + +- Privacy is considered only after a regulatory complaint or breach occurs. +- No privacy review exists in the design or architecture phase. +- Privacy requirements are treated as "nice to have" and deferred to future sprints. +- The only privacy control is a breach notification procedure. +- Privacy risks are identified exclusively through external audits rather than internal proactive review. +- Data collection decisions are made without assessing necessity or proportionality upfront. + +## Regulatory cross-references + +| Regulation | Reference | Relevance | +|------------|-----------|-----------| +| GDPR | Art. 25(1) | Requires implementing appropriate measures at the time of determination of means of processing | +| GDPR | Art. 35 | DPIA required for high-risk processing before processing begins | +| APP | APP 1.2 | Entities must take reasonable steps to implement practices that ensure compliance | +| CCPA/CPRA | §1798.100 | Businesses must inform consumers at or before point of collection | + +--- + +Content paraphrased from Dr. Ann Cavoukian's 7 Foundation Principles of Privacy by Design (2009) with attribution. Regulatory mappings are planning references, not legal interpretations. diff --git a/.github/skills/project-planning/privacy-by-design/references/02-privacy-as-the-default.md b/.github/skills/project-planning/privacy-by-design/references/02-privacy-as-the-default.md new file mode 100644 index 000000000..5a922a829 --- /dev/null +++ b/.github/skills/project-planning/privacy-by-design/references/02-privacy-as-the-default.md @@ -0,0 +1,69 @@ +--- +title: 'PbD-02: Privacy as the Default Setting' +description: Privacy by Design reference for ensuring personal data is automatically protected in any system without requiring individual action +--- + +# 02 Privacy as the Default + +Identifier: PbD-02 +Category: Default Settings + +## Source mapping + +- **Cavoukian Principle 2** — Privacy as the Default Setting +- **GDPR Art. 25(2)** — Data protection by default +- **APP 3** — Collection of solicited personal information (purpose limitation) +- **APP 5** — Notification of collection of personal information +- **CCPA §1798.100(b)** — Business shall not collect additional categories without notice + +## Description + +Privacy as the Default ensures that personal data is automatically protected in any IT system or business practice. If an individual does nothing, their privacy remains intact. No action is required on the part of the individual to protect their privacy — it is built into the system by default. + +This principle mandates that only data necessary for the specific purpose is collected, used, and retained. Default settings must be the most privacy-protective options, with users explicitly opting in to less private configurations rather than having to opt out of invasive ones. + +## Principle checklist + +- Default settings collect only the minimum data necessary for the stated purpose. +- Users do not need to take action to protect their privacy; protection is automatic. +- Data collection forms and APIs default to the least-invasive option. +- Optional data fields are clearly distinguished from required fields. +- Consent mechanisms default to "not consented" (opt-in, not opt-out). +- Data sharing with third parties is disabled by default. +- Retention periods are set to the minimum necessary by default, not maximum allowed. +- Analytics and telemetry default to aggregated or anonymized collection. + +## Controls and mitigations + +1. Implement opt-in consent for any data collection beyond what is strictly necessary for service delivery. +2. Configure data retention policies to automatically delete or anonymize data at the earliest permissible point. +3. Set API default parameters to return minimal data (e.g., pagination limits, field filtering). +4. Design user interfaces so that the most privacy-protective option requires the least effort. +5. Disable telemetry identifiers, tracking cookies, and behavioral profiling by default. +6. Require explicit user action to enable data sharing, public profiles, or social features. +7. Review and document default settings in privacy documentation and release notes. + +## Anti-patterns + +- Pre-checked consent boxes or opt-out rather than opt-in consent. +- Default data collection includes fields not needed for the primary purpose. +- User profiles are public by default. +- Analytics track individual behavior by default with anonymization available only as an opt-in setting. +- Maximum retention periods are the default rather than minimum necessary. +- Third-party data sharing is enabled without explicit user consent. +- Dark patterns that make privacy-protective choices harder to find or select. + +## Regulatory cross-references + +| Regulation | Reference | Relevance | +|------------|-----------|-----------| +| GDPR | Art. 25(2) | Only personal data necessary for each specific purpose is processed by default | +| GDPR | Art. 5(1)(c) | Data minimization principle | +| APP | APP 3.1–3.2 | Collection must be reasonably necessary for entity functions | +| APP | APP 5 | Notification obligations at time of collection | +| CCPA/CPRA | §1798.100(b) | No collection of additional categories beyond disclosed purposes | +| CCPA/CPRA | §1798.135 | Right to opt-out of sale; opt-out link required | + +--- + +Content paraphrased from Dr. Ann Cavoukian's 7 Foundation Principles of Privacy by Design (2009) with attribution. Regulatory mappings are planning references, not legal interpretations. diff --git a/.github/skills/project-planning/privacy-by-design/references/03-privacy-embedded-into-design.md b/.github/skills/project-planning/privacy-by-design/references/03-privacy-embedded-into-design.md new file mode 100644 index 000000000..23e130d76 --- /dev/null +++ b/.github/skills/project-planning/privacy-by-design/references/03-privacy-embedded-into-design.md @@ -0,0 +1,67 @@ +--- +title: 'PbD-03: Privacy Embedded into Design' +description: Privacy by Design reference for embedding privacy into the design and architecture of systems and business practices +--- + +# 03 Privacy Embedded into Design + +Identifier: PbD-03 +Category: Architecture + +## Source mapping + +- **Cavoukian Principle 3** — Privacy Embedded into Design +- **GDPR Art. 25(1)** — Implement appropriate technical and organisational measures designed to implement data-protection principles +- **APP 1.2** — Take reasonable steps to implement practices, procedures, and systems for compliance +- **CCPA §1798.100** — Implement reasonable security procedures + +## Description + +Privacy is embedded into the design and architecture of IT systems and business practices. It is not bolted on as an add-on after the fact. Privacy is integral to the system without diminishing functionality. It is a core component of the system being delivered, not a trade-off or afterthought. + +This principle requires that privacy considerations are woven into the technical architecture, data models, access control layers, and business process flows from the earliest design stage. Privacy is treated as a first-class architectural concern alongside security, performance, and reliability. + +## Principle checklist + +- Privacy requirements are documented in architecture decision records or design specifications. +- Data flows are designed with privacy controls as integral components (not optional add-ons). +- Personal data is classified and labeled in data models and schemas. +- Access control architectures enforce need-to-know and purpose limitation at the system level. +- Data minimization is enforced architecturally (e.g., field-level encryption, tokenization, pseudonymization). +- Privacy-enhancing technologies (PETs) are evaluated during technology selection. +- System boundaries explicitly define where personal data enters, moves, and exits. +- Privacy controls are tested as part of the standard QA process, not as a separate audit. + +## Controls and mitigations + +1. Include privacy as a dimension in architecture reviews and design documents. +2. Use data flow diagrams that highlight personal data paths and processing purposes. +3. Implement purpose-binding at the data layer (tag data with processing purpose at collection). +4. Apply pseudonymization or tokenization where full identity is not required for processing. +5. Architect systems with privacy boundaries that limit data exposure between components. +6. Select privacy-enhancing technologies (differential privacy, homomorphic encryption, secure enclaves) where appropriate. +7. Document privacy architectural decisions in ADRs with explicit trade-off analysis. +8. Include privacy-specific test cases in integration and system testing. + +## Anti-patterns + +- Privacy is addressed only through a privacy policy document without technical implementation. +- Personal data flows freely between system components without purpose limitation. +- No data classification exists in the data model. +- Privacy controls are implemented as a separate module bolted onto an existing system. +- Privacy reviews happen only at the end of development, too late to influence architecture. +- Privacy-enhancing technologies are dismissed without evaluation because of perceived complexity. + +## Regulatory cross-references + +| Regulation | Reference | Relevance | +|------------|-----------|-----------| +| GDPR | Art. 25(1) | Technical and organisational measures to implement data-protection principles effectively | +| GDPR | Art. 5(1)(f) | Integrity and confidentiality — appropriate security of personal data | +| APP | APP 1.2 | Reasonable steps to implement practices, procedures, and systems | +| APP | APP 11.1 | Reasonable steps to protect personal information from misuse, interference, and loss | +| CCPA/CPRA | §1798.100 | Reasonable security procedures and practices | + +--- + +Content paraphrased from Dr. Ann Cavoukian's 7 Foundation Principles of Privacy by Design (2009) with attribution. Regulatory mappings are planning references, not legal interpretations. diff --git a/.github/skills/project-planning/privacy-by-design/references/04-full-functionality.md b/.github/skills/project-planning/privacy-by-design/references/04-full-functionality.md new file mode 100644 index 000000000..ecf185603 --- /dev/null +++ b/.github/skills/project-planning/privacy-by-design/references/04-full-functionality.md @@ -0,0 +1,64 @@ +--- +title: 'PbD-04: Full Functionality — Positive-Sum, Not Zero-Sum' +description: Privacy by Design reference for achieving both privacy and functionality without unnecessary trade-offs +--- + +# 04 Full Functionality + +Identifier: PbD-04 +Category: Positive-Sum + +## Source mapping + +- **Cavoukian Principle 4** — Full Functionality — Positive-Sum, Not Zero-Sum +- **GDPR Art. 25(1)** — Implement measures in an effective manner (privacy without degrading functionality) +- **APP 1.2** — Manage personal information in an open and transparent way (supporting both compliance and business functions) +- **CCPA §1798.100** — Consumer rights exercised without penalty to service quality + +## Description + +Privacy by Design seeks to accommodate all legitimate interests and objectives in a positive-sum manner, not through a zero-sum approach where unnecessary trade-offs are made. Privacy by Design avoids the pretense of false dichotomies such as privacy vs. security, or privacy vs. functionality. It demonstrates that it is possible to have both — full functionality and full privacy. + +This principle rejects the notion that privacy must come at the cost of business utility, user experience, or security. Instead, it demands creative design solutions that satisfy multiple objectives simultaneously. + +## Principle checklist + +- Privacy controls do not degrade the core user experience or service functionality. +- Privacy and security are treated as complementary, not competing, requirements. +- Data subjects who exercise privacy rights (opt-out, deletion) receive equivalent service quality. +- Design alternatives are explored before declaring a privacy-functionality trade-off. +- Privacy-preserving approaches (aggregation, anonymization, federated processing) are considered before raw data collection. +- Business objectives and privacy objectives are documented as co-equal requirements. +- No feature is implemented with the assumption that "privacy makes it impossible." + +## Controls and mitigations + +1. For each feature requiring personal data, document the minimum data needed and explore privacy-preserving alternatives. +2. Ensure users who decline optional data collection still receive full core functionality. +3. When a trade-off appears necessary, conduct a formal analysis documenting why both objectives cannot be simultaneously met. +4. Use A/B testing or prototyping to validate that privacy-preserving designs meet functionality requirements. +5. Apply anonymization, aggregation, or synthetic data techniques when full identification is not required. +6. Prohibit service degradation or dark patterns targeting users who exercise privacy rights. +7. Document positive-sum outcomes in privacy impact assessments. + +## Anti-patterns + +- Features are gated behind unnecessary data collection ("give us your data or lose functionality"). +- Privacy is framed as a blocker to business requirements without exploring alternatives. +- Users who opt out of tracking receive degraded service or reduced feature access. +- Security justifications are used to collect more personal data than necessary. +- The team assumes privacy and functionality are inherently at odds without testing alternatives. +- Dark patterns punish privacy-conscious choices (e.g., repeated consent prompts, friction). + +## Regulatory cross-references + +| Regulation | Reference | Relevance | +|------------|-----------|-----------| +| GDPR | Art. 7(4) | Consent must not be a condition for service where not necessary for performance | +| GDPR | Art. 25(1) | Effective implementation of principles without undermining processing purposes | +| APP | APP 3.3 | Collection must be by lawful and fair means | +| CCPA/CPRA | §1798.125 | No discrimination against consumers exercising their rights | + +--- + +Content paraphrased from Dr. Ann Cavoukian's 7 Foundation Principles of Privacy by Design (2009) with attribution. Regulatory mappings are planning references, not legal interpretations. diff --git a/.github/skills/project-planning/privacy-by-design/references/05-end-to-end-security.md b/.github/skills/project-planning/privacy-by-design/references/05-end-to-end-security.md new file mode 100644 index 000000000..25bb1055f --- /dev/null +++ b/.github/skills/project-planning/privacy-by-design/references/05-end-to-end-security.md @@ -0,0 +1,76 @@ +--- +title: 'PbD-05: End-to-End Security — Full Lifecycle Protection' +description: Privacy by Design reference for ensuring cradle-to-grave security of personal data including retention and disposal +--- + +# 05 End-to-End Security + +Identifier: PbD-05 +Category: Lifecycle Protection + +## Source mapping + +- **Cavoukian Principle 5** — End-to-End Security — Full Lifecycle Protection +- **GDPR Art. 25(1), Art. 32** — Security of processing throughout the data lifecycle +- **GDPR Art. 5(1)(e)** — Storage limitation +- **APP 11** — Security of personal information +- **APP 4** — Dealing with unsolicited personal information (destruction) +- **CCPA §1798.100(e)** — Disclosure of retention periods + +## Description + +Privacy by Design ensures cradle-to-grave protection of personal data. Strong security measures are essential to privacy from start to finish. This ensures that all data is securely retained and then securely destroyed at the end of the process. Privacy must be maintained throughout the entire lifecycle of the data — from collection through use, storage, transfer, and ultimately secure disposal. + +This principle addresses the full data lifecycle: ingestion, processing, storage, sharing, retention, archival, and destruction. It requires that security controls protect personal data at every stage, and that data does not persist beyond its necessary purpose. + +## Principle checklist + +- Personal data is protected by appropriate security measures at every lifecycle stage (collection, transit, storage, processing, sharing, archival, destruction). +- Encryption at rest and in transit is applied to personal data stores and communication channels. +- Access controls enforce least-privilege and purpose limitation across the data lifecycle. +- Data retention schedules are defined, documented, and purpose-linked for each data category. +- Automated disposal mechanisms execute at retention expiry without requiring manual intervention. +- Secure destruction methods are verified (cryptographic erasure, overwrite, physical destruction for media). +- Legal hold procedures exist that can suspend disposal when required, with documented scope and expiry. +- Audit trails record lifecycle transitions (collection, access, modification, sharing, disposal). + +## Controls and mitigations + +1. Classify all personal data by sensitivity and processing purpose at collection time. +2. Implement encryption at rest (AES-256 or equivalent) and in transit (TLS 1.2+) for all personal data. +3. Apply key management practices that enable cryptographic erasure at retention expiry. +4. Define per-category retention periods linked to processing purposes and regulatory minimums. +5. Implement automated retention enforcement (TTL policies, scheduled deletion jobs, lifecycle management policies). +6. Verify disposal through logs or certificates of destruction. +7. Establish legal hold procedures that can pause automated disposal with documented justification and expiry. +8. Monitor for orphaned data (personal data remaining after account deletion or purpose fulfillment). +9. Conduct periodic retention audits to identify data persisting beyond its justified retention period. + +## Anti-patterns + +- Personal data is retained indefinitely "just in case" without a purpose-linked justification. +- Disposal relies entirely on manual processes with no automation or verification. +- Encryption keys are not managed to enable cryptographic erasure. +- Data lifecycle stages are not documented; no one knows where personal data lives. +- Deletion requests result in soft-deletes that leave data accessible in backups indefinitely. +- No legal hold procedure exists, or legal holds are applied without scope or expiry. +- Audit logs do not capture data disposal events. +- Backup data is not included in retention and disposal policies. + +## Regulatory cross-references + +| Regulation | Reference | Relevance | +|------------|-----------|-----------| +| GDPR | Art. 5(1)(e) | Storage limitation — kept no longer than necessary | +| GDPR | Art. 17 | Right to erasure (right to be forgotten) | +| GDPR | Art. 25(1) | Appropriate measures including pseudonymization | +| GDPR | Art. 32 | Security of processing — encryption, resilience, restoration | +| APP | APP 4.2 | Destruction of unsolicited personal information not needed | +| APP | APP 11.1 | Reasonable steps to protect from misuse, interference, loss | +| APP | APP 11.2 | Destruction or de-identification when no longer needed | +| CCPA/CPRA | §1798.100(e) | Disclose retention period or criteria for determining period | +| CCPA/CPRA | §1798.105 | Consumer right to deletion | + +--- + +Content paraphrased from Dr. Ann Cavoukian's 7 Foundation Principles of Privacy by Design (2009) with attribution. Regulatory mappings are planning references, not legal interpretations. diff --git a/.github/skills/project-planning/privacy-by-design/references/06-visibility-and-transparency.md b/.github/skills/project-planning/privacy-by-design/references/06-visibility-and-transparency.md new file mode 100644 index 000000000..f3d05654a --- /dev/null +++ b/.github/skills/project-planning/privacy-by-design/references/06-visibility-and-transparency.md @@ -0,0 +1,74 @@ +--- +title: 'PbD-06: Visibility and Transparency — Keep It Open' +description: Privacy by Design reference for ensuring visibility and transparency in personal data practices +--- + +# 06 Visibility and Transparency + +Identifier: PbD-06 +Category: Openness + +## Source mapping + +- **Cavoukian Principle 6** — Visibility and Transparency — Keep It Open +- **GDPR Art. 12–14** — Transparent information, communication, and modalities +- **APP 1** — Open and transparent management of personal information +- **APP 5** — Notification of the collection of personal information +- **CCPA §1798.100(a)** — Right to know what personal information is collected + +## Description + +Privacy by Design seeks to assure all stakeholders that whatever the business practice or technology involved, it is in fact operating according to the stated promises and objectives, subject to independent verification. Its component parts and operations remain visible and transparent to users and providers alike. + +Transparency builds trust. Organizations must be able to demonstrate that their data handling practices match their stated policies, and data subjects must have visibility into how their data is used. Accountability and auditability are the mechanisms through which transparency is maintained. + +## Principle checklist + +- A clear, accessible privacy notice describes what data is collected, why, and how it is used. +- Privacy notices are written in plain language appropriate for the target audience. +- Data processing activities are documented in a processing register (records of processing activities). +- Data subjects can request and receive information about what data is held about them. +- Third-party data sharing is disclosed including recipients and purposes. +- Privacy practices are subject to independent verification or audit. +- Changes to data practices are communicated to affected users before taking effect. +- Complaint and inquiry mechanisms are accessible and responsive. + +## Controls and mitigations + +1. Maintain a publicly accessible privacy notice that is reviewed and updated at least annually. +2. Implement a Records of Processing Activities (ROPA) register for internal accountability. +3. Provide a self-service data access mechanism (data subject access request portal or API). +4. Publish a transparency report covering government requests, data incidents, and privacy metrics. +5. Conduct periodic independent privacy audits or certify against privacy standards (ISO 27701, SOC 2 Type II Privacy). +6. Version-control privacy notices and notify users of material changes. +7. Establish a privacy contact (DPO, privacy team) with clear escalation paths. +8. Log and respond to privacy inquiries within defined SLAs. + +## Anti-patterns + +- Privacy notices are written in dense legal language that users cannot understand. +- No records of processing activities exist internally. +- Users have no mechanism to discover what data is held about them. +- Data sharing with third parties is undisclosed or buried in terms and conditions. +- Privacy practices cannot be independently verified. +- Changes to data handling are made silently without notification to affected users. +- Complaint mechanisms are non-functional or unresponsive. + +## Regulatory cross-references + +| Regulation | Reference | Relevance | +|------------|-----------|-----------| +| GDPR | Art. 12 | Transparent, intelligible, easily accessible communication | +| GDPR | Art. 13–14 | Information to be provided at collection and when obtained indirectly | +| GDPR | Art. 15 | Right of access by the data subject | +| GDPR | Art. 30 | Records of processing activities | +| APP | APP 1.3–1.6 | APP privacy policy requirements | +| APP | APP 5 | Notification of collection | +| APP | APP 12 | Access to personal information | +| CCPA/CPRA | §1798.100(a) | Right to know categories and purposes | +| CCPA/CPRA | §1798.110 | Right to know specific pieces of information | +| CCPA/CPRA | §1798.130 | Methods for submitting consumer requests | + +--- + +Content paraphrased from Dr. Ann Cavoukian's 7 Foundation Principles of Privacy by Design (2009) with attribution. Regulatory mappings are planning references, not legal interpretations. diff --git a/.github/skills/project-planning/privacy-by-design/references/07-respect-for-user-privacy.md b/.github/skills/project-planning/privacy-by-design/references/07-respect-for-user-privacy.md new file mode 100644 index 000000000..8a3c1def6 --- /dev/null +++ b/.github/skills/project-planning/privacy-by-design/references/07-respect-for-user-privacy.md @@ -0,0 +1,79 @@ +--- +title: 'PbD-07: Respect for User Privacy — Keep It User-Centric' +description: Privacy by Design reference for keeping individual privacy interests paramount through user-centric design +--- + +# 07 Respect for User Privacy + +Identifier: PbD-07 +Category: User-Centricity + +## Source mapping + +- **Cavoukian Principle 7** — Respect for User Privacy — Keep It User-Centric +- **GDPR Art. 12–22** — Data subject rights (access, rectification, erasure, portability, objection) +- **APP 6** — Use or disclosure of personal information +- **APP 12–13** — Access to and correction of personal information +- **CCPA §1798.120** — Consumer right to opt-out of sale +- **CCPA §1798.185** — Consumer right to limit use of sensitive personal information + +## Description + +Above all, Privacy by Design requires architects and operators to keep the interests of the individual uppermost by offering strong privacy defaults, appropriate notice, and empowering user-friendly options. Keep it user-centric — give individuals a strong role in the management of their own data. + +This principle places the data subject at the center of system design. Individuals are not passive recipients of data processing; they are active participants with meaningful control over their personal information. Systems must empower users with choice, access, correction, and deletion capabilities. + +## Principle checklist + +- Users have granular control over what personal data is collected and how it is used. +- Consent is specific, informed, unambiguous, and revocable. +- Users can access, correct, and delete their personal data through self-service mechanisms. +- Data portability is supported — users can export their data in a structured, machine-readable format. +- Preference centers allow users to manage communication, sharing, and processing choices. +- Withdrawal of consent is as easy as giving consent. +- User interfaces are designed to empower privacy choices, not to overwhelm or confuse. +- Automated decision-making is disclosed with mechanisms to request human review. + +## Controls and mitigations + +1. Implement a privacy preference center where users manage consent, communication, and data sharing choices. +2. Provide data export/portability in standard machine-readable formats (JSON, CSV). +3. Implement self-service account deletion that triggers cascading data removal. +4. Ensure consent withdrawal is a single-action operation with immediate effect. +5. Design consent flows that are specific (per-purpose) rather than all-or-nothing. +6. Disclose automated profiling and decision-making with opt-out or human review options. +7. User-test privacy interfaces to ensure they are genuinely usable and not dark patterns. +8. Provide accessible mechanisms for individuals with disabilities to exercise their privacy rights. + +## Anti-patterns + +- Users cannot delete their accounts or personal data without contacting support. +- Consent is bundled (all-or-nothing) rather than granular per purpose. +- Withdrawal of consent requires more steps than granting it. +- No data export or portability mechanism exists. +- Privacy settings are buried in inaccessible menus. +- Automated decisions affecting users have no transparency or appeal mechanism. +- User interfaces are designed to nudge users toward less private options. +- Users with disabilities cannot access privacy controls due to inaccessible interfaces. + +## Regulatory cross-references + +| Regulation | Reference | Relevance | +|------------|-----------|-----------| +| GDPR | Art. 7(3) | Right to withdraw consent at any time; withdrawal as easy as giving consent | +| GDPR | Art. 15–16 | Right of access and rectification | +| GDPR | Art. 17 | Right to erasure | +| GDPR | Art. 20 | Right to data portability | +| GDPR | Art. 21 | Right to object | +| GDPR | Art. 22 | Automated individual decision-making including profiling | +| APP | APP 6 | Use or disclosure limited to collected purpose or exceptions | +| APP | APP 12 | Access to personal information on request | +| APP | APP 13 | Correction of personal information | +| CCPA/CPRA | §1798.105 | Right to deletion | +| CCPA/CPRA | §1798.106 | Right to correction | +| CCPA/CPRA | §1798.120 | Right to opt-out of sale or sharing | +| CCPA/CPRA | §1798.185 | Right to limit use of sensitive personal information | + +--- + +Content paraphrased from Dr. Ann Cavoukian's 7 Foundation Principles of Privacy by Design (2009) with attribution. Regulatory mappings are planning references, not legal interpretations. diff --git a/.github/skills/project-planning/privacy-by-design/references/assessment-protocol.md b/.github/skills/project-planning/privacy-by-design/references/assessment-protocol.md new file mode 100644 index 000000000..ccf38971c --- /dev/null +++ b/.github/skills/project-planning/privacy-by-design/references/assessment-protocol.md @@ -0,0 +1,119 @@ +--- +title: Assessment Protocol +description: Step-by-step protocol for agents assessing a system against PbD 7 Foundation Principles +--- + +# Assessment Protocol + +This document defines the step-by-step protocol that the Privacy Reviewer or Privacy Planner follows when assessing a system, feature, or data flow against the 7 Foundation Principles of Privacy by Design. + +## Assessment entry conditions + +Begin a PbD assessment when any of these conditions hold: + +- A new feature or system processes personal data and has not been assessed against PbD principles. +- A privacy review is requested during design, architecture, or pre-release review. +- A DPIA (from the `privacy-standards` skill) identifies high-risk processing that warrants principle-level analysis. +- A data retention audit is triggered by regulatory change or incident response. + +## Assessment phases + +### Phase 1: Scope and context + +1. Identify the system, feature, or data flow under assessment. +2. Determine the personal data categories involved (using the data inventory from `privacy-standards`). +3. Identify applicable jurisdictions (use `cross-jurisdictional-mapping.md` triggers). +4. Establish the assessment boundary: which components, services, and data stores are in scope. +5. Document the processing purposes and lawful bases for each data category. + +### Phase 2: Principle-by-principle assessment + +For each principle (PbD-01 through PbD-07): + +1. Read the principle reference file. +2. Evaluate each item in the principle checklist against the system evidence. +3. For each checklist item, record one of: + - **MET** — evidence confirms the indicator is satisfied. + - **NOT MET** — evidence confirms the indicator is violated or absent. + - **INSUFFICIENT EVIDENCE** — cannot determine from available information. +4. Check for anti-patterns listed in the principle reference. +5. Assign a principle-level verdict: PASS, PARTIAL, or FAIL (see verdict rules below). +6. Assign a severity: HIGH, MEDIUM, or LOW (see severity rules below). +7. Record the finding with citation fields from the principle reference. + +### Phase 3: Retention and disposal assessment + +When the system stores personal data: + +1. Verify retention schedules exist for each data category (use `data-retention-and-disposal.md`). +2. Check that retention periods are purpose-linked and justified. +3. Verify disposal methods are appropriate for the data sensitivity. +4. Check backup and replica inclusion in retention policies. +5. Verify legal hold procedures exist if the system could be subject to litigation holds. +6. Record retention-specific findings under PbD-05. + +### Phase 4: Cross-jurisdictional check + +When multiple jurisdictions apply: + +1. Use the jurisdictional scope triggers in `cross-jurisdictional-mapping.md`. +2. Identify which regulations apply to each data flow. +3. Verify that the implementation meets the highest applicable standard. +4. Flag any jurisdiction-specific obligations not met by the common baseline. +5. Record cross-jurisdictional findings with the applicable regulation and article. + +### Phase 5: Synthesis and handoff + +1. Aggregate findings into a summary with counts by verdict and severity. +2. Identify the top-priority findings (FAIL with HIGH severity first). +3. For each FAIL or PARTIAL finding, provide a specific, actionable remediation recommendation. +4. If all principles are PASS, confirm compliance and note any conditions. +5. Hand off findings in the finding schema format (see `finding-schema.md`). + +## Verdict rules + +| Verdict | Condition | +|---------|-----------| +| PASS | All checklist items are MET and no anti-patterns are detected | +| PARTIAL | Majority of checklist items are MET but gaps remain, OR anti-patterns are present with compensating controls | +| FAIL | Majority of checklist items are NOT MET, OR critical anti-patterns are present without compensating controls | + +## Severity rules + +| Severity | Condition | +|----------|-----------| +| HIGH | Finding involves sensitive data, affects many data subjects, or creates direct regulatory non-compliance risk | +| MEDIUM | Finding involves standard personal data, affects limited data subjects, or creates indirect compliance risk | +| LOW | Finding is a documentation or process gap with no direct impact on data subjects | + +## Evidence expectations + +Acceptable evidence for MET determinations: + +- Architecture documents or ADRs showing privacy-by-design decisions +- Code showing privacy controls (encryption, access control, data minimization, consent mechanisms) +- Configuration files showing privacy-protective defaults +- Data flow diagrams showing personal data boundaries +- Retention schedule documents +- Privacy impact assessments or DPIA records +- Test cases covering privacy behaviors +- Monitoring or alerting configurations for privacy-relevant events + +## Interaction with other skills + +| Skill | Interaction | +|-------|-------------| +| `privacy-standards` | Provides data inventory, DPIA thresholds, and standards backbone; PbD assessment builds on top | +| `security-planning` | Security controls overlap with PbD-05; reference security findings rather than duplicating | +| `rai-planner` | RAI assessment may identify data use concerns that feed into PbD-04 and PbD-07 | + +## Stop rules + +- Stop the assessment if scope cannot be established (no identifiable system or data flow). +- Stop and escalate if the system processes data in a jurisdiction not covered by this skill's mappings. +- Do not fabricate evidence; record INSUFFICIENT EVIDENCE and note what is needed. +- Do not provide legal opinions; frame all findings as planning guidance requiring qualified review. + +--- + +Protocol synthesized from the assessment patterns used by the Security Reviewer and RAI Planner within hve-core, adapted for privacy principle 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..e3e8ef2a1 --- /dev/null +++ b/.github/skills/project-planning/privacy-by-design/references/cross-jurisdictional-mapping.md @@ -0,0 +1,104 @@ +--- +title: Cross-Jurisdictional Mapping +description: Regulatory equivalence matrix mapping PbD principles across GDPR, CCPA/CPRA, and Australian Privacy Principles +--- + +# Cross-Jurisdictional Mapping + +This reference provides a regulatory equivalence matrix to help the Privacy Planner and Reviewer identify applicable obligations when a system operates across multiple jurisdictions. + +## Jurisdictional scope triggers + +Assess which regulations apply based on: + +| Trigger | GDPR | CCPA/CPRA | APP (Australia) | +|---------|------|-----------|-----------------| +| Entity established in jurisdiction | Yes (Art. 3(1)) | Yes (Cal. entity) | Yes (Australian entity) | +| Processing data of jurisdiction's residents | Yes (Art. 3(2)) | Yes (CA consumers) | Possible (APP 2 — extraterritorial) | +| Revenue threshold | N/A | $25M+ annual revenue | $3M+ annual turnover (or other triggers) | +| Data volume threshold | N/A | 100K+ consumers/households | N/A | +| Derives revenue from selling data | N/A | 50%+ revenue from selling | N/A | + +## PbD principle-to-regulation equivalence matrix + +### PbD-01: Proactive Not Reactive + +| Obligation | GDPR | CCPA/CPRA | APP | +|------------|------|-----------|-----| +| Privacy assessment before processing | Art. 25(1), Art. 35 (DPIA) | No explicit DPIA but CPRA §1798.185(a)(15) audit regulations | APP 1.2 (reasonable steps) | +| Risk-based approach | Art. 24 (appropriate measures considering risk) | §1798.100 (reasonable security) | APP 11.1 (reasonable steps) | + +### PbD-02: Privacy as the Default + +| Obligation | GDPR | CCPA/CPRA | APP | +|------------|------|-----------|-----| +| Data minimization by default | Art. 5(1)(c), Art. 25(2) | §1798.100(b) (no excess collection) | APP 3 (necessary for functions) | +| Opt-in consent model | Art. 6–7 (consent conditions) | Opt-out model (§1798.120) but sensitive data requires opt-in (§1798.121) | APP 3 (solicited collection requires consent for sensitive) | +| Purpose limitation | Art. 5(1)(b) | §1798.100(c) (compatible purposes) | APP 6 (primary purpose or related secondary) | + +### PbD-03: Privacy Embedded into Design + +| Obligation | GDPR | CCPA/CPRA | APP | +|------------|------|-----------|-----| +| Technical measures | Art. 25(1) (pseudonymization, etc.) | §1798.100 (reasonable security) | APP 11.1 (reasonable steps) | +| Organizational measures | Art. 24, Art. 25(1) | Implied (reasonable security) | APP 1.2 (practices, procedures, systems) | + +### PbD-04: Full Functionality + +| Obligation | GDPR | CCPA/CPRA | APP | +|------------|------|-----------|-----| +| Non-discrimination for exercising rights | Art. 7(4) (consent not conditional) | §1798.125 (no discrimination) | Implied (APP 3 — fair means) | +| Service equivalence | Art. 7(4) | §1798.125(a) (no denial, different price, quality) | Not explicit but fair dealing implied | + +### PbD-05: End-to-End Security + +| Obligation | GDPR | CCPA/CPRA | APP | +|------------|------|-----------|-----| +| Retention limitation | Art. 5(1)(e) | §1798.100(e) (disclose period) | APP 11.2 (destroy when no longer needed) | +| Right to deletion | Art. 17 | §1798.105 | APP 11.2 (entity-initiated), APP 13.1 (correction on request) | +| Security of processing | Art. 32 | §1798.100 (reasonable security) | APP 11.1 (protect from misuse) | +| Processor obligations | Art. 28 (DPA required) | §1798.140(j) (service provider contracts) | APP 8 (cross-border disclosure) | + +### PbD-06: Visibility and Transparency + +| Obligation | GDPR | CCPA/CPRA | APP | +|------------|------|-----------|-----| +| Privacy notice | Art. 12–14 | §1798.100(a), §1798.130 | APP 1.3–1.6 (privacy policy), APP 5 (collection notice) | +| Right to access | Art. 15 | §1798.100, §1798.110 | APP 12 | +| Records of processing | Art. 30 | Not explicit but audit requirement emerging | Not explicit but APP 1.2 implies | +| Third-party disclosure | Art. 13(1)(e)–(f) | §1798.115 (right to know about sharing) | APP 1.4(e) (overseas recipients in policy) | + +### PbD-07: Respect for User Privacy + +| Obligation | GDPR | CCPA/CPRA | APP | +|------------|------|-----------|-----| +| Consent withdrawal | Art. 7(3) (as easy as giving) | §1798.120 (opt-out of sale) | APP 7 (can withdraw consent for direct marketing) | +| Data portability | Art. 20 | Not in CCPA; CPRA §1798.130(a)(2) (machine-readable) | Not explicit | +| Correction | Art. 16 | §1798.106 | APP 13 | +| Objection to processing | Art. 21 | §1798.120 (opt-out of sale/sharing) | Not explicit (but APP 7 for direct marketing) | +| Automated decision-making | Art. 22 (right to human review) | §1798.185 (limit use of sensitive PI) | Not explicit | + +## Key jurisdictional differences + +| Aspect | GDPR | CCPA/CPRA | APP | +|--------|------|-----------|-----| +| Consent model | Opt-in (Art. 6–7) | Opt-out (except sensitive: opt-in) | Consent required for sensitive (APP 3.3) | +| Enforcement body | DPAs (each EU member state) | California AG + CPPA | OAIC | +| Breach notification | 72 hours to DPA (Art. 33) | No specific timeline (Cal. Civil Code §1798.82) | Notifiable Data Breaches scheme (30 days assessment) | +| Cross-border transfer | Adequacy + SCCs/BCRs (Ch. V) | No explicit restriction | APP 8 (reasonable steps for overseas recipients) | +| Children's data | Art. 8 (parental consent under 16/13) | CalOPPA + COPPA apply | APP 3.4 (capacity to consent) | +| Maximum fine | €20M or 4% global turnover | $7,500 per intentional violation | A$50M or 30% of turnover (since 2022) | + +## Multi-jurisdictional compliance strategy + +When a system spans multiple jurisdictions: + +1. Apply the highest common standard across all applicable regulations as the baseline. +2. Implement jurisdiction-specific controls only where a regulation imposes unique obligations (e.g., GDPR cross-border transfer mechanisms). +3. Document which regulations apply and which specific articles govern each data flow. +4. Maintain a jurisdictional applicability register updated when new markets or data residency requirements emerge. +5. Align consent mechanisms with the most restrictive applicable model (typically GDPR opt-in). + +--- + +Content synthesized from GDPR (Regulation (EU) 2016/679), CCPA/CPRA (California Civil Code §1798), and Australian Privacy Act 1988 (Privacy Principles). Paraphrased with attribution for planning use, not legal interpretation. diff --git a/.github/skills/project-planning/privacy-by-design/references/data-retention-and-disposal.md b/.github/skills/project-planning/privacy-by-design/references/data-retention-and-disposal.md new file mode 100644 index 000000000..1081a1be9 --- /dev/null +++ b/.github/skills/project-planning/privacy-by-design/references/data-retention-and-disposal.md @@ -0,0 +1,100 @@ +--- +title: Data Retention and Disposal +description: Deep-dive into Principle 05 lifecycle obligations covering retention schedules, disposal methods, legal holds, and verification +--- + +# Data Retention and Disposal + +This reference expands PbD-05 (End-to-End Security) with detailed guidance on data retention schedules, disposal methods, legal hold procedures, and verification practices. + +## Retention schedule requirements + +A retention schedule must define for each personal data category: + +| Field | Description | Example | +|-------|-------------|---------| +| Data category | Classification of the personal data | Customer contact details | +| Processing purpose | Why the data is collected and used | Service delivery, billing | +| Lawful basis | Legal ground for processing | Contract performance (GDPR Art. 6(1)(b)) | +| Retention period | Duration the data is kept | 3 years post-contract termination | +| Retention justification | Why this period (not shorter or longer) | Statutory limitation period + 1 year buffer | +| Disposal method | How data will be destroyed | Cryptographic erasure + backup purge | +| Review trigger | When to reassess the schedule | Annual privacy review or regulation change | + +## Retention period determination + +When determining appropriate retention periods: + +1. Start with the minimum period required to fulfill the processing purpose. +2. Check regulatory minimum retention requirements (tax records, financial audit trails, employment records). +3. Apply statutory limitation periods where legal exposure requires data preservation. +4. Add no more buffer than demonstrably necessary beyond the regulatory or purpose-driven minimum. +5. Document the justification for the chosen period explicitly. + +## Disposal methods + +| Method | When to use | Verification | +|--------|-------------|--------------| +| Cryptographic erasure | Cloud-hosted data with managed encryption keys | Key destruction confirmed; data rendered unrecoverable | +| Logical deletion with overwrite | On-premises database records | Overwrite verification; sector-level confirmation | +| Physical destruction | Decommissioned storage media | Certificate of destruction from certified vendor | +| De-identification | Data has ongoing analytical value; identity not required | Re-identification risk assessment passes threshold | +| Anonymization | Statistical or research use cases | k-anonymity, l-diversity, or differential privacy verification | + +## Backup and replica considerations + +- Retention policies must account for backup copies, replicas, CDN caches, and disaster recovery stores. +- Define maximum acceptable delay between primary disposal and backup purge (backup retention lag). +- If backup retention exceeds primary retention, document the gap and implement compensating controls (access restriction on backup media). +- Include backup purge verification in disposal audit trail. + +## Legal hold procedures + +A legal hold suspends normal disposal when litigation, investigation, or regulatory action requires data preservation. + +### Legal hold lifecycle + +1. **Initiation** — Legal counsel issues hold notice specifying scope (data categories, date ranges, custodians). +2. **Scope documentation** — Hold scope is recorded with start date, justification, and affected data stores. +3. **Automated suspension** — Disposal automation is paused for in-scope data; hold is enforced technically where possible. +4. **Periodic review** — Holds are reviewed at defined intervals (e.g., quarterly) to confirm continued necessity. +5. **Release** — Legal counsel issues release notice; normal disposal resumes for previously held data. +6. **Disposal execution** — Released data proceeds through standard disposal method and verification. + +### Legal hold anti-patterns + +- Holds applied without defined scope (entire database frozen indefinitely). +- No review cadence; holds persist years beyond their justification. +- No technical enforcement; disposal automation continues despite hold notice. +- Hold release does not trigger disposal; data persists indefinitely after release. + +## Disposal verification checklist + +- [ ] Primary data store: deletion confirmed (logs or system confirmation) +- [ ] Backup copies: purge scheduled within defined backup retention lag +- [ ] Replicas and caches: invalidated or expired +- [ ] Third-party processors: disposal confirmation received (contractual obligation under DPA) +- [ ] Audit trail: disposal event logged with timestamp, method, and operator +- [ ] Verification: independent confirmation that data is unrecoverable (spot-check or attestation) + +## Regulatory mapping for retention and disposal + +| Regulation | Reference | Requirement | +|------------|-----------|-------------| +| GDPR | Art. 5(1)(e) | Storage limitation — no longer than necessary for purposes | +| GDPR | Art. 17 | Right to erasure on request (subject to exemptions) | +| GDPR | Art. 28(3)(g) | Processor must delete or return data at end of service | +| APP | APP 4.2 | Destroy unsolicited information not reasonably necessary | +| APP | APP 11.2 | Destroy or de-identify when no longer needed for any purpose | +| CCPA/CPRA | §1798.100(e) | Disclose retention period or criteria for determining it | +| CCPA/CPRA | §1798.105 | Right to deletion (subject to exemptions) | + +## Citation fields for findings + +- `pbd_principle`: PbD-05 End-to-End Security +- `retention_category`: The data category being assessed +- `retention_gap`: Description of the gap (e.g., "no defined retention period", "disposal not verified") + +--- + +Content synthesized from GDPR storage limitation requirements, Australian Privacy Principles APP 4 and APP 11, and CCPA/CPRA disclosure and deletion rights. Paraphrased with attribution for planning use. diff --git a/.github/skills/project-planning/privacy-by-design/references/finding-schema.md b/.github/skills/project-planning/privacy-by-design/references/finding-schema.md new file mode 100644 index 000000000..51c304b01 --- /dev/null +++ b/.github/skills/project-planning/privacy-by-design/references/finding-schema.md @@ -0,0 +1,158 @@ +--- +title: Finding Schema +description: Structured output format for PbD assessment findings used by Privacy Reviewer and Privacy Planner agents +--- + +# Finding Schema + +This document defines the structured output format for Privacy by Design assessment findings. Agents use this schema to produce consistent, machine-readable results that integrate with the hve-core review and backlog handoff workflow. + +## Finding record structure + +Each finding is a discrete assessment result for one principle or sub-check. + +```yaml +finding: + id: "PBD--" # e.g., PBD-01-001 + principle: "PbD-" # e.g., PbD-01 + principle_name: "" # e.g., Proactive Not Reactive + category: "" # e.g., Prevention + verdict: "PASS | PARTIAL | FAIL" + severity: "HIGH | MEDIUM | LOW" + title: "" + description: "" + evidence: "" + remediation: "" # Required for PARTIAL and FAIL + checklist_items_met: + checklist_items_total: + anti_patterns_detected: ["", ""] # Empty array if none + citations: + pbd_principle: "PbD- " + gdpr_article: "" # Optional + app_principle: "" # Optional + ccpa_section: "<§section>" # Optional + jurisdiction_flags: ["GDPR", "CCPA", "APP"] # Which apply +``` + +## Assessment summary structure + +The summary aggregates all principle findings into a top-level report. + +```yaml +assessment_summary: + system_name: "" + assessment_date: "" + scope: "" + jurisdictions: ["", ""] + overall_verdict: "COMPLIANT | PARTIALLY_COMPLIANT | NON_COMPLIANT" + findings_count: + pass: + partial: + fail: + severity_distribution: + high: + medium: + low: + top_priority_findings: + - id: "" + title: "" + severity: "<severity>" + remediation: "<brief fix>" + principles_assessed: + - principle: "PbD-01" + verdict: "PASS | PARTIAL | FAIL" + severity: "HIGH | MEDIUM | LOW | N/A" + - principle: "PbD-02" + verdict: "PASS | PARTIAL | FAIL" + severity: "HIGH | MEDIUM | LOW | N/A" + # ... through PbD-07 + retention_assessment: + conducted: true | false + categories_assessed: <count> + categories_compliant: <count> + gaps_identified: <count> + cross_jurisdictional: + jurisdictions_applicable: ["GDPR", "CCPA", "APP"] + common_baseline_met: true | false + jurisdiction_specific_gaps: <count> +``` + +## Overall verdict rules + +| Overall verdict | Condition | +|-----------------|-----------| +| COMPLIANT | All 7 principles are PASS | +| PARTIALLY_COMPLIANT | No principles are FAIL but one or more are PARTIAL | +| NON_COMPLIANT | One or more principles are FAIL | + +## Finding ID conventions + +- Format: `PBD-<NN>-<SSS>` where NN is the principle number (01–07) and SSS is a sequence within that principle. +- Retention findings use: `PBD-05-R<SSS>` (R prefix distinguishes retention sub-findings). +- Cross-jurisdictional findings use: `PBD-CJ-<SSS>` for findings that span multiple principles. + +## Integration with backlog handoff + +Each FAIL or PARTIAL finding maps to a potential backlog item: + +```yaml +backlog_item: + source_finding: "<finding_id>" + title: "[Privacy] <remediation title>" + description: | + **Finding**: <finding description> + **Principle**: <principle name> + **Severity**: <severity> + **Remediation**: <actionable fix> + **Regulatory reference**: <citation> + priority: "<mapped from severity: HIGH→P1, MEDIUM→P2, LOW→P3>" + labels: ["privacy", "pbd", "compliance"] + acceptance_criteria: + - "<specific condition that resolves the finding>" +``` + +## Retention-specific finding extensions + +Retention findings under PbD-05 include additional fields: + +```yaml +retention_finding: + id: "PBD-05-R001" + data_category: "<category name>" + current_retention: "<current period or 'undefined'>" + required_retention: "<justified period>" + disposal_method: "<current method or 'none defined'>" + backup_included: true | false + legal_hold_capable: true | false + gap_type: "undefined_period | excessive_retention | no_disposal | no_backup_coverage | no_legal_hold" +``` + +## Example finding + +```yaml +finding: + id: "PBD-02-001" + principle: "PbD-02" + principle_name: "Privacy as the Default" + category: "Default Settings" + verdict: "FAIL" + severity: "HIGH" + title: "Analytics tracking enabled by default without consent" + description: "User analytics include individual behavioral tracking enabled by default. Users must navigate to Settings > Privacy > Analytics to disable tracking." + evidence: "Configuration file analytics.config.json shows tracking.enabled: true as default. No consent prompt appears before tracking begins." + remediation: "Set tracking.enabled to false by default. Implement an opt-in consent prompt before enabling individual behavioral tracking." + checklist_items_met: 3 + checklist_items_total: 8 + anti_patterns_detected: + - "Pre-checked consent boxes or opt-out rather than opt-in consent" + - "Analytics track individual behavior by default" + citations: + pbd_principle: "PbD-02 Privacy as the Default" + gdpr_article: "Art. 25(2)" + ccpa_section: "§1798.120" + jurisdiction_flags: ["GDPR", "CCPA"] +``` + +--- + +Schema design follows the finding and backlog patterns established by the security-reviewer and RAI Planner skills within hve-core, adapted for privacy principle assessment. diff --git a/.github/skills/project-planning/privacy-by-design/references/implementation-patterns.md b/.github/skills/project-planning/privacy-by-design/references/implementation-patterns.md new file mode 100644 index 000000000..ce8373eb3 --- /dev/null +++ b/.github/skills/project-planning/privacy-by-design/references/implementation-patterns.md @@ -0,0 +1,261 @@ +--- +title: Implementation Patterns +description: Pragmatic code-level and architecture-level patterns agents can verify when assessing PbD principle adherence +--- + +# Implementation Patterns + +This reference provides pragmatic, verifiable implementation patterns that an agent can look for in code, configuration, and architecture when assessing PbD principle adherence. Each pattern maps to one or more principles and provides concrete indicators. + +## PbD-01: Proactive indicators in code + +### Privacy Impact Assessment integration + +Look for: + +- Pre-commit hooks or CI checks that flag new personal data collection points +- Architecture Decision Records (ADRs) with privacy as a decision driver +- Issue templates or PR templates that include privacy impact questions +- Privacy-tagged user stories or acceptance criteria in backlog items + +### Privacy threat modeling artifacts + +Look for: + +- STRIDE analysis files that include privacy-specific threats (information disclosure, elevation of privilege for data access) +- Data flow diagrams annotating personal data boundaries +- Privacy risk registers in project documentation + +## PbD-02: Default setting patterns + +### Configuration-level checks + +```yaml +# PASS indicators — privacy-protective defaults +analytics: + tracking_enabled: false # Disabled by default + anonymize_ip: true # Anonymized by default + consent_required: true # Opt-in required + +cookies: + third_party: disabled # No third-party by default + session_only: true # Minimal persistence + +user_profile: + visibility: private # Private by default + search_indexing: false # Not indexed by default +``` + +```yaml +# FAIL indicators — privacy-invasive defaults +analytics: + tracking_enabled: true # Tracking without consent + anonymize_ip: false # Full IP collection + consent_required: false # No consent gate + +user_profile: + visibility: public # Public by default + search_indexing: true # Indexed without consent +``` + +### Consent mechanism patterns + +``` +PASS: Consent flows use opt-in (unchecked checkboxes, explicit "I agree" action) +FAIL: Pre-checked consent boxes, bundled consent, consent buried in terms +PASS: Consent withdrawal is a single-action operation accessible from the same location +FAIL: Withdrawal requires contacting support or navigating obscure settings +``` + +### API default patterns + +``` +PASS: API endpoints return minimal fields by default; expand via explicit ?fields= parameter +FAIL: API endpoints return all user data by default including sensitive fields +PASS: Pagination defaults to smallest reasonable page size +FAIL: Endpoints return unbounded result sets with full user records +``` + +## PbD-03: Embedded design indicators + +### Architecture patterns + +| Pattern | PbD alignment | What to look for | +|---------|---------------|------------------| +| Data classification in schema | PbD-03 | Column/field annotations marking PII, sensitive, public | +| Purpose-binding at collection | PbD-03 | Data tagged with processing purpose at ingestion point | +| Privacy boundaries in microservices | PbD-03 | Separate services for identity vs. analytics vs. business logic | +| Tokenization/pseudonymization | PbD-03 | User identifiers replaced with tokens in analytics pipelines | +| Field-level encryption | PbD-03 | Sensitive fields encrypted independently of storage encryption | + +### Code-level indicators + +Look for: + +- Data classification decorators or annotations on model classes +- Purpose-binding metadata attached to data collection endpoints +- Separate data access layers for PII vs. non-PII queries +- Privacy-aware logging that redacts or masks personal data +- Input validation that rejects unnecessary personal data fields + +```python +# PASS indicator — data classification in code +@data_classification(category="sensitive", purpose="billing") +class PaymentInfo: + card_last_four: str # Only last 4 stored + billing_zip: str + +# PASS indicator — privacy-aware logging +logger.info("Payment processed", extra={"user_id": mask(user_id), "amount": amount}) + +# FAIL indicator — logging PII +logger.info(f"Payment for {user.email} with card {card_number}") +``` + +## PbD-04: Positive-sum indicators + +### Non-discrimination patterns + +Look for: + +- Feature flags or configuration that ensures opted-out users retain full core functionality +- A/B test configurations that do not degrade experience for privacy-conscious cohorts +- Terms of service that do not condition service access on optional data collection +- No differential pricing or feature gating based on consent choices + +### Code indicators + +``` +PASS: Service works fully with analytics disabled +FAIL: Features break or degrade when tracking is blocked +PASS: Rate limits and quotas are identical regardless of consent status +FAIL: Higher quotas or premium features require accepting additional data collection +``` + +## PbD-05: Lifecycle security patterns + +### Encryption verification + +| Check | Evidence | +|-------|----------| +| Encryption at rest | Storage configuration shows AES-256, managed keys, or customer-managed keys | +| Encryption in transit | TLS 1.2+ enforced; HTTP redirected to HTTPS; HSTS headers present | +| Key rotation | Key management policy shows rotation schedule (e.g., 90 days) | +| Cryptographic erasure capability | Key management supports key deletion as a disposal method | + +### Retention enforcement patterns + +```yaml +# PASS — automated retention enforcement +storage: + lifecycle_rules: + - condition: + age_days: 365 + matches_prefix: "user-analytics/" + action: delete + + backup_retention: + max_days: 90 + auto_purge: true + +# FAIL — no lifecycle management +storage: + lifecycle_rules: [] # No rules defined + backup_retention: + max_days: unlimited +``` + +### Deletion verification + +Look for: + +- Cascading delete logic that removes data from all stores (primary, cache, backup, CDN) +- Deletion confirmation logs or audit trail entries +- Soft-delete to hard-delete pipeline with defined timelines +- Data subject access request (DSAR) handling workflows + +## PbD-06: Transparency indicators + +### Privacy notice patterns + +Look for: + +- Privacy policy accessible from every page (footer link, modal, or dedicated route) +- Plain-language summaries alongside legal text +- Version history of privacy notices (git history or CMS versioning) +- Automated notification to users when privacy policy changes materially + +### Data access patterns + +``` +PASS: Self-service DSAR portal or API endpoint for data export +FAIL: Users must email support to request their data +PASS: Data export includes all categories with clear labeling +FAIL: Data export is partial or requires multiple requests +PASS: Response within defined SLA (e.g., 30 days per GDPR) +FAIL: No defined timeline for data access requests +``` + +### Records of processing + +Look for: + +- Processing activity register (spreadsheet, database, or documentation) +- Each entry lists: purpose, legal basis, categories, recipients, retention, safeguards +- Register is maintained and updated when processing changes + +## PbD-07: User-centric indicators + +### Privacy control accessibility + +Look for: + +- Privacy settings reachable within 2 clicks/taps from main navigation +- Granular consent management (per-purpose, not all-or-nothing) +- Account deletion available as self-service (not "contact support to delete") +- Data portability export in standard formats (JSON, CSV) +- WCAG 2.2 AA compliance for privacy-related UI elements + +### Consent granularity patterns + +``` +PASS: Separate consent for analytics, marketing, third-party sharing, profiling +FAIL: Single "I agree to everything" consent covering all purposes +PASS: Per-partner consent for data sharing (can consent to Partner A but not B) +FAIL: Blanket "share with partners" consent +``` + +### Automated decision-making + +Look for: + +- Disclosure of automated profiling or algorithmic decisions affecting users +- Mechanism to request human review of automated decisions +- Explanation capability for algorithmic outcomes (even if simplified) + +## Cross-cutting indicators + +### CI/CD privacy checks + +| Check | Principle | What to verify | +|-------|-----------|----------------| +| PII scanner in pipeline | PbD-01, PbD-03 | Automated detection of new PII collection points | +| Privacy test suite | PbD-02, PbD-05 | Tests verifying privacy defaults and data lifecycle | +| Consent flow tests | PbD-02, PbD-07 | Automated verification of opt-in behavior | +| Data classification linter | PbD-03 | Schema changes require classification annotation | +| Retention policy validator | PbD-05 | New data stores require retention configuration | + +### Infrastructure-as-code indicators + +``` +PASS: Terraform/Bicep includes lifecycle rules on storage resources +PASS: Network policies restrict data egress to approved destinations +PASS: Logging configuration excludes PII fields from log sinks +FAIL: Storage resources created without lifecycle management +FAIL: No network-level data exfiltration controls +FAIL: Application logs contain unmasked personal data +``` + +--- + +Patterns synthesized from privacy engineering best practices, GDPR technical guidance (Article 29 Working Party), and architecture patterns observed in privacy-mature systems. Provided as planning reference material with attribution. diff --git a/.github/skills/project-planning/privacy-by-design/references/industry-privacy-profiles.md b/.github/skills/project-planning/privacy-by-design/references/industry-privacy-profiles.md new file mode 100644 index 000000000..f888d4051 --- /dev/null +++ b/.github/skills/project-planning/privacy-by-design/references/industry-privacy-profiles.md @@ -0,0 +1,203 @@ +--- +title: Industry Privacy Profiles +description: Industry-specific PbD principle emphasis, regulatory priorities, and assessment focus areas +--- + +# Industry Privacy Profiles + +This reference maps the 7 PbD Foundation Principles to industry-specific contexts, highlighting which principles demand elevated attention, what industry-specific regulatory obligations apply, and which assessment checks should be prioritized per sector. + +## How to use industry profiles + +1. Identify the system's industry context (from `.pbd-config.yml` or package analysis). +2. Load the matching profile to adjust assessment weighting. +3. Apply industry-specific checks alongside the universal principle checklist. +4. Flag industry-mandatory controls that go beyond the universal requirements. + +## Telecommunications + +### Principle emphasis + +| Principle | Industry priority | Rationale | +|-----------|------------------|-----------| +| PbD-01 Proactive | HIGH | Metadata retention laws require privacy planning before system design | +| PbD-02 Default | CRITICAL | Location and communication data must be protected by default (ePrivacy) | +| PbD-05 End-to-End | CRITICAL | CDR, location history, and content have mandated retention and disposal | +| PbD-06 Transparency | HIGH | Subscribers must know what metadata is retained and for how long | +| PbD-07 User-Centric | HIGH | Opt-in required for location-based services beyond network operation | + +### Industry-specific checks + +- Location data collection defaults to OFF for value-added services (PbD-02) +- CDR retention period matches regulatory mandate (not indefinite) (PbD-05) +- Subscriber consent mechanism exists for location-based services (PbD-07) +- Network metadata anonymized before analytics use (PbD-02) +- Roaming data sharing governed by transfer agreements (PbD-05) +- Lawful interception isolated from general access (PbD-03) +- Device identifiers (IMEI, IMSI) not correlated across services without purpose binding (PbD-03) + +### Key regulations + +- ePrivacy Directive (EU) — consent for location, confidentiality of communications +- Telecommunications Act 1997 (AU) — metadata retention, interception warrants +- CPNI Rules 47 CFR § 64.2001 (US) — customer network information protection + +--- + +## Healthcare + +### Principle emphasis + +| Principle | Industry priority | Rationale | +|-----------|------------------|-----------| +| PbD-02 Default | CRITICAL | Health data requires maximum protection by default (HIPAA minimum necessary) | +| PbD-03 Embedded | CRITICAL | Privacy must be architectural (segmentation, de-identification, break-the-glass) | +| PbD-04 Full Functionality | HIGH | Patients exercising rights must not lose care quality | +| PbD-05 End-to-End | CRITICAL | Health records have complex retention (clinical vs. research vs. billing) | +| PbD-07 User-Centric | HIGH | Patient access rights (21st Century Cures), correction, consent withdrawal | + +### Industry-specific checks + +- Minimum necessary principle applied to all health data disclosures (PbD-02) +- HIPAA de-identification method applied for research/analytics (Safe Harbor or Expert Determination) (PbD-03) +- Break-the-glass mechanism exists with mandatory post-access audit (PbD-03) +- 42 CFR Part 2 segmentation for substance abuse and mental health records (PbD-03) +- Patient portal provides electronic access to health records (PbD-07) +- DICOM de-identification strips patient metadata from medical images (PbD-05) +- Genetic data handled with GINA non-discrimination controls (PbD-04) +- Clinical research consent separate from treatment consent (PbD-07) + +### Key regulations + +- HIPAA Privacy and Security Rules (US) — minimum necessary, patient rights, safeguards +- 42 CFR Part 2 (US) — substance abuse record consent requirements +- My Health Records Act 2012 (AU) — digital health record controls +- GDPR Art. 9 (EU) — health data as special category + +--- + +## Financial Services + +### Principle emphasis + +| Principle | Industry priority | Rationale | +|-----------|------------------|-----------| +| PbD-02 Default | HIGH | Default data minimization for KYC (collect only what regulation requires) | +| PbD-03 Embedded | CRITICAL | PCI DSS requires privacy embedded in architecture (CDE isolation, tokenization) | +| PbD-04 Full Functionality | HIGH | Customers opting out of profiling must retain full service access (PSD2, CCPA §1798.125) | +| PbD-05 End-to-End | CRITICAL | Financial records have regulatory retention minimums AND deletion obligations | +| PbD-06 Transparency | HIGH | Automated credit decisions require explainability (GDPR Art. 22, FCRA) | + +### Industry-specific checks + +- PCI DSS cardholder data environment (CDE) architecturally isolated (PbD-03) +- Card data tokenized outside payment processing (PbD-03) +- CVV never stored (even encrypted) (PbD-02) +- KYC documents retained only for regulatory minimum, then destroyed (PbD-05) +- Credit scoring logic transparent to consumers with dispute mechanism (PbD-06) +- No service degradation for customers who opt out of profiling (PbD-04) +- AML/CTF monitoring does not create overbroad surveillance beyond regulatory mandate (PbD-02) +- Transaction data segregated from marketing analytics (PbD-03) +- Strong customer authentication for payment initiation (PbD-05) + +### Key regulations + +- PCI DSS v4.0 (Global) — cardholder data protection architecture +- PSD2/SCA (EU) — strong customer authentication, open banking consent +- FCRA (US) — credit reporting accuracy, consumer rights +- APRA CPS 234 (AU) — information security for regulated entities +- AML/CTF Act 2006 (AU) — customer identification, transaction monitoring + +--- + +## Profile configuration + +Projects can specify their industry profile and override principle priorities in `.pbd-config.yml`: + +```yaml +# .pbd-config.yml — placed at repository root +version: "1.0" + +# Industry profile (loads matching section above) +industry: "telco" # Options: telco, healthcare, financial + +# Override principle priorities for your org +principle_overrides: + - principle: "PbD-04" + priority: "CRITICAL" + justification: "Our telco offers essential services; accessibility during privacy exercise is mandatory" + +# Additional industry-specific checks beyond the profile +custom_checks: + - principle: "PbD-03" + check: "5G network slice identifiers treated as subscriber PII" + severity: "HIGH" + + - principle: "PbD-05" + check: "eSIM profile data destroyed within 30 days of deactivation" + severity: "MEDIUM" + +# Suppress checks that don't apply +suppressions: + - check: "DICOM de-identification" + reason: "Not a healthcare system; no medical imaging" + + - check: "PCI DSS CDE isolation" + reason: "No payment card processing; payments handled by external gateway" +``` + +## Configuration schema + +### `version` + +Required. Currently `"1.0"`. + +### `industry` + +Required. Activates the matching industry profile. Values: `telco`, `healthcare`, `financial`. + +### `principle_overrides` + +Optional. Override the default priority for a principle within the selected industry. + +| Field | Required | Description | +|-------|----------|-------------| +| `principle` | Yes | PbD principle ID (e.g., `PbD-04`) | +| `priority` | Yes | New priority: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` | +| `justification` | Yes | Why this override exists | + +### `custom_checks` + +Optional. Add org-specific checks beyond the industry profile. + +| Field | Required | Description | +|-------|----------|-------------| +| `principle` | Yes | Which principle this check maps to | +| `check` | Yes | Description of the check | +| `severity` | Yes | Finding severity if check fails: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` | + +### `suppressions` + +Optional. Suppress checks that don't apply to this system. + +| Field | Required | Description | +|-------|----------|-------------| +| `check` | Yes | The check description or keyword to suppress | +| `reason` | Yes | Why it doesn't apply | + +## Assessment integration + +When the Privacy Reviewer assesses a system: + +1. Load `.pbd-config.yml` if present (or infer industry from codebase). +2. Adjust principle checklist weighting based on industry priority. +3. Add industry-specific checks to the assessment protocol. +4. Apply custom checks from the configuration. +5. Skip suppressed checks. +6. Report findings with industry context (which regulation triggers the requirement). + +A principle marked CRITICAL in the industry profile that receives a FAIL verdict produces a CRITICAL-severity finding (elevated from the default tier-based severity). + +--- + +Industry profiles are original content (CC BY 4.0) synthesized from sector-specific privacy engineering practices. Regulatory references are paraphrased with attribution for planning use, not legal interpretation.