Danijel Martinek
879b0215c3
Adds docs/compliance/ as the canonical onboarding reference for the compliance module, covering every field in each generated YAML artifact with inline annotations and explaining the docs/compliance/ (examples) vs compliance/ (live artifacts) split. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
69 lines
3.7 KiB
YAML
69 lines
3.7 KiB
YAML
# docs/compliance/sub-processors.example.yml — annotated reference for the sub-processors schema
|
|
#
|
|
# This file is NOT generated. It shows both kinds of entries that appear in
|
|
# compliance/sub-processors.yml and explains what each field means.
|
|
#
|
|
# Generated artifact : compliance/sub-processors.yml
|
|
# Generator : pnpm compliance:sub-processors
|
|
# Sources : (1) docs/library-decisions/*.md — frontmatter where is-sub-processor: true
|
|
# (2) compliance/sub-processors.manual.yml — hand-authored non-SDK vendors
|
|
#
|
|
# The two entry kinds are described below. Fields are rendered in a fixed order:
|
|
# package first, then remaining fields alphabetically.
|
|
|
|
sub-processors:
|
|
# ── Kind 1: library-trace entry ───────────────────────────────────────────────
|
|
# Sourced automatically from a library-decision file in docs/library-decisions/.
|
|
# To register a library as a sub-processor, add these fields to its frontmatter:
|
|
#
|
|
# is-sub-processor: true
|
|
# data-sent: "user email and display name for transactional notifications"
|
|
# region: EU
|
|
# dpa-signed: true
|
|
# sccs-required: false
|
|
# contact: https://acme-sdk.example/privacy/dpa
|
|
#
|
|
# The generator reads package, version, and decision from the existing trace
|
|
# frontmatter and merges the sub-processor fields automatically.
|
|
- package: "@acme/notifications-sdk" # npm package name (natural sort key; must match package: in trace)
|
|
contact: https://acme-sdk.example/privacy/dpa # DPA / privacy contact URL
|
|
data-sent:
|
|
"user email address and display name for transactional notification delivery"
|
|
# Plain-language description of what data is transmitted
|
|
decision: approved # Carry-through from library trace (approved | rejected | …)
|
|
dpa-signed: true # Data Processing Agreement in place with this vendor
|
|
region: EU # Primary data-residency region for this processor
|
|
sccs-required:
|
|
false # Standard Contractual Clauses required for data transfer?
|
|
# Required when region is outside the EEA and no adequacy decision
|
|
source: library-trace # Fixed value for entries sourced from a library decision file
|
|
version: "^2.3.0" # npm version specifier from the library trace
|
|
|
|
# ── Kind 2: manual entry ──────────────────────────────────────────────────────
|
|
# For sub-processors that are NOT npm packages (REST APIs, SaaS integrations,
|
|
# infrastructure providers, etc.), create compliance/sub-processors.manual.yml
|
|
# and add entries there. The generator merges this file at emit time and injects
|
|
# source: "manual" automatically.
|
|
#
|
|
# Format for compliance/sub-processors.manual.yml (simple YAML list, no header):
|
|
#
|
|
# - package: acme-email-service
|
|
# version: REST API v3
|
|
# data-sent: "user email address and message content"
|
|
# region: EU
|
|
# dpa-signed: true
|
|
# sccs-required: false
|
|
# contact: https://acme-email.example/legal/dpa
|
|
# decision: approved
|
|
#
|
|
# The "package" field is used as the sort key; use a slug-style identifier.
|
|
- package: acme-email-service # Slug identifier for non-npm vendors (no @ prefix)
|
|
contact: https://acme-email.example/legal/dpa
|
|
data-sent: "user email address and message body for transactional email delivery"
|
|
decision: approved
|
|
dpa-signed: true
|
|
region: EU
|
|
sccs-required: false
|
|
source: manual # Fixed value for entries sourced from sub-processors.manual.yml
|
|
version: "REST API v3" # Non-npm version descriptor; use the API version or contract date
|