Files
agentic-dev/docs/compliance/sub-processors.example.yml
Danijel Martinek f77e6ea881 chore(template): clean-slate template snapshot from bb4a0c7
Curated, product-agnostic snapshot of the post-story-04 tree: demo
content deleted, auth-only reference feature, web-next shell, all gates
green. Product-specific docs, ADRs 027-029, PRDs/epics/archive, editor
library traces, and product naming are curated out; generic template
repairs (coverage provider devDeps, root test:coverage script, live
lint fixes, root-only release-please) are kept. See TEMPLATE.md for
provenance, curation list, and usage.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016j8z4VHjedXDTjEDNg7qHK
2026-07-12 20:40:54 +02:00

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