diff --git a/REGISTER.md b/REGISTER.md index 9d69772..b01e5fa 100644 --- a/REGISTER.md +++ b/REGISTER.md @@ -2,7 +2,7 @@ Generated by `tools/register_index.py` from `findings/`. Do not edit by hand. Last built 2026-08-20. -6 open of 9 findings; 3 notes below the floor. +6 open of 9 findings; 2 notes below the floor. ## Findings @@ -45,7 +45,6 @@ Seen, deliberately not findings. Not graded, not reviewed, not published. | ID | Note | Why below the floor | | --- | --- | --- | -| [RISK-N-0004](notes/RISK-N-0004-zone-lookup-facility.md) | No facility answers which zone a workload is in, or what applies there | missing capability, not a defect — there is nothing to route to a fix owner, and the register does not file undone work | | [RISK-N-0003](notes/RISK-N-0003-defects-found-by-reading-not-monitoring.md) | Every defect in this register was found by reading, none by monitoring | no owner and no defect — it is an argument about where to invest detection, and the register cannot route an argument | | [RISK-N-0001](notes/RISK-N-0001-noisy-neighbour-uncharacterised.md) | Noisy-neighbour behaviour is uncharacterised | no decision changes today — no tenant shares a saturating workload, and what is missing is measurement work, not a defect to route | diff --git a/docs/regulatory/README.md b/docs/regulatory/README.md deleted file mode 100644 index fb3d8b7..0000000 --- a/docs/regulatory/README.md +++ /dev/null @@ -1,20 +0,0 @@ -# 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 deleted file mode 100644 index 0211aad..0000000 --- a/docs/regulatory/audit-retention-basis.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -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. diff --git a/notes/RISK-N-0004-zone-lookup-facility.md b/notes/RISK-N-0004-zone-lookup-facility.md deleted file mode 100644 index 7d725c6..0000000 --- a/notes/RISK-N-0004-zone-lookup-facility.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -id: RISK-N-0004 -type: note -title: "No facility answers which zone a workload is in, or what applies there" -date: "2026-08-20" -source: "the-custodian, 2026-08-20; surfaced by RISK-F-0003 and RISK-F-0008" -floor_reason: "missing capability, not a defect — there is nothing to route to a fix owner, and the register does not file undone work" -revisit: "when the facility lands, or when a fourth finding turns on a zone answer nobody can give" -routed_to: zone-engine -ruling: RISK-RULING-2026-08-20 ---- - -# RISK-N-0004 — nothing can answer "which zone, and what applies there" - -The operator's requirement, 2026-08-20: there should be a facility that answers, -easily, **which zone a workload is in** and **which policies and guarantees -apply in that zone**. - -**Ruled a note, not a finding.** Consistent with `RISK-N-0001`: what is missing -is capability, not a control. There is no defect, no owning repo carrying a -gap, and nothing for this register to route to a fix owner. Filing undone work -as a finding is how a register stops being readable. - -Routed to `zone-engine` as the owner of the zone model. This repo records the -requirement and its consumers; it does not design or build it. - -## Why the register cares — three findings already wait on it - -Recorded because a note with a real dependency list is worth more than a -finding with none. - -- **`RISK-F-0003`** — the operator directed that an absent lane `risk` grade - should resolve from **maturity context**: tolerable in an early or - experimental context, `high` or `critical` in a production one. `ops-warden` - and this register both established that `.repo-classification.yaml` - `category` cannot carry that signal — `railiance-platform` runs production - OpenBao as `tooling`. The lookup is what would make that rule computable - rather than aspirational. `ops-warden` is grading the five exposed lanes by - hand in the meantime (`WARDEN-WP-0032-T05`) precisely because it does not - exist. -- **`RISK-F-0008`** — the operator's ruling includes that zone-level privacy, - pseudonymity or anonymity guarantees may raise the floor for what identity - an audit record must carry. `audit-core` cannot honour a guarantee it cannot - look up at accept time. -- **`RISK-F-0007`** — verification of a named consumer boundary is available on - request. Scoping a request by zone is more useful than scoping it by repo, - and only possible if zone membership is answerable. - -## What this register would want from it, stated as needs and not as a design - -Offered to `zone-engine` as consumer requirements. The design is theirs. - -1. **Answerable about a workload, not only about a repo.** A repo can run - several workloads at different maturities; `railiance-platform` is the - standing proof. -2. **Authoritative, not inferred.** A lookup that guesses from labels or names - reproduces the failure it exists to fix — `RISK-F-0003` is a finding about a - field being optional, and a facility that silently returns "unknown, assumed - low" would be the same defect at a higher altitude. Unknown must read as - unknown. -3. **Guarantees, not only membership.** "Which zone" is half an answer. The - consuming decisions are about what applies there. -4. **Machine-readable.** So that `make check` in this repo can eventually ask - whether a finding's system sits in a zone whose guarantees change its grade, - rather than a person remembering to. - -## What this note is not - -Not a request for a schedule, not a design, and not a claim that the absence is -currently causing harm. `RISK-F-0003`'s five lanes are being graded by hand and -`audit-core` can implement the operator's minimisation ruling today without -knowing any zone. The facility makes three existing decisions cheaper and one -future class of them possible; it does not unblock anything that is stuck. - -It comes back as a finding only if a fourth finding turns on a zone answer that -nobody can give.