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

---
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.