tegwick
5a7e4ac2d4
RISK-REG-0001: eight-year voucher period (BEG IV) confirmed against secondary sources and §147 AO. RISK-POL-0009/0002: positions unchanged; new restore evidence noted as partial. RISK-POL-0012: receiving duty still unowned; issuing phase-in dates added, flagged for confirmation. RISK-POL-0011: stays dormant. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 6903@bnt-lap001 Assistant-Session: 8319e8a8-ffa6-4eb3-b8bf-b29945628f89
80 lines
3.7 KiB
Markdown
80 lines
3.7 KiB
Markdown
---
|
|
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: 1h
|
|
clean_streak: 1
|
|
last_checked: "2026-09-22T06:26:12Z"
|
|
next_check: "2026-09-22T07:26:12Z"
|
|
checked_by: "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.
|