coulomb/risk-nexus
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
risk-nexus/docs/regulatory/policies/RISK-POL-0002-retention-and-erasure.md
tegwick 7f135f9e0f Legal policy set: written before needed, dormant until a context activates 
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>
2026-08-20 23:36:22 +02:00

2.7 KiB
Raw Blame History

id type title regime status activates_when owner written related cadence clean_streak last_checked next_check
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
instant 0 2026-08-20T21:30:00Z 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.