---
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
last_checked: "2026-09-01T00:38:53Z"
next_check: "2026-09-01T00:38:53Z"
cadence: instant
clean_streak: 0
checked_by: "codex/risk-nexus"
---

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

## Reviews

- **2026-08-20** — clean check: grounds unchanged; still waiting on audit-core's co-residency horizon. Cadence instant → 1h (1 clean in a row); next check 2026-08-20 11:02Z.

---

# Amendment — 2026-08-20: retention periods, stated rather than deferred

`RISK-WP-0003-T02`. The original record named duration as the weakest point in
the estate's position and left the period open, pending `audit-core`'s
co-residency horizon.

`docs/method/dependencies.md`, written the same week, says the register never
waits to decide. Applying that here: **target periods are stated now**, with
what would change them recorded beside them. A position with a period somebody
can argue with is stronger than an honest blank.

## Target periods, per category

| Category | Target | Ground and reasoning |
| --- | --- | --- |
| Operator and agent security audit records | **12 months** | Art 6(1)(f) with Art 32. Twelve months covers an annual review cycle and the ordinary lag between an incident happening and being discovered. Longer needs a specific reason, per record class, not a habit. |
| Counterparty transaction evidence | **3 years, running to the end of the third calendar year** | Art 17(3)(e), defence of legal claims, tracking the general German limitation period (§195, §199 BGB — three years from the end of the year in which the claim arose). Evidence outliving the claim it could defend has no ground. |
| Accounting vouchers (*Buchungsbelege*) | **8 years** | §147 AO / §257 HGB. Shortened from ten years by the Fourth Bureaucracy Relief Act with effect from 2025. **Worth confirming before relied on** — it is recent and this repo has not verified it against the current text. |
| Books, inventories, annual accounts | **10 years** | §257 HGB, unchanged by that reform. |
| Commercial and business letters | **6 years** | §257 HGB. |
| Personal data in audit records falling in none of the above | **delete** | No ground identified means no retention. The operator's minimisation ruling of 2026-08-20 should mean this category is close to empty by construction. |

## Target is not achieved, and the difference is the finding

These are **targets**. The estate cannot currently state what it *achieves*,
for the reason `audit-core` gave: at `P1` the real erasure horizon is the
maximum across every co-resident on `platform-pg`, not the value any one
service declares. A service can declare twelve months and be unable to deliver
it because a neighbour's backup retention outlives it.

So the position is:

1. The estate **states** these targets and can defend the reasoning for each.
2. The estate **cannot yet demonstrate** that any of them is achieved.
3. The gap between the two is an infrastructure fact, not a legal one, and it
   is what `RISK-F-0008` carries.

That is a materially better position than having no period at all, and it is
worse than having a verified one. Both halves are stated so nobody reads the
table as a compliance claim.

## What would change this

- **`audit-core`'s co-residency horizon.** If the real maximum is longer than
  the targets, the targets are aspirational and the table says so.
- **A keyed commitment working** (`RISK-F-0008`). Then erasure becomes
  available and the retention argument narrows to the retained-by-obligation
  rows only, which are the strong ones.
- **Confirmation of the eight-year voucher period.** Flagged above; the rest of
  the table does not depend on it.
- **Any of the three triggers** for buying an external determination, which
  remain unruled.

Default if none of these arrives by 2026-11-17: this table stands as the
estate's stated position, with the achieved-versus-target gap recorded as
unresolved.

- **2026-09-01** — not clean: the dated review found that the 2026-08-20 target-period amendment had never advanced this record's check state. The targets now stand explicitly; achievement under the shared backup horizon and keyed-commitment feasibility remain open. Cadence 1h → instant; checked again immediately.