docs(compliance): document policy template convention in README and glossary

Add a "Policy templates" section to docs/compliance/README.md explaining
the docs/compliance/templates/ directory, the copy-to-compliance/ workflow,
the [FILL IN:] placeholder convention, and the verification one-liner.

Add four glossary entries: fill-in template, [FILL IN:] marker,
pre-launch compliance checklist, and compliance overview.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
2026-05-20 12:49:50 +00:00
parent ef20345b76
commit a74b7360e1
2 changed files with 39 additions and 0 deletions

View File

@@ -213,6 +213,33 @@ Run `pnpm compliance:sub-processors` after any change to regenerate `compliance/
---
## Policy templates
The `docs/compliance/templates/` directory contains fill-in-the-blank runbooks for the operational policies required before a GDPR-covered launch. These are **template originals** — do not edit them in place.
### Copy-to-`compliance/` workflow
1. Copy the desired template from `docs/compliance/templates/` to `compliance/` (repo root):
```bash
cp docs/compliance/templates/dsr-procedure.template.md compliance/dsr-procedure.md
```
2. Open the copied file and replace every `[FILL IN:]` marker with the project-specific value.
3. Commit the filled file to the repo as a live compliance artifact (same cadence as `compliance/*.yml`).
### `[FILL IN:]` convention
Every placeholder that requires a project-specific value is marked with the literal string `[FILL IN:]` followed by a short description of what is expected. This makes placeholders machine-detectable and easy to audit.
To verify that all placeholders in your live artifacts have been resolved, run:
```bash
grep -rn '\[FILL IN:' compliance/
```
A zero-line result means all templates have been fully filled in. Any output identifies the file and line that still needs attention.
---
## `sccs-required` guidance
Set `sccs-required: true` when:

View File

@@ -309,6 +309,18 @@ External service that processes personal data on behalf of the controller (Strip
**`docs/compliance/` vs `compliance/`**:
Split locations for compliance artifacts. `docs/compliance/` (template-shipped) holds FILL-IN TEMPLATES (`.template.md` runbooks, `.example.yml` references). Root `compliance/` (consumer-created) holds LIVE ARTIFACTS (`data-map.yml`, `retention-policy.yml`, `sub-processors.yml` from generators + consumer-authored filled runbooks). Audit evidence lives in `compliance/`. See ADR-025.
**Fill-in template**:
A `.template.md` file under `docs/compliance/templates/` containing placeholder markers (`[FILL IN:]`) that a project team copies to `compliance/` and completes with project-specific values before launch.
**`[FILL IN:] marker`**:
The literal string `[FILL IN:]` used in fill-in templates to mark every placeholder that requires a project-specific value; machine-detectable via `grep -rn '\[FILL IN:' compliance/` to audit completion status.
**Pre-launch compliance checklist**:
The operational checklist at `docs/guides/pre-launch-compliance-checklist.md` enumerating the GDPR and security controls that must be verified before going live with a production workload — covers data mapping, retention policy, DSR readiness, consent UI, sub-processor contracts, and security headers.
**Compliance overview**:
The hub document at `docs/guides/compliance-overview.md` that maps the full GDPR compliance surface of the template — explains where each artifact lives, which generator or guide produces it, and how the pieces connect (PII inventory, retention, DSR, audit, consent, sub-processors, policy templates, and the pre-launch checklist).
**Span**:
A traced unit of work. Emitted by `tracer.startSpan(...)` (inline in repos) or `withSpan(...)` (composed for use cases + controllers).