Technische und Organisatorische Maßnahmen (TOM)

Dies ist die öffentliche Fassung. Sie enthält die Maßnahmen vollständig; nicht enthalten sind die interne Änderungshistorie des Dokuments und die Ablageorte der Nachweise. Beides legen wir Auftraggebern und der Aufsichtsbehörde auf Anfrage vor.

NexDeck Platform — Anhang zur Auftragsverarbeitung nach Art. 28 DSGVO

Cover

Hinweis zur Rechtsform: Die Kre8ive Evolution UG (haftungsbeschränkt) ist am 12.08.2026 in das Handelsregister des Amtsgerichts Duisburg unter HRB 40868 eingetragen worden. Die Vorgesellschaft ist damit beendet; der Gründungszusatz im Firmennamen ist entfallen. Sitz ist Kastellstr. 34, 46147 Oberhausen; gesetzlicher Vertreter ist der Geschäftsführer Stephan Grundmeyer. Die Rechtsform war zu keinem Zeitpunkt eine GmbH — die frühere Fassung dieses Hinweises nannte sie irrtümlich so.

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 (nur in der internen Fassung)
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:

Zu den Nachrichteninhalten im Team-Postfach: Die Anwendung speichert sie auf allen ihren Wegen nur verschlüsselt — beim automatischen Abgleich, beim von Hand angestoßenen Abruf, beim Senden, beim Verfassen neuer E-Mails, bei automatisierten Nachrichten, Antworten und Entwürfen. Fehlt der Schlüssel, wird weder abgerufen noch gesendet noch gespeichert, und der Betrieb wird alarmiert; eine unverschlüsselte Ablage als Ausweichweg gibt es nicht. Ältere, noch unverschlüsselt gespeicherte Inhalte verschlüsselt ein nächtlicher Lauf schrittweise nach.

Grenzen dieser Maßnahme: Die Verschlüsselung erfolgt in der Anwendung; die Datenbank selbst weist unverschlüsselte Einträge nicht zurück. Im Kundenverlauf wird zu jeder Nachricht eine kurze Textvorschau gespeichert, die nur der Verschlüsselung der Datenbank (§ 1.1) unterliegt. Über verschlüsselte Nachrichteninhalte ist keine Volltextsuche möglich.

Key-Hierarchie: Ein 32-Byte-Masterschlüssel liegt in den Umgebungsvariablen der Laufzeitumgebung (Vercel), getrennt nach Production / Staging / Development. Der Key wird at-Rest verschlüsselt durch Vercel verwaltet und niemals geloggt. Hard-Fail beim Start, falls der Masterschlüssel fehlt oder nicht 32 Bytes lang ist.

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. werden E-Mail-Domains generischer Provider in Benachrichtigungen zur Kontakt-E-Mail-Adresse nicht durchgereicht).

1.5 Hash-Algorithmen

1.6 Key-Management

• Schlüssel und Geheimnisse der Laufzeit liegen in Vercel Environment Variables, dort at-Rest verschlüsselt.

• Schlüssel der Entwicklungsumgebung liegen seit dem 11.09.2026 nicht mehr im Klartext in Arbeitskopien, sondern in einem 1Password-Tresor; die Konfigurationsdateien enthalten nur noch Verweise (op://…). Anlass war ein Abgleich, bei dem sich zwei Dateien bei zwei Geheimnissen widersprachen — darunter zwei verschiedene Stripe-Live-Schlüssel.

• Trennung nach Stage: Production, Preview, Development je eigener Schlüssel.

• Keine Schlüssel im Code-Repository. Durchgesetzt wird das durch zwei Riegel im Pre-Commit-Hook: einen Pfad-Riegel, der jede Datei mit .env im Namen ablehnt, und eine Mustererkennung über den Dateiinhalt.

• Empfohlene Rotation: Masterschlüssel der Anwendungsverschlüsselung alle 12 Monate, Service-Role-Keys der Datenbank ad-hoc bei Verdacht. Letzte Rotation: 2026-05-28 (Sicherheitsüberprüfung; vollständige Rotation des persönlichen Zugriffstokens für die Datenbank-Plattform, der administrativen AWS-Zugangsdaten sowie der geheimen und der öffentlichen API-Schlüssel der Datenbank).

• Service-Role-Keys ausschließlich serverseitig (Server Actions, Route Handlers); Frontend nutzt anon-Key (publishable). Geprüft durch eine eigene Semgrep-Regel der Schwere ERROR, die den Dienstschlüssel in Dateien außerhalb der serverseitigen Pfade meldet (Rhythmus siehe § 6.3).

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 den Abgleich der Mandantenkennung jeder Zeile mit der Mandantenkennung aus dem Anmelde-Token bzw. aus der Sitzungseinstellung.
• Verifikation: Eine Abfrage des Datenbankkatalogs nach Tabellen ohne RLS sowie ein Abgleich des Datenbankschemas gegen den im Code erwarteten Stand. Beide laufen als Zusicherung innerhalb der Testsuite, nicht als durchgehende Prüfung bei jeder Änderung.
• Defense-in-Depth: Wo eine Server Action mit dem Dienstschlüssel arbeitet, filtert sie zusätzlich ausdrücklich auf den aktuellen Mandanten; mit sitzungsgebundenem Zugriff trägt die RLS (siehe § 8.2). Ein Prüf-Hook im Entwicklungsablauf warnt, wenn eine Datei Datenbankzugriffe ohne jeden Mandantenbezug enthält; er blockiert nicht.
• PostgREST-Grants: Neue Tabellen erhalten ausdrückliche Zugriffsrechte (GRANT) für die Rolle angemeldeter Nutzer (Pflicht ab Supabase Data API 30.10.2026). Ein Prüf-Hook im Entwicklungsablauf warnt, wenn eine Migration eine Tabelle anlegt, ohne Zugriffsrechte zu vergeben; er blockiert die Migration nicht.

2.2 Role-Based Access Control (RBAC)

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

• Plattform-Ebene: Plattform-Kennzeichen „Super-Admin“ (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 ein Branchen-Preset je Mandant (handwerk, agentur, dienstleister) und mandantenbezogene Anpassungen einzelner Rechte — keine branchen-spezifischen Rollen, um RBAC-Modell flach und prüfbar zu halten.
• Sub-Rollen-Visibility: Sidebar- und Feature-Gating über eine serverseitige Rechteprüfung in Server Actions; zusätzliche Sperren in der Oberfläche der Verwaltungsbereiche.

2.3 Multi-Factor-Authentication (MFA)

• Verfahren: TOTP (RFC 6238) via Supabase Auth MFA.
• Aktivierung pro Tenant: Mandanten-Einstellung „MFA für Administratoren verpflichtend“ — Admins und Owner müssen MFA aktivieren, sonst kein Zugang zu den Verwaltungsbereichen.
• Vorbereitet: Globale MFA-Enforcement-Option (plattformweiter Schalter, mit dem Onboarding der ersten Produktivmandanten aktivierbar).
• Recovery: Backup-Codes (10 Stück, einmalig generiert, gehashed gespeichert).

2.4 Audit-Log

2.5 Geheimnis-Management in CI/CD

Pre-Commit (lokal, greift vor jedem Commit):

• Pfad-Riegel: Jede zum Commit vorgemerkte Datei, deren Name .env enthält, wird abgelehnt — ohne Muster, ohne Ausnahme außer .env.example. Eingeführt nach dem Vorfall vom 04.08.2026 (siehe unten).
• Mustererkennung über den Dateiinhalt, für strukturierte Geheimnisse (JWT, AWS-Access-Keys, Stripe-Keys, private Schlüssel).

🔴 Wirksamkeit dieser Mustererkennung, gemessen am 15.09.2026 — und das Ergebnis war: sie hat nie gegriffen. Der Riegel war an zwei voneinander unabhängigen Stellen wirkungslos, jede davon hätte allein genügt:

1. Der Hook suchte in der Antwort des Prüfprogramms nach der Sperr-Entscheidung in einer Schreibweise ohne Leerzeichen; ausgegeben wird sie mit einem Leerzeichen hinter dem Doppelpunkt. Die Prüfung traf also nie zu.
2. Die Schleife über die vorgemerkten Dateien lief in einer Subshell. Der Abbruch darin beendete nur diese Subshell; maßgeblich blieb das Ergebnis der zuletzt geprüften Datei. Eine unauffällige Datei am Ende der Liste hat jeden Fund davor überschrieben.

Gemessen mit einer vorgemerkten Datei, die einen Stripe-Live-Schlüssel enthielt: der Hook lief durch. Beides ist am 15.09.2026 behoben und mit Positiv- und Negativkontrolle nachgemessen — auch unter einer einfachen POSIX-Shell und mit Leerzeichen im Dateinamen.

Die Aufnahme dieses Befunds in dieses Dokument ist bewusst: ein TOM, das eine Maßnahme behauptet, die es nicht gibt, ist gegenüber einer Aufsichtsbehörde schlechter als eines, das die Lücke benennt und ihre Schließung nachweist.

CI (GitHub Actions):

• TruffleHog v3 als Workflow. Rhythmus siehe § 6.3 — nicht als Pre-Commit-Hook, anders als frühere Fassungen dieses Dokuments angaben.

Vorfall 04.08.2026: Ein git add -A nahm eine Sicherungsdatei mit der Namensform .env.local.bak-vor-rename-… mit; 201 echte Schlüssel gelangten in das GitHub-Repository. Die Ausschlussliste kannte diese Schreibweise nicht, und die Mustererkennung war aus den oben genannten Gründen wirkungslos. Alle betroffenen Schlüssel wurden rotiert. Der Pfad-Riegel ist die Konsequenz daraus.

Hardcoded-Token-Audit: Bei der Sicherheitsüberprüfung am 28.05.2026 wurden 17 historische Test-Token-Dateien vollständig aus Repository und Git-Historie entfernt.

⬜ Nicht bestätigt: Frühere Fassungen führten GitGuardian als Dauer-Monitor auf dem Repository. Diese Angabe ließ sich bei der Revision Q3 nicht belegen und ist deshalb gestrichen, nicht fortgeschrieben.

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. Termine, Einsatzzuordnungen und Rechnungen).
• Schema-Drift-Abgleich: Ein Abgleich des Datenbankschemas gegen die im Code erwarteten Felder, ausgeführt als Zusicherung innerhalb der Testsuite. Er erfasst lesende Zugriffe; ein fehlendes Schreibziel erkennt er nicht.

3.2 Append-only-Audit-Log

• Löschen und Ändern von Einträgen des Audit-Logs per Trigger blockiert, Verstöße werden ihrerseits geloggt.
• Hashchain (SHA-256) verkettet Einträge zeitlich.
• Sicherung: Die tägliche Datenbanksicherung (§ 4.2) umfasst 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 auf den Ursprungsbeleg.
• Hash-Sicherung: PDF-SHA-256-Hash zusätzlich am Rechnungsdatensatz gespeichert, für Tamper-Detection.
• Die Härtung des DATEV-Exports ist in einem internen Prüfbericht dokumentiert.

3.4 Code- und Build-Integrität

• Lock-Files: package-lock.json committet, Build schlägt bei Drift fehl.
• Pre-Commit-Hook (Husky), vor jedem Commit: Pfad-Riegel gegen .env-Dateien und Mustererkennung auf Geheimnisse im Dateiinhalt; TypeScript-Typprüfung; Formprüfung der Server-Funktionen (Dateien mit 'use server' dürfen nur asynchrone Funktionen exportieren); Testpflicht für neu hinzukommende schreibende Server-Actions.
• CI-Build: Der Bau laeuft auf einem festgelegten Node-Stand; die engines-Angabe des Projekts verlangt 22.x oder 24.x.

3.5 Lizenz-Compliance

Eingeführt am 22.05.2026:

• 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.
• Prüfung auf verbotene Lizenzen (AGPL, SSPL, BUSL, CC-BY-NC) als Workflow vorhanden; derzeit abgeschaltet (kein zeitgesteuerter Lauf, kein Pre-Commit-Hook) — Rhythmus siehe § 6.3.

3.6 KI-Tool-Aufrufe

• Alle KI-Tool-Aufrufe (NEX, Auto-Match, Vision) werden im Audit-Log mit einer eigenen KI-Kategorie protokolliert (Werkzeug, Eingabe-Hash, Zeitstempel, betroffener Tenant, User).
• Vertex-AI-Region erzwungen auf europe-west1 (Belgien) für Sonnet 4.6 (Schrems-II-konform).

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

4.1 Hosting-Topologie

4.2 Datensicherung

• Datenbank: Supabase erstellt täglich eine vollständige Sicherung der Datenbank in Frankfurt; vorgehalten werden die Sicherungen der letzten sieben Tage. Eine Wiederherstellung auf einen beliebigen Zeitpunkt (Point-in-Time-Recovery) ist nicht gebucht.
• 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 (löste Cloudflare Turnstile ab).
• Disposable-E-Mail-Blocklist für Public-Booking (24 generische Domains).

4.4 Monitoring und Alarmierung

• Sentry: Error- und Performance-Monitoring, Tenant-isolierte Tags. Wirksamkeit der Tags durch eine eingerichtete Alarmregel (fehlgeschlagene Auslösung bei E-Rechnungen) 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: Ein intern dokumentiertes Breach-Response-Playbook 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

• Wiederherstellung aus der Tagessicherung: Die Datenbank kann auf den Stand einer der täglichen Sicherungen der letzten sieben Tage zurückgesetzt werden.
• Möglicher Datenverlust (RPO): bis zu 24 Stunden — alles, was nach der letzten Tagessicherung geschrieben wurde.
• Wiederherstellungszeit (RTO): Zielwert 4 Stunden. Der Wert ist nicht gemessen; ein protokollierter Wiederherstellungstest liegt noch nicht vor.
• Cross-Region-Replikation: Aktuell nicht aktiviert; bewusste Entscheidung wegen EU-only-Datenresidenz. Eine spätere Aktivierung wird erwogen.

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 im Code-Repository; 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. Eine Wiederherstellung aus der Tagessicherung würde Audit-Einträge, die nach dieser Sicherung entstanden sind, 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)

Letzte Prüfrunde am 28./29.05.2026:

Statische Analyse (abgeschlossen 2026-05-28):

Zusätzlich: 3 Dockerfile-Hardenings (USER-Anweisung), GCM statt CBC für interne Crypto-Pfade; persönliches Zugriffstoken der Datenbank-Plattform, administrative AWS-Zugangsdaten sowie geheime und öffentliche API-Schlüssel der Datenbank rotiert.

Dynamische Analyse (abgeschlossen 2026-05-29):

6.2 Static-Analysis-Pipeline

• TypeScript-strict auf gesamtem Repo (tsc --noEmit).

• ESLint mit eigenen Regeln: u. a. gegen fehlende Mandantenfilter und gegen vermischte Zustandsangaben im Kalender, dazu die Abhängigkeitsprüfung für React-Hooks.

• Semgrep: 12 NexDeck-eigene Regeln (Tenant-Isolation, kein Service-Role-Client im Frontend, Dateiform für Server-Funktionen, Audit-Pflicht bei Finanz-Mutationen, Positiv-Allowlist in Aufräumroutinen). Der Semgrep-Prüflauf bricht bei jedem Fund der Schwere ERROR ab; er läuft je TOM-Revision und lokal, nicht automatisch (siehe § 6.3).

  🔴 Wirksamkeit, gemessen am 15.09.2026 — und das Gate war keines. Der Lauf meldete 8527 Funde und konnte deshalb strukturell nie grün werden. Nachgemessen ergab sich:

  • 2 von 12 Regeln ließen sich gar nicht laden. Der Analysator meldet das auf der Fehlerausgabe und setzt den Lauf fort — ein Durchlauf ohne diese Regeln sieht aus wie ein erfolgreicher. Betroffen war unter anderem die Taint-Regel, die den Weg eines Service-Role-Clients bis zum Datenbankzugriff verfolgen soll.
  • 2272 Funde der Schwere ERROR waren sämtlich unzutreffend. Ein Muster für einen synchronen Export traf auch auf asynchrone Exporte zu, ein Muster für Wert-Exporte auch auf Standard-Exporte. Nach der Berichtigung: 0.
  • Die Tenant-Regel nahm ihre eigene Ausnahme nie in Anspruch, weil die Ausnahme einen längeren Ausdruck beschrieb als die Regel selbst. 6023 → 2108.

  Das Gate läuft seither bei sauberem Stand mit Rückgabewert 0 durch und schlägt bei einer eingepflanzten Verletzung fehl; beides ist gemessen. Die verbleibenden Funde der Schwere WARNING sind nicht abgearbeitet — sie sind kein Gate, sondern ein Arbeitsvorrat, und § 8 führt sie als solchen.

6.3 Vulnerability-Scanning

Verbindlich ist ab dieser Fassung der tatsächliche Rhythmus:

Damit die vierteljährliche Auslösung nicht wieder unbemerkt ausfällt, erinnert seit dem 15.09.2026 ein automatischer Wecker an die fällige Revision: 14 Tage vorher, am Stichtag und danach wöchentlich. Die Frist liest er aus diesem Dokument, nicht aus einer zweiten Quelle. Anlass war, dass die Revision Q3 17 Tage überfällig war und dies nur zufällig auffiel.

6.4 Monitoring-basierte Wirksamkeitsprüfung

• Sentry-Pattern-Analyse: Neue Fehler-Pattern werden in Alert-Rules überführt (Beispiel: Alarmregel für fehlgeschlagene Auslösungen bei E-Rechnungen).
• Error-Rate-Tracking: Pro Tenant, mit Schwellwert-Alarmierung.

6.5 Manuelles 3-fach-Audit je Entwicklungsabschnitt

Seit dem 26.05.2026 verbindlich festgelegt: Nach jedem abgeschlossenen Entwicklungsabschnitt 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 dem Abschluss eines Entwicklungsabschnitts wird dazu verbindlich eine festgelegte, intern dokumentierte Audit-Routine 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

Die Nachweise zu den vorstehend genannten Prüfungen (Prüfberichte, Protokolle, Planungsunterlagen) werden intern geführt und Auftraggebern sowie der Aufsichtsbehörde auf Anfrage vorgelegt.

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

7.1 Sub-Processor-Liste

• Vollständige, jederzeit aktuelle Liste unter https://www.nexdeck.app/subprocessors (Stand 2026-09-16: 27 Sub-Processors).
• Vierteljährliche Re-Validierung im Rahmen der TOM-Revision.
• Anzeige- und Widerspruchsrecht des Auftraggebers nach Art. 28 Abs. 2 Satz 2 DSGVO und der 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, Deepgram). In diesen Fällen: SCCs in der Fassung 2021/914/EU plus dokumentierte Transfer Impact Assessment (TIA).
• 🔴 Zur Reichweite des EU-Endpunkts bei Deepgram (klargestellt 03.09.2026): Der geteilte EU-Endpunkt verarbeitet Audio und Transkripte in AWS Frankfurt und speichert sie nicht dauerhaft. Er ist jedoch keine vollständige EWR-Residenz — Konto-, Projekt-, API-Schlüssel-, Nutzungs-, Abrechnungs- und Telemetriedaten können globale Verwaltungswege nehmen, und autorisiertes Personal außerhalb des EWR kann für Support und Administration auf Systeme zugreifen (schriftliche Auskunft des Anbieters, intern archiviert). Die vollständige Residenz-Zusage des Anbieter-DPA (§ 9.2) gilt nur für dessen Einzelmandanten-Produkt, das NexDeck nicht einsetzt. Tragend sind daher die SCC.

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 UG (haftungsbeschränkt)
• 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

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:

7.8 KI-spezifische technische und organisatorische Maßnahmen (Betrieb von KI-Funktionen) — NEU 2026-07-22

Für KI-gestützte Funktionen (Chat-Assistent, Beleg-/Dokumentenerfassung, RAG-Wissenssuche, Sprachdiktat, proaktive Vorschläge, Lead-Bewertung) gelten ergänzend die folgenden Maßnahmen. Grundlage: Art. 32 i.V.m. Art. 28 DSGVO, DSK-Orientierungshilfe „Künstliche Intelligenz und Datenschutz" (06.05.2024) sowie DSK-Orientierungshilfe zu TOM bei Entwicklung/Betrieb von KI-Systemen (Juni 2025). Cloud-LLM-Inferenz = Auftragsverarbeitung (NexDeck = Auftragsverarbeiter, LLM-Anbieter = Sub-Auftragsverarbeiter, Art. 28 Abs. 4).

Vorbehalt (Datenschutzbeauftragter/Anwalt): Der konkrete Art.-22-Trigger je Funktion, die DSFA-Pflicht je Verarbeitung (DSK-OH KI Rn. 39 „vielfach erforderlich"), die hinreichende Anonymisierungswirkung der Pseudonymisierung im Einzelfall (Rn. 49; EDPB Opinion 28/2024) sowie die Rollenabgrenzung Auftragsverarbeiter vs. gemeinsame Verantwortlichkeit (Art. 26; Rn. 32-35) bleiben der einzelfallbezogenen Bewertung vorbehalten.

7.9 Vektordatenbank-/RAG-spezifische Maßnahmen (Company-Brain) — NEU 2026-07-23

Für die KI-Dokumentenanalyse über eine Vektor-Wissensdatenbank (RAG, „Company-Brain") gelten ergänzend zu §7.8 die folgenden Maßnahmen. Grundlage: Art. 32 i.V.m. Art. 28 DSGVO, DSK-Orientierungshilfe „Künstliche Intelligenz und RAG" v1.0 (Okt. 2025) sowie DSK-Orientierungshilfe zu TOM bei Entwicklung/Betrieb von KI-Systemen (Juni 2025). Der allgemeine KI-Teil (§7.8) bleibt unverändert; §7.9 ergänzt die Vektor-/RAG-Spezifika.

7.10 Abruf öffentlicher Wetterdaten für das Bautagebuch — NEU 2026-09-01

Ein Bautagebuch-Eintrag kann seit dem 01.09.2026 die gemessenen Wetterwerte des Tages tragen (Temperatur morgens/mittags, Windspitze, Niederschlagssumme). Quelle sind die offenen Beobachtungsdaten des Deutschen Wetterdienstes, bezogen über den offenen Dienst Bright Sky. Es entsteht kein Auftragsverarbeitungsverhältnis — die Maßnahmen unten sichern, dass das auch so bleibt.

Einordnung: kein Subprozessor (Einzelheiten intern dokumentiert), Verarbeitung im VVT-Eintrag V-24 mitverzeichnet, Lizenz- und Attributionspflicht in den Open-Source-Hinweisen. Keine erneute Zustimmung des Auftraggebers erforderlich: es kommt kein Auftragsverarbeiter hinzu, es ändert sich keine Datenkategorie beim Mandanten und keine seiner Pflichten.

7.11 Personal- und Lohndaten — NEU 2026-09-18

Beschäftigtendaten liegen in NexDeck in mehreren Stufen: Stammdaten für die Einsatzplanung, Lohnmerkmale für die Lohnvorbereitung, Merkmale besonderer Kategorien (Art. 9 DSGVO) und Abwesenheiten. Jede Stufe hat ihre eigene Schranke, und die Schranken liegen in der Datenbank, nicht nur in der Anwendung — der Dienstschlüssel der Anwendung umgeht Row-Level Security, eine Regel allein in einer Server-Action gälte für einen zweiten Schreiber nicht. Verzeichnet in VVT V-28 und V-31.

Herkunft des Befunds: Die Spaltensperre für die Abwesenheitsart bestand seit Mai 2026 und wurde am 03.09.2026 versehentlich aufgehoben, als eine Migration den Spalten-Grant für einen fehlenden Tabellen-Grant hielt. Zwischen dem 03.09. und dem 18.09.2026 hätten angemeldete Mitglieder eines Mandanten Art und Notiz der Abwesenheiten ihrer Kolleg:innen über die Programmierschnittstelle lesen können; gemessen am 18.09.2026 stand in der gesamten Datenbank keine Abwesenheit mit Art „Krankheit" oder „Elternzeit". Am 18.09.2026 wiederhergestellt.

Vorbehalt (Datenschutzbeauftragter/Anwalt): Die hinreichende Irreversibilität der physischen Embedding-Löschung über alle Ebenen (inkl. Sub-AV/Backup) trägt ein Rest-Risiko der Personenbeziehbarkeit; die Rollenabgrenzung (Auftragsverarbeiter vs. gemeinsame Verantwortlichkeit, Art. 26) bleibt vorbehalten.

8. Offene Punkte und Carryovers (Transparenz)

Diese Sektion macht offene Punkte transparent. Sie ersetzt keine Wirksamkeitsbestaetigung, sondern dient der Nachvollziehbarkeit.

Es bestehen offene Punkte aus Sicherheits- und Lizenzpruefungen. Sie werden intern nach Schwere gefuehrt, mit Behebungsweg und Termin versehen und in der vierteljaehrlichen Revision dieses Dokuments fortgeschrieben. Die Einzelheiten zu einem einzelnen Befund — Kennung, betroffene Fassung, Behebungsstand — legen wir Auftraggebern auf Anfrage und der Aufsichtsbehoerde vor; oeffentlich benennen wir sie nicht, solange der Befund offen ist, weil die Kennung zusammen mit der eingesetzten Fassung eine Anleitung zum Angriff waere.

8.4 Klar abgegrenzte Nicht-Zertifizierungen

NexDeck Platform ist Stand 2026-09-16 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: Dieses Dokument ist im Code-Repository versioniert; jede Änderung erzeugt einen Git-Commit, der den Stand festhält. Der Dateiname trägt aus Gründen der Verweis-Stabilität weiterhin das Quartal der Erstanlage — maßgeblich ist die Versions- und Standangabe auf dem Deckblatt. Diese Stelle nennt die Fassung bewusst NICHT noch einmal: eine zweite Angabe derselben Sache veraltet, sobald die erste sich ändert — genau das ist beim Sprung auf v2.1 passiert, und die öffentliche Seite trug dadurch kurzzeitig zwei verschiedene Fassungsnummern.

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; diese Seite zeigt die öffentliche Fassung der TOM; die vollständige interne Fassung geht an Auftraggeber im B2B-Kontext.

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-Q4, spätestens 2026-12-16).
• 🔴 Die Revision Q3 war 17 Tage überfällig und ist nur zufällig aufgefallen. § 9.5 nannte den 29.08.2026; niemand und nichts war an dieses Datum gebunden. Seit dem 15.09.2026 erinnert ein automatischer Wecker daran (§ 6.3); die Frist liest er aus diesem Dokument, es gibt also keine zweite Quelle, die abweichen könnte.
• Ad-hoc: bei jeder wesentlichen Änderung an Verarbeitungs-Architektur, Sub-Processor-Wechsel, bei Sicherheitsvorfall oder bei Änderung der Rechtsform. Die HRB-Eintragung am 12.08.2026 war ein solcher Anlass; sie ist mit v1.6 eingearbeitet.

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

Zu den vorstehenden Maßnahmen bestehen interne Bezugsdokumente (Vorlagen, Playbooks, Prüfprotokolle). Sie werden Auftraggebern und der Aufsichtsbehörde auf Anfrage vorgelegt. Öffentlich abrufbar sind die Datenschutzerklärung (/privacy), die Liste der Unterauftragnehmer (/subprocessors) und die Open-Source-Hinweise (/legal/third-party-notices).

11.3 Versionsstände produktiver Komponenten (Stand 2026-09-16)

Die folgenden Werte sind am 16.09.2026 einzeln gemessen worden; die Spalte „woran gemessen" nennt je Zeile die Quelle.

Laufende Prüfwerkzeuge (Stand 24.09.2026): Trivy (Abhängigkeits-Scan) und TruffleHog (Geheimnis-Scan über die Historie) laufen als eigene, manuell ausgelöste Workflows. npm audit läuft bei jeder Auslieferung und zusätzlich lokal (Rhythmus siehe § 6.3). Der OSV-Scanner liegt im Lizenz-Workflow, der derzeit abgeschaltet ist. Der letzte dynamische Test mit OWASP ZAP fand in der Prüfrunde Ende Mai 2026 statt.

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

NexDeck ist nach §28 BSIG aktuell KEINE direkt regulierte Einrichtung (interne NIS2-Selbstklassifizierung, 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).

🔴 (e) und (f) waren bis 2026-Q2 als umgesetzt geführt und stehen ab dieser Fassung auf teilweise. Grund ist keine Verschlechterung der Lage, sondern eine Messung: (e) stützte sich auf die Sicherheits-Workflows, und diese Workflows liefen seit dem 13.06.2026 nicht (§ 6.3). (f) stützte sich auf eine Wirksamkeitsprüfung, deren Rhythmus nicht eingehalten wurde (§ 9.5). Beide Zeilen tragen jetzt das, was tatsächlich läuft.

12.1 Substanz-Score

NexDeck setzt nach interner Selbsteinschätzung rund 65–70 % der Art.-21- Maßnahmen-Kategorien substanziell um. Die Abwärtskorrektur gegenüber den zuvor genannten 70–75 % folgt aus der Herabstufung von (e) und (f) und ist eine Berichtigung der Messung, nicht der Lage. Offen bleiben (g) Awareness-Schulung, (c) BCM-Formalisierung sowie die Wiederherstellung eines belegbaren Rhythmus für (e) und (f).

Bezugsrahmen-Disclaimer (Pflicht): Substanz-Score 65–70 % 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 interne ISMS-Richtlinie §12.2) oder CAIQ-Lite Fragebogen (46 Items, interner Fragebogen). Stand: 2026-09-16.

12.2 Wording-Disclaimer (Pflicht)

Bei externer Nutzung dieses Mappings (Vendor-Assessments, Kunden-Anfragen, Trust-Center): Pflicht-Disclaimer aus dem internen Formulierungsleitfaden §4 (Standard- oder Kurz-Disclaimer) MUSS beigefügt werden.

12.3 Quartalsweise Re-Bewertung

Diese Mapping-Tabelle wird zusammen mit dem TOM quartalsweise auf Änderungen geprüft. Ändert sich der Status einer Maßnahme, wird die Fassung dieses Dokuments erhöht.

12.X Support-AI-Layer (2026-06-04)

Für den Support-KI-Layer gelten zusätzliche technische und organisatorische Maßnahmen: Verschlüsselung at-rest und in-transit, ein fortlaufend gesicherter Prüfpfad, abgestufte Plattform-Rollen mit protokolliertem Übersteuerungsrecht, ein Vorab-Filter für rechts-, steuer- und gesundheitsbezogene Ausgaben sowie gestufte Bestätigungspflichten vor dem Absenden. Die Zuordnung dieser Maßnahmen zu den einzelnen Bausteinen der Anwendung führen wir intern.

Ende des Dokuments.

Dokument-Klassifikation: Öffentliche Fassung, zur freien Weitergabe bestimmt. Die vollständige interne Fassung ist vertraulich und wird Auftraggebern im Rahmen des AVV sowie auf Anforderung einer zuständigen Aufsichtsbehörde vorgelegt.