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:
@@ -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:
|
||||
|
||||
@@ -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).
|
||||
|
||||
|
||||
Reference in New Issue
Block a user