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

id	type	title	status	owner	determined	finding	sources_read	external_review	last_checked	next_check	cadence	clean_streak
RISK-REG-0001	regulatory-record	On what basis the estate retains personal data inside audit records	determined-internally	risk-nexus	2026-08-20	RISK-F-0008	GDPR Arts 5, 6, 17, 21, 32; Recitals 49, 65; HGB §257; AO §147	none	2026-08-20T05:25:00Z	2026-08-20T05:25:00Z	instant	0

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.