diff --git a/docs/method/escalation.md b/docs/method/escalation.md index c13f32f..0309815 100644 --- a/docs/method/escalation.md +++ b/docs/method/escalation.md @@ -2,10 +2,12 @@ id: RISK-METHOD-ESCALATION type: method title: "Escalation: what reaches the operator personally" -status: proposed +status: adopted owner: the-custodian drafted_by: risk-nexus drafted: "2026-08-19" +adopted: "2026-08-20" +adopted_by: the-custodian workplan: RISK-WP-0001-T03 review_interval: 3m disclosure: restricted @@ -18,9 +20,15 @@ restricted_reason: "names the operator's spend thresholds and describes when the operator personally rather than sitting in a register, and says the rule is not yet written. This is the rule, drafted by `risk-nexus`. -**Status: `proposed`.** The custodian adopts it. It is not in force until the -front-matter says `adopted`, and an unadopted rule is worse than an unwritten -one because it looks like coverage. +**Status: `adopted`, 2026-08-20, as written.** The thresholds in trigger 3 — +€50/month recurring, €500 one-off — were this repo's proposal and are now the +operator's numbers. They bound nothing yet: the one spend decision taken so far +(`RISK-F-0006`) was approved without a figure being named. + +The rule governed four escalations before it was adopted, which is the state +`RISK-WP-0001-T03` refused to leave open — a draft that quietly governs is +worse than either an adopted rule or no rule, because it looks like coverage +while nobody has agreed to it. Getting this wrong in either direction is a failure: escalating everything makes the operator the queue, escalating nothing makes the register a place diff --git a/docs/regulatory/policies/README.md b/docs/regulatory/policies/README.md new file mode 100644 index 0000000..8915c82 --- /dev/null +++ b/docs/regulatory/policies/README.md @@ -0,0 +1,73 @@ +# Legal policy set + +A catalogue of legal positions the estate will need, **written before they are +needed and dormant until a context activates one**. + +Operator ruling, 2026-08-20: the estate will not buy an external determination +in build mode (`RISK-F-0008`). What it will do instead is keep this set, so +that when a work context arrives which needs a specific legal position in +place, the position is retrieved rather than researched from scratch. + +That is a direct answer to the failure `INTENT.md` names — regulation +"consulted and discarded", the same question asked twice and the answer +silently expiring. + +## How a policy works + +Each policy is dormant, active, or superseded, and carries an **activation +condition**: the fact about the world that makes it apply. Nothing here is a +compliance claim. A dormant policy asserts nothing about today; it states what +would be required *if* its condition became true, so that the day it does, the +work is retrieval rather than discovery. + +```yaml +id: RISK-POL-0002 +regime: GDPR +status: dormant +activates_when: "the estate holds personal data of an identifiable natural person" +requires_of_systems: [...] +evidence: what would have to exist to show it is met +``` + +**A policy is not a plan and does not schedule work.** It is what the owning +repo consults when its context changes. Deciding what to build in response is +the owning repo's, as `INTENT.md` requires. + +## Retrieval by context + +The point of the set is that a context pulls a slice. Some worked examples: + +| A context like… | Pulls | +| --- | --- | +| First real user account, of any kind | `0001`, `0002`, `0003`, `0004`, `0005`, `0008` | +| Consumer-facing product in Germany | the above plus `0011`, and `0010` if an agent talks to them | +| A vendor processing our data | `0006`, and `0007` if outside the EU | +| Selling to a business customer | `0009`, `0012`, and `0006` if we process for them | +| Public-sector procurement | `0013` | + +## The set + +| ID | Regime | Policy | Status | Activates when | +| --- | --- | --- | --- | --- | +| `0001` | GDPR Art 6 | Lawful basis for processing | dormant | any processing of personal data begins | +| `0002` | GDPR Arts 5(1)(e), 17 | Retention and erasure | **part-active** | any personal data is held — the commercial half is already live | +| `0003` | GDPR Arts 15–22 | Data subject rights handling | dormant | a natural person can identify themselves to us | +| `0004` | GDPR Art 32 | Security of processing | dormant | personal data is processed | +| `0005` | GDPR Arts 33–34 | Breach notification, 72 hours | dormant | personal data is held; fires on the first breach, not before | +| `0006` | GDPR Art 28 | Processors and sub-processors | dormant | a vendor processes personal data on our behalf | +| `0007` | GDPR Arts 44+ | International transfers | dormant | personal data leaves the EEA, including to a vendor's support desk | +| `0008` | GDPR Art 30 | Records of processing | dormant | processing begins and the small-scale exemption does not hold | +| `0009` | HGB §257, AO §147 | Commercial and tax retention | **active** | already — the estate invoices and books | +| `0010` | EU AI Act | AI transparency and deployer duties | dormant | an AI system interacts with a person, or is placed on the market | +| `0011` | BFSG / EAA | Accessibility of digital services | dormant | a consumer-facing digital service is offered in Germany | +| `0012` | UStG / ViDA | E-invoicing | **active** | already — a German business must be able to receive structured e-invoices | +| `0013` | GWB / VgV / UVgO | Public procurement participation | dormant | the estate bids for public contracts | + +Written in full so far: `0002`, `0009`, `0011`, `0012` — the two that are +already active, and the two most likely to activate next. The rest carry their +activation condition here and are written when a context approaches, which is +the point of the catalogue: **the trigger is recorded now, the text is written +when it is needed.** + +Every entry is `risk-nexus`'s record of what a source says. None of it is legal +advice, and this repo cannot make it into any. diff --git a/docs/regulatory/policies/RISK-POL-0002-retention-and-erasure.md b/docs/regulatory/policies/RISK-POL-0002-retention-and-erasure.md new file mode 100644 index 0000000..2d3cb82 --- /dev/null +++ b/docs/regulatory/policies/RISK-POL-0002-retention-and-erasure.md @@ -0,0 +1,63 @@ +--- +id: RISK-POL-0002 +type: legal-policy +title: "Retention and erasure" +regime: "GDPR Arts 5(1)(e), 17; HGB §257; AO §147" +status: part-active +activates_when: "any personal data is held — the commercial half (RISK-POL-0009) is already live" +owner: risk-nexus +written: "2026-08-20" +related: [RISK-POL-0009, RISK-REG-0001, RISK-F-0008] +cadence: instant +clean_streak: 0 +last_checked: "2026-08-20T21:30:00Z" +next_check: "2026-08-20T21:30:00Z" +--- + +# RISK-POL-0002 — retention and erasure + +Two duties pulling opposite ways, which is why they are one policy. Storage +limitation says keep it no longer than necessary; retention duties say keep it +for a fixed term; erasure says delete on request. A system that satisfies one +in isolation usually breaks another. + +## The order of operations + +1. **Is there a statutory retention duty?** (`RISK-POL-0009`.) If yes, the + record is kept for the term, and an erasure request does not defeat it — + Art 17(3)(b). The exemption is **per record**, not per system. +2. **Is there a live purpose?** If not, storage limitation (Art 5(1)(e)) + requires deletion regardless of whether anyone asked. +3. **Has someone asked?** Then Art 17, minus whatever survives step 1 or an + Art 17(3) exemption, each of which must be identified per category rather + than claimed wholesale. + +The periods per category are in `RISK-REG-0001`, with the reasoning and the +weak points named. + +## What it requires of systems + +- **Deletion must be possible.** Not scheduled, not intended — possible, and + demonstrated once. `RISK-F-0008` exists because `audit-core` established that + in their store it currently is not. +- **The real horizon is the maximum across co-residents.** A service declaring + twelve months on shared infrastructure achieves the longest retention of + anything sharing that infrastructure, including backups. Declared periods are + claims until that is established. +- **A commitment over cleartext defeats erasure.** A retained hash of a + low-entropy record is a confirmation oracle: destroying the key does not + erase content that can still be tested against a surviving commitment. Keyed + commitments (HMAC, per-subject salt) restore erasability — open with + `audit-core`. +- **Minimisation beats exemption.** Operator ruling, 2026-08-20: opaque subject + ids, agent identifiers where possible, operator credentials only where + necessary, policy decisions tracked to the responsible party. Data that never + arrives needs no ground, no exemption and no argument. + +## Evidence that would show this is met + +A retention schedule per category; a demonstrated deletion at expiry; a stated +and verified co-residency horizon; a demonstrated restore proving the retained +side works too. + +None of those exist yet, and `RISK-F-0008` carries the gap. diff --git a/docs/regulatory/policies/RISK-POL-0009-commercial-and-tax-retention.md b/docs/regulatory/policies/RISK-POL-0009-commercial-and-tax-retention.md new file mode 100644 index 0000000..1439654 --- /dev/null +++ b/docs/regulatory/policies/RISK-POL-0009-commercial-and-tax-retention.md @@ -0,0 +1,66 @@ +--- +id: RISK-POL-0009 +type: legal-policy +title: "Commercial and tax retention" +regime: "HGB §257, AO §147" +status: active +activates_when: "the estate keeps commercial books or issues and receives invoices — already true" +owner: risk-nexus +written: "2026-08-20" +cadence: instant +clean_streak: 0 +last_checked: "2026-08-20T21:30:00Z" +next_check: "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. diff --git a/docs/regulatory/policies/RISK-POL-0011-accessibility.md b/docs/regulatory/policies/RISK-POL-0011-accessibility.md new file mode 100644 index 0000000..1929a42 --- /dev/null +++ b/docs/regulatory/policies/RISK-POL-0011-accessibility.md @@ -0,0 +1,60 @@ +--- +id: RISK-POL-0011 +type: legal-policy +title: "Accessibility of digital services" +regime: "BFSG (European Accessibility Act, Directive 2019/882), EN 301 549 / WCAG" +status: dormant +activates_when: "a consumer-facing digital service or product is offered in Germany — e-commerce, banking, e-books, ticketing, or a consumer app" +owner: risk-nexus +written: "2026-08-20" +cadence: instant +clean_streak: 0 +last_checked: "2026-08-20T21:30:00Z" +next_check: "2026-08-20T21:30:00Z" +--- + +# RISK-POL-0011 — accessibility + +**Dormant, and the most likely of the dormant set to activate.** The estate has +a consumer domain and design work in it; the day any of that is offered to +consumers in Germany, this applies in full and without a grace period for new +services. + +## Why it is written before it is needed + +Accessibility cannot be retrofitted cheaply. It constrains component choice, +colour, focus handling, form semantics and content structure — decisions taken +early and expensively reversed. A policy retrieved at launch is a rebuild; a +policy read at design time is a constraint like any other. + +That is the whole argument for this catalogue existing, and this is the entry +that demonstrates it. + +## What it requires, in outline + +- Conformance to the harmonised standard (EN 301 549, which carries WCAG at + level AA) for the service's interface, and for its documentation and support. +- An **accessibility statement**, published, saying what conforms and what does + not. +- Accessibility considered in the product's own conformity assessment, with + records kept. + +Micro-enterprises providing services are outside scope, which is a real +exemption and also a fragile one to build on — it disappears with headcount or +turnover, and the product does not become accessible by growing. + +## What it requires of systems + +Design-time, not launch-time: semantic markup, keyboard operability, contrast +and focus visibility, form labelling and error identification, no +information-by-colour-alone, captions and alternatives for media. Plus a way to +**test** these that runs before release rather than at it. + +## Evidence that would show this is met + +A conformance assessment against EN 301 549; a published accessibility +statement; automated and manual test results in the release path. + +Nothing here binds any repo today. `whynot-design` and the consumer-domain +repos are where it will land, and naming the owner is theirs, not the +register's. diff --git a/docs/regulatory/policies/RISK-POL-0012-e-invoicing.md b/docs/regulatory/policies/RISK-POL-0012-e-invoicing.md new file mode 100644 index 0000000..f126fea --- /dev/null +++ b/docs/regulatory/policies/RISK-POL-0012-e-invoicing.md @@ -0,0 +1,55 @@ +--- +id: RISK-POL-0012 +type: legal-policy +title: "E-invoicing" +regime: "UStG §14 (as amended by the Wachstumschancengesetz), EN 16931, ViDA" +status: active +activates_when: "the estate is a German business receiving B2B invoices — already true" +owner: risk-nexus +written: "2026-08-20" +cadence: instant +clean_streak: 0 +last_checked: "2026-08-20T21:30:00Z" +next_check: "2026-08-20T21:30:00Z" +--- + +# RISK-POL-0012 — e-invoicing + +**Active now, on the receiving side.** Since 1 January 2025 a German business +must be **able to receive** a structured electronic invoice conforming to +EN 16931 for domestic B2B transactions. That obligation had no transition +period: the issuing obligations are phased, the receiving one was not. + +Issuing obligations phase in afterwards, with thresholds by turnover. The +estate should assume it will be required to issue conformant invoices before it +notices the deadline, because the receiving obligation arrived that way. + +## What it requires of systems + +- An inbox that accepts a structured invoice (XRechnung, or ZUGFeRD's hybrid + PDF/A-3 carrying the XML) and does not treat it as an attachment to be + eyeballed. +- Storage of the **structured original**. A rendered PDF is not the invoice; a + human-readable copy alongside it is not sufficient by itself. +- Retention per `RISK-POL-0009` — eight years for the voucher, in the original + format it was received in. + +## Where it bears on this estate + +`markitect` and `binect-js` handle document flows, and `rapp-qonto`/`fin-hub` +touch payment and banking records. None of them is currently claimed to be the +receiving point for statutory invoices, and **this policy does not assign that +role** — naming the system that must satisfy this is the owning repo's +decision, not the register's. + +What the register records is that the duty exists, is live, and currently has +no named owner in the estate. + +## Evidence that would show this is met + +A demonstrated receipt and archival of an EN 16931 invoice, retained in its +structured form, retrievable at eight years. + +Not established. If a supplier sends one tomorrow, nobody here can say what +happens to it — which is a small, ordinary, entirely fixable gap, and exactly +the kind that only becomes visible when it is written down. diff --git a/workplans/RISK-WP-0001-make-the-register-decidable.md b/workplans/RISK-WP-0001-make-the-register-decidable.md index ac990f8..671b2f2 100644 --- a/workplans/RISK-WP-0001-make-the-register-decidable.md +++ b/workplans/RISK-WP-0001-make-the-register-decidable.md @@ -4,18 +4,12 @@ type: workplan title: "Make the register decidable: severity, disclosure, escalation, expiry" domain: infotech repo: risk-nexus -status: active +status: finished owner: the-custodian topic_slug: risk-nexus created: "2026-08-19" updated: "2026-08-20" waiting_on: - - who: the-custodian - what: "adopt docs/method/escalation.md, which is producing decisions while still status: proposed" - since: "2026-08-19" - would_change: "the rule stops being a draft that looks like coverage; the spend thresholds become the operator's numbers rather than ours" - default: "recorded as de facto in force but unratified, and every escalation sent under it says so on its face" - default_at: "2026-09-17" - who: the-custodian what: "register finding / note / regulatory-record as canon work-record kinds, or rule that the register is a different ontology" since: "2026-08-20" @@ -159,7 +153,7 @@ Completed 2026-08-19. `docs/method/disclosure.md`. The deferral was re-taken and ```task id: RISK-WP-0001-T03 -status: progress +status: done priority: high ``` @@ -185,7 +179,7 @@ The custodian adopts the rule. Ask, do not assume. **Output:** `docs/method/escalation.md`. -In progress 2026-08-19. `docs/method/escalation.md` is written and `status: proposed`. All five INTENT triggers settled — 1 adopted and bounded, 2 adopted unbounded, 3 bounded at EUR 50/month or EUR 500 one-off, 4 bounded by one failed routing exchange, 5 bounded at twice the review interval — plus trigger 6 (ordering hazard producing a false attestation), added because `RISK-F-0002` produced the case. Tested against all seven findings before proposing. **Not done until the custodian adopts it**, and the spend numbers are the operator's to overwrite. +In progress 2026-08-19. `docs/method/escalation.md` is written and `status: proposed`. All five INTENT triggers settled — 1 adopted and bounded, 2 adopted unbounded, 3 bounded at EUR 50/month or EUR 500 one-off, 4 bounded by one failed routing exchange, 5 bounded at twice the review interval — plus trigger 6 (ordering hazard producing a false attestation), added because `RISK-F-0002` produced the case. Tested against all seven findings before proposing, and against nine by the time it was adopted. The €50/month and €500 thresholds are now the operator's numbers rather than ours — they bound nothing so far, since the only spend decision taken (`RISK-F-0006`) was approved without a figure. ### T04 — Review dates and expiry