Design architecture with data minimization

Design Architecture with Data Minimization

Data minimization means collecting, storing, and exposing only what is strictly necessary for a defined purpose. Building this into architecture reduces attack surface, lowers breach impact, simplifies DSARs, and aligns with GDPR and CPRA requirements.

Model Only What You Need

• Define the purpose for every field before adding it to the schema.

• Prefer progressive profiling so nonessential fields are captured later or not at all.

• Use allowlists for accepted attributes in APIs and events.

Separate Identity From Behavior

• Store PII in a dedicated store and keep behavioral data pseudonymous.

• Use a stable internal subject_id that is not an email or phone.

• Join PII to events only when strictly required and log joins.

Gate Collection on Consent and Purpose

• Drive collection from consent flags and declared purposes.

• Block writes for nonessential data when consent is absent.

• Re-check consent on scope changes.

Trim Logs and Telemetry

• Do not log request bodies or full payloads by default.

• Redact by default and sample sparingly.

• Drop or truncate IPs unless strictly needed.

Aggregate and Anonymize Early

• Convert raw events to aggregates near the edge.

• Use k-anonymity thresholds for reports and consider differential privacy.

Limit Access and Sharing

• Enforce column and row level security for PII.

• Expose minimal views to internal consumers and vendors.

• Keep API responses lean and purpose bound.

Retain Briefly and Design for Deletion

• Set short default retention with explicit exceptions.

• Cascade deletions from a single source of truth.

• Purge caches, search indexes, and backups on deletion.

Example: Pseudonymous User Model

Schema split

-- PII store
CREATE TABLE users_pii (
  pii_id UUID PRIMARY KEY,
  email TEXT UNIQUE NOT NULL,
  name TEXT,
  phone TEXT
);

-- Pseudonymous identity
CREATE TABLE subjects (
  subject_id UUID PRIMARY KEY,
  pii_id UUID REFERENCES users_pii(pii_id) ON DELETE CASCADE
);

-- Event data without PII
CREATE TABLE analytics_events (
  id BIGSERIAL PRIMARY KEY,
  subject_id UUID NOT NULL REFERENCES subjects(subject_id),
  event_name TEXT NOT NULL,
  props JSONB NOT NULL,
  occurred_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

Restrict PII with RLS

ALTER TABLE users_pii ENABLE ROW LEVEL SECURITY;
CREATE POLICY pii_no_read ON users_pii
  FOR SELECT USING (false); -- only privileged role can grant access

Deterministic pseudonymous ID

# subject_id derived from email using a secret pepper
import hmac, hashlib, uuid
def subject_id_for(email, pepper):
    digest = hmac.new(pepper.encode(), email.strip().lower().encode(), hashlib.sha256).digest()
    return str(uuid.UUID(bytes=digest[:16], version=4))

API allowlist and reject unknowns

components:
  schemas:
    Signup:
      type: object
      additionalProperties: false
      required: [email, password]
      properties:
        email: { type: string, format: email }
        password: { type: string, minLength: 12 }

Logging redaction middleware

app.use((req, _res, next) => {
  const safe = { path: req.path, method: req.method, user: req.user?.id || null };
  console.info("req", safe); // never log body or headers with PII
  next();
});

Quick Data Minimization Checklist

• Define a purpose for each field and reject unknown attributes

• Split PII from events and use pseudonymous subject_id

• Gate collection and processing on consent and declared purpose

• Redact logs and keep telemetry minimal

• Set short retention and enforce end to end deletion

Conclusion

Architecting for data minimization shrinks the blast radius of incidents, makes user rights easy to fulfill, and proves necessity and proportionality to regulators. By separating PII, limiting collection, and enforcing tight access and retention, teams meet legal requirements while keeping systems simpler and safer.