Privacy Implementation Patterns¶

Engineering Patterns

This page provides concrete implementation patterns for privacy requirements. Every pattern maps to a GDPR article and a Cavoukian principle. Use these patterns as building blocks — do not invent your own privacy mechanisms.

GDPR Article 6 requires a legal basis for processing personal data. Consent (Art. 6(1)(a)) is the most common basis for optional processing. Consent must be freely given, specific, informed, and unambiguous.

Never use a single "I agree to everything" checkbox. Consent must be purpose-specific.

Pattern: Purpose-Based Consent Records

consent_records:
  - user_id: pseudonymized_id
    purpose: "marketing_email"
    granted: true
    timestamp: "2026-03-26T10:00:00Z"
    version: "privacy-policy-v3"
    method: "explicit_checkbox"
    ip_hash: "sha256:..."
  - user_id: pseudonymized_id
    purpose: "analytics"
    granted: false
    timestamp: "2026-03-26T10:00:00Z"
    version: "privacy-policy-v3"
    method: "explicit_checkbox"
    ip_hash: "sha256:..."

Each purpose is a separate consent record. Each record captures when, how, and what version of the privacy policy was active at the time of consent.

Withdrawing consent must be as easy as giving it. GDPR Article 7(3): "It shall be as easy to withdraw as to give consent."

Pattern: Consent Withdrawal

Consent management UI accessible from user profile
One-click withdrawal per purpose
Withdrawal triggers immediate cessation of processing for that purpose
Withdrawal does not affect lawfulness of prior processing
Withdrawal timestamp recorded alongside original consent

When the privacy policy changes, existing consent may be invalidated. The system must track which policy version each consent relates to.

Pattern: Policy Version Binding

privacy_policies:
  - version: "v3"
    effective_date: "2026-01-01"
    purposes:
      - id: "marketing_email"
        description: "Send promotional emails about new features"
      - id: "analytics"
        description: "Aggregate usage statistics to improve the product"

consent_records:
  - policy_version: "v3"   # Bound to specific version
    purpose: "marketing_email"
    # If v4 adds new processing to "marketing_email",
    # existing v3 consent does NOT cover v4 processing

Purpose Limitation¶

GDPR Article 5(1)(b): Personal data shall be collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes.

Data Model Design¶

Purpose limitation is enforced at the schema level.

Pattern: Purpose-Tagged Data

Every personal data field has a declared purpose. Data cannot be queried or processed outside its declared purpose.

CREATE TABLE user_data (
    id UUID PRIMARY KEY,
    user_id UUID NOT NULL,
    field_name TEXT NOT NULL,
    field_value TEXT NOT NULL,  -- encrypted
    purpose TEXT NOT NULL,      -- declared purpose
    legal_basis TEXT NOT NULL,  -- consent, contract, legitimate_interest
    collected_at TIMESTAMPTZ NOT NULL,
    expires_at TIMESTAMPTZ,    -- retention limit
    CONSTRAINT valid_purpose CHECK (purpose IN (
        'service_delivery', 'billing', 'marketing', 'analytics', 'support'
    ))
);

Application code queries data with purpose context:

// Good: purpose-scoped query
const email = await getUserData(userId, 'email', { purpose: 'billing' });

// Bad: unscoped query — rejected by data access layer
const email = await getUserData(userId, 'email');

Cross-Purpose Processing¶

If data collected for purpose A is needed for purpose B, this requires either: - Compatible purpose assessment (documented) - New consent for purpose B - Another legal basis for purpose B

Never silently reuse data across purposes.

Storage Limitation¶

GDPR Article 5(1)(e): Personal data shall be kept for no longer than is necessary for the purposes for which it is processed.

Retention Policies¶

Every data category has a defined retention period. Retention is automated, not manual.

Pattern: Automated Retention Enforcement

retention_policies:
  - category: "account_data"
    retention: "account_lifetime + 30 days"
    trigger: "account_deletion"
    action: "hard_delete"

  - category: "transaction_records"
    retention: "7 years"  # Legal requirement
    trigger: "transaction_date"
    action: "anonymize"   # Keep for reporting, remove PII

  - category: "support_tickets"
    retention: "2 years"
    trigger: "ticket_closure_date"
    action: "hard_delete"

  - category: "analytics_events"
    retention: "90 days"
    trigger: "event_date"
    action: "hard_delete"

  - category: "audit_logs"
    retention: "3 years"
    trigger: "log_date"
    action: "hard_delete"

A scheduled job runs daily to enforce retention policies. Enforcement is logged for audit.

Automated Deletion¶

Deletion is not "mark as deleted." Deletion is removal from all stores.

Deletion checklist:

[ ] Primary database record deleted
[ ] Cache entries invalidated
[ ] Search index entries removed
[ ] File storage objects deleted
[ ] CDN cache purged
[ ] Backup retention policy accounts for this
[ ] Log entries containing PII redacted or expired
[ ] Third-party processors notified (Art. 17(2))

Data Minimization¶

Collect only what is needed. Not what might be useful someday.

Collection Minimization¶

Pattern: Schema-Level Minimization

The data model defines the maximum set of fields. Fields not in the schema cannot be stored. Every field has a documented justification.

user_profile:
  fields:
    - name: "email"
      required: true
      purpose: "service_delivery"
      justification: "Required for account login and notifications"
    - name: "display_name"
      required: false
      purpose: "service_delivery"
      justification: "Shown in UI for personalization"
    # NOT collected:
    # - date_of_birth (not needed for service)
    # - phone_number (not needed unless SMS verification chosen)
    # - address (not needed unless physical delivery involved)

Pseudonymization¶

GDPR Recital 28 identifies pseudonymization as a safeguard. Pseudonymize at the earliest possible point.

Pattern: Early Pseudonymization

User Input → API Gateway → [Pseudonymize] → Application → Database
                                ↑
                          Pseudonymization happens HERE,
                          not at the database layer

Pseudonymization separates identity from behavior:

Store	Contains	Example
Identity Store	Real identity ↔ Pseudonym mapping	`email: user@example.com → pseudo_abc123`
Application Store	Pseudonymized records	`pseudo_abc123 performed action X`

The identity store has stricter access controls. Most application code never sees real identities.

Pseudonymization vs. Anonymization¶

	Pseudonymization	Anonymization
Reversible	Yes, with the key	No
Still personal data	Yes (GDPR applies)	No (GDPR does not apply)
Use case	Operational processing	Analytics, research
Method	Tokenization, hashing with key	Aggregation, k-anonymity, differential privacy

Pseudonymized data is still personal data under GDPR. Only truly anonymized data falls outside GDPR scope.

Encryption Patterns¶

At Rest¶

All personal data is encrypted at rest.

Layer	Method	Key Management
Database	Transparent Data Encryption (TDE)	Database-managed
File storage	AES-256-GCM per object	Vault-managed
Backups	Full backup encryption	Vault-managed, separate key
Field-level	Application-layer encryption	Vault-managed, per-tenant key

Field-Level Encryption¶

For highly sensitive fields (health data, financial data, government IDs), use application-layer encryption in addition to TDE.

Pattern: Envelope Encryption

1. Generate a Data Encryption Key (DEK) per record
2. Encrypt the field value with the DEK
3. Encrypt the DEK with a Key Encryption Key (KEK) from Vault
4. Store: encrypted_value + encrypted_DEK
5. To decrypt: get KEK from Vault → decrypt DEK → decrypt value

Benefits: - Key rotation affects only the KEK, not every record - Per-record DEKs limit blast radius of key compromise - Vault access is audited — every decryption is logged

In Transit¶

TLS 1.3 for all external communication
mTLS for internal service-to-service communication
Certificate pinning for mobile clients
No mixed content (HTTP + HTTPS)

Privacy-Preserving Analytics¶

GE builds analytics that provide business value without compromising user privacy.

Traditional web analytics rely on third-party cookies, tracking pixels, and fingerprinting. All of these require consent under GDPR and the ePrivacy Directive.

Pattern: Server-Side Analytics

Client → Server → [Strip PII] → Analytics Store

Collected:
- Page path (not full URL with query parameters)
- Timestamp (rounded to hour)
- Country (from IP, IP not stored)
- Device category (mobile/desktop/tablet)
- Referrer domain (not full URL)

NOT collected:
- IP address
- User agent string (fingerprinting risk)
- Cookies or identifiers
- Cross-session tracking

Aggregation-First¶

Individual events are aggregated before storage. No individual-level analytics data persists beyond the aggregation window.

Raw events (1 hour window) → Aggregate → Store aggregates → Delete raw events

Differential Privacy¶

For statistical queries on sensitive data, add calibrated noise to prevent re-identification.

Use cases: salary benchmarks, health statistics, demographic analysis.

Right to Delete (Right to Erasure)¶

GDPR Article 17 grants data subjects the right to erasure. Implementation must be thorough and auditable.

Cascade Delete¶

Deleting a user account must cascade to all related data across all systems.

Pattern: Deletion Registry

deletion_cascade:
  user_account:
    - table: "user_profiles"
      action: "hard_delete"
    - table: "user_preferences"
      action: "hard_delete"
    - table: "orders"
      action: "anonymize"  # Keep for financial records
    - table: "support_tickets"
      action: "hard_delete"
    - table: "analytics_events"
      action: "hard_delete"
    - table: "audit_logs"
      action: "pseudonymize"  # Keep structure, remove identity
    - service: "email_provider"
      action: "api_delete"
    - service: "payment_processor"
      action: "api_delete"
    - store: "file_storage"
      action: "delete_user_directory"
    - store: "search_index"
      action: "remove_user_documents"

Audit Trail Preservation¶

Deletion must be auditable without preserving the deleted data.

Pattern: Deletion Audit Record

{
  "event": "user_data_deleted",
  "timestamp": "2026-03-26T10:00:00Z",
  "requester": "data_subject",
  "request_id": "del_abc123",
  "scope": "full_account",
  "systems_affected": [
    "user_profiles", "user_preferences", "orders",
    "support_tickets", "analytics_events", "audit_logs",
    "email_provider", "payment_processor", "file_storage",
    "search_index"
  ],
  "completion_status": "complete",
  "verification": "sha256_hash_of_deletion_log"
}

The audit record contains no personal data. It proves that deletion occurred without revealing what was deleted.

Backup Handling¶

Backups complicate the right to delete.

Pattern: Backup Deletion Strategy

Rolling backups with retention period (30 days)
Deletion request recorded in a "deletion ledger"
When a backup is restored, the deletion ledger is replayed
This ensures deleted data does not resurface from backups
Document this process for data subjects who ask

Data Subject Rights Implementation¶

GDPR Articles 15-22 grant data subjects extensive rights. Each must be implementable programmatically.

Right	Article	Implementation
Access	Art. 15	Export all data in machine-readable format
Rectification	Art. 16	Edit personal data through account settings
Erasure	Art. 17	Cascade delete (see above)
Restrict Processing	Art. 18	Flag account, pause all non-essential processing
Data Portability	Art. 20	Export in JSON/CSV, import capability
Object	Art. 21	Opt-out of specific processing purposes
Automated Decisions	Art. 22	Human review option for AI-driven decisions

Response deadline: 30 days from request receipt. Extension: up to 60 additional days for complex requests (with notice).

Data Processing Agreements¶

When GE builds systems that involve third-party processors, a Data Processing Agreement (DPA) is required under GDPR Article 28.

DPA must include:

Subject matter and duration of processing
Nature and purpose of processing
Types of personal data and data subject categories
Obligations and rights of the controller
Sub-processor approval requirements
Data breach notification obligations
Audit rights
Data return and deletion upon termination

Eric handles DPA review and execution during client onboarding.