tegwick
7d6ded5743
Read the repo inbox after grading, which is the wrong order and is now recorded as such. flex-auth had answered the NetworkPolicy question on 2026-08-18 (narrow ingress, not default-deny — L3 becomes L2, critical becomes high) and reported RISK-F-0001 fixed at 12:35 today with live 401 probes. F-0001 closes fixed and public; its escalation is withdrawn before it was ever sent. RISK-F-0002's ordering constraint lifts with it and its trigger-6 escalation is withdrawn. audit-core had routed the erasure-versus-audit legal question here on 2026-08-18 asking for an owner. RISK-N-0002 was wrong to call it a note: the remedy is not retrofittable, so the decision can only be taken early. Promoted to RISK-F-0008, owned by this repo as regulatory intake, escalated on trigger 2. Accepted rapp-postgres's record format and ops-warden's typed-act escalation vocabulary. Reading the inbox is now question zero of every review. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
128 lines
5.4 KiB
Markdown
128 lines
5.4 KiB
Markdown
---
|
||
id: RISK-F-0008
|
||
type: finding
|
||
title: "The legal basis for retaining audit facts against an erasure request has been assumed, never established"
|
||
status: open
|
||
reported_by: audit-core
|
||
reported_via: audit-core
|
||
routed_by: audit-core
|
||
date_reported: "2026-08-18"
|
||
date_filed: "2026-08-19"
|
||
system: audit-core
|
||
environment: production
|
||
fix_owner: risk-nexus
|
||
fix_tracking: unset
|
||
related: [RISK-F-0005]
|
||
supersedes: RISK-N-0002
|
||
# Graded by risk-nexus 2026-08-19 — docs/rulings/2026-08-19-third-grading.md
|
||
severity: medium
|
||
severity_at_production: high
|
||
impact: I3
|
||
likelihood: L2
|
||
fidelity_modifier: false
|
||
production_rescore: true
|
||
disclosure: public
|
||
publication: pending-handover
|
||
escalation: required
|
||
escalation_trigger: 2
|
||
escalation_status: pending-operator
|
||
last_reviewed: "2026-08-19"
|
||
review_by: "2026-11-17"
|
||
graded_by: risk-nexus
|
||
ruling: RISK-RULING-2026-08-19-C
|
||
---
|
||
|
||
# RISK-F-0008 — the exemption nobody has established
|
||
|
||
## What is true
|
||
|
||
`audit-core` holds audit evidence across tenants, targets `R2` on the Tenancy
|
||
Posture retention ladder, and has declared `R4` — verified erasure —
|
||
unreachable by design. The technical reasoning is sound and documented
|
||
(`audit-core/docs/erasure-and-audit.md`, framework Decision 4.5.3):
|
||
crypto-shredding would destroy the evidence the service exists to hold, and
|
||
their integrity chain commits to a SHA-256 of the cleartext record, which
|
||
survives key destruction as a confirmation oracle against low-entropy audit
|
||
rows. Destroying a key does not erase content a surviving commitment can still
|
||
be tested against.
|
||
|
||
The consequence is that if an Article 17 request arrives naming a data subject
|
||
in the audit trail, `audit-core` has no mechanism. The answer would rest on
|
||
audit evidence being exempt — legal obligation, or legitimate interest in fraud
|
||
and security investigation.
|
||
|
||
**Those grounds are ordinary. Nobody in this estate has actually reached them.**
|
||
`audit-core` routed the question here on 2026-08-18 rather than absorbing it,
|
||
saying plainly that they are not competent to answer it and that they have been
|
||
assuming it. §19.11 of the framework says the same in its own words: the legal
|
||
basis for retaining audit facts remains a risk/legal question outside the
|
||
framework.
|
||
|
||
## Why this repo owns it
|
||
|
||
This is the first finding where `fix_owner` is `risk-nexus`.
|
||
|
||
`INTENT.md` moved regulatory intake here from `policy-nexus` on 2026-08-17,
|
||
precisely because deciding what a rule demands of us is a judgement about risk
|
||
rather than an act of publishing. `audit-core` routed it by both available
|
||
routes and asked for an owner rather than an opinion. Refusing it would be this
|
||
repo declining its own remit.
|
||
|
||
What this repo owns is the **record**: what the source says, when, and what
|
||
therefore is or is not established. It does not own legal advice — `INTENT.md`
|
||
is explicit — and it does not own the redesign. If the basis does not hold,
|
||
`audit-core` owns encrypt-then-hash at accept time, and that is not
|
||
retrofittable onto events already accepted.
|
||
|
||
## The three questions, as asked
|
||
|
||
1. On what basis does the estate retain personal data inside audit records
|
||
against an erasure request, and does that basis hold for the categories
|
||
`audit-core` stores?
|
||
2. Does it hold across the full 30-day recoverable window and beyond, given
|
||
that at `P1` the real erasure horizon is the maximum across every
|
||
co-resident on `platform-pg`, not the value `audit-core` declares?
|
||
3. If it does not hold, `R4` is urgent rather than theoretical, and the answer
|
||
is a substantial redesign with a long lead time.
|
||
|
||
## Register ruling — 2026-08-19
|
||
|
||
`medium` today (`I3` × `L2`), `high` at production, `public`, **escalated on
|
||
trigger 2**.
|
||
|
||
`I3`: an unmet retention obligation in the audit store crosses from a technical
|
||
question to an obligation with an outside counterparty, and the remediation is
|
||
a non-retrofittable redesign rather than a patch. `L2`: no request has arrived
|
||
and the estate holds no real data subject's records yet, but the trigger is
|
||
somebody else's to pull and needs no foothold here.
|
||
|
||
`production_rescore: true`. The likelihood of an Article 17 request is a
|
||
function of having real users; that is exactly what production means.
|
||
|
||
**Escalation, trigger 2** — "creates or reveals an obligation with an outside
|
||
counterparty". It reveals one. The estate cannot decide unilaterally that this
|
||
obligation is small, and the operator is the only party who can commission an
|
||
answer that is more than an assumption. The ask is narrow: authorise someone to
|
||
establish the basis, or record that the estate knowingly runs on the assumption
|
||
and for how long.
|
||
|
||
**Disclosure `public`.** Nothing here shortens a path to a defect: it is a
|
||
question about a legal basis, published as a question. `audit-core`'s technical
|
||
reasoning is already written down and worth reading.
|
||
|
||
## How it got here
|
||
|
||
Ruled a note on 2026-08-19 (`RISK-N-0002`) on the reasoning that no obligation
|
||
exists yet. That ruling was made without reading `audit-core`'s message, which
|
||
had been in this repo's inbox since 2026-08-18 and asks specifically for an
|
||
owner. The note was wrong on the second floor test: recording this *does*
|
||
change a decision, because the redesign it might force cannot be retrofitted
|
||
and therefore has to be decided early or not at all.
|
||
|
||
`RISK-N-0002` is superseded by this record.
|
||
|
||
## Reviews
|
||
|
||
- **2026-08-19** — promoted from note, graded, escalated. Open at review:
|
||
has the basis been established or the assumption recorded; has anything
|
||
changed about what categories `audit-core` stores.
|