# Privacy By Design

> When to activate: privacy by design, PbD, DPIA, data minimization, purpose limitation, privacy impact assessment, privacy engineering, pseudonymization

- Skill: `mattakushi432/privacy-by-design` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mattakushi432/privacy-by-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mattakushi432/privacy-by-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Mattakushi432 (https://skillmd.com/u/mattakushi432)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mattakushi432/privacy-by-design

---


# Privacy by Design

## 7 Foundational Principles (Ann Cavoukian)

| # | Principle | In practice |
|---|-----------|-------------|
| 1 | Proactive not reactive | Build privacy in from the start; don't bolt on after |
| 2 | Privacy as the default | Default settings protect privacy; users opt IN to sharing |
| 3 | Privacy embedded into design | Not an add-on; integral to system architecture |
| 4 | Full functionality (positive-sum) | Privacy AND security AND functionality — not zero-sum |
| 5 | End-to-end security | Data protected throughout full lifecycle |
| 6 | Visibility and transparency | Openness about policies and practices |
| 7 | Respect for user privacy | User-centric: keep it user-friendly and privacy-protective |

## DPIA Trigger Checklist

A Data Protection Impact Assessment is required when processing is "likely to result in a high risk." Conduct a DPIA if **2 or more** apply:

- [ ] Systematic and extensive profiling or automated decision-making with legal effects
- [ ] Processing special category / sensitive data at scale
- [ ] Systematic monitoring of publicly accessible areas (CCTV, location tracking)
- [ ] New technology being deployed
- [ ] Processing data of vulnerable individuals (children, employees, patients)
- [ ] Matching or combining datasets beyond original collection purpose
- [ ] Large-scale processing of personal data
- [ ] Invisible processing (data not collected directly from subject)
- [ ] Cross-border data transfers to countries without adequacy decisions

## DPIA Process

### Step 1: Describe the Processing
- What personal data is collected?
- Who are the data subjects?
- What is the purpose and legal basis?
- Who are the recipients (internal and third parties)?
- Where is data stored and transferred?
- How long is it retained?

### Step 2: Assess Necessity and Proportionality
- Is the processing necessary for the stated purpose?
- Is there a less privacy-invasive way to achieve the same goal?
- Is the legal basis appropriate and documented?
- Are data subjects adequately informed?

### Step 3: Identify and Assess Risks

| Risk | Likelihood (1-5) | Severity (1-5) | Score | Mitigation |
|------|-----------------|----------------|-------|------------|
| Unauthorized access | | | | |
| Data breach / exposure | | | | |
| Excessive data collection | | | | |
| Purpose creep | | | | |
| Inaccurate data leading to harm | | | | |

### Step 4: Identify Mitigations
- Technical controls (encryption, access control, pseudonymization)
- Organizational controls (policies, training, contracts)
- Design changes (data minimization, shorter retention)

### Step 5: Consult DPO (if applicable)
- If residual risk remains high after mitigation → consult supervisory authority before processing

### Step 6: Document and Sign Off
- Document findings and decisions
- Obtain approval from data controller / DPO
- Schedule review date (at least when processing changes materially)

## Data Minimization Techniques

| Technique | Description | Example |
|-----------|-------------|---------|
| Collection limitation | Only collect what's needed for the purpose | Don't collect DOB if only age verification needed |
| Retention limitation | Delete when no longer needed | Auto-purge logs after 90 days |
| Access limitation | Restrict who can see data | Mask PAN except last 4 digits for support agents |
| Aggregation | Use aggregate stats instead of individual records | Cohort analytics instead of user-level tracking |
| Pseudonymization | Replace identifiers with tokens | Replace email with user_id in analytics events |
| Anonymization | Remove all identifying information | Publish research data with k-anonymity applied |

## Purpose Limitation Implementation

### Definition
Data collected for Purpose A must not be used for Purpose B without either:
- A new, compatible purpose (assess compatibility — link to original)
- Fresh consent for the new purpose
- A specific legal basis for the new purpose

### Compatibility Assessment Factors
1. Link between original and new purpose
2. Context of collection (subject's reasonable expectations)
3. Nature of data (sensitive data → stricter)
4. Consequences for data subjects
5. Existence of safeguards

### Technical Enforcement
- Tag data records with collection purpose at ingestion
- Enforce purpose tags in data access layer (deny cross-purpose queries)
- Audit logs for all data access with purpose declared

## Pseudonymization vs Anonymization

| | Pseudonymization | Anonymization |
|-|-----------------|---------------|
| Definition | Replace identifiers; re-identification possible with key | Remove all identifiers; re-identification not possible |
| Still personal data? | **Yes** — GDPR still applies | **No** — GDPR does not apply |
| Reversible? | Yes (with key) | No |
| Risk | Key compromise = re-identification | Residual inference risk |
| Use case | Analytics, research with need for re-linking | Publishing, open data, sharing |
| Techniques | Tokenization, hashing with salt | K-anonymity, l-diversity, differential privacy |

## Privacy Risk Scoring Matrix

| Likelihood | Low impact | Medium impact | High impact |
|-----------|-----------|---------------|-------------|
| High | Medium risk | High risk | Critical risk |
| Medium | Low risk | Medium risk | High risk |
| Low | Negligible | Low risk | Medium risk |

**Action by level:**
- Critical: Do not proceed without DPA consultation + significant redesign
- High: Mandatory mitigation + DPIA sign-off
- Medium: Mitigate and document
- Low/Negligible: Document and monitor

## Privacy Review Checklist for New Features

Before launching any feature that processes personal data:

- [ ] Data minimization: only collecting what's needed?
- [ ] Legal basis identified and documented?
- [ ] Purpose documented and communicated to users?
- [ ] Retention period defined and enforced technically?
- [ ] Data encrypted at rest and in transit?
- [ ] Access controls applied (least privilege)?
- [ ] Third-party data sharing identified and contractually covered?
- [ ] DPIA completed (if high-risk processing)?
- [ ] User rights supported (access, deletion, portability)?
- [ ] Privacy notice updated to reflect new processing?
- [ ] Data breach response plan covers this new data type?

## Privacy Engineering Patterns

### Data Masking
```sql
-- Display only last 4 digits of payment card
SELECT
  customer_id,
  CONCAT('****-****-****-', RIGHT(card_number, 4)) AS masked_card
FROM payments;
```

### Pseudonymization with HMAC
```python
import hmac, hashlib
def pseudonymize(email: str, secret_key: bytes) -> str:
    return hmac.new(secret_key, email.encode(), hashlib.sha256).hexdigest()
```

### Differential Privacy (concept)
Add calibrated noise to aggregate queries so individual records cannot be inferred:
- Laplace mechanism for numeric queries
- Randomized response for categorical data
- Budget tracking: each query consumes epsilon budget

### Aggregation Instead of Individual Tracking
```sql
-- Instead of: SELECT user_id, page_views FROM sessions
-- Use:
SELECT
  DATE_TRUNC('day', session_date) AS day,
  COUNT(DISTINCT user_id) AS unique_visitors,
  SUM(page_views) AS total_page_views
FROM sessions
GROUP BY 1;
```