risk-nexus/docs/regulatory/policies/README.md
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

73 lines
4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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