Implementation seed for ADR-025 Epic D, the final epic: seven fill-in policy templates under docs/compliance/templates/ (2 anchored, 5 skeleton with not-code-enforced banner), a two-column pre-launch compliance checklist mapping playbook obligations to template mechanisms, a compliance-overview.md hub, and a landed + refreshed operator-checklist.md. Pure docs — no code, no conformance changes. Status: approved — ready for pnpm work decompose.
22 KiB
id, title, type, status, author, created, updated
| id | title | type | status | author | created | updated |
|---|---|---|---|---|---|---|
| compliance-docs-scaffolds | Compliance docs scaffolds — Epic D of ADR-025 | prd | approved | danijel | 2026-05-20T09:18:39Z | 2026-05-20T09:34:30.184Z |
Problem
Epics A–C shipped the compliance machinery: PII manifests + retention + sub-processor generators (A), DSR + consent + cookie banner (B), security headers + rate-limit + SBOM (C). A consumer adopting the template now has the code-enforced ~80% of the DPA/GDPR playbook.
But three documentation gaps remain, each of which hurts a real reader:
- No human-authored policy artifacts. A DPA auditor or a customer doing GDPR due diligence expects
incident-runbook.md,dsr-procedure.md,backup-policy.md,password-policy.md,device-policy.md,onboarding.md,offboarding.md— organizational policy documents the code can't generate. Every consumer writes these from a blank page, usually badly, usually late. - No single launch gate. There's no answer to "are we compliant enough to ship to a paying customer?" The playbook §19 is a generic checklist; nothing maps it to this template's concrete features (
pnpm compliance:emit-all --check,core-audit, DSR endpoints) or flags which obligations are the consumer's own. - No compliance map. After 4 epics, compliance docs sprawl across
docs/compliance/,docs/guides/(8+ files),docs/decisions/(6 ADRs), and rootcompliance/. A new agent, auditor, or engineer has no entry point answering "how is compliance structured here?"
A fourth, smaller gap: docs/guides/operator-checklist.md has sat untracked since the ADR-022/023 work and is now stale — it predates ADR-024 (analytics) and ADR-025 (the compliance epics). The pre-launch checklist needs to cross-reference it, so it must be landed and refreshed.
ADR-025 settled the strategy: fill-in templates under docs/compliance/, a pre-launch checklist, the docs/compliance/ vs root compliance/ split documented. This PRD is the implementation seed for Epic D — the final epic of ADR-025.
Goal
Ship the compliance documentation layer so a downstream consumer gets: (1) seven copy-and-fill policy templates, (2) a template-tailored pre-launch compliance checklist that maps every playbook obligation to its template mechanism or flags it consumer/infra-scope, (3) a single compliance-overview.md hub mapping the 22 playbook sections to their covering ADR/guide/template. Pure documentation — no code, no manifests, no conformance rules.
In scope
Fill-in policy templates — docs/compliance/templates/
Seven Markdown templates, copy-to-compliance/-and-fill. Two tiers:
- Anchored (reference real Epic A/B/C features):
incident-runbook.template.md— breach detection → triage → containment → notification (GDPR Art. 33 72h / typical DPA 24h) → post-mortem. Cross-references the audit channel (ADR-018), Sentry alerting (ADR-014), the security-headers + rate-limit surfaces (Epic C).dsr-procedure.template.md— how a data subject request is received, validated, fulfilled, and recorded. Cross-references the DSR endpoints +core-dsrinterfaces (Epic B), the auditCONSENT_*/RESTRICTactions, thecompliance/data-map.ymlartifact (Epic A).
- Skeleton (org-policy structure, heavy
[FILL IN:], "policy not code-enforced by the template" banner):backup-policy.template.mdpassword-policy.template.md— banner explicitly cross-references ADR-025's deferral of MFA + password policy + lockout (product-shaped, not built)device-policy.template.mdonboarding.template.mdoffboarding.template.md
All templates use the [FILL IN: <description>] marker convention — self-documenting, greppable, collision-free.
Pre-launch compliance checklist — docs/guides/pre-launch-compliance-checklist.md
A two-column status table. Column 1 = playbook obligation (drawn from playbook §19 + the 22 sections). Column 2 = one of:
- Shipped by template — with the concrete verification command (e.g.
pnpm compliance:emit-all --check,pnpm conformance, securityheaders.com scan) - Consumer responsibility — the consumer must do this (fill a policy template, wire a vendor)
- Infra responsibility — deploy/infra-layer (EU region pinning, TLS at edge, backups)
The table operationalizes ADR-025's three-way coverage split (template-shaped / deferred / consumer-scope) into a checkable launch gate.
Compliance overview hub — docs/guides/compliance-overview.md
The single entry point. Maps each of the 22 playbook sections to the ADR / guide / template / epic that covers it. Includes the "what's deferred / what's consumer-scope" summary. Links one-directionally out to every compliance guide, ADR, and template. Added to CLAUDE.md "Read First".
Operator checklist — land + refresh docs/guides/operator-checklist.md
The existing untracked operator-checklist.md is committed and refreshed to current state:
- Add ADR-024 operator actions (analytics backend wiring is consumer-scope; note it)
- Add ADR-025 operator actions: the
compliance/directory as committed audit evidence, the compliance drift CI gate + pre-commit hook, retention purge job scheduling, thecompliance/sub-processors.manual.ymlhand-authored file - Keep the existing ADR-022/023 content (push to remote, GitHub Apps, branch protection, weekly cadence)
Doc wiring (one-directional)
CLAUDE.md"Read First" — addcompliance-overview.mdpointerdocs/compliance/README.md— add a "Policy templates" section pointing attemplates/and explaining the copy-to-compliance/workflow + the[FILL IN:]convention + thegrep -rn '\[FILL IN:' compliance/verification one-linerdocs/glossary.md— new entries:pre-launch compliance checklist,compliance overview,fill-in template,[FILL IN:] marker- Existing compliance guides (
dsr.md,consent.md,security-headers.md,rate-limiting.md,audit-and-compliance.md,ci-security.md) — not touched; the overview links to them one-directionally
Out of scope
- Any code, manifest field, ESLint rule, brand, generator, or conformance change — Epic D is pure documentation
- Rewriting the existing compliance guides —
dsr.md,consent.md, etc. stay as-is; the overview links to them, they don't link back - A machine-checkable "no
[FILL IN:]left incompliance/" lint/CI gate — the marker convention is chosen to allow a future check, but Epic D ships docs only; the gate is a deferred follow-up - Generating
compliance/*.mdfilled artifacts — the template shipsdocs/compliance/templates/*.template.md; the consumer copies and fills. The template never ships filled policy docs (it has no real org data) - DPIA / RoPA / SCC / Privacy Policy / ToS / DPA document templates — legal-instrument artifacts; consumer + legal counsel author them. The overview names them as consumer-scope but Epic D ships no template for them
- Enforcing the password policy the
password-policy.template.mddocuments — MFA + password rules + lockout are ADR-025 deferrals; the template documents the policy shape, not the enforcement - Broadening
docs/compliance/README.mdinto the hub — the README stays scoped to generator schema reference; the hub is the separatecompliance-overview.md - Multi-language / localized policy templates — English only
- The Epic D docs covering Epic D itself — no meta-documentation
Constraints
- ADR-025 — Epic D is the fourth and final epic; strategy settled there. The
docs/compliance/vs rootcompliance/split is canonical. - ADR-018, ADR-014, ADR-017, ADR-022, ADR-023, ADR-024 — the overview + anchored templates cross-reference these; references must be accurate to shipped state.
- No conformance surface — Epic D adds no manifest field, no ESLint rule, no brand. Conformance ESLint rule count stays 13 (
pii-declaration-must-be-complete,no-undeclared-consent-check,no-undeclared-rate-limitlanded in Epics A–C). Any rule-count reference in Epic D docs must say 13. - Sequencing — Epic D lands after Epics A, B, C so the anchored templates + checklist + overview reference shipped features, not planned ones. If a referenced feature is still in flight at decompose time, the story for that doc waits.
[FILL IN:]convention — every placeholder uses[FILL IN: <description>]. No bare{{ }}, no italic-only markers.- Skeleton banner — the 5 skeleton templates carry a banner stating the policy is organizational and not code-enforced by the template.
password-policy.template.md's banner cross-references ADR-025's MFA/password deferral by ADR number. - One-directional links — Epic D touches
CLAUDE.md,docs/compliance/README.md,docs/glossary.md+ new files only. Existing guides are not edited. - Conventional Commits — every story = one
docs:orchore(docs):commit. - No
--no-verify— pre-commit gates run; the compliance drift gate (emit-all --check) must still pass (Epic D changes no collections, so it will).
Success criteria
docs/compliance/templates/contains 7*.template.mdfiles; each anchored one cross-references at least one real ADR + one realpnpmcommand or shipped interface; each skeleton one carries the "not code-enforced" banner.grep -rn '\[FILL IN:' docs/compliance/templates/returns matches in every template (proves the convention is used); the same grep against a hypothetical filled copy incompliance/would return empty.docs/guides/pre-launch-compliance-checklist.mdis a two-column table; every "Shipped by template" row names a runnable verification command; every consumer/infra row is explicitly labelled.docs/guides/compliance-overview.mdmaps all 22 playbook sections; every row points at a real ADR / guide / template / epic; the file is listed in CLAUDE.md "Read First".docs/guides/operator-checklist.mdis tracked in git (no longer untracked) and contains sections for ADR-024 + ADR-025 operator actions.docs/compliance/README.mdhas a "Policy templates" section.docs/glossary.mdhas the 4 new entries.pnpm lint && pnpm typecheck && pnpm test && pnpm conformance && pnpm fallow:audit && pnpm compliance:emit-all --checkall green (Epic D touches no code, so these are unaffected — the criterion is "didn't break anything").- No broken internal doc links — every
[text](path)in the new files resolves to an existing file.
User stories
- As a downstream consumer preparing for a DPA audit, I want seven copy-and-fill policy templates so I produce the required organizational documents without starting from a blank page.
- As a downstream consumer, I want every placeholder marked
[FILL IN: <description>]so I (or an agent) cangrepfor unfilled spots and never ship a half-filled runbook. - As a downstream consumer filling
password-policy.template.md, I want a banner telling me the template doesn't enforce these rules in code so I don't assume MFA/lockout is wired. - As a launching team, I want a pre-launch checklist that tells me, per obligation, whether the template handled it (and how to verify) or whether it's on me.
- As a compliance officer, I want the checklist's "Shipped by template" rows to name a runnable command so I can produce verification evidence on demand.
- As an auditor or new engineer, I want a single
compliance-overview.mdmapping the 22 playbook sections to where each is covered so I don't reverse-engineer the structure from scattered files. - As an AI agent asked "is feature X compliant?", I want
compliance-overview.mdin CLAUDE.md "Read First" so I start from the map, not from grep. - As a template operator, I want
operator-checklist.mdcommitted and current so the steps I follow reflect ADR-024 + ADR-025, not just the older ADR-022/023 state. - As a downstream consumer reading the incident runbook, I want it to reference the actual audit channel + Sentry alerting so the breach procedure uses the template's real observability surface.
- As a downstream consumer reading the DSR procedure, I want it to reference the actual
/api/gdpr/*endpoints +core-dsrinterfaces so the procedure matches the shipped code. - As a template author, I want the existing
docs/compliance/README.mdto stay scoped to generator schema and the newcompliance-overview.mdto be the hub, so neither doc tries to be both. - As a template maintainer, I want Epic D to touch only CLAUDE.md + README + glossary + new files so the change has a small, reviewable blast radius.
Implementation decisions
Module surface
Epic D creates no packages and modifies no code. It is entirely under docs/.
New files:
docs/guides/compliance-overview.md— the hubdocs/guides/pre-launch-compliance-checklist.md— the two-column launch gatedocs/compliance/templates/incident-runbook.template.md— anchoreddocs/compliance/templates/dsr-procedure.template.md— anchoreddocs/compliance/templates/backup-policy.template.md— skeletondocs/compliance/templates/password-policy.template.md— skeletondocs/compliance/templates/device-policy.template.md— skeletondocs/compliance/templates/onboarding.template.md— skeletondocs/compliance/templates/offboarding.template.md— skeleton
Modified files:
docs/guides/operator-checklist.md— landed from untracked + refreshed for ADR-024/025CLAUDE.md— "Read First" gainscompliance-overview.mddocs/compliance/README.md— gains a "Policy templates" sectiondocs/glossary.md— 4 new entries
Marker convention
[FILL IN: <description>] — fixed [FILL IN: prefix (greppable), free-text description inside (self-documenting), ] close. Example: Notify [FILL IN: data protection officer name + email] within [FILL IN: hours — GDPR Art. 33 caps at 72] of a confirmed breach.
The README documents the convention and the verification one-liner grep -rn '\[FILL IN:' compliance/.
Template tiers
Anchored (incident-runbook, dsr-procedure): structured around real template features. Each names specific ADRs, pnpm commands, interfaces, endpoints. They still contain [FILL IN:] markers for genuinely org-specific values (on-call contacts, escalation names, SLA targets) but the procedure skeleton is template-substantive.
Skeleton (backup-policy, password-policy, device-policy, onboarding, offboarding): mostly [FILL IN:]. Each opens with a banner:
This is an organizational policy template. The template scaffolds the document structure; it does not enforce these rules in code. Fill every
[FILL IN:]marker and have the policy reviewed by whoever owns compliance.
password-policy.template.md's banner adds: a sentence pointing at ADR-025's explicit deferral of MFA + password policy + lockout, so a reader understands the template has no code backing the password rules they're about to write.
Pre-launch checklist shape
Two-column Markdown table. Rows grouped by playbook section (Infrastructure, Data, Application, Secrets, Sub-Processors, Logging, Breach, DSR, Backup, SDLC, Workforce, Legal, Documentation). Column 2 values are one of three labelled kinds with the verification command inline for the "Shipped by template" kind. The checklist links to compliance-overview.md (the map) and to the relevant templates (the consumer-action artifacts).
Compliance overview shape
A section-by-section map of the 22 playbook sections. For each: a one-line statement of the obligation, then the covering artifact(s) — ADR number, guide path, template path, or epic. A closing summary restates ADR-025's deferrals (RBAC, MFA, breach-detection, GDPR Art. 22) and the consumer/infra-scope items (EU region, TLS, MDM, legal instruments).
Operator checklist refresh
Landing the existing untracked file as the starting point, then adding two sections:
- ADR-024 (analytics) — analytics backend is consumer-chosen + consumer-wired; operator action is "decide whether to wire an analytics vendor; if so, run it through
/evaluate-library." - ADR-025 (compliance) —
compliance/*.ymlare committed audit evidence; the compliance drift gate runs in pre-commit + CI; the retention purge job schedules percustom.retention;compliance/sub-processors.manual.ymlis hand-authored for non-npm vendors.
The existing ADR-022/023 content (remote push, GitHub Apps, branch protection, weekly Renovate/Socket cadence) is preserved.
No conformance surface
Epic D adds no manifest field, no ESLint rule, no brand, no generator. The conformance rule count stays 13. The compliance drift CI gate is unaffected (no collections change).
Testing decisions
Epic D is documentation — "testing" means verification, not unit tests:
- Link integrity — every relative Markdown link in the new files resolves to an existing file. Verified by a link-check pass during the documentation story (manual
grepof](targets, or a one-off script; no permanent CI gate added). - Marker presence —
grep -rn '\[FILL IN:' docs/compliance/templates/returns hits in all 7 templates. - ADR/command accuracy — every ADR number,
pnpmcommand, interface name, and endpoint path referenced in the anchored templates + overview + checklist is cross-checked against shipped state at authoring time (Epics A–C are landed by the time Epic D dispatches). - Gate pass-through —
pnpm lint && pnpm typecheck && pnpm test && pnpm conformance && pnpm compliance:emit-all --checkstay green; Epic D touches no code, so the criterion is "no regression." - No new test files — there is no code to test. No repository contract suite, no use-case unit tests, no Playwright specs.
- Prior art to mirror —
docs/compliance/README.md(existing, Epic A) for the annotated-doc voice;docs/guides/ci-security.md+docs/guides/audit-and-compliance.mdfor guide structure + the "What X requires / How the template handles it" framing;docs/guides/operator-checklist.md(the untracked file itself) for the checklist voice.
Open questions
- Q1: Should the pre-launch checklist live in
docs/guides/ordocs/compliance/? — Recommended:docs/guides/. It's a how-to/runbook (the consumer runs it), anddocs/compliance/is now reserved for generator schema +templates/. Keeps the "guides = how-to" / "compliance = schema + templates" split clean. - Q2: Should the 7 templates carry a
status: templatefrontmatter field so a future lint can distinguish unfilled from filled? — Recommended: yes, minimal frontmatter (status: template+playbook-section: <n>). Cheap, and it enables the deferred "no unfilled template incompliance/" check without committing to building that check now. - Q3: Does
compliance-overview.mdduplicate ADR-025's content? — Recommended: no — ADR-025 is the decision record (why this strategy); the overview is the navigational map (where each thing lives). The overview links to ADR-025 rather than restating its rationale. - Q4: Should Epic D add a CI link-check for docs? — Recommended: no, deferred. A docs link-checker is a reasonable future addition but it's a CI/tooling change, not a docs deliverable; bundling it into a pure-docs epic widens scope. Note it in "Out of scope (deferred)."
- Q5: Refresh
operator-checklist.mdcontent fully, or land-then-refresh in two commits? — Recommended: two stories — story 1 lands the file verbatim aschore(docs), story 2 refreshes it asdocs(compliance). Keeps the "what existed" vs "what changed" diff legible for review.
Out of scope (deferred)
- CI link-checker for docs — reasonable future tooling PRD; not a pure-docs deliverable (see Q4)
- A
no-unfilled-templatecheck — verifyingcompliance/*.mdhas no[FILL IN:]left; the marker convention + Q2 frontmatter enable it, but building the check is deferred - DPIA / RoPA / SCC / Privacy Policy / ToS / DPA templates — legal instruments; consumer + counsel author them
- Localized (non-English) policy templates
- Auto-generating filled policy docs from template config — the template has no org data; filling is inherently a consumer action
- A compliance dashboard / status page — the pre-launch checklist is static Markdown; a live dashboard is out of scope
Further notes
- Builds on: ADR-025 (strategy umbrella — Epic D is its fourth epic), Epic A PRD (
compliance-manifests-pii-retention-subprocessors— the overview + checklist reference its generators +compliance/*.yml), Epic B PRD (dsr-consent-and-cookie-banner— thedsr-proceduretemplate references its endpoints + interfaces), Epic C PRD (security-headers-rate-limit-sbom— theincident-runbook+ checklist reference its headers + rate-limit + SBOM). - Closes: ADR-025. With Epic D, all four epics of the EU compliance baseline are decomposed; the template's compliance coverage reaches the ~80% ADR-025 targeted, with the remaining ~20% explicitly documented as deferred or consumer/infra-scope in
compliance-overview.md. - Sequencing: Epic D dispatches last. Within Epic D: (1) land
operator-checklist.mdverbatim, (2) refresh it, (3) write the 7 templates (anchored first — they need the most cross-referencing), (4) write the pre-launch checklist, (5) writecompliance-overview.md, (6) wire CLAUDE.md + README + glossary. The overview is written near-last so it can link to the finished templates + checklist. - Stakeholders: downstream consumers preparing for audits (primary beneficiary — get policy templates + launch gate), auditors + compliance officers (get the overview map + verifiable checklist), template operators (get a current operator checklist), AI agents (get
compliance-overview.mdas a Read-First entry point), template authors (small reviewable blast radius — docs only). - PII note: Epic D ships no code and stores no data — no PII surface, no
custom.piichanges, no DSR interaction. Thepassword-policydeferral note is the only place Epic D references unbuilt behavior, and it does so explicitly to prevent a false enforcement assumption.