microsoft · pratik wayase (PratikWayase) · Aug 9, 2026
@@ -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.
@@ -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`.
@@ -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.
@@ -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.
@@ -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}"
+}
@@ -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
@@ -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}