tegwick 7f135f9e0f Legal policy set: written before needed, dormant until a context activates

Operator ruling: no external determination in build mode, but keep the
set of legal policies for reuse when a work context needs one in place.

docs/regulatory/policies/ catalogues thirteen, keyed by activation
condition rather than by regime, with a retrieval table so a context
pulls a slice: first real user account pulls six of them; a
consumer-facing product in Germany pulls those plus accessibility. Two
are already active and nobody had noticed — commercial and tax retention,
and the e-invoicing receiving obligation that has been live since 2025
with no named owner in the estate. Four written in full; the rest carry
their trigger now and get their text when a context approaches, which is
the point.

RISK-POL-0011 is the argument for the whole catalogue: accessibility
cannot be retrofitted cheaply, so a policy retrieved at launch is a
rebuild while one read at design time is just a constraint.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-20 23:36:22 +02:00

2.8 KiB

Raw Blame History

id	type	title	regime	status	activates_when	owner	written	cadence	clean_streak	last_checked	next_check
RISK-POL-0009	legal-policy	Commercial and tax retention	HGB §257, AO §147	active	the estate keeps commercial books or issues and receives invoices — already true	risk-nexus	2026-08-20	instant	0	2026-08-20T21:30:00Z	2026-08-20T21:30:00Z

RISK-POL-0009 — commercial and tax retention

Active now. This is the one policy in the set that does not wait for a context: the estate already invoices, holds bank records and keeps books.

What the sources require

Class	Period	Source
Books, inventories, opening balance sheets, annual accounts, management reports	10 years	§257(1) no. 1, (4) HGB; §147(1) no. 1, (3) AO
Accounting vouchers (Buchungsbelege)	8 years	§147(3) AO, shortened from ten by the Fourth Bureaucracy Relief Act with effect from 2025
Commercial and business letters received and sent	6 years	§257(2), (4) HGB; §147(1) nos. 2–3 AO

Periods run from the end of the calendar year in which the last entry was made or the document created — not from the document's own date. That detail is the one most often got wrong, and it always extends the period rather than shortening it.

The eight-year figure is recent and this repo has not verified it against the current text. Confirm before relying on it for a deletion decision; ten years is the safe reading if nobody has.

What it requires of systems

Records in these classes must be retrievable for the whole period, not merely undeleted. A backup nobody can restore from does not satisfy a retention duty — the same standard RISK-F-0006 applies to apps-pg.
Immutability of content: they must not be silently rewritable.
Deletion must be possible and deliberate at the end of the period. Retention duty is a floor, not a licence; RISK-POL-0002 supplies the ceiling.

Where it collides

With erasure (RISK-POL-0002, RISK-F-0008). An erasure request touching a record inside a statutory retention period does not defeat the duty — Art 17(3)(b) GDPR covers exactly this. But the exemption is per record, not per system: it covers the invoice, not the entire event log the invoice passed through.

That distinction is where "we keep audit because it is audit" fails, and it is why RISK-REG-0001 states periods per category rather than one figure.

Evidence that would show this is met

A retention schedule per record class; a demonstrated restore from the oldest retained period; a deletion routine that actually runs at expiry.

None of those exist yet. This policy is active in the sense that the duty applies, not in the sense that it is demonstrably satisfied — and the register says which.

2.8 KiB Raw Blame History Unescape Escape