Payroll, GDPR & Multi-tenancy

GDPR Patterns

GDPR is not optional for Personio — it's foundational. Every senior engineer there must have an opinion on right-to-erasure, data residency, and audit logs.

The right-to-erasure decision tree

The actual erasure pipeline

Why anonymize beats hard delete in HR

If you hard-delete an employee, you break:

• Payroll history (FK employee_id dangling).
• Audit trail ("who approved this time off?" → null).
• Manager-report tree (employees who reported to this person).
• Statutory reporting (DE requires 10-year retention of payroll records).

Anonymization preserves the integrity of the record while removing the personal data:

-- Before
employees: { id: emp-42, name: 'Anna Schmidt', email: 'anna@acme.com',
             salary: 4825.50, manager_id: emp-12 }

-- After anonymize
employees: { id: emp-42, name: 'ERASED USER', email: '<erased>',
             salary: 4825.50, manager_id: emp-12,
             erased_at: '2026-05-15', erased_request_id: 'req-9' }

-- Payroll history STILL VALID — emp-42 still exists as a record.
-- Auditor can verify "salary 4825.50 was paid to emp-42 in April 2026"
-- without knowing who that person was.

Data residency strategies

EU customers must have their data stored in EU. Three approaches:

The audit-log exemption (Art. 17(3))

SLAs and timelines

• Acknowledge erasure request: within 1 month.
• Complete erasure: "without undue delay," typically 30 days. Extensions allowed for complex cases.
• Inform third parties: if you shared data with sub-processors (payroll providers, ATS integrations), you must propagate the erasure request to them.

Multi-tenancy Patterns

Personio runs 10k+ tenants on shared infrastructure. Multi-tenancy is in the DNA of every design decision.

The three models

Personio default: Pool with Postgres RLS as a safety net. Move large/regulated tenants to silo as needed.

Pool model essentials

-- Every table has tenant_id as part of the primary key
CREATE TABLE employees (
  tenant_id    UUID NOT NULL,
  employee_id  UUID NOT NULL,
  ...
  PRIMARY KEY (tenant_id, employee_id)
);

-- Postgres Row-Level Security as a safety net
ALTER TABLE employees ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON employees
  USING (tenant_id = current_setting('app.current_tenant')::uuid);

-- Application sets the tenant context per request
SET LOCAL app.current_tenant = 'tenant-acme-uuid';
SELECT * FROM employees;  -- only Acme's rows

The "tenant_id everywhere" discipline

• Caches: never key by entity_id alone. Always (tenant_id, entity_id).
• Search indexes: include tenant_id as a mandatory filter.
• Queues / events: partition by tenant_id; events carry tenant in payload.
• Logs / metrics: tag with tenant_id (but be careful about cardinality blowup).
• Cross-tenant analytics: ETL to a separate warehouse. Never JOIN across tenants in OLTP.

Noisy neighbor mitigation

One slow tenant can exhaust resources for everyone. Strategies:

What to say in the interview

Audit Log Design

Personio is a system of record. Auditors will query the audit log years later. Get the design right once.

Schema

CREATE TABLE audit_log (
  id            UUID DEFAULT gen_random_uuid(),
  tenant_id     UUID NOT NULL,
  ts            TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  actor_id      UUID,            -- who did it (NULL for system)
  actor_type    VARCHAR(16),    -- user / system / integration
  resource_type VARCHAR(32) NOT NULL,  -- employee, payslip, timeoff…
  resource_id   UUID NOT NULL,
  action        VARCHAR(32) NOT NULL,  -- create, update, delete, approve…
  before_state  JSONB,
  after_state   JSONB,
  metadata      JSONB,           -- ip, user-agent, request_id
  prev_hash     BYTEA,           -- hash chain for tamper evidence
  hash          BYTEA NOT NULL,
  PRIMARY KEY (tenant_id, ts, id)
) PARTITION BY RANGE (ts);

-- Monthly partitions for fast retention management
CREATE TABLE audit_log_2026_05 PARTITION OF audit_log
  FOR VALUES FROM ('2026-05-01') TO ('2026-06-01');

-- Query: all changes to one employee, newest first
CREATE INDEX ON audit_log (tenant_id, resource_type, resource_id, ts DESC);

Tamper evidence via hash chain

Each row's hash = sha256(prev_hash + payload). If anyone alters a past row, all subsequent hashes break. Auditors can verify the chain without trusting your DB.

def append_audit(tenant_id, payload):
    with txn:
        prev = db.execute(
            "SELECT hash FROM audit_log WHERE tenant_id=%s ORDER BY ts DESC LIMIT 1",
            (tenant_id,)
        ).fetchone()
        prev_hash = prev[0] if prev else bytes(32)  # genesis
        h = hashlib.sha256(prev_hash + json.dumps(payload, sort_keys=True).encode())
        db.execute("INSERT INTO audit_log (..., prev_hash, hash) VALUES (...)",
                   ..., prev_hash, h.digest())

Write path — never block user writes

Why async? Audit insert latency shouldn't impact user request latency. If audit-log DB is down, user writes continue; audit catches up later via Kafka retention.

Retention by category

What to query for

• "Show all changes to employee X" → (tenant_id, resource_type='employee', resource_id=X), ts DESC.
• "Who approved payslip Y?" → (tenant_id, resource_type='payslip', resource_id=Y, action='approve').
• "Compliance report: all PII access in Q1" → action='read', resource_type IN (...) partitioned scan.
• "Erasure verification: hash chain integrity from 2024-01-01 to today" → recompute hashes, compare.

Common mistakes to avoid

• Audit log in main DB without partitioning. Becomes a multi-billion-row monster. Partition by month from day 1.
• Synchronous audit write inside user transaction. User writes slow down, fail when audit fails.
• Storing full request bodies. PII explosion. Store before/after of changed fields only.
• Forgetting tenant_id. Cross-tenant audit query = leak.
• No tamper evidence. If audit can be edited, it's not audit — it's a log.

Reading this in the interview