risk-nexus/docs/regulatory/audit-retention-basis.md
tegwick 56b8d61583 Work the register due list, and add the one-check-per-sitting rule
Nine records checked. Five clean and climbed to 1h: RISK-F-0003, 0004,
0005, 0006, 0009 and RISK-REG-0001. Three moved and stay at instant —
RISK-F-0002 (RISK-V-0001 found the flex-auth-ops-warden policy admits no
ingress, so the live question there is now availability rather than
attestation), RISK-F-0007 (the on-request path walked for the first time
as RISK-V-0002), RISK-F-0008 (the determination now exists).

The rule: a finding recorded as moved is not clean-checked in the same
sitting. Re-reading your own keystrokes and climbing produces a rung that
says the world held still when what held still was the last five minutes.
The rung carries stability information or it carries nothing.

record_check.py now handles regulatory records as well as findings.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 12:03:12 +02:00

6.2 KiB

id type title status owner determined finding sources_read external_review last_checked next_check cadence clean_streak
RISK-REG-0001 regulatory-record On what basis the estate retains personal data inside audit records determined-internally risk-nexus 2026-08-20 RISK-F-0008 GDPR Arts 5, 6, 17, 21, 32; Recitals 49, 65; HGB §257; AO §147 none 2026-08-20T10:02:42Z 2026-08-20T11:02:42Z 1h 1

RISK-REG-0001 — the retention basis, written down

The first record of this repo's regulatory-intake remit, and the outstanding half of RISK-F-0008. audit-core asked for an owner and an eventual answer; this is the answer as far as it can honestly be given without buying one.

What this is. A statement of what the sources say, which ground the estate relies on for which category of data, and for how long. It is a position that can be argued with, which is the whole point — RISK-F-0008 exists because the estate had been assuming one without writing it down.

What this is not. Legal advice. INTENT.md is explicit that this repo does not give it, and nothing here has been reviewed by anyone qualified. Where the position is weak, this record says so rather than sounding confident.

The question

audit-core holds audit evidence across tenants, targets R2 on the Tenancy Posture retention ladder, and has declared R4 (verified erasure) unreachable by design — crypto-shredding would destroy the evidence the service exists to hold, and their SHA-256-over-cleartext commitment survives key destruction as a confirmation oracle against low-entropy records.

So if an Art 17 request names a data subject appearing in the audit trail, there is no mechanism. The position rests on the record being exempt.

The grounds, per category

The exemption is never blanket. It is per category of data and per purpose, and the estate's position has to be stated that way or it is not a position.

Category Ground relied on Strength
Operator and agent identifiers, actions, timestamps Art 6(1)(f) legitimate interest in the security of processing, reinforced by Art 32's obligation to ensure it; Recital 49 names network and information security as a legitimate interest Strong. This is the ordinary, widely accepted case.
Counterparty or end-user identifiers appearing in event payloads Art 17(3)(e) — establishment, exercise or defence of legal claims — with Art 6(1)(f) for the processing itself Adequate on existence, weak on duration. See below.
Records that are commercial books, invoices or tax-relevant documents passing through audit Art 17(3)(b) legal obligation, given HGB §257 (6/10 years) and AO §147 Strong but narrow. These duties cover books and invoices. They do not convert an application audit log into a retained commercial record.

Where this position is weak, stated plainly

Duration, not existence. Supervisory practice tends to accept security and audit logging under legitimate interest and then ask how long. "We keep audit forever because it is audit" is the form that fails. A defensible answer names a period per category and a reason for it, and the estate does not have one yet — audit-core declares a horizon, and their own question 2 points out that at P1 the real horizon is the maximum across every co-resident on platform-pg, not the declared value. That gap is the most likely point of failure in this entire position, and it is an infrastructure fact rather than a legal one.

Art 21 objection. Legitimate interest carries a right to object. The estate would have to show compelling legitimate grounds overriding the subject's interests. For security and fraud-investigation evidence that is a normal argument to win, but it is an argument, not an exemption that applies automatically.

Art 5(1)(e) storage limitation applies regardless of the erasure exemption. An exemption from erasure on request is not a licence to retain indefinitely.

What the operator's ruling of 2026-08-20 does to this

It shrinks the second row of the table, which is the weak one.

Opaque subject identifiers, agent identifiers where possible, operator credentials only where necessary, and policy decisions tracked to the responsible party — the effect is that most audit records stop containing the category whose retention is hardest to justify. What remains is the first row, where the position is strong.

This is the most useful thing that has happened to this question. A weak legal argument avoided by holding less data is better than a strong one relied upon.

The estate's position, as recorded today

  1. The estate relies on Art 6(1)(f) with Art 32 for operator and agent audit records, and on Art 17(3)(e) for records evidencing a transaction with a counterparty.
  2. It relies on Art 17(3)(b) only for records that are independently subject to a commercial or tax retention duty, and does not extend that duty to application logs generally.
  3. It does not yet have a defensible retention period per category. This is the open item, and it is audit-core's co-residency horizon that must be settled before a period can be stated honestly.
  4. It holds that the operator's minimisation ruling is the primary control, and the exemption the fallback — in that order.

What would change this record

  • audit-core answering whether a keyed commitment restores erasability. If it does, the estate stops relying on an exemption for anything it could instead erase, and this record narrows to the retained-by-obligation categories only.
  • A stated retention period per category, once the co-residency horizon is known.
  • Any of the three triggers for buying an external determination: the estate first holding a real person's data, a counterparty contract requiring a stated position, or an actual Art 17 request. This record is explicitly not a substitute for that — it is what the estate says while none of them has happened.

Reviewed every 90 days with RISK-F-0008, or immediately on any trigger.

Reviews

  • 2026-08-20 — clean check: grounds unchanged; still waiting on audit-core's co-residency horizon. Cadence instant → 1h (1 clean in a row); next check 2026-08-20 11:02Z.