risk-nexus/findings/RISK-F-0008-audit-retention-legal-basis-assumed.md

id	type	title	status	reported_by	reported_via	routed_by	date_reported	date_filed	system	environment	fix_owner	fix_tracking	related	supersedes	severity	severity_at_production	impact	likelihood	fidelity_modifier	production_rescore	disclosure	publication	escalation	escalation_trigger	escalation_status	last_reviewed	review_by	graded_by	ruling
RISK-F-0008	finding	The legal basis for retaining audit facts against an erasure request has been assumed, never established	open	audit-core	audit-core	audit-core	2026-08-18	2026-08-19	audit-core	production	risk-nexus	unset	RISK-F-0005	RISK-N-0002	medium	high	I3	L2	false	true	public	pending-handover	required	2	pending-operator	2026-08-19	2026-11-17	risk-nexus	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.