tegwick
56b8d61583
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>
119 lines
6.2 KiB
Markdown
119 lines
6.2 KiB
Markdown
---
|
|
id: RISK-REG-0001
|
|
type: regulatory-record
|
|
title: "On what basis the estate retains personal data inside audit records"
|
|
status: determined-internally
|
|
owner: risk-nexus
|
|
determined: "2026-08-20"
|
|
finding: RISK-F-0008
|
|
sources_read: "GDPR Arts 5, 6, 17, 21, 32; Recitals 49, 65; HGB §257; AO §147"
|
|
external_review: none
|
|
last_checked: "2026-08-20T10:02:42Z"
|
|
next_check: "2026-08-20T11:02:42Z"
|
|
cadence: 1h
|
|
clean_streak: 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.
|