Privacy By Design
MicrosoftOfficialPublished by Microsoft
- Skill
- Guidelines
- Security
- CC-BY-4.0
- No issues found
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
Download the skill as a ZIP:
https://autogineer.com/agent-skills/microsoft/privacy-by-design/downloadUnzip 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/Awhen 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-planningor 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_EVIDENCEand 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-planningskill already covers; cross-reference them.
Normative references (PbD 7 Foundation Principles)
Operational references
Assessment Protocol — step-by-step protocol for conducting a PbD assessment
Finding Schema — structured output format for findings and backlog handoff
Implementation Patterns — pragmatic code-level and architecture-level verification patterns
Supplementary references
Data Retention and Disposal — Principle 05 deep-dive: retention schedules, disposal methods, legal holds
Cross-Jurisdictional Mapping — regulatory equivalence matrix across GDPR, CCPA/CPRA, and APP
Industry Privacy Profiles — sector-specific principle priorities, checks, and
.pbd-config.ymlcustomization
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.01through07— 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.ymlcustomization 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 Reactivegdpr_article: GDPR article reference, e.g.,Art. 25app_principle: Australian Privacy Principle number, e.g.,APP 1ccpa_section: CCPA/CPRA section reference
Finding severity conventions
| Severity | Meaning |
|---|---|
| CRITICAL | Established deficiency with severe direct risk, or FAIL under an effective CRITICAL industry priority |
| 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 |
| N/A | No 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
| Verdict | Meaning |
|---|---|
| PASS | All applicable checks are MET, with no unresolved evidence or anti-patterns |
| PARTIAL | A deficiency is established but the FAIL threshold is not met |
| FAIL | More than half of applicable checks are NOT MET, or an uncompensated critical anti-pattern is established |
| INSUFFICIENT_EVIDENCE | No 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
| Verdict | Condition |
|---|---|
| NON_COMPLIANT | One or more principles are FAIL; retain any evidence gaps separately |
| INCOMPLETE | No FAIL, but any principle or applicable retention/jurisdiction check has incomplete evidence |
| PARTIALLY_COMPLIANT | Complete evidence, no FAIL, and at least one PARTIAL |
| COMPLIANT | Complete 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 thresholdsprivacy-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
| 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
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)
Modifications: Mapped to PbD principles as regulatory equivalence; paraphrased with attribution
Australian Privacy Principles (APP)
Source: https://www.oaic.gov.au/privacy/australian-privacy-principles
Copyright: © Commonwealth of Australia
Modifications: Mapped to PbD principles as cross-jurisdictional equivalence; paraphrased with attribution
CCPA/CPRA
Source: https://oag.ca.gov/privacy/ccpa
Modifications: Mapped to PbD principles as cross-jurisdictional equivalence; paraphrased with attribution
Files
- ATTRIBUTION.mdAdded by AutoGineer977 B
- LICENSEAdded by AutoGineer16.6 KiB
- SKILL.md12.9 KiB
- references/00-principle-index.md4.0 KiB
- references/01-proactive-not-reactive.md4.4 KiB
- references/02-privacy-as-the-default.md4.5 KiB
- references/03-privacy-embedded-into-design.md4.7 KiB
- references/04-full-functionality.md4.4 KiB
- references/05-end-to-end-security.md5.8 KiB
- references/06-visibility-and-transparency.md5.6 KiB
- references/07-respect-for-user-privacy.md5.5 KiB
- references/assessment-protocol.md9.7 KiB
- references/cross-jurisdictional-mapping.md13.3 KiB
- references/data-retention-and-disposal.md7.1 KiB
- references/finding-schema.md10.8 KiB
- references/implementation-patterns.md10.1 KiB
- references/industry-privacy-profiles.md11.3 KiB
references/implementation-patterns.md
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
# 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# 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 consentConsent 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 settingsAPI 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 recordsPbD-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
# 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 collectionPbD-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
# 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: unlimitedDeletion 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 requestsRecords 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" consentAutomated 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 dataPatterns 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.
Source principles: IPC Ontario, Privacy by Design; regulatory basis: GDPR Article 25. Indicators are examples, not proof of a whole-principle PASS; apply the assessment protocol to all applicable evidence.
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 or Microsoft.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download privacy-by-design.zip