Privacy By Design

Privacy by Design

7 Foundational Principles (Ann Cavoukian)

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

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

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

Privacy Risk Scoring Matrix

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;