Privacy Check Skill

Privacy by Design assessment.

Workflow

7 Foundational Principles (Cavoukian)

1. Proactive not Reactive: Are privacy measures built in from the start?

   • Privacy considered in design phase, not bolted on
   • Risks identified before implementation

2. Privacy as Default: Is the most private option the default?

   • Data collection opt-in, not opt-out
   • Minimum data collected by default
   • Sharing disabled by default

3. Privacy Embedded in Design: Is privacy integral to the system?

   • Privacy controls are core features, not add-ons
   • Architecture supports data minimization

4. Positive-Sum, not Zero-Sum (originally "Full Functionality"): Privacy without trade-offs?

   • Privacy features don't degrade user experience
   • Not a false choice between privacy and functionality
   • Avoid false dichotomies: privacy vs. security, privacy vs. business value

5. End-to-End Security: Data protected throughout its lifecycle?

   • Encryption at rest and in transit
   • Secure deletion when no longer needed
   • Access controls throughout the data lifecycle

6. Visibility and Transparency: Is data processing transparent?

   • Users know what data is collected and why
   • Processing purposes documented and communicated
   • Third-party sharing disclosed

7. Respect for User Privacy: Are user interests centered?

   • Users can access their data
   • Users can correct their data
   • Users can delete their data
   • Consent is informed, specific, and revocable

Data Protection Assessment

• What data is collected? List all personal data fields.
• Why? Lawful basis for each data element.
• How long? Retention period for each data type.
• Who accesses it? List all parties with access.
• Where is it stored? Data residency and cross-border transfers.
• How is it protected? Encryption, access control, monitoring.
• What if breached? Incident response plan exists?

Output

## Privacy Assessment: [Feature/System]

### PbD Principles
| Principle | Status | Notes |
|-----------|--------|-------|
| Proactive | Pass/Fail | ... |
| Default privacy | Pass/Fail | ... |
| Embedded | Pass/Fail | ... |
| Full functionality | Pass/Fail | ... |
| End-to-end security | Pass/Fail | ... |
| Transparency | Pass/Fail | ... |
| User respect | Pass/Fail | ... |

### Data Inventory
| Data | Purpose | Basis | Retention | Protection |
|------|---------|-------|-----------|-----------|
| ... | ... | ... | ... | ... |

### Risks and Recommendations
1. [risk and recommended action]

Canvas (MANDATORY — the source of truth, do this FIRST)

.claude/canvas/privacy-assessment.yml is the canonical record. The decision log is provenance; the canvas is what the framework READS. Write the canvas before the decision log — if only one of the two lands, it must be this one.

WHY THIS SECTION EXISTS (v0.170.0). On the dogfood project this file carried last_assessed: 2026-05-04 while all seven Privacy-by-Design principles read assessment: not-assessed with empty evidence, and data_inventory was empty. A date asserting an assessment that never landed is worse than an empty file: a reader checking freshness sees an assessed record, and the Privacy theory gate — Required at L2-L4 — reads it. Never stamp last_assessed in a run that does not also fill the principles.

UPDATE each of the seven keys in principles (proactive_not_reactive, privacy_as_default, privacy_embedded, full_functionality, end_to_end_security, visibility_transparency, respect_for_users):

  <principle_key>:
    assessment: pass|partial|fail|not-assessed
    evidence: "<what was observed, and where>"

Then: data_inventory (what personal data the product actually touches — an empty list is a CLAIM that it touches none, so make it deliberately), dpia_required + dpia_rationale, and last_assessed.

last_assessed IS A CLAIM ABOUT THE PRINCIPLES BELOW IT. Set it only when they were filled in the same run. If the assessment is partial, say which keys were judged in dpia_rationale rather than dating the whole file.

Postflight: Verify-After-Write (write-narration-verification discipline)

Hard rule (per CLAUDE.md Communication Rules, anti-pattern #7 Stage 2 graduation). Before any user-facing summary claims the assessment was recorded, use the Read tool on the canvas file and confirm the VALUE fields above actually changed — not just _meta.last_validated. A stamp moving while the assessed fields stay at their defaults is the exact failure this skill shipped with: the file reads fresh and holds nothing. Preflight protects what gets written; Postflight protects what gets claimed about what was written.

Decision Log (MANDATORY per G-P4)

APPEND a ### Privacy Assessment entry to .claude/harness/decision-log.md with: principles assessed, data flows identified, risks found, GDPR compliance status.

Theory Citations

• Cavoukian: Privacy by Design (7 principles)
• GDPR: Data protection regulation