Compliance, Zertifizierung & Audit-Bereitschaft
Lebende Doku (CLAUDE.md §Compliance): Belege/Checklisten für Zertifizierungen und Audits werden
laufend mitgepflegt — nicht erst zum Audit. Bei jedem relevanten Feature den Compliance-Bezug
hier nachziehen. Risiken parallel im docs/betrieb/Risikoregister.md.
Zielmärkte & relevante Rahmen
Primärmärkte DE · AT · CH (Reihenfolge DE→DACH→EU). Relevante Rahmenwerke, die bei Features proaktiv zu berücksichtigen und ggf. zu flaggen sind:
| Thema | DE | AT | CH | Bezug |
|---|---|---|---|---|
| Datenschutz | DSGVO + BDSG | DSGVO + DSG | revDSG (CH-eigen, kein EU) | OP-LOG-1, OP-OBS-1, OP-SEC-1 |
| E-Rechnung B2B | Pflicht (Empfang ab 2025) — XRechnung/ZUGFeRD | E-Rechnung (Bund) | QR-Rechnung | OP-BILLING-1 |
| Datenresidenz | EU | EU | CH/EU (CH = Nicht-EU) | OP-I18N-1, OP-AUTH-1 |
| Arbeitszeit (Scheduler-Planung darf keine unzulässigen Schichten erzwingen) | ArbZG | AZG | ArG | OP-OPT-7, Scheduler |
| Produkt-/Datensicherheit | — | — | — | OP-SEC-1 |
CH-Hinweis: Schweiz ist nicht EU (eigene Währung CHF, revDSG statt DSGVO, eigene Zahlarten wie TWINT). Multi-Currency/i18n nicht hartkodieren → OP-I18N-1.
Zertifizierungs-/Compliance-Tracker (lebend)
Stand: 2026-06-27. Kanonische At-a-glance-Statusübersicht für Zertifizierungen (ISO/TÜV) und regulatorische Compliance (DSGVO/revDSG …). Review-Takt: zu Session-/PR-Beginn mitpflegen (CLAUDE.md §Compliance) — bei jedem relevanten Feature die betroffene Zeile nachziehen. Belege git-nah (privates Repo/Advisory), keine Secrets/PII im Klartext.
Status-Legende: ☐ offen · ◐ in Arbeit · ☑ erfüllt/bereit · ➖ n/a (noch nicht relevant).
| # | Rahmen / Anforderung | Status | Beleg / Artefakt (git-nah) | Nächster Schritt | Bezug |
|---|---|---|---|---|---|
| ISO/IEC 27001 (ISMS) | |||||
| C-01 | Scope / Statement of Applicability | ☐ | — | SoA-Entwurf anlegen (Scope: Worker/DO + Solver + Doku-Site) | — |
| C-02 | Risikobehandlung | ◐ | docs/betrieb/Risikoregister.md (Register gepflegt) | Behandlungsplan je Top-Risiko ergänzen | RISK-* |
| C-03 | Zugriffs-/Rollenmodell | ◐ | Cloudflare Access; interim Infra-Kosten per verifizierter Access-Allowlist gegated (fail-closed) | echtes Mandanten-/Rollenmodell | OP-AUTH-1, OP-COST-1 |
| C-04 | Audit-Log (revisionssicher) | ◐ | D1/EU taktano-audit, Dual-Write live (#186), append-only | Panel/Rollen/Suche (Slice 3) | OP-AUDIT-1 |
| C-05 | Lieferkette / SBOM | ☑ | CycloneDX-SBOM CI-Job sbom (npm Server+Client, je Lauf) + Dependabot + npm/pip-audit-Gates + CodeQL Default Setup; alle GitHub-Actions SHA-/Version-gepinnt (letzte @master-Referenz flyctl 07-03 gepinnt); Vuln-Assessment 07-03: 0 Prod-Runtime-Vulns, Dev-Toolchain-Highs behoben, Residuen begründet akzeptiert (RISK-4) | Solver-CycloneDX (cyclonedx-py) + signierte Release-SBOM | OP-SBOM-1 |
| C-06 | Incident-/Logging-Prozess | ◐ | OTel-Logger-Wrapper live (strukturiert, PII-Scrubbing, Version/Build/trace_id) → OTLP-Export nach Grafana Cloud EU live (Logs + native Metrics), in-App-Verbindungstest + Status-Karte (v0.48.x); No-Console-Gate | Alerting-Regeln + Incident-Runbook (Reaktionspfad) | OP-LOG-1, OP-OBS-1 |
| Datenschutz (DSGVO/BDSG · DSG · revDSG) | |||||
| C-07 | Datenresidenz EU | ◐ | R2 jurisdiction=eu (Fotos/Modelle), D1 weur, Telemetrie Grafana Cloud EU (otlp-gateway-prod-eu-west-2), Better-Auth EU-self-host geplant | Residenz aller Dienste (Solver/Fly EU-Region) belegen | OP-I18N-1, OP-AUTH-1, OP-OBS-1 |
| C-08 | Datenschutz-Folgenabschätzung (DSFA) | ☐ | — | DSFA für Foto-/PII-Verarbeitung (OP-QS-2) + Scheduler-Personendaten | OP-QS-2 |
| C-09 | Datenminimierung / PII-Scrubbing | ◐ | Foto-Pre-Upload-Gate (On-Device Gesichts-/Kennzeichen-Verpixelung, OP-QS-2); Datenmodell „Kunde = nur Name + CRM-Link“; PII-Scrubbing im Logger live (sensible Keys + E-Mail-Maskierung, vor OTLP-Export, test:obs) | Scrubbing-Regeln bei neuen Log-Feldern laufend prüfen | OP-QS-2, OP-LOG-1 |
| C-10 | Auftragsverarbeitung (AVV) + Subdienstleister | ☐ | Dienste: Cloudflare, Fly.io, EU-LLM-Provider (In-App-Assistent, OP-AI-4), Grafana Labs (Telemetrie, OP-OBS-1), (geplant) SevDesk/Better-Auth | AVV/DPA je Subdienstleister + Verzeichnis (VVT); AVV mit LLM-Provider + DPA mit Grafana (s. C-18) vor Produktiv-Aktivierung | OP-BILLING-1, OP-AI-4, OP-OBS-1 |
| C-11 | Betroffenenrechte (Auskunft/Löschung) | ☐ | — | Lösch-/Auskunftspfad konzipieren (Audit-Log-Retention beachten) | OP-AUDIT-1 |
| TÜV / Produkt- & IT-Sicherheit | |||||
| C-12 | Architektur-/Datenfluss-Doku | ◐ | docs/architektur/* (Audit-Log/Observability/Kosten), CLAUDE.md §Architektur | konsolidiertes Datenfluss-/Trust-Boundary-Diagramm | — |
| C-13 | Penetrationstest-Bericht | ☐ | — | autorisierten Pentest vor Mehr-Mandanten-Betrieb beauftragen | OP-SEC-1 |
| C-14 | Notfall-/Fail-safe-Konzept | ◐ | Zugang fail-open (OP-ACCESS-1), TS-Solver-Fallback bei CP-SAT-Ausfall | Backup-/Restore- + Incident-Runbook | OP-ACCESS-1 |
| Markt-/Rechtskonformität | |||||
| C-15 | E-Rechnung B2B (DE/AT/CH) | ☐ | Konzept docs/architektur/Billing-Zugang.md; SevDesk als Rechnungs-SoR geplant | XRechnung/ZUGFeRD-Empfang + QR-Rechnung CH | OP-BILLING-1 |
| C-16 | Security-Audit (autorisiert) | ☐ | Vuln-Gates (Dependabot/audit/CodeQL) als Vorarbeit | Scope/Angriffsflächen + Findings-Prozess | OP-SEC-1 |
| KI / LLM (In-App-Assistent) | |||||
| C-17 | LLM-Datenverarbeitung EU-konform | ◐ | EU-gehostetes Modell gewählt (ASSISTENT_LLM_BASE_URL, DSGVO-Residenz); dormant ohne Key (deploy-sicher); Datenminimierung (schmale Insight-Projektion, kein Klartext-PII im Prompt); Tools nur read/simulate (kein Auto-Apply) | AVV mit Provider (C-10) + EU-Region final verifizieren; externe vs. interne Doku-Sicht scharf schalten (OP-DOCS-5) | OP-AI-4, RISK-15 |
| Observability / Telemetrie | |||||
| C-18 | Telemetrie-Datenverarbeitung EU-konform (Grafana) | ◐ | Grafana Cloud EU (otlp-gateway-prod-eu-west-2) live; Datenminimierung: nur Betriebs-Telemetrie (Logs/Metriken), PII-gescrubbt (C-09), keine Kundendaten by design; Region-/Backend-Wechsel code-frei via OTLP | DPA/AVV mit Grafana Labs abschließen (Standard-DPA über grafana.com/legal akzeptieren + gegenzeichnen) und ins VVT (C-10) aufnehmen; Retention/Aufbewahrung dokumentieren; vor Go-Live final verifizieren | OP-OBS-1, RISK-16, C-10 |
| C-19 | Doku-RAG-Index (Cloudflare Vectorize) — Residenz | ◐ | Vectorize ohne EU-Jurisdiktions-Option (anders als R2, Index global verteilt) — Datenminimierung by design: der Index taktano-doku enthält NUR Doku-Chunks aus docs/**/*.md + Metadaten (Datei/Titel/Sichtbarkeit), kein PII, keine Kunden-/Tenant-Daten; die Frage-Embeddings laufen über das EU-Modell (C-17), nur der Ergebnis-Vektor geht an Vectorize; Cloudflare ist als Subdienstleister bereits im AVV-Scope (C-10) | Vectorize in die AVV-/VVT-Betrachtung (C-10) explizit aufnehmen; periodisch prüfen, ob Cloudflare EU-Jurisdiktion für Vectorize anbietet (dann pinnen); bei künftig sensibleren Index-Inhalten (z. B. Tenant-Doku) Residenz neu bewerten | OP-DOCS-2, OP-AI-4, RISK-17, C-10 |
Lesart: ☑ = belegbar erfüllt; ◐ = Grundlage/Interim vorhanden, Lücke benannt; ☐ = noch offen. Die Detail-Substantiierung je Standard steht unter SBOM (C-05) sowie in den verlinkten OPs/Docs. Neue Compliance-/Zertifizierungs-Themen hier als Zeile ergänzen (nicht nur im Fließtext).
SBOM (Software Bill of Materials) — OP-SBOM-1
Immer aktuell (CLAUDE.md §Compliance): CycloneDX je Ökosystem.
- npm (Server + Client):
npm run sbom(=npm sbom --sbom-format cyclonedx). CI-Jobsbom(.github/workflows/ci.yml) erzeugt Server- + Client-SBOM bei jedem Lauf als Artefaktsbom-cyclonedx. - Python-Solver:
pip-audit✅ im CI-Jobsecurity-audit(Vuln-Scan überrequirements.txt); CycloneDX-SBOM (cyclonedx-py) noch offen. - Umgesetzt (06-27): Vuln-Gates im CI —
npm audit(Produktiv-Deps, high+) +pip-audit(Solver) und Dependabot (npm/pip/actions). CodeQL-SAST ✅ aktiv via GitHub Default Setup (TS+Python, kein eigener Workflow; s. u.). Details unten. - Wöchentlicher Sanity-Lauf (06-27): Workflow
weekly-audit.yml(Montags-Cron + manuell) fährt die Vuln-Audits zeitgesteuert neu (fängt neu bekannt gewordene Advisories ohne Push) und prüft viascripts/check-security-setup.sh, ob die Kontrollen + Repo-Settings „alle gesetzt" sind (warnt, blockt nicht). Dokumentiert als Sanity-Check:docs/betrieb/Sanity-Checkliste.md→ „Security-/Setup-Sanity". - Geplant: optional signierte, versionierte Release-SBOM (an Version+Build, CLAUDE.md §Versionierung) als Zertifizierungs-Beleg.
Werkzeug-Befund Supply-Chain & Code-Qualität (06-27) — OP-SEC-1/OP-SBOM-1
Bewertung externer Tools (User-Frage „Hilft uns SonarQube/Snyk?"): Lücken sind real, aber zuerst gratis & GitHub-nativ zu schließen (kein Drittanbieter, kein Quellcode-/Dependency-Export, DSGVO-arm):
- Supply-Chain (RISK-4) — ✅ umgesetzt 06-27: Dependabot (
.github/dependabot.yml: npm Server+Client, pip Solver, github-actions; wöchentlich, Patch/Minor gruppiert) + CI-Jobsecurity-audit(npm audit --omit=dev --audit-level=highServer/Client als blockierender Gate = ausgeliefertes Risiko; volles Audit inkl. Dev informativ;pip-auditSolver; least-privilegepermissions: contents:read). Gate blockiert PR/CI, nichtdeploy.needs(bewusst: ein nicht-patchbares Prod-Advisory soll keine Release-Sperre auslösen — neue Advisories werden via CI aufmaintrotzdem rot). Snyk erst später als Komfort (Lizenz-/Audit-Dashboard), nicht zwingend. - Lint/Static/SAST-Gate — ✅ CodeQL via Default Setup (06-27): Code scanning im Repo als
GitHub Default Setup aktiviert → GitHub fährt CodeQL selbst (erkennt TS+Python automatisch,
läuft auf PR/Push, null Wartung). Bewusst kein eigener
codeql.yml(advanced + default schließen sich aus). Findings im Security-Tab; Status best-effort im wöchentlichen Setup-Sanity-Lauf. Ergänzend offen: ESLint + ruff/mypy (Style/Lint). SonarQube/SonarCloud nur später als audit-fähiges Quality-/Coverage-Dashboard (dann mit Datenresidenz-Vorbehalt — self-host bevorzugt). - Bewusst: Dev-Toolchain-Vulns (Wrangler/Miniflare → undici/ws, high) brechen CI nicht — sie werden nicht
in den Worker deployt; der blockierende Gate prüft
--omit=dev. Dev-Advisories laufen über Dependabot-PRs ein. - Sentry/Grafana sind kein Security-Tool, sondern OP-OBS-1-Backend-Kandidaten →
docs/architektur/Observability.md.
Proaktives Flagging (verbindlich)
Tauchen kritische/regulatorisch relevante Themen auf (s. Rahmen-Tabelle) — für DE/AT/CH oder generell —
aktiv darauf hinweisen und Handlungsoptionen aufzeigen, nicht still übergehen; Risiko in
Risikoregister.md eintragen, Umsetzung als OP in ops/<ID>.md (→ Offene-Punkte.md).
Bezüge
OP-SEC-1 (Pentest/Angriffsflächen) · OP-AUDIT-1 (Audit-Log) · OP-LOG-1 (Log-Handling) ·
OP-OBS-1 (OTel/Observability → docs/architektur/Observability.md) · OP-SBOM-1 (SBOM) · OP-BILLING-1/OP-ACCESS-1 (Abrechnung/Zugang) ·
OP-AUTH-1 (Auth/Mandanten) · OP-I18N-1 (Mehrsprachigkeit/Multi-Currency) · docs/betrieb/Risikoregister.md.
↩ Zurück zur Doku-Landkarte · Lesepfade · Register (alle OPs)