risk-nexus/docs/regulatory/policies/RISK-POL-0002-retention-and-erasure.md

id	type	title	regime	status	activates_when	owner	written	related	cadence	clean_streak	last_checked	next_check	checked_by
RISK-POL-0002	legal-policy	Retention and erasure	GDPR Arts 5(1)(e), 17; HGB §257; AO §147	part-active	any personal data is held — the commercial half (RISK-POL-0009) is already live	risk-nexus	2026-08-20	RISK-POL-0009 RISK-REG-0001 RISK-F-0008	1h	1	2026-09-22T06:26:12Z	2026-09-22T07:26:12Z	worsch

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.

2026-09-22 review. The position is unchanged and RISK-F-0008 still carries the gap. Two partial inputs have arrived since 2026-08-20:

• audit-core (AUDIT-WP-0008) states it declares nothing above the 30-day platform-pg default and will not extend any co-resident's horizon. That is a stated contribution to the co-residency horizon. It does not verify the instance maximum, which also depends on the other co-residents and on backup retention.
• Restores from the retained side are demonstrated for apps-pg and Forgejo (RPF-WP-0029, RPF-WP-0038). That shows the retained side works, but it proves no deletion at expiry.

Reviews

• 2026-09-22 — clean check: Position unchanged; audit-core states a 30-day contribution (unverified instance maximum); restore evidence exists, no deletion evidence; F-0008 carries the gap. Cadence instant → 1h (1 clean in a row); next check 2026-09-22 07:26Z.