---
id: RISK-POL-0002
type: legal-policy
title: "Retention and erasure"
regime: "GDPR Arts 5(1)(e), 17; HGB §257; AO §147"
status: part-active
activates_when: "any personal data is held — the commercial half (RISK-POL-0009) is already live"
owner: risk-nexus
written: "2026-08-20"
related: [RISK-POL-0009, RISK-REG-0001, RISK-F-0008]
cadence: instant
clean_streak: 0
last_checked: "2026-08-20T21:30:00Z"
next_check: "2026-08-20T21:30:00Z"
---

# RISK-POL-0002 — retention and erasure

Two duties pulling opposite ways, which is why they are one policy. Storage
limitation says keep it no longer than necessary; retention duties say keep it
for a fixed term; erasure says delete on request. A system that satisfies one
in isolation usually breaks another.

## The order of operations

1. **Is there a statutory retention duty?** (`RISK-POL-0009`.) If yes, the
   record is kept for the term, and an erasure request does not defeat it —
   Art 17(3)(b). The exemption is **per record**, not per system.
2. **Is there a live purpose?** If not, storage limitation (Art 5(1)(e))
   requires deletion regardless of whether anyone asked.
3. **Has someone asked?** Then Art 17, minus whatever survives step 1 or an
   Art 17(3) exemption, each of which must be identified per category rather
   than claimed wholesale.

The periods per category are in `RISK-REG-0001`, with the reasoning and the
weak points named.

## What it requires of systems

- **Deletion must be possible.** Not scheduled, not intended — possible, and
  demonstrated once. `RISK-F-0008` exists because `audit-core` established that
  in their store it currently is not.
- **The real horizon is the maximum across co-residents.** A service declaring
  twelve months on shared infrastructure achieves the longest retention of
  anything sharing that infrastructure, including backups. Declared periods are
  claims until that is established.
- **A commitment over cleartext defeats erasure.** A retained hash of a
  low-entropy record is a confirmation oracle: destroying the key does not
  erase content that can still be tested against a surviving commitment. Keyed
  commitments (HMAC, per-subject salt) restore erasability — open with
  `audit-core`.
- **Minimisation beats exemption.** Operator ruling, 2026-08-20: opaque subject
  ids, agent identifiers where possible, operator credentials only where
  necessary, policy decisions tracked to the responsible party. Data that never
  arrives needs no ground, no exemption and no argument.

## Evidence that would show this is met

A retention schedule per category; a demonstrated deletion at expiry; a stated
and verified co-residency horizon; a demonstrated restore proving the retained
side works too.

None of those exist yet, and `RISK-F-0008` carries the gap.