diff --git a/docs/regulatory/README.md b/docs/regulatory/README.md new file mode 100644 index 0000000..fb3d8b7 --- /dev/null +++ b/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` | diff --git a/docs/regulatory/audit-retention-basis.md b/docs/regulatory/audit-retention-basis.md new file mode 100644 index 0000000..0211aad --- /dev/null +++ b/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.