Technische und Organisatorische Maßnahmen (TOM)

NexDeck Platform — Anhang zur Auftragsverarbeitung nach Art. 28 DSGVO

Cover

Hinweis zur Rechtsform: Die Kre8ive Evolution GmbH befindet sich aktuell in Gründung (i.G.). Nach erfolgter Eintragung im Handelsregister (HRB) werden Rechtsform, HRB-Nummer, Sitz und gesetzliche Vertreter in diesem Dokument, im AVV, in der Datenschutzerklärung sowie im Impressum aktualisiert.

Inhaltsverzeichnis

1. Pseudonymisierung und Verschlüsselung (Art. 32 Abs. 1 lit. a)
2. Vertraulichkeit (Art. 32 Abs. 1 lit. b)
3. Integrität (Art. 32 Abs. 1 lit. b)
4. Verfügbarkeit und Belastbarkeit (Art. 32 Abs. 1 lit. b)
5. Wiederherstellbarkeit (Art. 32 Abs. 1 lit. c)
6. Verfahren zur regelmäßigen Wirksamkeitsprüfung (Art. 32 Abs. 1 lit. d)
7. Sicherstellung im Vertragsverhältnis (Art. 32 Abs. 4)
8. Offene Punkte und Carryovers (Transparenz)
9. Aufbewahrung und Versionierung
10. Versions-Log
11. Anhang: Referenzen und Normenbezug

1. Pseudonymisierung und Verschlüsselung (Art. 32 Abs. 1 lit. a DSGVO)

1.1 Verschlüsselung at-Rest

1.2 Verschlüsselung in-Transit

• Transport-Layer: TLS 1.3 (Mindest-Version) zwischen Client, Vercel-Edge, Supabase und AWS S3. TLS 1.2 deaktiviert.
• HSTS: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload auf allen produktiven Domains (nexdeck.app, www.nexdeck.app). Ein HTTP-Fallback existiert nicht (Redirect 308 von HTTP → HTTPS auf Edge).
• Inter-Service: Supabase-Postgres-Verbindungen ausschließlich über TLS, Service-Role-Keys nur Server-zu-Server.
• Webhooks: Alle eingehenden Webhooks (Stripe, Unipile, OneSignal, AWS SNS) ausschließlich über HTTPS mit Signatur-Verifikation.
• E-Mail-Transport (AWS SES): Versand und Empfang über AWS SES mit erzwungenem TLS (TlsPolicy: Require bzw. TLS-only Receipt). Eingehender Mailempfang erfolgt ausschließlich über eine dedizierte Subdomain (SES-Inbound-MX) — die produktive Haupt-Mail-Infrastruktur des Auftraggebers (eigener Mailprovider) bleibt davon unberührt.

1.3 Application-Layer-Encryption

Sensible Felder oberhalb der Postgres-at-Rest-Schicht werden zusätzlich auf Applikationsebene verschlüsselt:

Key-Hierarchie: ENCRYPTION_KEY als 32-Byte-Masterschlüssel in Vercel-Environment-Variables, getrennt nach Production / Staging / Development. Der Key wird at-Rest verschlüsselt durch Vercel verwaltet und niemals geloggt. Hard-Fail beim Start, falls ENCRYPTION_KEY fehlt oder nicht 32 Bytes lang ist (siehe Wave Business-Email C1).

1.4 Pseudonymisierung

• Identifier: Alle User- und Tenant-IDs als UUIDv4 (kryptografisch sicher generiert, kollisionsresistent). Keine sequentiellen Integer-IDs in öffentlich exponierten API-Responses.
• Externe Magic-Links: 32 Bytes kryptografisch zufälliger Hex-String, Single-Use, TTL 15 Minuten (Booking) bzw. 7 Tage (Proposal), nach Einlösung invalidiert.
• Cross-System-Identifier: Externe IDs (Stripe Customer-IDs, Unipile Account-IDs, OneSignal Player-IDs) werden separat in Mapping-Tabellen geführt, nie als Primärschlüssel verwendet.
• Logs: PII in Application-Logs (Sentry) wird gehasht oder maskiert (z. B. E-Mail-Domains generischer Provider werden in contact_email-Notifications nicht durchgereicht, siehe Wave 42l Iter-4 Finding F4).

1.5 Hash-Algorithmen

1.6 Key-Management

• Sämtliche Schlüssel und Geheimnisse werden in Vercel Environment Variables verwaltet, dort at-Rest verschlüsselt.
• Trennung nach Stage: Production, Preview, Development je eigener Schlüssel.
• Keine Schlüssel im Code-Repository (durchgesetzt per Pre-Commit-Hook TruffleHog und Daueraktivierung GitGuardian auf GitHub).
• Empfohlene Rotation: ENCRYPTION_KEY alle 12 Monate, Supabase-service_role-Keys ad-hoc bei Verdacht. Letzte Rotation: 2026-05-28 (Security-Sprint, vollständige Rotation Supabase PAT + AWS_ADMIN + sb_secret_* + sb_publishable_*).
• Service-Role-Keys ausschließlich serverseitig (Server Actions, Route Handlers); Frontend nutzt anon-Key (publishable). Validiert per Custom-Hook validate-no-service-role-frontend.

2. Vertraulichkeit (Art. 32 Abs. 1 lit. b DSGVO)

2.1 Row-Level Security (RLS)

• Coverage: 100 % aller multi-tenant-relevanten Tabellen (~200 Tabellen) haben aktive RLS-Policies.
• Policy-Pattern: Tenant-Isolation primär über tenant_id = (auth.jwt() ->> 'tenant_id')::uuid bzw. current_setting('app.tenant_id').
• Verifikation: Daily-CI-Check via pg_policies-Query stellt sicher, dass keine Tabelle ohne RLS deployed wird. Schema-Drift-Check (scripts/check-schema-drift-pre-gl.ts) als Pre-Go-Live-Gate.
• Defense-in-Depth: Zusätzlich zur RLS wird in jedem UPDATE/DELETE in Server Actions explizit .eq('tenant_id', currentTenant) gesetzt, validiert per Custom-Hook validate-tenant-isolation (siehe Wave 42l Iter-4 Finding F8).
• PostgREST-Grants: Neue Tabellen erhalten explizite GRANT-Statements für authenticated-Rolle (Pflicht ab Supabase Data API 30.10.2026, durchgesetzt per Migrations-Template-Hook).

2.2 Role-Based Access Control (RBAC)

NexDeck implementiert ein zweistufiges RBAC-Modell, konform mit Art. 28 DSGVO:

• Plattform-Ebene: is_super_admin Boolean (Kre8ive-Evolution-Mitarbeitende für Support und Wartung).
• Tenant-Ebene: 8 Kern-Rollen — owner, admin, manager, dispatcher, backoffice, worker, finance, auditor_viewer — zuzüglich Legacy-Rollen (sales_partner, member) für Bestandskonten.
• Permissions: 33 atomare Permissions, gruppiert in 10 Permission-Groups.
• Branchen-Anpassung: Über tenants.industry_preset_slug (handwerk, agentur, dienstleister) und JSONB-permission_overrides — keine branchen-spezifischen Rollen, um RBAC-Modell flach und prüfbar zu halten.
• Sub-Rollen-Visibility: Sidebar- und Feature-Gating per requirePermission(...) in Server Actions; UI-Guards in /admin/* Pages (siehe Wave 42l Iter-5).

2.3 Multi-Factor-Authentication (MFA)

• Verfahren: TOTP (RFC 6238) via Supabase Auth MFA.
• Aktivierung pro Tenant: tenants.require_mfa_for_admins Boolean — Admins und Owner müssen MFA aktivieren, sonst kein Login auf /admin/* Routen.
• Pre-Go-Live: Globale MFA-Enforcement-Option vorbereitet (Feature-Flag global_mfa_enforced, im Real-Tenant-Onboarding aktivierbar).
• Recovery: Backup-Codes (10 Stück, einmalig generiert, gehashed gespeichert).

2.4 Audit-Log

2.5 Geheimnis-Management in CI/CD

• TruffleHog v3 als Pre-Commit-Hook auf allen Branches.
• GitGuardian als Dauer-Monitor auf dem GitHub-Repository, Alarmierung bei verdächtigen Commits.
• detect-secrets als zusätzlicher Pre-Commit-Hook für strukturierte Geheimnisse (JWT-Pattern, AWS-Access-Keys, Stripe-Keys).
• Hardcoded-Token-Audit: Im Security-Sprint 2026-05-28 wurden 17 historische Test-Token-Files vollständig aus Repo und Git-History entfernt.

2.6 HTTP-Sicherheits-Header

3. Integrität (Art. 32 Abs. 1 lit. b DSGVO)

3.1 Datenbank-Integrität

• Constraints: CHECK, UNIQUE, NOT NULL, FOREIGN KEY mit expliziter ON DELETE-Strategie (RESTRICT für Finanz-/Audit-Bezug, CASCADE nur bei eigentumsgebundenen Kindern).
• Optimistic Locking: DB-Trigger-Pattern für konfliktrelevante Schreibvorgänge (z. B. appointments, crew_assignments aus Calendar-Master Phase 2 F1, invoices aus Vendor-Sprint Wave 43c).
• Schema-Drift-Snapshot: scripts/check-schema-drift-pre-gl.ts als CI-Gate, Pre-Go-Live 0 Findings garantiert (zuletzt verifiziert 2026-05-26 nach Wave 43-DATEV-Closure und Vendor-Sprint).

3.2 Append-only-Audit-Log

• DELETE und UPDATE auf audit_log per Trigger blockiert, Verstöße werden ihrerseits geloggt.
• Hashchain (SHA-256) verkettet Einträge zeitlich.
• Replikation: Supabase-PITR sichert auch das Audit-Log.

3.3 GoBD-Unveränderbarkeit

• Rechnungs-PDFs: Speicherung in AWS S3 mit Object Lock (WORM-Mode, Compliance), Aufbewahrungsdauer 10 Jahre, parallel versioning enabled.
• Storno-Pattern: Keine echten Löschungen von Belegen, stattdessen Storno-Beleg mit Verweis (gobd_storno_of).
• Hash-Sicherung: PDF-SHA-256-Hash zusätzlich in invoices.pdf_hash für Tamper-Detection.
• Siehe compliance/wave-43-audit-log.md für vollständigen DATEV-Export-Hardening-Audit.

3.4 Code- und Build-Integrität

• Lock-Files: package-lock.json committet, Build schlägt bei Drift fehl.
• Pre-Commit-Hook protect-critical-files: Schützt sicherheitskritische Pfade (src/core/lib/security/**, src/middleware.ts, Migrations) vor unbeabsichtigten Änderungen ohne Owner-Bestätigung.
• Husky-Hooks: Lint, TypeScript-Check, Test-Subset vor jedem Commit.
• CI-Build: Vercel führt reproduzierbare Builds aus mit pinned Node-Version (20.x LTS).

3.5 Lizenz-Compliance

Eingeführt im License-Compliance-Sprint 2026-05-22:

• license-checker-rseidelsohn für Manifest-Scan aller 1.688 Produktions-Pakete.
• CycloneDX SBOM (@cyclonedx/cyclonedx-npm) als maschinenlesbare Bill-of-Materials.
• OSV-Scanner Binary v2.3.8 für Vulnerability-Cross-Reference.
• Hard-Block in CI bei verbotenen Lizenzen (AGPL, SSPL, BUSL, CC-BY-NC).
• Nightly Cron zur Daueraktualisierung.
• Pre-Commit-Hook prüft nur bei Manifest-Änderungen, reduziert Latenz.

3.6 KI-Tool-Aufrufe

• Alle KI-Tool-Aufrufe (NEX, Auto-Match, Vision) werden in audit_log mit Kategorie ai_* protokolliert (Werkzeug, Eingabe-Hash, Zeitstempel, betroffener Tenant, User).
• Vertex-AI-Region erzwungen auf europe-west1 (Belgien) für Sonnet 4.6 (Schrems-II-konform, siehe project_vertex_ai_regions.md).

4. Verfügbarkeit und Belastbarkeit (Art. 32 Abs. 1 lit. b DSGVO)

4.1 Hosting-Topologie

4.2 Backup und Point-in-Time-Recovery

• Datenbank: Supabase PITR aktiviert, Rollback-Window 7 Tage, Daily Full-Backups, transparente WAL-Archivierung.
• Objekt-Storage: S3 Versioning aktiv, 30-Tage-Recover-Window für versehentlich gelöschte Objekte, Object Lock für GoBD-Belege darüber hinaus.
• Konfiguration: Vercel-Environment-Variables versioniert über Vercel-eigene Audit-Logs.

4.3 DDoS- und Missbrauchs-Schutz

• Vercel WAF mit automatischer Layer-7-DDoS-Mitigation.
• Edge-Rate-Limiting via Upstash Redis mit drei Stufen: Per-User, Per-IP, Per-AI-Route.
• ALTCHA (self-hosted) als Bot-Protection auf öffentlichen Booking-Routen — vollständig EU-gehostet, keine US-Routing (Ablösung von Cloudflare Turnstile in Wave 42l, siehe booking_open_followups.md).
• Disposable-E-Mail-Blocklist für Public-Booking (24 generische Domains, siehe Wave Business-Email Finding C2).

4.4 Monitoring und Alarmierung

• Sentry: Error- und Performance-Monitoring, Tenant-isolierte Tags. Wirksamkeit der Tags durch Sentry-Rule-ID 605288 (GoBD E-Rechnung Trigger-Failed) belegt.
• Uptime-Checks: Healthcheck-Endpoints /healthz und /api/healthz, externe Probes.
• Vercel-Analytics: Aggregierte Performance-Metriken, keine personenbezogenen Tracking-Cookies.

4.5 Incident-Response

• Breach-Response-Playbook: .claude/plans/active/2026-04-17_breach-response-playbook.md definiert Eskalationsstufen, 72-h-Meldekette nach Art. 33 DSGVO, Kommunikationsvorlagen, forensische Schritte.
• Sub-Processor-Resilienz: Multi-Provider-Strategie für kritische Wege (AWS SES als Fallback, falls Unipile-Connection des Tenants nicht verfügbar).
• Status-Page (intern): Vorbereitung läuft, Aktivierung mit Real-Tenant-Onboarding.

5. Wiederherstellbarkeit (Art. 32 Abs. 1 lit. c DSGVO)

5.1 Datenbank-Recovery

• Supabase Point-in-Time-Recovery: Rollback auf jeden Zeitpunkt innerhalb der letzten 7 Tage.
• Recovery-Time-Objective (RTO): ≤ 1 Stunde für Voll-Recovery (Test 2026-04 erfolgreich durchgeführt).
• Recovery-Point-Objective (RPO): ≤ 1 Minute (WAL-Archivierung kontinuierlich).
• Cross-Region-Replikation: Aktuell nicht aktiviert; bewusste Entscheidung wegen EU-only-Datenresidenz. Erwogen für Sprint+5+.

5.2 Storage-Recovery

• S3 Versioning: 30-Tage-Recover für versehentlich gelöschte Objekte.
• Object Lock (GoBD-Belege): WORM-Schutz über 10 Jahre.

5.3 Code-Recovery

• Git: Spiegelung auf GitHub (origin) als externe Quelle.
• Vercel: Deploy-History 30 Tage rückrollbar via Vercel Dashboard (Instant Rollback).
• Migrations: SQL-Migrations versioniert in nexdeck-platform/supabase/migrations/; Down-Migrations für kritische Schema-Änderungen bewusst nicht standardmäßig vorgesehen — stattdessen Forward-Fix-Pattern.

5.4 Konfigurations-Recovery

• Vercel Environment Variables: Versioniert, audit-loggt, Export für Disaster-Recovery monatlich gesichert (verschlüsselt, in Owner-Custody).

5.5 Audit-Trail bleibt erhalten

• 10-Jahre-Retention des Audit-Logs darf durch Recovery-Operationen nicht verkürzt werden. PITR-Rollback würde Audit-Einträge im Rollback-Zeitfenster zurücksetzen; in einem solchen Fall greift das Breach-Response-Playbook mit gesonderter Protokollierung (Manueller Forensik-Eintrag).

6. Verfahren zur regelmäßigen Wirksamkeitsprüfung (Art. 32 Abs. 1 lit. d DSGVO)

6.1 Penetration-Tests (vierteljährlich)

Aktueller Sprint 2026-05-28/29, Plan .claude/plans/active/2026-05-28_pentest-tooling-stack.md:

Phase A.5 — Static Analysis (abgeschlossen 2026-05-28):

Zusätzlich: 3 Dockerfile-Hardenings (USER-Anweisung), GCM statt CBC für interne Crypto-Pfade, Supabase PAT + AWS_ADMIN + sb_secret_* + sb_publishable_* rotiert.

Phase A1 — Dynamic Analysis (abgeschlossen 2026-05-29):

6.2 Static-Analysis-Pipeline

• TypeScript-strict auf gesamtem Repo (tsc --noEmit).
• ESLint mit Custom-Rules: nexdeck-calendar/no-mixed-state-axes, no-tenant-id-missing, react-hooks/exhaustive-deps.
• Semgrep: Default-Ruleset, NexDeck-Custom-Rules in Sprint+2 geplant (Tenant-ID-Required, No-Service-Role-Frontend).

6.3 Vulnerability-Scanning

• Trivy: Tägliche Image- und Filesystem-Scans.
• OSV-Scanner: Tägliche Cron-Läufe (siehe Lizenz-Compliance-Sprint).
• npm-audit: Pre-Commit + CI.
• CycloneDX SBOM: Maschinenlesbar erzeugt, archiviert je Release.

6.4 Monitoring-basierte Wirksamkeitsprüfung

• Sentry-Pattern-Analyse: Neue Fehler-Pattern werden in Alert-Rules überführt (Beispiel: category=gobd-einvoice-trigger-failed, Rule-ID 605288).
• Error-Rate-Tracking: Pro Tenant, mit Schwellwert-Alarmierung.

6.5 Manuelles 3-fach-Audit pro Wave

Verbindliche User-Direktive 2026-05-26 (Cozy-Pelican-Plan): Nach jedem Block bzw. nach jeder Wave wird ein 3-fach-Audit durchgeführt mit den Spuren:

1. RLS + RBAC (Tenant-Isolation, Defense-in-Depth)
2. Compliance, Legal, Audit-Logs (DSGVO, GoBD, AGB-Bezug)
3. Bugs, Tests, Gaps (Funktionsdeckung, Regression, Manual-Tests)

Vor jedem Wave-Abschluss wird die Audit-Routine feedback_audit_routine_post_todo.md verbindlich angewendet.

6.6 Lizenz-Compliance-Daueraktivierung

• license-check Daily-Cron schlägt bei neuen verbotenen Lizenzen Alarm.
• AGB §12q dokumentiert Open-Source-Komponenten, /legal/third-party-notices öffentlich abrufbar.

6.7 Nachweise

• Pentest-Plan: .claude/plans/active/2026-05-28_pentest-tooling-stack.md
• License-Compliance-Sprint: license_compliance_sprint_2026_05_22.md
• Wave-43-DATEV-Audit: compliance/wave-43-audit-log.md
• Schema-Drift-Snapshot: scripts/check-schema-drift-pre-gl.ts (Daily-CI)

7. Sicherstellung im Vertragsverhältnis (Art. 32 Abs. 4 DSGVO)

7.1 Sub-Processor-Liste

• Vollständige, jederzeit aktuelle Liste unter https://nexdeck.app/legal/subprocessors (Stand 2026-05-29: 24+ Sub-Processors).
• Vierteljährliche Re-Validierung im Rahmen der TOM-Revision.
• Anzeige- und Widerspruchsrecht des Auftraggebers nach AVV §-Klausel zur Auftragnehmerkette.

7.2 AVV / DPA mit allen Sub-Processors

7.3 EU-only-Processing wo möglich

• Hauptverarbeitung ausschließlich in EU-Regionen (Supabase eu-central-1, Vercel fra1, AWS eu-central-1, Vertex AI europe-west1).
• US-Drittlandtransfers nur dort, wo ein gleichwertig sicheres EU-Pendant fehlt (Sentry, OneSignal, Stripe-Fallback). In diesen Fällen: SCCs in der Fassung 2021/914/EU plus dokumentierte Transfer Impact Assessment (TIA).

7.4 Mitarbeiterverpflichtung und Schulung

• Alle Mitarbeitenden mit Datenzugang unterzeichnen eine Vertraulichkeitsvereinbarung gemäß Art. 28 Abs. 3 lit. b und Art. 29 DSGVO.
• Regelmäßige DSGVO-Sensibilisierungs-Schulungen, Dokumentation intern bei Kre8ive Evolution GmbH i.G.
• Zugriffe auf Produktivdaten ausschließlich nach Need-to-Know-Prinzip, geloggt im Audit-Trail (Tenant-Impersonation-Events).

7.5 Meldepflichten und Eskalation

• 72-h-Meldekette nach Art. 33 DSGVO an Auftraggeber, dokumentiert im Breach-Response-Playbook.
• Bei Betroffenenrisiko: Benachrichtigung der Betroffenen nach Art. 34 DSGVO durch den Verantwortlichen, vorbereitete Templates beim Auftragsverarbeiter vorhanden.

7.6 Weisungsgebundenheit

• NexDeck verarbeitet Auftraggeber-Daten ausschließlich auf dokumentierte Weisung des Verantwortlichen (Vertragstext, Default-Konfiguration der Plattform, dokumentierte Support-Tickets).
• Eigenverarbeitung für aggregierte Statistik und Sicherheitszwecke nur in pseudonymisierter Form.

7.7 Projektgebundener Kundenbereich / Client-Portal (Magic-Link, Endkunden-UGC) — NEU 2026-07-10, PENDING_LAWYER_REVIEW

Maßnahmen für die optionale Funktion, über die Endkunden des Auftraggebers ohne eigenes Nutzerkonto (Magic-Link) Nachrichten und Medien (Dateien/Fotos/Videos) einstellen. Da hier erstmals Fremdinhalte von Dritten verarbeitet werden, gelten ergänzend:

8. Offene Punkte und Carryovers (Transparenz)

Diese Sektion macht offene Punkte transparent. Sie ersetzt keine Wirksamkeitsbestätigung, sondern dient der Nachvollziehbarkeit. Bewertung der Risiken und geplanter Schließungstermine:

8.1 CRITICAL — Pre-Go-Live-Blocker

• FullCalendar Premium Commercial License: Aktueller Code in zwei Komponenten (TeamScheduler.tsx, ResourceTimelineBoard.tsx) ist ohne kommerzielle Lizenz nicht für SaaS einsetzbar (CC-BY-NC-ND hartcodiert bzw. GPL-Fallback). Käufung durch Owner unmittelbar bevorstehend (User-Statement 2026-05-22). Aktion: Nach Kauf NEXT_PUBLIC_FULLCALENDAR_LICENSE_KEY in Vercel Production setzen und Hardcode entfernen. Bis dahin: Kein Real-Tenant-Onboarding-Live-Schalt.
• GmbH-HRB-Eintragung: Aktuell Kre8ive Evolution GmbH i.G. Mit Eintragung im Handelsregister werden TOM, AVV, AGB, Datenschutzerklärung, Impressum, Stripe-Tax-ID und PDF-Templates aktualisiert. Aktion: Trigger ist HRB-Bestätigung; Update-Checkliste siehe pending_gmbh_legal_form_update.md.

8.2 HIGH (Sprint+1 bis Sprint+5)

• CSP script-src 'unsafe-inline' Finding (ZAP Phase A1): Nonce-Migration deferred wegen Vercel-Edge-Inkompatibilität bei dynamischen Routes. Plan B: Subresource Integrity (SRI) für statische Scripts in Sprint+5.
• 21 HIGH-Severity CVEs in dev-only Packages: (next, request deprecated, libxmljs, capacitor) — Migration vs. Accept-Risk-Entscheidung in Sprint+1.
• xlsx-Prototype-Pollution-CVE: Evaluation exceljs-Migration in Sprint+1, Doku siehe compliance/xlsx-vuln-evaluation-2026-05-28.md.

8.3 LOW (Sprint+5 und später)

• Custom Semgrep-Rules für NexDeck (tenant-id-required, no-service-role-frontend) — Sprint+2.
• Custom Nuclei-Templates für Stripe-Webhook-Forgery, JWT-Tenant-Bypass — Sprint+3.
• CI-Integration TruffleHog + Trivy in GitHub-Actions — Sprint+4.
• Cross-Region-DR für Postgres (aktuell bewusst deaktiviert wegen EU-only) — Re-Evaluation Sprint+5+.

8.4 Klar abgegrenzte Nicht-Zertifizierungen

NexDeck Platform ist Stand 2026-05-29 nicht zertifiziert nach:

• ISO/IEC 27001
• ISO/IEC 27018
• SOC 2 (Type I oder II)
• TISAX
• BSI C5 (Cloud Computing Compliance Criteria Catalogue)

Wirksamkeit wird stattdessen über die in Sektion 6 beschriebenen Verfahren nachgewiesen. Eine Zertifizierungs-Roadmap kann auf Anfrage von Großkunden erstellt werden.

9. Aufbewahrung und Versionierung

9.1 TOM-Aufbewahrung

• Intern: 10 Jahre (gleichlautend mit GoBD-Belegen).
• Versionskontrolle: Diese Datei (compliance/TOM-2026-Q2.md) ist im Repository versioniert; jede Änderung erzeugt einen Git-Commit, der den Stand revisionssicher festhält.

9.2 Auslieferung an Auftraggeber

• TOM ist als Anhang zum AVV Bestandteil des Vertrags.
• Auslieferung als PDF bei jedem neuen Real-Tenant-Onboarding.
• Bei jeder Versionserhöhung erfolgt Benachrichtigung der bestehenden Auftraggeber per E-Mail; das aktuelle Dokument liegt unter dem Tenant-Dashboard zum Download bereit.

9.3 Öffentliche Privacy-Policy

• /privacy Route enthält eine endkunden-verständliche Mini-TOM-Übersicht; die vollständige TOM bleibt vertraulich und wird ausschließlich im B2B-Kontext geteilt.

9.4 Aufsichtsbehörden

• Auf schriftliche Anfrage einer zuständigen Aufsichtsbehörde wird die jeweils aktuelle Vollversion innerhalb von 5 Werktagen bereitgestellt.

9.5 Revisionsrhythmus

• Planmäßig: quartalsweise (nächste Revision 2026-Q3, spätestens 2026-08-29).
• Ad-hoc: bei jeder wesentlichen Änderung an Verarbeitungs-Architektur, Sub-Processor-Wechsel, bei Sicherheitsvorfall oder bei Änderung der Rechtsform (HRB-Eintragung).

10. Versions-Log

11. Anhang: Referenzen und Normenbezug

11.1 Rechtsgrundlagen und Standards

• DSGVO Art. 32: https://gdpr-info.eu/art-32-gdpr/
• DSGVO Art. 28 (Auftragsverarbeitung): https://gdpr-info.eu/art-28-gdpr/
• DSGVO Art. 33 / 34 (Meldepflichten): https://gdpr-info.eu/art-33-gdpr/
• BSI IT-Grundschutz: https://www.bsi.bund.de/grundschutz
• EDPB Guidelines 04/2020 (TOMs nach Art. 32): https://edpb.europa.eu/
• ENISA Cybersecurity Framework / NIS2 für SaaS-Anbieter: https://www.enisa.europa.eu/
• EU-Standardvertragsklauseln (SCC) 2021/914: https://eur-lex.europa.eu/eli/dec_impl/2021/914
• Schrems-II-Urteil (EuGH C-311/18): https://curia.europa.eu/

11.2 Interne Bezugsdokumente

11.3 Versionsstände produktiver Komponenten (Stand 2026-05-29)

12. NIS2-Art.-21-Maßnahmen-Mapping (Cross-Reference)

NexDeck ist nach §28 BSIG aktuell KEINE direkt regulierte Einrichtung (siehe compliance/NIS2-SELBSTKLASSIFIZIERUNG-2026.md Stand 2026-06-01). Die Maßnahmen nach Art. 21 NIS2-Richtlinie werden jedoch substanziell als Plattform-Sicherheits-Baseline umgesetzt — Beweggründe sind die §43 GmbHG- Sorgfaltspflicht und die Vorbereitung auf Kunden, die uns über die Lieferketten-Klausel §30 Abs. 2 Nr. 4 BSIG vertraglich verpflichten können.

Diese Mapping-Tabelle ist KEINE Konformitäts-Bescheinigung im Sinne des Art. 24 NIS2-RL. Sie dient als interne Übersicht und als Basis für Vendor-Assessments (CAIQ-Lite, SIG-Lite).

12.1 Substanz-Score

NexDeck setzt nach interner Selbsteinschätzung ~70-75% der Art.-21- Maßnahmen-Kategorien substantiell um. Die verbleibenden Lücken (g) Awareness-Training und (c) BCM-Formalisierung werden in Block 5 (Sprint 2026-06) geschlossen.

Bezugsrahmen-Disclaimer (Pflicht): Substanz-Score 70-75% bezieht sich auf NIS2 Art. 21 Maßnahmen-Kategorien nach §30 BSIG (10 Kategorien a-j). NICHT vergleichbar mit ISO 27001 Annex A (93 Controls, siehe ISMS-POLICY.md §12.2) oder CAIQ-Lite Fragebogen (46 Items, siehe CAIQ-LITE-2026.md). Stand: 2026-06-15.

12.2 Wording-Disclaimer (Pflicht)

Bei externer Nutzung dieses Mappings (Vendor-Assessments, Kunden-Anfragen, Trust-Center): Pflicht-Disclaimer aus docs/internal/nis2-wording-guide.md §4 (Standard- oder Kurz-Disclaimer) MUSS beigefügt werden.

12.3 Quartalsweise Re-Bewertung

Diese Mapping-Tabelle wird zusammen mit dem TOM quartalsweise über das /tom-review-Skill auf Änderungen geprüft. Status-Spalten-Änderungen LIVE/TEILWEISE/PLANNED bumpen LEGAL_VERSIONS.tom automatisch.

12.X Support-AI-Layer (Wave-1f-C, 2026-06-04)

Sub-Sektion zu §12 NIS2-Mapping — beschreibt zusätzliche technische und organisatorische Maßnahmen rund um den Support-AI-Layer (siehe .claude/plans/active/2026-06-02_support-ai-masterplan*.md v2.4 + Wave-0..1e LIVE auf main).

Querverweis NIS2-Block-3 Breach-Response-Playbook: Im Falle eines Sicherheitsvorfalls im Support-AI-Layer (z.B. Cross-Tenant-Leak, Hash-Chain-Inkonsistenz, Sub-Processor-Ausfall > 4h) greift der bestehende NIS2-Block-3-Breach-Workflow. Spezifische Support-AI-Trigger:

• Sub-Processor-Ausfall (Vertex + Bedrock gleichzeitig nicht erreichbar): Auto-Fallback auf Human-Only-Mode, Sentry-Severity FATAL.
• Hash-Chain-Bruch (verify_action_log_chain Nightly schlägt fehl): Auto-Sperre der Tenant-Cases bis Compliance-Officer Co-Sign — Pre-HRB-Phase: Solo-Founder-Rebuild mit 60d-Review-Frist (siehe Wave-1f-A RebuildReviewQueue).
• Cost-Cap-Bypass-Verdacht (>3 Hard-Block-Bypasses/Tenant/Monat): Tenant-Audit + Plattform-Pause-Action.

12.Y Selbstbewertung Support-AI gegen NIS2 Art. 21

Substanz-Score Support-AI-Layer-spezifisch: 85-90% der NIS2-Art-21-Kategorien durch oben gelistete Maßnahmen abgedeckt. Gilt zusätzlich zum allgemeinen NexDeck-Plattform-Score (70-75%, siehe §12.1). Nicht abgedeckt:

• (d) Lieferketten-Sicherheit Sub-Sub-Processor (Anthropic→Vertex→GCP-Region-Provider): Beruhen wir auf Vertex-/Bedrock-DPA, keine eigene Audit-Pflicht
• (h) Verschlüsselungs-Schlüssel-Management Customer-Managed-Keys (CMK): pending Customer-Demand
• (j) Plattform-Authentifizierung mit MFA-Pflicht für Tenant-Admins: pending Wave-1f-E + Tenant-Admin-Onboarding-Sweep

Re-Bewertung quartalsweise zusammen mit §12.1.

Ende des Dokuments.

Dokument-Klassifikation: Vertraulich. Weitergabe ausschließlich im Rahmen des AVV oder auf Anforderung einer zuständigen Aufsichtsbehörde.