RISK-REG-0001: write down the retention basis, and open regulatory intake

The outstanding half of RISK-F-0008 that needed no authorisation. Grounds
stated per category rather than as a blanket exemption: Art 6(1)(f) with
Art 32 for operator and agent records, Art 17(3)(e) for counterparty
transaction evidence, Art 17(3)(b) only where a commercial or tax duty
independently applies. The weak part is named as duration rather than
existence, and audit-core's co-residency horizon is identified as the
most likely point of failure in the whole position. Not legal advice, and
the record says so.

Also opens docs/regulatory/ with the record format — dated, sourced, and
reviewed, because a regulatory answer expires.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/regulatory/README.md

@@ -0,0 +1,20 @@
+# Regulatory intake
+
+Moved here from `policy-nexus` on 2026-08-17: deciding what an external rule
+demands of the estate is a judgement about risk, not an act of publishing.
+
+One file per question. Each record states **what a source says and when**, and
+what the estate therefore relies on. What the estate must consequently *do* is
+the owning repo's decision, not this repo's — `INTENT.md`.
+
+A record carries `sources_read`, `determined`, `external_review` (usually
+`none`, and it must say so rather than implying otherwise), and `review_by`.
+A regulatory answer expires; that is why it is dated and reviewed rather than
+consulted once and discarded, which is the failure that moved this remit here.
+
+**These records are not legal advice** and this repo cannot make them into any.
+Where a position is weak, the record says which part and why.
+
+| Record | Question | Finding |
+| --- | --- | --- |
+| `audit-retention-basis.md` | On what basis are audit records retained against an erasure request? | `RISK-F-0008` |

docs/regulatory/audit-retention-basis.md

@@ -0,0 +1,112 @@
+---
+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
+review_by: "2026-11-17"
+---
+
+# 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.