AutoGineer
Generated banner for Privacy By Design
Generated logo for Privacy By Design

Privacy By Design

MicrosoftOfficialPublished by Microsoft

  • Skill
  • Guidelines
  • Security
  • CC-BY-4.0
  • No issues found
Download ZIP

From the author

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).
— the description by Microsoft

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The Privacy by Design (PbD) skill provides a comprehensive knowledge base and assessment protocol for evaluating software systems against the 7 Foundation Principles established by Dr. Ann Cavoukian. It enables users to conduct proactive privacy reviews, identify deficiencies, and map findings to regulatory requirements including GDPR, CCPA/CPRA, and Australian Privacy Principles. The skill includes structured checklists, implementation patterns, and a finding schema to ensure consistent, evidence-based privacy assessments across the development lifecycle.

What it does

  • Assesses system designs against the 7 Foundation Principles of Privacy by Design.
  • Provides a structured protocol for conducting privacy impact assessments.
  • Maps privacy findings to GDPR, CCPA/CPRA, and Australian Privacy Principles.
  • Evaluates data retention, disposal, and lifecycle management practices.
  • Identifies privacy-related anti-patterns in architecture and configuration.
  • Generates actionable remediation items for identified privacy deficiencies.

When to use it

  • During the design phase of a new system or feature involving personal data.
  • When performing a proactive privacy audit to identify potential compliance gaps.
  • To verify that privacy controls are embedded into the architecture rather than added post-deployment.
  • When establishing data retention and disposal schedules for sensitive information.
  • To generate structured privacy assessment reports for stakeholders.

Advantages

  • Promotes a proactive, preventative approach to privacy rather than reactive compliance.
  • Standardizes privacy assessments using a clear, evidence-based schema.
  • Facilitates cross-jurisdictional compliance mapping.
  • Integrates privacy considerations directly into the software development lifecycle.
  • Provides clear, actionable remediation guidance for identified risks.

Usage examples

“Assess our new user registration flow against the 7 Privacy by Design principles.”
The agent will walk through each of the 7 principles, checking for proactive design, default privacy settings, and end-to-end security, ultimately providing a compliance verdict and specific remediation steps.
“Check our data retention policy for compliance with PbD-05.”
The agent will evaluate the current retention and disposal lifecycle against Principle 05, identifying gaps in data minimization or legal hold procedures and suggesting improvements.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/microsoft/privacy-by-design/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip privacy-by-design.zip -d .agents/skills

Documentation by Microsoft

Privacy by Design

This SKILL.md is the entrypoint for the Privacy by Design skill.

The skill provides structured assessment references for the 7 Foundation Principles of Privacy by Design (Cavoukian, 2009). Consumers that explicitly load it can assess privacy practices across the software lifecycle. It complements privacy-standards with principle-level criteria, retention and disposal checks, regulatory mappings, a finding schema and implementation patterns. Current agent wiring is described under Integration below.

[!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 an evidence-based assessment against the 7 PbD Foundation Principles, with per-principle verdicts, explicit evidence gaps, deficiency severity, and remediation for established deficiencies. Assessment labels describe this planning rubric, not legal certification.

Success criteria

  • All 7 principles have a verdict, evidence completeness, and severity (N/A when no deficiency is established).

  • 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 assessment verdict (COMPLIANT / PARTIALLY_COMPLIANT / NON_COMPLIANT / INCOMPLETE) is determined without treating missing evidence as a failed control.

  • Finding, principle, checklist and severity counts reconcile under the finding schema.

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/PARTIAL/FAIL/INSUFFICIENT_EVIDENCE results with evidence-backed severity

  • 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 the evidence needed. Continue supported checks without inventing deficiency remediation for unknowns.

  • 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

  2. 01 Proactive Not Reactive

  3. 02 Privacy as the Default

  4. 03 Privacy Embedded into Design

  5. 04 Full Functionality

  6. 05 End-to-End Security

  7. 06 Visibility and Transparency

  8. 07 Respect for User Privacy

Operational references

Supplementary references

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

SeverityMeaning
CRITICALEstablished deficiency with severe direct risk, or FAIL under an effective CRITICAL industry priority
HIGHPrinciple is violated with direct risk to data subjects
MEDIUMPrinciple is partially met; gaps exist that could lead to non-compliance
LOWMinor gap; principle intent is largely met but documentation or controls could improve
N/ANo deficiency established, including PASS and unknown-only results

Data sensitivity informs the impact of a proven deficiency; it does not create one. Preserve CRITICAL in records and summaries. CRITICAL and HIGH map to P1, with CRITICAL ordered first; MEDIUM maps to P2 and LOW to P3. PASS and unknown-only results do not create remediation backlog items.

Finding verdict conventions

VerdictMeaning
PASSAll applicable checks are MET, with no unresolved evidence or anti-patterns
PARTIALA deficiency is established but the FAIL threshold is not met
FAILMore than half of applicable checks are NOT MET, or an uncompensated critical anti-pattern is established
INSUFFICIENT_EVIDENCENo deficiency established, but unknown evidence or zero applicable checks prevents PASS

Apply the ordered rules in the assessment protocol. Record evidence completeness independently so a proven deficiency is not hidden by unknown checks. Suppressions require a documented applicability reason and do not count as MET.

Overall assessment verdicts

VerdictCondition
NON_COMPLIANTOne or more principles are FAIL; retain any evidence gaps separately
INCOMPLETENo FAIL, but any principle or applicable retention/jurisdiction check has incomplete evidence
PARTIALLY_COMPLIANTComplete evidence, no FAIL, and at least one PARTIAL
COMPLIANTComplete evidence and all 7 principles PASS

Evaluate these rows in order. Never use null for a verdict or interpret an unknown jurisdictional baseline as met or failed.

Integration with Privacy Planner and Reviewer

This skill complements privacy-standards (which provides the NIST PF, GDPR, CCPA, OWASP backbone). A consumer performing PbD assessment should explicitly load both:

  • privacy-standards — standards mapping, data-flow reasoning, DPIA thresholds

  • privacy-by-design — principle-level assessment, retention/disposal checks, cross-jurisdictional equivalence, implementation pattern verification

The current Privacy Planner and Privacy Reviewer do not explicitly load privacy-by-design. This skill supplies assessment knowledge, not automatic integration; dedicated agent wiring is outside this skill change. It remains background-only (user-invocable: false).

Interaction with other skills

SkillRelationship
privacy-standardsProvides data inventory, DPIA thresholds, and standards backbone; PbD builds on top
security-planningSecurity controls overlap with PbD-05; reference rather than duplicate
rai-plannerRAI data-use concerns feed into PbD-04 (full functionality) and PbD-07 (user respect)
secure-by-designSBD-11 (Secure Deprecation) aligns with PbD-05 lifecycle; cross-reference for decommissioning

Attribution and licensing posture

SKILL.md and references/ contain original assessment guidance and paraphrased summaries under CC BY 4.0. The cited publications remain authoritative and retain their own rights; this license does not relicense upstream text. Principle names and legal identifiers are preserved for traceability. No upstream document is reproduced or bundled.

Cavoukian PbD Foundation Principles

  • Author: Dr. Ann Cavoukian, Information and Privacy Commissioner of Ontario

  • Source: https://www.ipc.on.ca/sites/default/files/legacy/2018/01/pbd.pdf

  • 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)
Australian Privacy Principles (APP)
CCPA/CPRA

Files

references/finding-schema.md

title: Finding Schema description: Structured output format for PbD assessment findings from consumers that explicitly load the privacy-by-design skill

Finding Schema

Consumers that explicitly load privacy-by-design use this schema for consistent, machine-readable assessment results and potential review or backlog handoff. The schema does not establish automatic loading by existing agents or authorize tracker mutations.

Finding record structure

Each finding is a discrete assessment result for one principle or sub-check.

finding:
  id: "PBD-<principle_number>-<sequence>"  # e.g., PBD-01-001
  principle: "PbD-<number>"                # e.g., PbD-01
  principle_name: "<short name>"           # e.g., Proactive Not Reactive
  category: "<category>"                   # e.g., Prevention
  verdict: "PASS | PARTIAL | FAIL | INSUFFICIENT_EVIDENCE"
  evidence_status: "COMPLETE | INCOMPLETE"
  severity: "CRITICAL | HIGH | MEDIUM | LOW | N/A"
  title: "<concise finding title>"
  description: "<what was found>"
  evidence: "<what evidence supports this finding>"
  remediation: "<specific actionable fix>"  # Only for PARTIAL and FAIL; omit otherwise
  evidence_gaps: ["<missing evidence and how to obtain it>"]  # Empty when complete
  checklist_items_met: <count>
  checklist_items_not_met: <count>
  checklist_items_unknown: <count>
  checklist_items_total: <count>
  checklist_items_suppressed: <count>
  suppressed_checks: [{check: "<check>", reason: "<applicability evidence>"}]
  anti_patterns_detected: ["<pattern1>", "<pattern2>"]  # Empty array if none
  citations:
    pbd_principle: "PbD-<number> <name>"
    gdpr_article: "<Art. N>"               # Optional
    app_principle: "<APP N>"               # Optional
    ccpa_section: "<§section>"             # Optional
    retention_category: "<known category>" # Retention findings when known
    retention_gap: "<established gap>"     # Omit when no gap is established
  affected_principles: ["PbD-05"]         # Required for cross-jurisdictional findings
  jurisdiction_flags: ["GDPR", "CCPA", "APP"]  # Which apply

Assessment summary structure

The summary aggregates all principle findings into a top-level report.

assessment_summary:
  system_name: "<name of assessed system>"
  assessment_date: "<ISO 8601 date>"
  scope: "<boundary description>"
  jurisdictions: ["<jurisdiction1>", "<jurisdiction2>"]
  overall_verdict: "COMPLIANT | PARTIALLY_COMPLIANT | NON_COMPLIANT | INCOMPLETE"
  evidence_status: "COMPLETE | INCOMPLETE"
  findings_count:
    pass: <count>
    partial: <count>
    fail: <count>
    insufficient_evidence: <count>
  severity_distribution:
    critical: <count>
    high: <count>
    medium: <count>
    low: <count>
    not_applicable: <count>
  top_priority_findings:
    - id: "<finding_id>"
      title: "<title>"
      severity: "<severity>"
      remediation: "<brief fix>"
  principles_assessed:
    - principle: "PbD-01"
      verdict: "PASS | PARTIAL | FAIL | INSUFFICIENT_EVIDENCE"
      evidence_status: "COMPLETE | INCOMPLETE"
      severity: "CRITICAL | HIGH | MEDIUM | LOW | N/A"
    - principle: "PbD-02"
      verdict: "PASS | PARTIAL | FAIL | INSUFFICIENT_EVIDENCE"
      evidence_status: "COMPLETE | INCOMPLETE"
      severity: "CRITICAL | HIGH | MEDIUM | LOW | N/A"
    # ... through PbD-07
  retention_assessment:
    conducted: true | false
    evidence_status: "COMPLETE | INCOMPLETE | NOT_APPLICABLE"
    categories_assessed: <count>
    categories_compliant: <count>
    categories_with_gaps: <count>
    categories_unknown: <count>
    gaps_identified: <count>
  cross_jurisdictional:
    jurisdictions_applicable: ["GDPR", "CCPA", "APP"]
    common_baseline_status: "MET | NOT_MET | INSUFFICIENT_EVIDENCE | NOT_APPLICABLE"
    jurisdiction_specific_gaps: <count>

Overall verdict rules

Evaluate rows in order. These are assessment-rubric labels, not legal certification. Unknown evidence never becomes null, a false baseline, or an invented deficiency.

Overall verdictCondition
NON_COMPLIANTAt least one principle FAIL, even if other evidence is incomplete
INCOMPLETENo FAIL, but any principle or applicable retention/jurisdiction assessment has incomplete evidence
PARTIALLY_COMPLIANTComplete evidence, no FAIL, and at least one PARTIAL
COMPLIANTComplete evidence and all 7 principles PASS
Count and completeness invariants

  • checklist_items_total = checklist_items_met + checklist_items_not_met + checklist_items_unknown. The total is the applicable denominator after justified suppressions; suppressed items are not MET or unknown.

  • suppressed_checks records every excluded check and its reason; its length equals checklist_items_suppressed. No applicable checks yields INSUFFICIENT_EVIDENCE, INCOMPLETE evidence, and N/A severity, not PASS.

  • findings_count counts each unique finding record once. Its four buckets sum to the number of records, which may exceed seven when sub-findings exist. Each record also occupies exactly one severity bucket, including not_applicable for N/A; both totals agree.

  • principles_assessed contains exactly one entry for each of PbD-01 through PbD-07, derived from all applicable checks and sub-findings using the protocol. These rollups are not counted again in findings_count.

  • PASS and INSUFFICIENT_EVIDENCE records have N/A severity and omit remediation. PARTIAL and FAIL record only established deficiencies, require remediation, and may also carry independent evidence gaps.

  • Summary evidence is INCOMPLETE if any principle, applicable retention category or jurisdiction obligation is unresolved. A known FAIL still produces NON_COMPLIANT. Every incomplete result names its evidence gaps.

  • categories_assessed counts all in-scope retention categories, including unknowns, and equals categories_compliant + categories_with_gaps + categories_unknown. Assign a category with any proven gap to categories_with_gaps even if other evidence is unknown; preserve its evidence gaps independently. gaps_identified counts distinct proven retention gaps, not categories or missing evidence.

  • No stored personal data makes retention NOT_APPLICABLE with zero counts. Missing retention evidence for stored personal data makes it INCOMPLETE, not NOT_APPLICABLE.

  • The common baseline is NOT_MET if a common applicable obligation is demonstrably unmet, otherwise INSUFFICIENT_EVIDENCE if any remains unknown, otherwise MET. Use NOT_APPLICABLE only when no common baseline applies, with a reason; retain jurisdiction-specific gaps and evidence requests separately.

Evidence requests and priority ordering

List missing evidence and the smallest request that would resolve it in evidence_gaps; do not generate remediation backlog items for unknown-only results. top_priority_findings contains only PARTIAL/FAIL findings, ordered CRITICAL, HIGH, MEDIUM, LOW, with FAIL before PARTIAL within a tier. Preserve original severity when mapping to backlog priority.

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:

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: CRITICAL→P1, 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:

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 | "UNKNOWN"
  legal_hold_capable: true | false | "UNKNOWN"
  gap_type: "undefined_period | excessive_retention | no_disposal | no_backup_coverage | no_legal_hold" # Only for an established gap

These fields extend the base finding rather than replacing its verdict, severity, completeness, evidence and citations. Populate retention_category when known and retention_gap only for an established gap. Use "unknown" for unavailable period/method evidence; "undefined" or "none defined" asserts verified absence. Unknown backup or legal-hold capability does not mean false and does not justify a gap type. Record a supported legal-hold exception before concluding retention is excessive.

Example finding

finding:
  id: "PBD-02-001"
  principle: "PbD-02"
  principle_name: "Privacy as the Default"
  category: "Default Settings"
  verdict: "FAIL"
  evidence_status: "COMPLETE"
  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_not_met: 5
  checklist_items_unknown: 0
  checklist_items_total: 8
  checklist_items_suppressed: 0
  suppressed_checks: []
  evidence_gaps: []
  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.

Source principles: IPC Ontario, Privacy by Design. Schema and aggregation rules are repository-original planning guidance.

Requirements and compatibility

Written for: GitHub Copilot, Claude Code

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Claude Code frontmatter

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Microsoft
Publisher
Microsoft (Official)
Source
microsoft/hve-core · .github/skills/project-planning/privacy-by-design · commit f425e94
Licence
Creative Commons Attribution 4.0 International (redistribution allowed)
  • LICENSE (written by AutoGineer)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Microsoft.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download privacy-by-design.zip