Implementing Data Minimization Architecture

Implementing Data Minimization Architecture

Overview

Data minimization is a core principle of the GDPR under Article 5(1)(c), requiring that personal data be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed." Article 25(1) mandates that controllers implement appropriate technical and organisational measures, such as pseudonymisation, designed to implement data-protection principles effectively and to integrate necessary safeguards into the processing.

The European Data Protection Board (EDPB) Guidelines 4/2019 on Article 25 Data Protection by Design and by Default clarify that data minimization applies across four dimensions: the amount of data collected, the extent of processing, the period of storage, and the accessibility of data. ENISA's 2019 report on pseudonymisation techniques provides the technical foundation for implementing these requirements at scale.

Data Minimization Architecture Layers

Layer 1: Collection Minimization

Reduce data at the point of ingestion before it enters backend systems.

Techniques:

Prism Data Systems AG Implementation: Prism Data Systems AG deploys an API gateway validation layer that enforces a strict allowlist of fields per endpoint. The customer onboarding endpoint /api/v2/customers accepts only: email, display_name, country_code, and consent_references[]. Fields like date_of_birth, phone_number, and billing_address are collected only when the customer activates the billing module, implementing progressive collection tied to purpose activation.

Layer 2: Processing Minimization

Reduce the identifiability of data during computation.

Pseudonymization (Article 4(5))

Article 4(5) defines pseudonymisation as "the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures."

ENISA Pseudonymization Techniques (2019 Report):

Prism Data Systems AG Implementation: Prism Data Systems AG uses HMAC-SHA256 pseudonymization for all analytics pipelines. Customer identifiers are pseudonymized at the boundary between the transactional database and the analytics data warehouse. The HMAC key is stored in a Hardware Security Module (HSM) managed by the security operations team, physically and logically separated from the analytics infrastructure per ENISA recommended controls.

Anonymization (Recital 26)

Recital 26 states that the principles of data protection should not apply to anonymous information, namely "information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable." The Article 29 Working Party Opinion 05/2014 on Anonymisation Techniques (WP216) established three risk criteria:

1. Singling out — the ability to isolate a record identifying an individual
2. Linkability — the ability to link two records relating to the same individual
3. Inference — the ability to deduce the value of an attribute from other attributes

Anonymization Techniques:

Layer 3: Storage Minimization

Limit how much identifiable data persists at rest.

Field-Level Encryption Architecture:

                    ┌────────────────────────┐
                    │   Application Layer    │
                    │  (plaintext in memory) │
                    └──────────┬─────────────┘
                               │
                    ┌──────────▼─────────────┐
                    │  Encryption Service    │
                    │  AES-256-GCM per field │
                    │  Key: KMS / HSM        │
                    └──────────┬─────────────┘
                               │
          ┌────────────────────┼────────────────────┐
          │                    │                    │
 ┌────────▼───────┐  ┌────────▼───────┐  ┌────────▼───────┐
 │  email (enc)   │  │  name (enc)    │  │  country (clr) │
 │  DEK-email-v3  │  │  DEK-name-v3   │  │  (not PII)     │
 └────────────────┘  └────────────────┘  └────────────────┘

Each personally identifiable field is encrypted with a dedicated Data Encryption Key (DEK) wrapped by a Key Encryption Key (KEK) in AWS KMS or Azure Key Vault. This enables selective decryption: analytics queries on country never require decrypting email or name.

Prism Data Systems AG Implementation: Prism Data Systems AG classifies all database columns into four sensitivity tiers: