tegwick
7f135f9e0f
Operator ruling: no external determination in build mode, but keep the set of legal policies for reuse when a work context needs one in place. docs/regulatory/policies/ catalogues thirteen, keyed by activation condition rather than by regime, with a retrieval table so a context pulls a slice: first real user account pulls six of them; a consumer-facing product in Germany pulls those plus accessibility. Two are already active and nobody had noticed — commercial and tax retention, and the e-invoicing receiving obligation that has been live since 2025 with no named owner in the estate. Four written in full; the rest carry their trigger now and get their text when a context approaches, which is the point. RISK-POL-0011 is the argument for the whole catalogue: accessibility cannot be retrofitted cheaply, so a policy retrieved at launch is a rebuild while one read at design time is just a constraint. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
63 lines
2.7 KiB
Markdown
63 lines
2.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: 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.
|