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.

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.

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.

Ende des Dokuments.

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