risk-nexus/docs/regulatory/audit-retention-basis.md

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