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

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

Pseudonymization with HMAC

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

-- 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;