Verfahrensverzeichnis nach Art. 30 DSGVO
Dies ist die öffentliche Fassung. Sie enthält die Verarbeitungstätigkeiten vollständig; nicht enthalten sind die interne Änderungshistorie und die Verweise auf interne Unterlagen. Das vollständige Verzeichnis legen wir der Aufsichtsbehörde nach Art. 30 Abs. 4 DSGVO auf Anfrage vor.
Stand: 2026-09-24 Verantwortlicher: Kre8ive Evolution UG (haftungsbeschränkt), Kastellstr. 34, 46147 Oberhausen, vertreten durch den Geschäftsführer Stephan Grundmeyer (eingetragen im Handelsregister des Amtsgerichts Duisburg unter HRB 40868, Eintragung am 12.08.2026) Kontakt Datenschutz: datenschutz@nexdeck.de Master-Data-Quelle: _master-data.md
Dieses Verzeichnis dokumentiert alle Verarbeitungstätigkeiten nach Art. 30 Abs. 1 DSGVO. Es wird mindestens einmal jährlich überprüft und bei neuen Verarbeitungen unmittelbar aktualisiert.
Einordnung
- NexDeck als Verantwortlicher (V-01 ff.): für das eigene Saas-Produkt + Marketing/Verkauf gegenüber eigenen Kunden (B2B-Tenants).
- NexDeck als Verantwortlicher in eigener Sache: für die eigenen Beschäftigten der Kre8ive Evolution UG (Mandant 6, „NexDeck Zentrale") — Art. 30 Abs. 1, siehe V-31. Dieselbe Verarbeitung ist für die Beschäftigten anderer Mandanten eine Auftragsverarbeitung; der Eintrag hält beide Rollen getrennt.
- NexDeck als Auftragsverarbeiter (AV-xx): für Tenant-Kunden-Daten (Datenhaltung, RLS-isoliert). Hier gilt Art. 28 + AVV (siehe /avv).
Dieses Dokument listet die NexDeck-als-Verantwortlicher-Seite. Die AV-Verarbeitungen sind im AVV geregelt.
V-13 — Telephony-Matching (optional pro Tenant)
| Feld | Wert |
|---|---|
| Nummer | V-13 |
| Bezeichnung | Sipgate-Webhook-Empfang + CRM-Matching von Call-Metadaten |
| Zweck | Zuordnung eingehender/ausgehender Telefonate zu Leads/Kunden/Projekten im CRM. Effizienzsteigerung im Vertrieb + Kundenkontakt-Management. Basis für Timeline-Einträge, Rückruf-Tasks. |
| Rechtsgrundlage | Bestandskunden: Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung). Unbekannte Anrufer: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse, Rückruf-Management) — Interessenabwägung dokumentiert (siehe unten). |
| Betroffene | Telefonpartner des jeweiligen Tenants (Leads, Kunden, Interessenten, gelegentliche Anrufer) |
| Datenkategorien | Rufnummer (eingehend + ausgehend), Zeitstempel (Start, Antwort, Ende), Gesprächsdauer, Richtung (inbound/outbound), Call-ID für Event-Korrelation, verantwortlicher Nutzer (falls ausgehend). KEINE Audio-Inhalte, KEINE Transkripte. |
| Empfänger | sipgate GmbH (Düsseldorf, DE) — nur Webhook-Gegenstelle. Intern: RLS-isoliert pro Tenant, Zugriff nur durch authentifizierte Tenant-User. |
| Drittland-Transfer | Keiner. Sipgate DE-hosted. Keine US-Sub-Prozessoren im Webhook-Pfad. |
| Löschfristen | Matched Calls (Lead/Client/Project): 6 Jahre (HGB § 257). Unmatched Calls: 90 Tage Anonymisierung (SHA-256-Hash), danach 180 Tage Löschung (Art. 5 Abs. 1 lit. e DSGVO). Durchgesetzt via public.anonymize_unidentified_calls() + QStash-Cron telephony/anonymize-unidentified (täglich 03:00 UTC). |
| TOMs | TLS-Transport, RLS-basierte Tenant-Isolation, Audit-Log (crm_calls_audit_log), Webhook-Payload append-only (telephony_webhook_log), SECURITY DEFINER Retention-Function mit service_role-GRANT. Keine Gesprächsaufzeichnung. |
Interessenabwägung (Art. 6 Abs. 1 lit. f) — Unbekannte Anrufer
- Berechtigtes Interesse NexDecks/der Tenants: effizientes Kundenkontakt-Management, Rückrufbereitschaft, keine verlorenen Lead-Chancen
- Interesse der Betroffenen: Informationelle Selbstbestimmung, Datenminimierung
- Abwägung: Rufnummer ist nur als Metadatum gespeichert, keine Inhalts-Daten. Kurze Retention (90/180 Tage). Widerspruchsrecht nach Art. 21 DSGVO gegenüber dem Tenant. Die Verarbeitung entspricht üblichen CRM-Standards und ist für den Geschäftszweck erforderlich.
- Ergebnis: Interessen der Betroffenen überwiegen nicht.
V-14 — Unknown-Caller-Archiv (Retention-Layer zu V-13)
| Feld | Wert |
|---|---|
| Nummer | V-14 |
| Bezeichnung | Temporäre Speicherung unidentifizierter Rufnummern + Anonymisierungs- und Löschpipeline |
| Zweck | Ermöglicht Rückruf-Zuordnung eines unbekannten Anrufers zu einem noch nicht im CRM erfassten Lead innerhalb eines angemessenen Rückruf-Fensters. Verhindert gleichzeitig unbegrenzte Speicherung von Rufnummern ohne Geschäftsbezug. |
| Rechtsgrundlage | Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an Kundenkontakt-Rekonstruktion). Art. 5 Abs. 1 lit. e DSGVO (Speicherbegrenzung) bestimmt die Fristen. |
| Betroffene | Nicht im Tenant-CRM erfasste Anrufer (One-off-Anrufer, versehentliche Anrufe, Spam-Nummern) |
| Datenkategorien | Gleich wie V-13, plus Retention-Status (anonymized_at), Generated Column is_identified. |
| Empfänger | Nur intern (Tenant-Admins via NexDeck-UI). Keine Weitergabe. |
| Drittland-Transfer | Keiner. |
| Löschfristen | 90 Tage: Anonymisierung — Rufnummer wird zu SHA-256-Hash mit Prefix ANON_. 180 Tage: Vollständige Löschung der Zeile. Webhook-Logs: unabhängig nach 180 Tagen gelöscht (Debug-Trail ohne Geschäftswert). |
| TOMs | Cron-basierte automatische Durchsetzung (anonymize_unidentified_calls()). Generated Column is_identified verhindert manuelle Umgehung der Retention. Audit-Trail via activity_log bei jedem Cron-Lauf. Index idx_crm_calls_unidentified_created für effizienten Scan. |
V-15 — E-Mail-Archivierung via BCC (zubuchbare Funktion)
| Feld | Wert |
|---|---|
| Nummer | V-15 |
| Bezeichnung | BCC-basierte Archivierung versendeter Geschäftsmails (Rechnungen, Angebote, Mahnungen) in Tenant-eigenes Postfach |
| Zweck | Erfüllung der gesetzlichen Aufbewahrungspflicht für Geschäftsbriefe und Rechnungen. Archivierungs-Mitteilung an Tenant-eigenes Postfach zur späteren Prüfung, Revision, Steuerberater-Weitergabe. |
| Rechtsgrundlage | Art. 6 Abs. 1 lit. c DSGVO i.V.m. HGB § 257 (Geschäftsbriefe 6 Jahre) und AO § 147 (Rechnungen 10 Jahre). Keine Einwilligung erforderlich — gesetzliche Pflicht. |
| Betroffene | Empfänger der jeweiligen E-Mail (Bestandskunden, Angebots-Empfänger) |
| Datenkategorien | Vollständige Mail (Header + Body + Anhänge inkl. PDF-Rechnung). Message-ID zur Korrelation mit document_email_log. |
| Empfänger | Amazon Web Services (SES, Region eu-north-1, Stockholm) — Versand-Infrastruktur. Tenant-eigenes Postfach — Archiv-Zweck. Optional via Unipile (FR, EU) für Tenant-Inbox-Anzeige. |
| Drittland-Transfer | Keiner (AWS EU, Unipile FR/EU). |
| Löschfristen | Versandprotokoll (document_email_log): Aufbewahrungsklasse handelsbrief_6j (72 Monate; § 257 Abs. 1 Nr. 2 und 3, Abs. 4 HGB, § 147 Abs. 1 Nr. 2 und 3, Abs. 3 AO), Fristbeginn mit dem Versand (sent_at). Keine automatische Löschung nach Fristablauf: gelöscht wird erst, wenn Inhaber oder Administrator des Mandanten die Klasse und das Ereignisjahr in der Freigabeliste freigeben; solange eine Aufbewahrungssperre (§ 147 Abs. 3 AO) offen ist, ist keine Freigabe möglich. Die Archivkopie im Postfach des Mandanten liegt nicht bei NexDeck; über ihre Aufbewahrung und Löschung entscheidet der Mandant. Die mitgesandte Rechnung selbst (PDF) folgt ihrer Belegklasse belegdaten_8j (8 Jahre, § 147 Abs. 1 Nr. 4, Abs. 3 AO; § 14b Abs. 1 UStG) im Eintrag der Ausgangsrechnungen. |
| TOMs | TLS-Transport, S3 Object Lock (WORM) für finalisierte PDF-Anhänge, Tenant-RLS auf document_email_log und email_events, Tags mit tenant_id in SES MessageTags für Zuordnung. |
V-16 — E-Mail-Öffnungs- und Klicktracking (Opt-in)
| Feld | Wert |
|---|---|
| Nummer | V-16 |
| Bezeichnung | Optionales Tracking von E-Mail-Öffnungen und Link-Klicks (nur nach Tenant-Admin-Opt-in) |
| Zweck | Messung der E-Mail-Performance für Vertriebs-Optimierung (Angebots-Nachverfolgung, Kampagnen-Effizienz). |
| Rechtsgrundlage | Kontextabhängig: B2B (gewerbliche Empfänger): Art. 6 Abs. 1 lit. f DSGVO. § 25 TDDDG nach herrschender Meinung nicht anwendbar (Unternehmensgeräte keine „Endeinrichtung"). B2C (Privatpersonen): Art. 6 Abs. 1 lit. a DSGVO (aktive Einwilligung) + § 25 TDDDG. Da der B2B/B2C-Kontext technisch nicht erkennbar ist, bleibt Opt-in als Default. |
| Betroffene | E-Mail-Empfänger (Bestandskunden, Angebots-Empfänger) |
| Datenkategorien | Öffnungs-Zeitstempel, IP-Adresse des Öffners, User-Agent, geklickte Links (Link-Redirects). |
| Empfänger | Amazon Web Services (SES Event Destinations → SNS). Intern: email_events Tabelle, pro Tenant RLS-isoliert. |
| Drittland-Transfer | Keiner (AWS EU-Frankfurt). |
| Löschfristen | 24 Monate nach Event, danach Pflicht-Löschung. Widerruf der Einwilligung jederzeit möglich (Art. 7 Abs. 3 DSGVO). |
| TOMs | Feature-Flag feature.email.open_tracking default OFF. Opt-in erfordert Zweit-Bestätigungsmodal mit Rechtstext. Widerruf-Flow gleich einfach wie Opt-in. Consent-Historie in user_consent_log (granted/revoked). |
V-17 — KI-gestützte CRM-Vorschläge (NEX Sales Assistant)
| Feld | Wert |
|---|---|
| Nummer | V-17 |
| Bezeichnung | Automatisierte Vorschläge für Vertriebshandlungen durch LLM-basierte Analyse von Lead-/Call-Kontext |
| Zweck | Effizienzsteigerung im Vertrieb durch kontextuelle KI-Vorschläge: Pre-Call-Briefing, Outcome-Vorschlag, Follow-up-Empfehlung, Datenlücken-Hinweise, Kampagnen-Insights. Keine autonomen Schreibvorgänge — jede Empfehlung erfordert User-Bestätigung (KI-Act Art. 14). |
| Rechtsgrundlage | Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse — Vertriebs-Effizienz). Tenant-Admin aktiviert pro Feature-Flag. |
| Betroffene | Leads, Kontakte, Bestandskunden, Kampagnen-Zielpersonen |
| Datenkategorien | Name, Rufnummer, E-Mail, Unternehmen, Kommunikationshistorie (Text), Lead-Status, Kampagnen-Attribution. KEIN Call-Audio, KEINE Transkripte. |
| Empfänger | Google Cloud EMEA Limited (Dublin, Irland) via Vertex AI (EU-Region europe-west1) und Amazon Web Services (Bedrock, EU-Region) als Auftragsverarbeiter — beide mit @anthropic-ai/vertex-sdk bzw. eu.anthropic.claude-*-Modell-IDs. US-Konzernmutter (Google LLC / AWS Inc.) nur als konzerninterner Sub-Prozessor. Kein direkter Anthropic-API-Zugriff. |
| Drittland-Transfer | Keiner für die primäre Verarbeitung — alle AI-Calls bleiben in EU-Rechenzentren (Region-Pinning, EDPB 05/2021). Der Cloud-DPA beider Anbieter enthält SCCs (Art. 46) als Auffangmechanismus für etwaigen konzerninternen Support-Zugriff. |
| Löschfristen | Keine eigene NEX-Speicherung. Alle verwendeten Daten verbleiben in NexDeck-DB und unterliegen den jeweiligen Retention-Policies (V-13, V-14, Tenant-CRM-Daten). |
| TOMs | TLS in transit, AES-256 at rest (RDS/Bedrock). Capability-basierte Zugriffskontrolle. Budget-Limit pro Tenant (ai_budget_cents_daily default 500 Cent/Tag). Audit-Log mit actor_type='nex_assistant' und cost_cents pro Request. Human-in-the-Loop für alle Write-Aktionen (User-Confirm-Pflicht). |
V-18 — Materialverwaltung, Lagerhaltung & Materialzuordnung zu Beschäftigten (2026-06-30)
| Feld | Inhalt |
|---|---|
| Zweck | Eigener Lager-/Fahrzeugbestand, projektbezogene Materialverbrauchserfassung, Übernahme verbrauchten Materials in Rechnungspositionen („Consumed = Billed", selektiv/manuell), interne Nachkalkulation (Soll/Ist, kalkulatorische Marge auf Basis interner Einkaufskosten). |
| Rechtsgrundlagen | Art. 6 Abs. 1 lit. b DSGVO; Mitarbeiter-Zuordnung Art. 88 DSGVO i.V.m. § 26 Abs. 1 BDSG (Verantwortlicher = Tenant/Arbeitgeber); Art. 6 Abs. 1 lit. c DSGVO i.V.m. § 147 AO/GoBD für rechnungsrelevante Buchungsbelege. |
| Betroffene | Beschäftigte des Auftraggebers (optionale Materialzuordnung issued_to_user_id/issued_to_name/used_by/created_by); Endkunden (über fakturiertes Material indirekt). |
| Datenkategorien | Materialstammdaten; Materialverbrauch je Projekt; interne Einkaufskosten (cost_price_cents — nicht personenbezogen, Geschäftsgeheimnis § 17 UWG); Mitarbeiter-Zuordnung; auto-erzeugte Rechnungspositionen (VK, Menge, Steuersatz). |
| Empfänger / Drittland | Keine neuen Sub-Prozessoren; Verarbeitung in NexDeck-DB (Supabase EU). EK/Marge erscheinen NICHT beim Endkunden (nicht in Angebot/Rechnung/E-Rechnung — verifiziert wf_9940cf53). |
| Löschfristen | Rechnungsrelevante Entnahmen 10 J (§ 147 AO/GoBD), danach Pseudonymisierung der Mitarbeiter-UUID; nicht-abgerechnete/stornierte Entnahmen kürzer. |
| TOMs | RLS-Tenant-Isolation; append-only Audit (material_usage_events, warehouse_audit_log); RBAC projects:budget_view für EK/Marge (worker ausgeschlossen); Finanzfelder via protect_material_usage_modification unveränderlich. |
| Verantwortlichkeit | NexDeck/Kre8ive Evolution = Auftragsverarbeiter (Art. 28). Tenant = Verantwortlicher für Beschäftigtendaten (Art. 13-Info + ggf. § 87 Abs. 1 Nr. 6 BetrVG). |
V-19 — Projektgebundener Kundenbereich / Client-Portal (Magic-Link-Kundenchat, § 9.22, 2026-07-10)
| Feld | Inhalt |
|---|---|
| Zweck | Projektbezogene Zwei-Wege-Kommunikation mit dem Endkunden über einen No-Login-Magic-Link (/chat/[token]): Nachrichten, Medien-Upload (Fotos/Videos/Dateien), Anzeige kunden-sichtbar freigegebener Fortschritts-Meilensteine. Zugang auf genau ein Projekt beschränkt, nicht übertragbar, zeitlich befristet. |
| Rechtsgrundlagen | Art. 6 Abs. 1 lit. b DSGVO (Projekt-/Vertragsdurchführung mit dem Tenant); Art. 6 Abs. 1 lit. f DSGVO (Zugangssicherung/Missbrauchsabwehr: Token-Hash, gekürzte IP, UA, Audit); Art. 6 Abs. 1 lit. c DSGVO i.V.m. § 257 HGB/§ 147 AO/§§ 195, 199, 634a BGB für beleg-/beweisrelevante Inhalte. DSA-Melde-/Abhilfe-Mechanismus in Anlehnung an Art. 6/16 DSA (kein Art.-8-Monitoring). |
| Betroffene | Endkunden des Auftraggebers (Autoren eigener Nachrichten/Medien); ggf. abgebildete Dritte in Medien. |
| Datenkategorien | Angezeigter Name; Nachrichteninhalte; hochgeladene Medien inkl. Metadaten (z.B. EXIF); Zugangs-Token (nur als SHA-256-Hash), pseudonymisierte (gehashte) IP, User-Agent, Zeitstempel (Ausstellung/Zugriff/Nachricht — append-only Audit). |
| Empfänger / Drittland | Keine neuen Sub-Prozessoren; Speicherung in NexDeck-DB (Supabase EU, Frankfurt) + Medien in S3 (eu-central-1). Team-Benachrichtigung über bestehende Kanäle (Push generisch, ohne Inhalt/Name an US-Dienst — Art. 5 Datenminimierung). |
| Löschfristen | Zweckdifferenziert: Zugangslink Standard 90 Tage gültig (max. 365; befristet nur den Zugang). Koordinationsmedien ab Projektabschluss + tenant-konfigurierte Frist (Standard 12 Monate, max. 120 Monate, media_retention_temporary_months) → zweistufiger Hard-Delete. Nachrichteninhalte spätestens 30 Tage nach Vertragsende (Karenz) bzw. auf Löschverlangen (Art. 17). Beleg-/beweisrelevant 3 bzw. 6–10 Jahre (§ 257 HGB/§ 147 AO/§§ 195,199,634a BGB); Token-Hash/gekürzte IP als Nachweisdaten mit dem Vorgang. Protokoll des Kundenzugangs (project_chat_share_audit_log) teilt die Klasse der Freigabe, die es protokolliert (project_chat_shares, inhaltsdaten): es geht mit ihr, spätestens mit dem Mandanten. Sein Riegel lässt das Löschen seit Migration 36661000 in der Mandantenlöschung und im Aufbewahrungslauf zu (vorher brach die Löschung an ihm ab). Legal Hold + Art.-18-Einschränkung im Streitfall (siehe AVV Anlage 3). |
| TOMs | RLS-Tenant-Isolation + FORCE; SECDEF-Token-RPCs (REVOKE anon/authenticated, GRANT service_role, projekt/tenant NUR aus Share-Record); Token nur als Hash gespeichert, kurze TTL, Widerruf; interne Notizen serverseitig aus dem Kunden-Read gestrippt (visibility='client'); append-only Share-Audit-Log; Rate-Limit + IP-Hash. |
| Verantwortlichkeit | Tenant = Verantwortlicher (Art. 13-Information gegenüber Endkunden). NexDeck/Kre8ive Evolution = Auftragsverarbeiter (Art. 28) + neutraler Hosting-Dienst; für DSA-Pflichtdaten (Melde-/Takedown-Bearbeitung) eigenständig Verantwortlicher (Art. 6 Abs. 1 lit. c). |
V-20 — E-Mail-Empfang (Inbound) + Roh-MIME-/Anhang-Speicherung (§ 9.23-C, 2026-07-13)
| Feld | Inhalt |
|---|---|
| Zweck | Entgegennahme eingehender E-Mails (Antworten von Endkunden/Lieferanten sowie Weiterleitungen) über eine token-basierte NexDeck-Empfangsadresse (<token>@inbound.nexdeck.de) zur projekt-/mandantenbezogenen Zwei-Wege-Kommunikation und Geschäftskorrespondenz-Dokumentation. Anhänge werden zur Anzeige/zum Download bereitgestellt. |
| Rechtsgrundlagen | Art. 6 Abs. 1 lit. b DSGVO (Kommunikation/Auftragsdurchführung); Art. 6 Abs. 1 lit. f DSGVO (Dokumentation der Geschäftskorrespondenz, Zuordnung via Token); für aufbewahrungspflichtige Geschäftsbriefe zusätzlich lit. c i.V.m. § 257 HGB / § 147 AO. |
| Betroffene | Absender eingehender E-Mails (Endkunden, Lieferanten, sonstige Korrespondenzpartner); ggf. in Anhängen abgebildete/genannte Dritte. |
| Datenkategorien | Vollständiger E-Mail-Header + Body; alle Datei-Anhänge (z.B. Verträge, Belege, Fotos — potenziell mit personenbezogenen Daten Dritter); Absender-/Empfänger-Adressen; Message-ID; Zeitstempel. Body-Inhalte in der NexDeck-DB verschlüsselt. |
| Empfänger / Drittland | Amazon Web Services — SES-Inbound (Empfang) + S3 (Speicherung des Roh-MIME inkl. Anhänge im Inbound-Bucket), beide eu-north-1 Stockholm. Speicherung der Body-Inhalte in Supabase (EU-Frankfurt). Bei angeschlossenem Postfach zusätzlich Unipile SAS (FR, EU). Kein Drittland-Transfer (alles EU/EWR). |
| Löschfristen | Roh-MIME + Anhänge werden mit dem zugehörigen Vorgang gelöscht; für beleg-/aufbewahrungspflichtige Korrespondenz 6 Jahre (§ 257 HGB) bzw. 10 Jahre (§ 147 AO), sonst zweckbezogen. Löschverlangen Art. 17 über den neutralen Marker/Live-RPC (keine PII-Spiegelung in append-only-Logs). Löschkonzept Anlage 3. |
| TOMs | Token dient ausschließlich der Mandanten-/Projekttrennung; Body verschlüsselt at-rest (Hardening laufend); Anhang-Nachladen ausschließlich aus dem gepinnten Inbound-Bucket mit Tenant-Berechtigungsprüfung + Streaming (keine zusätzliche dauerhafte Anhang-Kopie); RLS-Tenant-Isolation auf unipile_messages; Lifecycle-Guard (soft-deleted → keine Anhang-Auslieferung). Postfach-Freigabe in Suche und Mail-RPCs (Migration 36662000): search_unipile_messages, get_unlinked_message_attachments und auto_link_message_to_project filtern über unipile_lesbare_verbindungen — eigene Verbindung, Lesefreigabe, Inhaber des Postfachs, owner/admin bei Team-Postfach; persönliche Postfächer nur für den Inhaber und Freigegebene. get_all_unipile_messages_for_audit nur noch service_role. Postfach-Freigabe auch in der RLS (Migration 36980000): Lesen und Ändern von unipile_messages nur noch über die Postfächer, die die Person lesen darf (unipile_meine_lesbaren_verbindungen()); das Umhängen der Mails bei der Lead-Umwandlung läuft als Folge der erlaubten Lead-Änderung über alle Postfächer des Mandanten. Kundenmails teilen (Migration 37030000): aus persönlich verbundenen Postfächern mit Freigabe kundenmails (Vorgabe des Betriebs, festschreibbar) sehen Büro-Rollen Mails, die einem Kunden/Lead/Projekt zugeordnet sind und dessen Datensatz sie sehen dürfen; einzelne Mails als privat markierbar. ⚠️ Offen: die Chat-Suche kennt keine Freigabe je Konto. |
| Verantwortlichkeit | Tenant = Verantwortlicher (Art. 13/14 gegenüber Absendern). NexDeck/Kre8ive Evolution = Auftragsverarbeiter (Art. 28). |
V-21 — Proaktive KI-Assistenz-Loops (Payment-Watchdog / Lead-Rescue / Daily-Briefing / Project-Risk-Monitor, 2026-07-22)
| Feld | Inhalt |
|---|---|
| Zweck | Proaktive, opt-in-basierte Benachrichtigungen/Vorschläge aus vorhandenen Geschäftsdaten: überfällige Rechnungen (Payment-Watchdog), vernachlässigte Leads (Lead-Rescue), Tages-Briefing (Daily-Briefing), Projektrisiken (Project-Risk-Monitor). Nur Vorschlag/Benachrichtigung — keine autonome Aktion (KI-Act Art. 14, HITL). |
| Rechtsgrundlagen | Kunden-/Lead-Dimension: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an Betriebs-/Vertriebseffizienz, Erwägungsgrund 47). Für die im Daily-Briefing verarbeiteten Beschäftigtendaten (Termine/Zuständigkeiten): Art. 88 DSGVO i.V.m. § 26 Abs. 1 BDSG (Verantwortlicher = Tenant/Arbeitgeber — konsistent mit V-18). Aktivierung ausschließlich durch Tenant-Admin pro Feature-Flag (proactive_payment_watchdog, proactive_lead_rescue, proactive_daily_briefing, proactive_project_risk_monitor), Default OFF. |
| Betroffene | Endkunden (überfällige Rechnungen), Leads/Kontakte (Lead-Rescue), Beschäftigte des Tenants (Termine im Briefing). |
| Datenkategorien | Kundenname/-E-Mail, Rechnungsstatus/-betrag, Lead-Kontaktdaten, Termindaten. Vor der KI-Verarbeitung werden personenbezogene Daten pseudonymisiert (Namen/E-Mail/Telefon/IBAN → Platzhalter; Art. 5 Abs. 1 lit. c) und erst im Ergebnis für den internen Owner rückübersetzt. |
| Empfänger / Drittland | Google Cloud EMEA Limited (Dublin, Irland) via Vertex AI als Auftragsverarbeiter, Modell Gemini 2.5 Flash-Lite (EU-Region europe-west3/west1); US-Konzernmutter (Google LLC) nur konzerninterner Sub-Prozessor. Drittland: keiner — Verarbeitung bleibt in EU-Rechenzentren (Region-Pinning); Cloud-DPA-SCCs (Art. 46) als Auffangmechanismus; kein direkter Anthropic-Zugriff. Regelbasierte Loops (Project-Risk-Monitor) ohne LLM. |
| Löschfristen | Keine eigene Speicherung der KI-Eingaben (in-memory, Pseudonymisierungs-Mapping nicht persistiert). Erzeugte Benachrichtigungen in notifications/system_notifications gemäß deren Retention; PII-freier Ausführungs-Nachweis in audit_logs (Art.-50-/GoBD-Nachweis, 10 J). Löschkonzept Anlage 3. |
| TOMs | PII-Redaktion vor jedem LLM-Call (redactPII/restorePII); Opt-in-Feature-Flag je Loop (Default OFF); Human-in-the-Loop (ausschließlich Vorschlag, keine automatische Ausführung); PII-freier Audit-Trail (logSkillExecution → audit_logs, nur skillId/Anzahl/priority); per-Tenant Token-/Budget-Cap; RLS-Tenant-Isolation der Quelldaten. |
| Verantwortlichkeit | Tenant = Verantwortlicher (Art. 13-Information ggü. Betroffenen). NexDeck/Kre8ive Evolution = Auftragsverarbeiter (Art. 28). DSFA-Stufe 2 (volle DSFA — umfangreiche PII + innovative KI; s. (intern dokumentiert)), Gegenzeichnung DSB/Anwalt (§8). |
V-22 — KI-Feedback / Eval (Nutzer-Bewertung von KI-Ausgaben, DSGVO-Redesign 2026-07-23)
Hinweis: Dieser Eintrag ist noch nicht abschliessend juristisch geprueft und wird vor einer Verwendung als Nachweis geprueft.
| Feld | Inhalt |
|---|---|
| Zweck | Qualitätssicherung/Verbesserung der KI-Funktionen anhand von Nutzer-Bewertungen (Daumen hoch/runter/Korrektur). Zwei getrennte Zwecke: (a) tenant-interne Genauigkeits-Auswertung (instruierte Verarbeitung für den Tenant, Art. 28); (b) Tenant-übergreifende Eval der NexDeck-Zentrale zur Produktverbesserung — nur als PII-freies Aggregat und nur mit Tenant-Opt-in. |
| Rechtsgrundlagen | (a) Tenant-intern: Art. 28 DSGVO (Weisung des Verantwortlichen). (b) Tenant-übergreifend: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an Produktverbesserung) — abgesichert durch Opt-in je Tenant (ai_feedback_eval_optin, Default OFF) und strikte Datenminimierung (nur PII-freies Aggregat), um einen Zweckwechsel Auftragsverarbeiter→Verantwortlicher (Art. 28 Abs. 10) zu vermeiden. |
| Betroffene | Nutzer:innen des Tenants (Verfasser der Bewertung); mittelbar in Freitext-Korrekturen genannte Personen (Kund:innen), soweit vom Nutzer eingegeben. |
| Datenkategorien | PII-FREIER Zähl-Kontext (KI-Oberfläche/content_type, Modell, Feedback-Typ, PII-freie Korrektur-Kategorie) im append-only Audit-Log. Optionaler Freitext einer Korrektur wird serverseitig vor jeder Speicherung mit redactPII redigiert und nur redigiert im löschbaren, tenant-scoped ai_feedback-Store abgelegt. Roher KI-Output wird nicht gespeichert. |
| Empfänger / Drittland | Keine Weitergabe an Dritte. Tenant-übergreifende Aggregat-Auswertung ausschließlich für Super-Admins der NexDeck-Zentrale. Verarbeitung EU-only. Kein Modelltraining mit Kundeninhalten (kein RLHF auf Roh-Inhalten; Eval = manuelle Aggregat-Durchsicht). |
| Löschfristen | Redigierter Korrektur-Freitext im ai_feedback-Store ist löschbar: enthalten in DSAR-Export (Art. 15) und Art.-17-Hard-Delete. Kurz-Retention (90–180 Tage TTL) für redigierte Korrekturen empfohlen (noch nicht automatisiert). Der append-only Audit-Log enthält keine löschbare PII (bewusst PII-frei). |
| TOMs | PII-Redaktion vor jeder Persistierung von Freitext (redactPII); PII-freier append-only Audit-Log (nur Zähl-Kontext + Enum-Kategorie); Tenant-Opt-in-Feature-Flag (Default OFF) mit serverseitiger Filterung der Cross-Tenant-Query; Aggregat-only-Cross-Tenant-Sicht (keine per-Zeile-Inhalte); Super-Admin-Gate (assertSuperAdminAction); RLS-Tenant-Isolation; tenant_id serverseitig (assertSafeTenant). |
| DSFA-Notwendigkeit | DSFA-Vorprüfung empfohlen (Art. 35): durch Datenminimierung (PII-frei/redigiert), Opt-in und EU-only voraussichtlich kein hohes Risiko → vermutlich keine volle DSFA erforderlich; abschließende Bewertung durch DSB/Anwalt. |
| Verantwortlichkeit | (a) Tenant-intern: Tenant = Verantwortlicher, NexDeck/Kre8ive Evolution = Auftragsverarbeiter (Art. 28). (b) Tenant-übergreifendes Aggregat mit Opt-in: NexDeck/Kre8ive Evolution im eigenen Verbesserungsinteresse (Art. 6 Abs. 1 lit. f) — Zulässigkeit durch PII-Freiheit + Opt-in abgesichert. ⚠️ |
V-23 — KI-/RAG-Dokumentenanalyse (Company-Brain) (2026-07-23)
Live-VVT-Eintrag — akzeptiert 2026-07-23 (User-autorisiert). Die zugehörigen bindenden Klauseln sind live: AVV „Modul B" (
src/app/(public)/avv/page.tsx) + TOM §7.9 ((intern dokumentiert)), Versionenavv/tomauf 2026-07-23 gebumpt. Internes Anwalts-Tracking (Detail-Redline + Residual-Flags): `. Maßgebliche Quelle: DSK-Orientierungshilfe „KI und RAG" v1.0 (17.10.2025). Einzige anwaltlich offene Frage: Rollen-Caveat (AV vs. Art. 26) — siehe Feld „Verantwortlichkeit".
| Feld | Inhalt |
|---|---|
| Zweck | Semantische Durchsuchbarkeit tenant-eigener Dokumente über eine Vektor-Wissensdatenbank (Retrieval-Augmented Generation, „Company-Brain"). Der Tenant lädt eigene Dokumente hoch; diese werden in Textabschnitte (Chunks) zerlegt, je Chunk wird ein Vektor (Embedding) erzeugt und im mandantengetrennten Vektorindex gespeichert; bei einer Nutzeranfrage werden die semantisch ähnlichsten Chunks abgerufen (Retrieval) und als Kontext für die KI-gestützte Wissenssuche/Antwort bereitgestellt. Die DSK-OH „KI und RAG" v1.0 unterscheidet drei Teilschritte — (a) Embedding-Erzeugung, (b) Vektorspeicherung, (c) Retrieval —, die hier sämtlich weisungsgebunden für den Tenant erfolgen (Art. 28). Harte Architektur-Regel: strukturierte Geschäftsdaten laufen über Tool-Calling, nicht über den Vektor-RAG. |
| Rechtsgrundlagen | Instruierte Verarbeitung für den Tenant: Art. 28 DSGVO (Weisung des Verantwortlichen). Die materielle Rechtsgrundlage der in den Dokumenten enthaltenen personenbezogenen Daten (Art. 6, ggf. Art. 9 und Art. 10 DSGVO) sichert der Tenant als Verantwortlicher zu (Tenant-Warrant); NexDeck trifft keine inhaltliche Prüfpflicht. Die KI-Inferenz (Embedding-Erzeugung) selbst = Auftragsverarbeitung, KI-Anbieter = Sub-Auftragsverarbeiter (Art. 28 Abs. 4; DSK-OH KI 06.05.2024 Rn. 32). |
| Betroffene | Alle in den hochgeladenen Dokumenten genannten/abgebildeten Personen — offener Katalog: Beschäftigte, Endkunden, Lieferanten, sonstige in Verträgen/Angeboten/Protokollen/Korrespondenz genannte Dritte. Der Tenant bestimmt durch die Auswahl der Dokumente den Kreis. |
| Datenkategorien | Dokumentinhalte (Volltext + abgeleitete Text-Chunks) inkl. möglicher personenbezogener Daten Dritter — offener Kategorien-Katalog (potenziell auch besondere Kategorien Art. 9 bzw. Art.-10-Daten, soweit vom Tenant eingestellt). Vektor-Repräsentationen (Embeddings) je Chunk — datenschutzrechtlich als personenbezogen behandelt, da über Embedding-Inversion Rückschlüsse auf den Ausgangstext möglich sind (DSK-OH RAG v1.0; „Ghost Vectors", arXiv 06/2026: ~25,5 % Namen aus soft-gelöschten Embeddings rekonstruierbar) → in jede Betroffenenrechts-/Art.-17-/DSAR-Kaskade einbezogen. Metadaten (tenant_id, Quell-Dokument-ID, Chunk-/Versions-ID). Keine strukturierten Geschäftsdaten (Tool-Calling-Regel). |
| Empfänger / Drittland | Google Cloud EMEA Limited (Irland) via Vertex AI (Gemini-Embedding-Modell) zur Embedding-Erzeugung — EU-Region: Vertex EU-Multi-Region-Endpunkt (locations/eu) für die Embedding-Erzeugung; generative Inferenz europe-west1 (Belgien); Zero Data Retention + kein Modelltraining. Vektorspeicherung in der NexDeck-Datenbank (Supabase / PostgreSQL pgvector, EU-Frankfurt), mandantengetrennt (RLS). Dokument-Originale in AWS S3 (EU, löschbarer Bucket, Schlüsselschema tenants/{id}/…). US-Konzernmütter nur konzerninterne Sub-Sub-Prozessoren; SCCs (Art. 46) als Auffang. Kein Drittland-Transfer in der Primärverarbeitung (EU-Region-Pinning; DSGVO-Hard-Fail statt US-Routing). |
| Löschfristen | Löschung kaskadiert auf alle Ebenen der abgeleiteten Daten: Quell-Dokument (S3 + DB) → Text-Chunks → Embeddings (physisch, nicht Soft-Delete) → Retrieval-/Query-Cache. Auslöser: Dokument-Löschung durch den Tenant (deleteKnowledgeDocumentGDPR), Supersede bei Dokument-Update (alte Chunks/Embeddings werden ersetzt, kein Koexistenz-Zustand), Art.-17-Verlangen/DSAR-Kaskade (purge_subject), Auto-Purge-Cron archivierter Dokumente. Restfenster ehrlich benannt: In verschlüsselten DB-Sicherungen (täglich, sieben Tage vorgehalten; kein Point-in-Time-Recovery; s. AVV Anlage 3) können Rest-Repräsentationen bis zum Rotations-Ablauf fortbestehen — kein „Sofort-Vergessen"; Wiederherstellung nur im Desaster-Fall, keine Rückführung in den Live-Index. Kein eigenständiger Speicherzweck der Embeddings über die Quelldaten hinaus (Art. 5 Abs. 1 lit. e). |
| TOMs | Mandantentrennung der Vektor-DB (tenant_id-Scoping + Metadaten-Pre-Filter vor jedem Retrieval, RLS auf document_embeddings); Hard-Delete/Rebuild-Löschkonzept gegen Ghost-Vectors (physische Entfernung + VACUUM statt Soft-Delete-Flag); deterministisches Chunk-/Versionsschema für atomaren Supersede (reindex_document-RPC); EU-Region-Pinning + ZDR + No-Training; PII-Redaktion für die generative Antwortschicht; datenarme KI-Inferenz-Protokollierung (ohne Klartext); Embeddings in jede Art.-17-/DSAR-Kaskade eingebunden. Detail: TOM (intern dokumentiert) §7.8 (KI allgemein) + §7.9 (RAG-/Vektor-spezifisch, live seit 2026-07-23). |
| DSFA-Notwendigkeit | Volle DSFA (Stufe 2) plausibel/angezeigt (Art. 35). Das System company-brain ist im KI-DSFA-Register ((intern dokumentiert)) als Datenklasse pii_rich → Stufe 2 geführt: innovative KI-Technologie + potenziell umfangreiche/kommunikationsreiche Dritt-PII (≥ 2 WP248-Kriterien; deriveDSFAStufe('pii_rich')). Finale Bewertung/Gegenzeichnung durch DSB/Anwalt. |
| Verantwortlichkeit | Tenant = Verantwortlicher (Art. 4 Nr. 7; Auswahl der Dokumente, Rechtsgrundlagen-Zusicherung Art. 6/9/10, Art.-13/14-Information gegenüber Betroffenen). NexDeck/Kre8ive Evolution = Auftragsverarbeiter (Art. 28); KI-Anbieter (Vertex) + Vektor-DB-Host (Supabase/pgvector) = Sub-Auftragsverarbeiter. ⚠️ Anwaltlich zu klären: Rollen-Caveat — DSK-OH RAG v1.0 lässt AV vs. Art. 26 offen; da NexDeck Embedding-Modell/Chunking/Retriever bestimmt, ist gemeinsame Verantwortlichkeit zu prüfen (Prozessor-Framing unter No-Training vertretbar, EDPB Guidelines 07/2020). Detail-Flags: `. |
V-24 — KI-gestützte Baustellendokumentation (Bautagebuch-Diktat + Fotobeschreibung) (2026-08-21)
Live-VVT-Eintrag. Deckt DREI Teilverarbeitungen ab, die technisch zusammengehören und bis heute in KEINEM Verzeichnis standen: (a) Auswertung des gesprochenen Bautagebuch-Diktats, (b) Beschreibung einzelner Baustellenfotos, (c) seit 2026-08-21 der kombinierte Aufruf, bei dem die Fotos eines Eintrags dem Diktat als Zusammenhang beiliegen. 🔴 (c) ist ein Verfahren mit zwei Quellen, nicht die Summe von (a) und (b).
| Feld | Inhalt |
|---|---|
| Zweck | Erstellung eines prüffähigen Bautagebuch-Eintrags aus dem, was die ausführende Person auf der Baustelle gesprochen hat. (a) Das Diktat wird transkribiert und in strukturierte Felder überführt (Bericht, Personenzahl, Stunden, Wetter, Mängel). (b) Zu einzelnen Fotos wird auf ausdrückliche Anforderung eine beschreibende Bildunterschrift erzeugt. (c) Beim kombinierten Aufruf liegen die nummerierten Fotos des Eintrags dem Diktat bei, damit das Modell Aussagen den richtigen Bildern zuordnen kann („Foto 2, linke Ecke neben der Tür"). 🔴 Harte Architektur-Regel: die Fotos sind Zusammenhang, keine Quelle — es gelangt nur in den Bericht, was gesprochen wurde. Was das Modell auf einem Bild sieht und niemand gesagt hat, wird nicht Bestandteil des Berichts. |
| Rechtsgrundlagen | Weisungsgebundene Verarbeitung für den Tenant: Art. 28 DSGVO. Die materielle Rechtsgrundlage für die Aufnahme und Verarbeitung der Bilder (Art. 6 Abs. 1, bei Beschäftigten § 26 BDSG, ggf. Art. 9) sichert der Tenant als Verantwortlicher zu; er bestimmt, was fotografiert und diktiert wird. Die KI-Inferenz selbst = Auftragsverarbeitung, Google = Sub-Auftragsverarbeiter (Art. 28 Abs. 4). |
| Betroffene | Offener Katalog. Beschäftigte des Tenants (Sprecher des Diktats; im Bericht namentlich genannte Kolleginnen und Kollegen), Auftraggeber und deren Beschäftigte, Nachunternehmer, Bewohnerinnen und Bewohner der dokumentierten Objekte sowie auf Fotos zufällig abgebildete Dritte. 🔴 Der letzte Kreis ist der kritische: Baustellenfotos entstehen in bewohnten Objekten, und wer im Bild ist, hat die Aufnahme nicht veranlasst. |
| Datenkategorien | Sprachtranskript des Diktats (Freitext, PII-redigiert vor der Übertragung an das Modell; Rückübersetzung erst nach der Antwort). Bilddaten von Baustellen-/Objektfotos — 🔴 eine Schwärzung ist bei Bildern technisch nicht möglich; der Schutz besteht ausschließlich in der Anweisung an das Modell, Personen nicht zu benennen oder zu beschreiben, und in der Ausgabeprüfung vor der Anzeige. Erzeugte Texte: Tagesbericht, Mängelliste, Bildunterschriften, Zuordnung Aussage↔Foto. Metadaten: tenant_id, project_id, Aufnahmezeitpunkt, Modellname, Konfidenz, Prompt-Hash. Wetter-Messwerte (seit 2026-09-01): Temperatur, Wind und Niederschlag einer öffentlichen Wetterstation für den Tag des Eintrags, dazu der Quellenvermerk mit Stationsname. 🔴 Diese Werte stammen nicht aus dem Modell — der Diktat-Prompt untersagt ausdrücklich einen Wetterdienst; sie werden getrennt abgerufen und getrennt angezeigt. Kein Audio — die Aufnahme wird nach der Texterkennung verworfen und nicht gespeichert. |
| Empfänger / Drittland | Google Cloud EMEA Limited (Irland) via Vertex AI, Modell gemini-3.1-flash-lite, EU-Multiregion über den Data-Residency-Endpunkt (aiplatform.eu.rep.googleapis.com, locations/eu); Zero Data Retention, kein Modelltraining mit Kundeninhalten. Transkription: Deepgram (EU-Endpunkt, mip_opt_out). Bildablage: AWS S3 (EU, Schlüsselschema tenants/{id}/…). US-Konzernmütter nur konzernintern; SCCs (Art. 46) als Auffang. Wetterabruf (seit 2026-09-01): Bright Sky (api.brightsky.dev, Open-Source, gehostet bei Hetzner in Deutschland) als Zustellweg für DWD-Beobachtungsdaten. Kein Auftragsverarbeiter — übertragen werden ausschließlich eine auf zwei Nachkommastellen gerundete Baustellenkoordinate und ein Kalenderdatum, Server zu Server, ohne Nutzer-IP; Einzelheiten in subprocessors.md § 3.11. Kein Drittland-Transfer in der Primärverarbeitung — die Region ist erzwungen (Allowlist + feste Host-Zuordnung; unbekannte Region = harter Abbruch, kein Rückfall auf einen US-Endpunkt). |
| Löschfristen | Die erzeugten Texte teilen die Frist ihres Trägers: Bildunterschrift = Lebensdauer des Fotos (project_media, Löschkonzept-Anker, harte Löschung inkl. S3-Objekt); Bericht = Lebensdauer des Bautagebuch-Eintrags. 🔴 Nach dem Festschreiben (locked) ist der Bericht unveränderlich und unterliegt der handels-/steuerrechtlichen Aufbewahrung — eine Löschung einzelner Angaben ist dann nicht mehr möglich; das ist die bewusste Folge der Beweisfunktion. Das Audio wird nie gespeichert. Bei Google entsteht durch ZDR keine Kopie. |
| TOMs | Region und Host ausdrücklich zugeordnet statt aus der Region abgeleitet (eine geratene URL antwortet möglicherweise und verliert dabei still die Residenz-Zusage). PII-Redaktion des Transkripts vor der Übertragung. Personen-Ausschluss im Bild-Prompt als einzige bildseitige Maßnahme — ausdrücklich benannt, nicht beschönigt. Ausgabeprüfung vor der Anzeige: Bewertungen und Freisprüche werden zurückgehalten, der Grund wird dem Menschen genannt. Aufwertungs-Melder: eine Bewertung, die im Bericht steht, aber nicht im Diktat, wird markiert. Freigabe je Betrieb (tenants.media_ai_scope: aus / nur Büro / alle) mit rollengeprüfter RPC; Tagesmenge begrenzt; Mandanten-, Projekt- und Sichtbarkeitsprüfung vor jedem Bildzugriff. Kein Ausweich auf einen Anbieter ohne Bildverarbeitung (ein Modell, das die Bilder nicht sieht, würde Zuordnungen erfinden). Wetterabruf: Koordinate auf zwei Nachkommastellen gerundet (rund 1 km) vor der Übertragung — für die Stationsauswahl unerheblich, für die Datenminimierung nicht. Kein Abruf ohne hinterlegte Baustellenkoordinate (kein Ersatzort aus Firmensitz oder Mandantenadresse). Vorhersagewerte werden verworfen; auf einem Beleg steht nur Gemessenes. |
| DSFA-Notwendigkeit | Zu prüfen, Tendenz Stufe 1 (Kurzprüfung). Kein Profiling, keine automatisierte Entscheidung mit Rechtswirkung (Art. 22), keine systematische Überwachung öffentlich zugänglicher Bereiche — die Aufnahme ist anlassbezogen und wird vom Menschen ausgelöst. Erhöhend wirkt: Bildmaterial aus bewohnten Objekten mit möglicher Dritt-PII, die sich nicht redigieren lässt. ⚠️ Anwaltlich zu klären / DSB: finale Einstufung. |
| Verantwortlichkeit | Tenant = Verantwortlicher (Art. 4 Nr. 7): er entscheidet, was fotografiert und diktiert wird, schaltet die Funktion für seinen Betrieb frei und informiert seine Beschäftigten sowie betroffene Dritte (Art. 13/14). NexDeck/Kre8ive Evolution = Auftragsverarbeiter (Art. 28). Google = Sub-Auftragsverarbeiter. |
| KI-VO (AI Act) | Transparenzpflicht nach Art. 50 Abs. 2 (maschinenlesbare Kennzeichnung KI-erzeugter Inhalte) — umgesetzt über data-ai-generated. Die sichtbare Offenlegung nach Abs. 4 trifft den Betreiber; die Kennzeichnung entfällt dort, wo eine fachkundige Person den Inhalt inhaltlich prüft und die Verantwortung übernimmt (Abs. 4 UAbs. 2) — genau das leistet der Bestätigungs-Schritt. 🔴 Deshalb darf die Übernahme in den Bericht nie automatisch geschehen. |
V-25 — Betreiber-Banking und Zahlungsverkehr (Qonto) (2026-09-04)
Live-VVT-Eintrag. Er schliesst eine Lücke, die bei der AVV-Bestandsaufnahme am 04.09.2026 auffiel: Qonto lief seit Monaten als Geschäftskonto des Betreibers, stand aber in keinem Verzeichnis — weil die Frage falsch gestellt war. Gesucht wurde ein AVV; gefehlt hat ein Verfahren.
🔴 Qonto ist kein Auftragsverarbeiter und gehört nicht in die Subprozessorenliste. Ein Zahlungsdienstleister ist nach der Praxis der Aufsichtsbehörden (u. a. BayLDA) nicht weisungsgebunden, sondern erfüllt eigene gesetzliche Pflichten (ZAG, GwG) und ist damit eigener Verantwortlicher; Art. 28 setzt eine Verarbeitung „im Auftrag" voraus. Hinzu kommt: hier werden keine Mandantendaten im Auftrag verarbeitet, sondern eigene Geschäftsdaten des Betreibers. Ein AVV wäre sachlich falsch, eine Aufnahme in die Subprozessorenliste der Plattform sogar irreführend — dort stehen ausschliesslich Auftragsverarbeiter für Mandantendaten.
| Feld | Inhalt |
|---|---|
| Nummer | V-25 |
| Bezeichnung | Geschäftskonto und Zahlungsverkehr des Betreibers (Qonto) |
| Zweck | Führung des Geschäftskontos der Kre8ive Evolution UG (haftungsbeschränkt): Ein- und Ausgangszahlungen, Kontoabgleich der eigenen Buchführung, Auszahlung von Provisionen an Vertriebspartner. |
| Rechtsgrundlagen | Art. 6 Abs. 1 lit. b DSGVO (Erfüllung des Vertrags mit dem Zahlungsempfänger bzw. dem Vertriebspartner) und lit. c (handels- und steuerrechtliche Aufzeichnungs- und Aufbewahrungspflichten, §§ 238, 257 HGB, §§ 145 ff. AO). Auf Seiten von Qonto zusätzlich eigene gesetzliche Pflichten nach ZAG und GwG. |
| Betroffene | Vertriebspartner (Provisionsempfänger), Lieferanten und Dienstleister des Betreibers, zahlende Kunden des Betreibers, Beschäftigte mit Kontozugriff. |
| Datenkategorien | Name bzw. Firmierung des Zahlungsempfängers, IBAN, Verwendungszweck, Betrag, Buchungsdatum, Zuordnung zur eigenen Buchhaltung. Bei Provisionen zusätzlich die Bezugnahme auf die Gutschrift nach § 14 Abs. 2 UStG. |
| Empfänger / Drittland | Qonto (Olinda SAS, Paris, Frankreich) als eigener Verantwortlicher, nicht als Auftragsverarbeiter. Kein Drittlandtransfer bekannt. Steuerberatung als Empfänger der Buchungsdaten im Rahmen des Mandats. |
| Löschfristen | Zahlungs- und Buchungsdaten sind Buchungsbelege: Aufbewahrung nach § 147 Abs. 3 AO (acht Jahre seit dem Vierten Bürokratieentlastungsgesetz) bzw. § 257 HGB, gerechnet ab Schluss des Kalenderjahres der letzten Eintragung. |
| TOMs | Zugang zum Konto nur über personengebundene Anmeldung mit zweitem Faktor; Freigabe von Überweisungen ausschliesslich in der Qonto-Anwendung (starke Kundenauthentifizierung). Der Auszahlungsweg der Plattform bleibt gesperrt, solange er nicht ausdrücklich freigeschaltet ist. IBAN-Daten der Vertriebspartner werden nicht ohne Erforderlichkeit exportiert. |
| Verantwortlichkeit | Kre8ive Evolution UG (haftungsbeschränkt) = Verantwortlicher. Qonto = eigener Verantwortlicher für die Zahlungsabwicklung. Kein Art.-28-Verhältnis. |
| Abgrenzung | Betrifft ausschliesslich das eigene Konto des Betreibers. Zahlungen der Mandanten an ihre Kunden laufen über Stripe und sind dort geregelt; Kontoinformationsdienste für Mandanten laufen über finAPI (Vertragsabschluss steht aus, siehe unten). |
| Offen | 🔴 finAPI: Der Vertrag wird erst mit Erteilung der USt-IdNr. abgeschlossen (bis dahin Sandbox). Beim Abschluss ist zu klären, ob finAPI als lizenzierter Kontoinformationsdienst ebenfalls eigener Verantwortlicher ist oder für die Kontodaten der Mandanten Auftragsverarbeiter — davon hängt ab, ob ein AVV nötig ist und ob finAPI in die Subprozessorenliste gehört. Dann entsteht ein eigener Eintrag. |
V-26 — Produktauswertung des Betreibers (Nutzungskennzahlen je Mandant) (2026-09-08)
Live-VVT-Eintrag. Er schliesst dieselbe Art von Lücke wie V-25, nur an anderer Stelle: die Auswertung läuft seit Monaten (täglicher Aggregationslauf, Cockpit unter einer internen Auswertungsoberfläche), stand aber in keinem Verzeichnis und in keinem Rechtstext. Gemessen am 07.09.2026: „Produktanalyse" und „Nutzungsstatistik" kamen in DSE, AVV und AGB gar nicht vor.
🔴 Hier ist der Betreiber Verantwortlicher, nicht Auftragsverarbeiter. Kennzahlen über das Vertragsverhältnis sind eigene Daten (Art. 6 Abs. 1 lit. b/f). Die Grenze ist eine einzige Zeile Code entfernt: sobald die Auswertung die Inhalte einbezieht, die uns der Mandant nach dem AVV anvertraut hat, verarbeiten wir Auftragsdaten zu eigenen Zwecken und werden dafür nach Art. 28 Abs. 10 DSGVO ohnehin zum Verantwortlichen — mit Betroffenenrechten gegenüber Personen, die uns gar nicht kennen.
| Feld | Inhalt |
|---|---|
| Nummer | V-26 |
| Bezeichnung | Produktauswertung / Nutzungskennzahlen je Mandant (Product Intelligence) |
| Zweck | Produktentscheidungen des Betreibers: erkennen, welche Module tatsächlich genutzt werden, wo Abläufe scheitern, welche Kosten die KI-Funktionen verursachen, welche Mandanten Unterstützung brauchen. |
| Rechtsgrundlage | Allein Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an bedarfsgerechter Weiterentwicklung). |
| Betroffene | In der Regel niemand — es sind Unternehmensdaten, und Erwägungsgrund 14 nimmt juristische Personen ausdrücklich aus. Personenbezug entsteht bei Einzelunternehmen, Freiberuflern und Personengesellschaften (GbR, OHG, KG, PartG, GmbH & Co. KG): dort stehen unmittelbar natürliche Personen hinter dem Betrieb. Seit 08.09.2026 wird das je Mandant aus tenant_settings.legal_form abgeleitet; 🔴 eine fehlende Angabe führt fail-closed zu „personenbezogen" — am 08.09.2026 traf das auf 12 von 17 Mandanten zu. |
| Datenkategorien | product_metrics_daily (Tageszähler je Mandant: Rechnungen, Angebote, Belege, Projekte, Leads, Kunden, E-Mails, Kalendereinträge, Zeiterfassungen, Gesamtaktionen; KI-Aufrufe gesamt/erfolgreich, mittlere Zuversicht, Kosten, angenommene/abgelehnte Vorschläge; Anzahl der an einem Tag aktiven Nutzerkonten). feature_flag_snapshots (freigeschaltete Module + Branche). Aus tenants: Firmenname, Branche, Anlagedatum. Aus tenant_settings: nur legal_form (Rechtsform), zur Bestimmung des Anwendungsbereichs. |
| Nicht erhoben | Keine Inhalte. Ausdrücklich nicht: ai_suggestions.suggestion_data (Vorschlag im Volltext), ai_suggestions.accepted_by, ai_action_log.user_id, ai_action_log.error_message. Die Zahl der aktiven Nutzer wird aus activity_log.user_id gebildet — gespeichert wird nur die Anzahl, nicht wer. |
| Empfänger / Drittland | Keine. Zugriff ausschliesslich über requireSuperAdmin() (Plattform-Administration des Betreibers). Speicherung in derselben Datenbank wie der übrige Betrieb, kein Drittlandtransfer, kein zusätzlicher Auftragsverarbeiter. |
| Löschfristen | Tageswerte 12 Monate, danach Verdichtung zu Monatswerten (product_metrics_monthly) und Löschung der Tageszeilen; Monatswerte weitere 36 Monate, danach Löschung. Insgesamt vier Jahre. Durchgesetzt vom Lauf verdichte-produktkennzahlen (monatlich, 3. des Monats). |
| TOMs | Zugang nur mit Plattform-Administrationsrechten. Der Aggregationslauf ist reine SQL-Zählung ohne Modellaufruf. Die Grenze zu den Inhalten ist durch einen Wächter im Test-Bestand abgesichert: tests/compliance/product-intelligence-liest-keine-inhalte.test.ts lässt die vier oben genannten Spalten im Cockpit-Quelltext nicht zu. |
| Verantwortlichkeit | Kre8ive Evolution UG (haftungsbeschränkt) = Verantwortlicher. Kein Art.-28-Verhältnis, weil keine Verarbeitung im Auftrag des Mandanten stattfindet. |
| Abgrenzung | Zugriffe von Beschäftigten des Betreibers auf Mandanteninhalte zur Unterstützung sind weisungsgebunden (Art. 28), gesondert protokolliert (support_access_log, support_action_log) und im AVV geregelt — ein anderes Verfahren. Das Support-Zugriffsprotokoll wird 12 Monate nach dem Zugriff gelöscht, die Support-Freigaben (support_access_grants) 12 Monate nach Ablauf oder Widerruf und erst, wenn kein Protokolleintrag mehr zu ihnen gehört (Lauf support_zugriff_frist_bereinigen, täglich, nicht bei offener Aufbewahrungssperre; Migration 36659000). Die Hash-Kette bleibt über einen Kettenanker je Mandant prüfbar (support_access_log_anker); ein schon gebrochenes Präfix wird nicht gelöscht, sondern gemeldet. AVV Anlage 3. |
| Betroffeneninformation | Datenschutzerklärung Abschnitt 4h (/privacy#produkt-telemetrie), eingefügt mit dem privacy-Bump auf 2026-09-08. |
| Widerspruch (Art. 21) | Gilt, weil lit. f. Kein Schalter geschuldet: Art. 21 Abs. 5 gibt der betroffenen Person die Möglichkeit automatisierter Ausübung, er verpflichtet den Verantwortlichen nicht zum Bau; EDPB 1/2024 Rn. 77 hält fest, dass die DSGVO keine Formerfordernisse für die Ausübung von Betroffenenrechten aufstellt. Geschuldet ist Erleichterung (Art. 12 Abs. 2 S. 1) und ein von anderen Informationen getrennter Hinweis (Art. 21 Abs. 4) — dieser stand zunächst als Aufzählungspunkt und ist am 08.09.2026 in einen abgesetzten Kasten überführt worden. 🔴 Technisch ist die Umsetzung eines eingehenden Widerspruchs nirgends gebaut; sie wäre von Hand zu leisten. |
| Offen | ⚠️ Anwaltlich zu klären: Bestätigung der Einordnung „allein lit. f" und der Abwägung. 🔴 Speicherdauer: Klasse plattform heisst heute „keine feste Frist", Art. 5 Abs. 1 lit. e verlangt eine Begrenzung — zu entscheiden ist eine Verdichtung alter Tageszähler zu Monatswerten. |
V-27 — Werbesperrliste (Beachtung des Werbewiderspruchs) (2026-09-08)
| Feld | Wert |
|---|---|
| Nummer | V-27 |
| Bezeichnung | Werbesperrdatei je Mandant — pseudonymisierter Abgleich beim Listenimport |
| Zweck | Sicherstellen, dass eine Person, die einer werblichen Ansprache widersprochen hat, beim Import einer Adressliste nicht erneut angesprochen wird. Der Abgleich ist der einzige Zweck; die Einträge werden für nichts anderes verwendet. |
| Rechtsgrundlage | Art. 21 Abs. 3 und Art. 6 Abs. 1 UAbs. 1 lit. f DSGVO i. V. m. Art. 17 Abs. 3 lit. b DSGVO. Die Aufsichtsbehörden behandeln Werbesperrdateien in der Orientierungshilfe „Verarbeitung personenbezogener Daten für Zwecke der Direktwerbung", Stand Februar 2022 (18.02.2022), Abschnitt 5.1, S. 17 — wörtlich: „Solche Werbesperrdateien können aufgrund von Art. 21 Abs. 3, Art. 6 Abs. 1 UAbs. 1 lit. f DS-GVO i. V. m. Art. 17 Abs. 3 lit. b DS-GVO … zulässig sein." 🔴 Diese Fassung stellt eine Bedingung auf, die die Vorgängerfassung von 2018 nicht kannte: „Eine Werbesperrdatei kann daher letztlich nur rechtmäßig sein, wenn die zu verhindernde Verarbeitung zu Werbezwecken auf Art. 6 Abs. 1 UAbs. 1 lit. f DS-GVO beruht." |
| Betroffene | Personen, die gegenüber dem Mandanten einer werblichen Ansprache widersprochen haben (Interessenten, ehemalige Interessenten, Kunden). |
| Datenkategorien | Ausschließlich ein Pseudonym: SHA-256 über die normalisierte E-Mail-Adresse bzw. Rufnummer (E.164), gebildet mit einem Server-Pepper (NEXDECK_AUDIT_PEPPER), der Mandanten-Kennung und einem Bereichsnamen (werbesperrliste:v1). Dazu: Art (E-Mail/Telefon), Anlass, Zeitpunkt, die anlegende Person und eine freie Notiz. 🔴 Die Notiz ist ein Freitextfeld: die Oberflaeche bittet um eine Angabe ohne Personenbezug, technisch erzwungen ist das NICHT. Sie kann daher personenbezogene Angaben enthalten, wenn der Mandant sie hineinschreibt — und teilt dann die Aufbewahrung des Sperrvermerks. (Zuvor stand hier die Zusage „ohne Personenbezug"; sie war durch den Code nicht gedeckt und ist im Dreifach-Audit vom 08.09.2026 berichtigt worden.) 🔴 Keine Klartext-Adresse und keine Klartext-Rufnummer. |
| Empfänger | Keine. Der Bestand verlässt den Mandanten nicht; er wird auch nicht an Dritte zum Abgleich übermittelt. |
| Drittland-Transfer | Keiner. Supabase EU (Frankfurt). |
| Löschfristen | Ein Sperrvermerk wird nicht gelöscht — er ist das Mittel, mit dem der Widerspruch dauerhaft beachtet wird; ihn zu löschen hieße, die Person wieder ansprechbar zu machen. Willigt die Person erneut ein, wird der Vermerk aufgehoben (aufgehoben_am, aufgehoben_von, aufhebung_grund) und beim Abgleich nicht mehr berücksichtigt; die Zeile bleibt zur Nachvollziehbarkeit bestehen. Mit dem Mandanten wird die Liste gelöscht (ON DELETE CASCADE). |
| TOMs | RLS-Isolation je Mandant; authenticated hat auf der Tabelle nur SELECT und INSERT sowie ein spaltengebundenes UPDATE auf die drei Aufhebungsfelder — kein DELETE, kein TRUNCATE, kein Schreibrecht auf den Hash. Die Policy für die Aufhebung verlangt aufgehoben_am IS NULL, ein bestehendes Aufhebungsdatum ist damit nicht überschreibbar. Bereichstrennung im Hash verhindert den Abgleich gegen andere pseudonymisierte Bestände. Alle fünf Riegel wurden am 08.09.2026 in Produktion in einer zurückgerollten Transaktion mit Positivkontrolle gemessen. |
| Verantwortlichkeit | Tenant = Verantwortlicher (er entscheidet, ob ein Widerspruch vorliegt, und unterrichtet die Person). NexDeck/Kre8ive Evolution = Auftragsverarbeiter (Art. 28). NexDeck bewertet nicht, ob ein Widerspruch wirksam ist. |
| Unterrichtungspflichten | Die Orientierungshilfe knüpft an dieselbe Stelle Hinweise, die die Software als Textbaustein bereitstellt und die der Mandant erteilt: (a) über „Sinn und Zweck der Aufnahme ihrer Daten in eine Sperrdatei" (Art. 12 Abs. 3 DSGVO); (b) wenn jemand „ausdrücklich und allein eine Löschung aller Daten aus der Werbesperrdatei" wünscht — bei uns also die Aufhebung —, der Hinweis, dass er „eventuell wieder Werbung erhalten kann"; (c) ergänzend der Verweis auf die Robinsonliste (ichhabediewahl.de) samt ihrer Grenze (der Abgleich ist freiwillig, ein Eintrag „keine Garantie"). 🔴 Versendet wird nichts automatisch. |
| Abgrenzung | Nicht tenant_email_suppressions. Jene ist eine Zustellbarkeitsliste (Hard Bounce, Beschwerde) mit Klartextadresse und einem anderen Zweck; beides zu vermischen hieße, eine gelöschte Person im Klartext weiterzuführen. |
| Offen | ⚠️ Anwaltlich zu klären, neu und gewichtiger als der bisherige Punkt: die Fassung Februar 2022 verlangt, dass „die zu verhindernde Verarbeitung zu Werbezwecken auf Art. 6 Abs. 1 UAbs. 1 lit. f DS-GVO beruht". Für den Anruf bei einem Gewerbetreibenden trägt das (§ 7 Abs. 2 Nr. 1 UWG: mutmaßliche Einwilligung genügt, Grundlage lit. f). Für Werbe-E-Mail verlangt § 7 Abs. 2 Nr. 2 UWG eine ausdrückliche Einwilligung; beruht die zu verhindernde Verarbeitung damit auf lit. a, greift die Voraussetzung nach ihrem Wortlaut nicht. Die E-Mail-Sperre bleibt gebaut, weil sie hier nicht nur Werbung verhindert, sondern die erneute Anlage eines Datensatzes aus einer Importliste — das ist eine Auslegung, keine Feststellung, und gehört bestätigt. 🔴 Der Widerspruch, der ohne bestehende Anfrage eintrifft, wird von Hand erfasst; es gibt keinen Weg, über den die betroffene Person ihn selbst auslöst. Der EDPB-Bericht zur koordinierten Aktion 2025 (Art. 17, angenommen Februar 2026) verlangt insoweit keinen Selbstbedienungsweg, sondern dass der Verantwortliche benennt, „who to contact and which communications channel(s) to use" — das ist eine Pflicht des Mandanten, nicht des Werkzeugstellers. |
V-28 — Beschäftigten-Vertragsverwaltung (Arbeitsverträge und Personalstammdaten) (2026-09-08)
| Feld | Wert |
|---|---|
| Nummer | V-28 |
| Bezeichnung | Anlegen, Erzeugen und Aufbewahren von Arbeitsverträgen je Mandant, samt der dafür nötigen Personalstammdaten |
| Zweck | Der Mandant erfüllt gegenüber seinen Beschäftigten die Nachweispflicht aus § 2 NachwG, dokumentiert die vereinbarten Bedingungen und hält den Vertrag für die gesetzliche Aufbewahrungsfrist vor. Die Stammdaten tragen daneben Einsatzplanung, Zeiterfassung und interne Nachkalkulation. |
| Rechtsgrundlage | Art. 6 Abs. 1 lit. b DSGVO (Durchführung des Arbeitsverhältnisses) und Art. 88 DSGVO i. V. m. § 26 Abs. 1 BDSG; für die Aufbewahrung Art. 6 Abs. 1 lit. c i. V. m. § 257 HGB. 🔴 § 26 BDSG steht seit EuGH C-34/21 nicht mehr allein — primär ist Art. 6, § 26 ist der nationale Kontext (so schon im Bump der Datenschutzerklärung vom 16.06.2026). |
| Betroffene | Beschäftigte des Mandanten, auch ausgeschiedene, solange die Frist läuft. |
| Datenkategorien | Am Schema erhoben, nicht geschätzt. Die Lohnmerkmale (Steuer-Identifikationsnummer, Steuerklasse, Sozialversicherungsnummer, Krankenkasse, IBAN) gehören zu V-31, nicht hierher. employment_contracts: Name, Anschrift (Straße, PLZ, Ort), Geburtsdatum, Tätigkeit, Arbeitsort, Beschäftigungsumfang, Wochenstunden, Monatsentgelt bzw. Stundensatz, Provisionssätze (Setup und laufend), Urlaubstage, Probezeit, Befristung samt Befristungsgrund, Vertragsbeginn und -ende, Unterzeichnung, Empfangsnachweis samt Weg, Fassung und Version, Dateiname und -größe, Papier-Ablageort, Bemerkung. employee_profiles: Personalnummer, Telefonnummer, Abteilung, Funktion, Ein- und Austrittsdatum, Wochenstunden, Stundensatz, interner Kostensatz, Entgeltgruppe, Vorgesetzter, Projektleiter-Kennzeichen sowie zwei offene Felder (notes, certificates). |
| 🔴 Besondere Kategorien (Art. 9) | Abgrenzung seit 17.09.2026: Merkmale besonderer Kategorien werden in einer eigenen Tabelle hinter einer engeren Schranke geführt und stehen in V-31. Für die beiden Tabellen dieses Eintrags gilt: in employment_contracts und employee_profiles gibt es kein Feld für Religionszugehörigkeit, Schwerbehinderung, Gewerkschaftszugehörigkeit oder Gesundheitsdaten — am Schema geprüft, nicht angenommen. |
| Empfänger | Keine externen. Innerhalb des Mandanten ist der Schreibzugriff auf employee_profiles seit Migration 34880000 auf team:manage beschränkt (RESTRICTIVE-Policy für INSERT/UPDATE, DELETE gesperrt); Anlegen und Ändern der Verträge sind super-admin-gebunden (34890000). Den eigenen Vertrag kann die betroffene Person lesen. |
| Drittland-Transfer | Keiner. Supabase EU (Frankfurt), Dateiablage AWS S3 EU (Frankfurt). |
| Löschfristen | employment_contracts = Klasse handelsbrief_6j (72 Monate), Anker beendet_am — die Frist beginnt mit dem Ende des Arbeitsverhältnisses, nicht mit dem Anlegen. 🔴 Ein laufendes Arbeitsverhältnis hat keinen Anker und wird nicht freigegeben; beendet_am entsteht durch Spiegelung aus employee_profiles.end_date (Trigger, Migration 34810000) und wurde am 08.09.2026 mit Positivkontrolle gemessen. employee_profiles = Klasse nachweis_sonstig. ⚠️ § 28f Abs. 1 SGB IV kann die tatsächliche Aufbewahrung im Einzelfall über sechs Jahre hinaus verlängern — eine Entscheidung des Betriebs, keine Regel der Software. |
| TOMs | RLS-Isolation je Mandant; Rollenschranke auf employee_profiles (nur team:manage) — sie ist die Antwort auf eine Messung: ein worker konnte zuvor die Entgelte von Kolleginnen ändern, geschlossen am 08.09.2026. Vertragsanlage und -änderung super-admin-gebunden; Vertragsdatei in EU-S3; Änderungen im Aktivitätsprotokoll. |
| Verantwortlichkeit | Tenant = Verantwortlicher (Arbeitgeber). NexDeck/Kre8ive Evolution = Auftragsverarbeiter (Art. 28). NexDeck beurteilt keinen Vertragsinhalt. |
| Betroffeneninformation | Pflicht des Mandanten nach Art. 13 DSGVO gegenüber seinen Beschäftigten; NexDeck stellt die Beschäftigten-Informationsseite bereit, erteilt die Information aber nicht selbst. |
| Offen | Die beiden offenen Felder (notes, certificates) sind heute kein praktischer Weg für Art.-9-Daten, weil keine Oberfläche sie führt und die Anwendung sie nicht schreibt. 🔴 Sobald jemand eine Eingabemaske dafür baut, entsteht der Weg — dann gehört ein Hinweis daneben. Als Auflage hier festgehalten, damit die Entscheidung nicht durch Bauen entsteht. ⚠️ Anwaltlich zu klären: § 5a Abs. 4 der Vertragsfassungen erlaubt den Abzug der Zahlungsgebühr von der Provisionsbasis; ihre Höhe steht bei Unterschrift nicht fest und wird nirgends erfasst — für einen Arbeitsvertrag ist die Bestimmtheit nach § 307 Abs. 1 S. 2 BGB die schärfere Frage. |
V-30 — Geschäftskorrespondenz der Zentrale über Google Workspace (2026-09-10)
Live-VVT-Eintrag. Er schliesst dieselbe Art Lücke wie V-25, nur andersherum: bei Qonto wurde ein AVV gesucht, wo ein Verfahren fehlte. Hier gab es den AVV — geschlossen am 10.09.2026 — aber weder ein Verfahren noch einen Subprozessor-Eintrag. Grund: die Dokumentation kannte Google Workspace bisher nur in der Tenant-Rolle (ein Mandant bindet sein eigenes Postfach an; dort ist Google eigenständiger Verantwortlicher). Dass der Betreiber seit dem 09.09.2026 selbst ein Workspace für
nexdeck.debetreibt, war nirgends erfasst.🔴 Anders als bei Qonto ist Google hier Auftragsverarbeiter. Ein Mailprovider, der Postfächer im Auftrag betreibt, verarbeitet weisungsgebunden — nicht in Erfüllung eigener gesetzlicher Pflichten. Deshalb gehört dieser Eintrag zusätzlich in die Subprozessorenliste: über die Postfächer der Zentrale läuft auch die Korrespondenz mit Mandanten und deren Kunden.
| Feld | Inhalt |
|---|---|
| Nummer | V-30 |
| Bezeichnung | E-Mail-Postfächer der NexDeck-Zentrale (Google Workspace, Domain nexdeck.de) |
| Zweck | Empfang und Versand der Geschäftskorrespondenz des Betreibers: Support- und Störungsmeldungen, Vertriebsanfragen, Rechnungs- und Mahnvorgänge, Datenschutz- und Betroffenenanfragen, Sicherheitsmeldungen, Schriftverkehr mit Behörden, Steuerberatung, Anbietern und Bewerbern. |
| Rechtsgrundlagen | Art. 6 Abs. 1 lit. b DSGVO (Anbahnung und Durchführung des Vertrags mit dem Mandanten), lit. c (handels- und steuerrechtliche Aufbewahrung von Handelsbriefen, §§ 238, 257 HGB, §§ 145 ff. AO; Beantwortung von Betroffenenanfragen nach Art. 12 ff. DSGVO) und lit. f (Beantwortung sonstiger Anfragen, Abwehr von Missbrauch). |
| Betroffene | Mandanten und deren Beschäftigte; Endkunden der Mandanten, soweit sie sich unmittelbar an die Zentrale wenden; Interessenten; Vertriebspartner; Lieferanten und Dienstleister; Behörden- und Kanzleimitarbeitende; Bewerbende. |
| Datenkategorien | Inhalt und Metadaten der E-Mails (Absender, Empfänger, Betreff, Text, Anhänge, Zeitstempel), Name und Kontaktdaten der schreibenden Person sowie alles, was sie von sich aus mitteilt — je nach Anliegen Vertrags-, Rechnungs-, Störungs- oder Beschäftigtenangaben. Ein Postfach ist inhaltlich nicht vorab begrenzbar; die Kategorien richten sich nach dem, was Dritte schreiben. |
| Empfänger / Drittland | Google Ireland Limited als Auftragsverarbeiter; Cloud Data Processing Addendum (Art. 28 DSGVO) angenommen am 10.09.2026 durch grundmeyer@nexdeck.de, EU-Datenschutzrecht ausdrücklich als anwendbar bestätigt. Übermittlung in Drittländer auf Grundlage der EU-Standardvertragsklauseln und der DPF-Zertifizierung des Mutterkonzerns. Beleg: (intern dokumentiert). |
| Löschfristen | E-Mails, die Handelsbriefe sind (Angebote, Auftragsbestätigungen, Rechnungen, Mahnungen), unterliegen § 257 HGB und § 147 AO. Sonstige Korrespondenz wird gelöscht, sobald der Vorgang erledigt und keine Aufbewahrungspflicht einschlägig ist. 🔴 Ein Löschkonzept für die Postfächer der Zentrale steht noch aus — siehe „Offen". |
| TOMs | Anmeldung nur personengebunden mit zweitem Faktor. Kein Einsatz von App-Passwörtern. Transportverschlüsselung; SPF, DKIM und DMARC auf nexdeck.de gesetzt. Zugriff auf die Postfächer nur durch den Geschäftsführer. |
| Verantwortlichkeit | Kre8ive Evolution UG (haftungsbeschränkt) = Verantwortlicher. Google Ireland Limited = Auftragsverarbeiter nach Art. 28. |
| Abgrenzung | Betrifft die Postfächer der Zentrale auf nexdeck.de. Nicht erfasst: der Mailversand der Anwendung (AWS SES, siehe Subprozessorenliste), der Mailempfang der Anwendung (SES-Inbound auf inbound.nexdeck.de, V-20) und Postfächer, die ein Mandant selbst anbindet (dort ist Google eigenständiger Verantwortlicher, OAuth-Eintrag der Subprozessorenliste). |
| Offen | 🔴 Aufbewahrung und Löschung der Zentral-Postfächer sind noch nicht geregelt — anders als bei den Mandantendaten, wo das Löschkonzept 72 Anker kennt. Zu klären: welche Ordner als Handelsbriefe gelten, wie lange sonstige Korrespondenz bleibt, und ob eine Archivierung eingerichtet wird. Vor dem Go-Live zu entscheiden. |
V-29 — Interessentendaten im Vertriebspartner-Kanal (Zuteilung und Eigenakquise) (2026-09-08)
| Feld | Wert |
|---|---|
| Nummer | V-29 |
| Bezeichnung | Erfassen, Zuteilen und Bearbeiten von Interessentendaten im Vertrieb über selbstständige Handelsvertreter (§ 84 HGB) im Mandanten des Betreibers (T6) |
| Zweck | Anbahnung von Verträgen über die NexDeck-Plattform: der Betreiber teilt eigene Anfragen einem Handelsvertreter zur Bearbeitung zu (Fall A); der Handelsvertreter erfasst daneben selbst ausgewählte Kontakte und meldet dem Betreiber daraus entstehende Geschäfte (Fall B). Dazu die Abrechnung der Provision. |
| Rechtsgrundlage | Fall A: Art. 6 Abs. 1 lit. b DSGVO (Anbahnung auf Anfrage der betroffenen Person) bzw. lit. f für die Ansprache im B2B-Bereich, mit § 7 UWG als Grenze der Kontaktaufnahme. Fall B: Rechtsgrundlage bestimmt der Handelsvertreter als Verantwortlicher; der Betreiber verarbeitet insoweit weisungsgebunden nach Art. 28. Für die Registrierung des Geschäfts und die Abrechnung: Art. 6 Abs. 1 lit. b (Vertriebsvertrag) und lit. c i. V. m. § 147 AO / § 257 HGB. |
| Betroffene | Ansprechpersonen bei Interessenten-Unternehmen; daneben die Handelsvertreter selbst (Zuordnung, Provision — dort siehe V-25 für die Auszahlung). |
| Datenkategorien | leads: Firmenname, Ansprechperson (Vor-/Nachname), E-Mail, Telefon, Anschrift, Branche, Quelle, geschätzter Wert, Notizen, Status, Zuteilung an Person und an Partnerbetrieb sowie datenherkunft ('unternehmer' oder 'partner'). 🔴 Bei Fall B trägt der Lead im Bestand des Betreibers weder Ansprechperson noch E-Mail-Adresse, wenn er aus einem Angebot entsteht — dort stehen nur Firmenname und Vertragsbezug. cpq_quotes trägt für den Vertragsschluss Name und E-Mail der Ansprechperson. |
| Empfänger | Der zugeordnete Handelsvertreter. Innerhalb des Betreibers bei Fall B nur Inhaber, Administrator, Backoffice und der Plattformbetrieb (is_super_admin) — durchgesetzt durch die RESTRICTIVE-Policy leads_partner_herkunft_select (Migration 34995000). Bei Fall A die Rollen mit leads:view nach der Berechtigungsmatrix. Keine externen Empfänger. |
| Drittland-Transfer | Keiner. Supabase EU (Frankfurt). |
| Löschfristen | Wie für Leads insgesamt: Anonymisierung verlorener Leads nach der je Mandant eingestellten Frist (Vorgabe 90 Tage), im Übrigen das Löschkonzept ((intern dokumentiert)). Für Fall B bestimmt die Frist der Handelsvertreter als Verantwortlicher, soweit die Plattform sie ihm nicht vorgibt — die mandantenweite Vorgabe der Plattform gilt technisch auch für seine Datensätze. |
| TOMs | Kennzeichen leads.datenherkunft mit CHECK-Bedingung; Trigger leads_herkunft_riegel (Herkunft nach dem Anlegen unveränderlich, ein Partner-Lead braucht seinen Partnerbetrieb, keine Zuteilung an andere); RESTRICTIVE-Policy leads_partner_herkunft_select; Berechtigung leads:view_partner in der Matrix, mit einem Test gegen die Rollenliste der Datenbank abgeglichen; reduzierte Übernahme beim Angebot (weder Name noch E-Mail der Ansprechperson wandern in den Bestand des Betreibers); Hinweis an der Lead-Karte für die Personen, die den Datensatz sehen dürfen. |
| Verantwortlichkeit | Fall A: Kre8ive Evolution UG (haftungsbeschränkt) = Verantwortliche, der Handelsvertreter = Auftragsverarbeiter (Art. 28 — der Vertrag dazu ist noch zu schließen, siehe „Offen"). Fall B: der Handelsvertreter = Verantwortlicher, die UG = sein Auftragsverarbeiter. 🔴 Der Plattform-AVV traegt das NICHT: er bestimmt seinen Auftraggeber als „den Kunden/Mandanten, der die NexDeck-Plattform nutzt (jeweiliger Tenant)", und der Handelsvertreter ist kein Mandant, sondern ein Profil INNERHALB von T6 ohne eigenes Abonnement. Fuer Fall B ist deshalb ein eigener Vertrag nach Art. 28 zu schliessen, in dem der Handelsvertreter Auftraggeber ist (§ 11 Abs. 5 lit. b der Fassungen V1 bis V3). Gefunden im Dreifach-Audit vom 08.09.2026 — die urspruengliche Fassung dieses Eintrags behauptete eine Grundlage, die es nicht gibt. 🔴 Die Einordnung erfolgt je Vorgang, nicht pauschal; eine gemeinsame Verantwortlichkeit nach Art. 26 wird nicht angenommen. Begründung und Quellen: (intern dokumentiert); vertraglich: § 11 Abs. 5 bis 7 der Fassungen V1 bis V3, für den Tippgeber § 8 Abs. 4 der Fassung V4. |
| Betroffeneninformation | Art. 14 DSGVO, weil die Daten nicht bei der betroffenen Person erhoben werden: spätestens bei der ersten Kontaktaufnahme. Bei Fall A trifft die Pflicht die UG, bei Fall B den Handelsvertreter. § 33 BDSG nimmt gewerbliche Ansprache davon nicht aus (am amtlichen Text geprüft 08.09.2026). Die Auskunft nach Art. 15 kann für einen einzelnen Lead im System erzeugt werden. |
| Offen | ✅ Beide AVV sind am 08.09.2026 geschrieben und in den Vertragsweg eingebaut ((intern dokumentiert) und AVV-B_…md, Anlagen 3a und 3b): sie werden mit dem Vertriebsvertrag vorgelegt, stehen im selben Annahmetext und im selben PDF. 🔴 Damit ist NICHT erledigt: sie sind Entwürfe und stehen wie die Vertriebsverträge selbst unter dem Vorbehalt, dass niemand sie anwaltlich geprüft hat. ⚠️ Anwaltlich zu klären: die Rollenaufteilung selbst ist eine Einordnung des Betreibers ohne anwaltliche Prüfung (Betreiber-Entscheidung 08.09.2026); die Auslöser, unter denen sie neu zu prüfen ist, stehen in A6. Ebenfalls offen: für Fall B gibt die Plattform die Löschfristen mandantenweit vor — der Handelsvertreter kann sie als Verantwortlicher nicht abweichend setzen. |
V-31 — Lohnstammdaten und Lohnvorbereitung (2026-09-17)
| Feld | Wert |
|---|---|
| Nummer | V-31 |
| Bezeichnung | Lohnstammdaten, Art-9-Merkmale, Sachbezüge und die Zusammenstellung des Monatspakets für die Steuerkanzlei |
| Zweck | Der Arbeitgeber hält die Angaben vor, die für das Lohnkonto (§ 41 Abs. 1 EStG i. V. m. § 4 LStDV), für die Meldungen und Entgeltunterlagen zur Sozialversicherung (§ 28a SGB IV, § 8 BVV) und für die Auszahlung gebraucht werden, stellt sie je Monat zusammen und übergibt sie der Steuerkanzlei, die daraus die Lohnabrechnung erstellt. Dazu die Nebenzwecke: Eintrittsbogen (welche Angabe für die Abrechnung noch fehlt), Sofortmeldung nach § 28a Abs. 4 SGB IV, Freigrenze der Sachbezüge nach § 8 Abs. 2 S. 11 EStG, Kontrolle der Zahlungsdatei vor der Überweisung. 🔴 NexDeck rechnet keinen Lohn ab und meldet an keine Behörde und keine Krankenkasse. |
| Rechtsgrundlage | Art. 6 Abs. 1 lit. c DSGVO i. V. m. § 41 Abs. 1 EStG, § 4 LStDV, § 28a und § 28f SGB IV (gesetzliche Aufzeichnungs- und Aufbewahrungspflicht des Arbeitgebers) sowie Art. 6 Abs. 1 lit. b DSGVO (Durchführung des Arbeitsverhältnisses), jeweils i. V. m. der Fachnorm. Für die Art-9-Merkmale: Art. 9 Abs. 2 lit. b DSGVO i. V. m. § 26 Abs. 3 BDSG — Konfession trägt die Kirchensteuer (§ 51a EStG), Schwerbehinderung und Gleichstellung tragen die Anzeige nach § 163 SGB IX. Die Elterneigenschaft ist keine besondere Kategorie; sie trägt den Beitragszuschlag nach § 55 Abs. 3 SGB XI und die Abschläge nach § 55 Abs. 3 SGB XI i. V. m. § 55a Abs. 9 SGB XI — Art. 6 Abs. 1 lit. c DSGVO. 🔴 Seit 23.09.2026 ohne § 26 Abs. 1 BDSG (EuGH C-34/21, wie AVV § 2.1 und V-33; Herleitung F4). |
| Betroffene | Beschäftigte, auch ausgeschiedene, solange die Frist läuft. Bestand am 17.09.2026 gemessen: 19 Personalprofile über alle Mandanten — und null Zeilen in employee_payroll_data, employee_special_category_data, sachbezuege und lohn_uebergaben. Die Verarbeitung ist gebaut und erreichbar; sie hat noch keinen Bestand. |
| Datenkategorien | Am Schema erhoben, nicht geschätzt (17.09.2026). employee_payroll_data (34 Spalten): Geburtsdatum, Geburtsort, Staatsangehörigkeit, Steuer-Identifikationsnummer, Steuerklasse, Kinderfreibeträge, Faktor, Sozialversicherungsnummer, Krankenkasse samt Betriebsnummer, IBAN, BIC, Kontoinhaber, Anschrift (Straße, PLZ, Ort, Land), Ersteintrittsdatum, Personengruppenschlüssel, Beschäftigungsart und Befristung, UV-Gefahrtarifstelle, SOKA-Bau-Nummer, erstes Dienstverhältnis, weitere Beschäftigungen, Vorbeschäftigung im Kalenderjahr, VWL (Empfänger, Betrag, Vertragsnummer). sachbezuege: Monat, Art, Betrag, Abgabetag und Abgabeort (§ 4 Abs. 2 Nr. 3 LStDV), Entgelt, Zusätzlichkeitsmerkmal, Gutschein-Merkmal, Bemerkung. lohn_uebergaben: Monat, Laufnummer, Umfang als Zähler und Summen, offene Punkte, Bemerkung, Freigabe- und Versandvermerk samt Empfänger-Hash. lohndatei_pruefungen / lohndatei_empfaenger: Dateiname, Zeilenzahl, Summe, Ampel, Befunde — je Zeile Betrag, zugeordnete Person und die Empfänger-IBAN. Ergänzt 23.09.2026 (Migrationen 36550000, 36560000): lohn_monatsbuchungen mit den Arten Zusatzzahlung, Vorschuss, Vorschuss-Verrechnung, Überstundenabgeltung, Überstundenzuschlag (Prozentsatz) und Arbeitgeberdarlehen (Auszahlung, Tilgung, Restschuld, vereinbarter Zinssatz — die Einordnung eines Zinsvorteils als Sachbezug trifft die Kanzlei); mindestlohn_ausnahmen (Grund, Gültig-ab, Rücknahme); tarif_mindeststundensaetze: vom Betrieb hinterlegter tariflicher Mindeststundensatz mit Bezeichnung und Gültig-ab (append-only, Aufhebung mit Grund). |
| 🔴 Besondere Kategorien (Art. 9) | employee_special_category_data — Konfession, Schwerbehinderung samt Grad und Gleichstellung. Sie liegen in einer eigenen Tabelle hinter einer engeren Schranke als die übrigen Lohnmerkmale (siehe TOMs); V-28 verweist für sie hierher. Ebenfalls in dieser Tabelle, aber keine besondere Kategorie: die Elterneigenschaft samt Zahl der Kinder unter 25 und Nachweisart (so auch AVV § 2.1 seit 2026-09-23.2). Sie bleibt bewusst hinter der engeren Schranke: sie berührt das Familienleben, und die engere Schranke ist die Vorgabe, die man begründet lockern kann, nicht umgekehrt. |
| Empfänger | Die Steuerkanzlei — und zwar auf zwei Wegen, die getrennt zu betrachten sind. (1) E-Mail mit dem Übergabeblatt als PDF, gebunden an die protokollierte Übergabe: nur an eine Adresse aus tenant_settings.tax_advisor_email_whitelist, höchstens fünf Versendungen je Tag und Mandant, der Empfänger wird als Hash vermerkt. Das Blatt trägt Zähler, Summen und offene Punkte — keine Einzelangaben zu Personen. (2) Die sechs CSV-Dateien des Monatspakets, die der Betreiber von Hand herunterlädt und übergibt; die Stammdatendatei trägt Personalnummer, Name, Steuer-ID, Steuerklasse, Kinderfreibeträge, Krankenkasse und IBAN. 🔴 Art-9-Merkmale gehen auf keinem der beiden Wege hinaus — am Code gemessen (17.09.2026): Konfession, Schwerbehinderung und Gleichstellung kommen im Monatspaket, im Übergabeblatt und in der Mail an keiner Stelle vor; der Eintrittsbogen nennt zur Elterneigenschaft ausschließlich, ob eine Antwort vorliegt, nie welche. Sonstige externe Empfänger: keine. Innerhalb des Mandanten siehe TOMs. |
| Drittland-Transfer | Keiner. Supabase EU (Frankfurt), Dateiablage AWS S3 EU (Frankfurt), Mailversand AWS SES EU (Frankfurt). |
| Löschfristen | Alle Tabellen 72 Monate, Norm § 41 Abs. 1 Satz 9 EStG (für die Sachbezüge zusätzlich § 4 Abs. 2 Nr. 3 LStDV, für die Art-9-Merkmale zusätzlich § 163 Abs. 1 SGB IX), Klasse nachweis_sonstig — also kein Löschlauf, sondern eine Freigabe zur Prüfung. Anker: employee_payroll_data, employee_special_category_data und sachbezuege erben den Anker des Personalprofils (employee_profiles.end_date) — ein laufendes Arbeitsverhältnis hat kein fristauslösendes Ereignis und wird nicht freigegeben. 🔴 Ausdrücklich nicht created_at und ausdrücklich nicht der abgabetag des Sachbezugs: der ist der Tag des Vorteils, nicht der der letzten Lohnzahlung. lohn_uebergaben hängt an erzeugt_am (die Übergabe IST das Ereignis), lohndatei_pruefungen an geprueft_am, lohndatei_empfaenger an seiner Prüfung. ⚠️ Für die Art-9-Merkmale gilt: sie rechtfertigen keine kürzere Frist als das Lohnkonto, an dem sie hängen — aber auch keine längere. ⚠️ § 28f Abs. 1 SGB IV kann die tatsächliche Aufbewahrung im Einzelfall verlängern; die Klassen tragen dafür das Kennzeichen svPruefungBindet. |
| TOMs | RLS-Isolation je Mandant (PERMISSIVE). Darüber zwei getrennte, engere Schranken als RESTRICTIVE-Policies: current_user_darf_lohnstammdaten() für die Lohnmerkmale und die Sachbezüge, current_user_darf_art9_personaldaten_sehen() für die Art-9-Merkmale — Letztere lässt nur Inhaber oder Super-Admin zu (oder einen ausdrücklichen Einzelvermerk personal:art9). Ein admin mit team:manage pflegt also die Bankverbindung und sieht das Kirchensteuermerkmal trotzdem nicht. Die betroffene Person liest den eigenen Satz. employee_payroll_data und employee_special_category_data sind append-only (DELETE-Policy false); der auditor_viewer ist auf allen vier Tabellen für SELECT, INSERT, UPDATE und DELETE ausgeschlossen. Der Versand an die Kanzlei hängt durch Konstruktion an der protokollierten Übergabe: ohne Freigabe kein Versand, ohne Blatt kein Versand, kein Versandvermerk ohne Versand. 🔴 Die Schranken liegen in der Datenbank, nicht nur in den Server-Actions — service_role trägt BYPASSRLS, und eine Regel allein in der Action gilt für den zweiten Schreiber nicht. |
| Verantwortlichkeit | 🔴 Zwei Rollen, je nach Mandant. Für die eigenen Beschäftigten der Kre8ive Evolution UG (Mandant „NexDeck Zentrale") ist die UG Verantwortliche nach Art. 30 Abs. 1 — dieser Eintrag ist insoweit ein Eintrag in eigener Sache, und nur dort sind das Monatspaket, die Übergabe und der Versand an die Kanzlei überhaupt freigeschaltet. Für die Beschäftigten anderer Mandanten ist der Mandant Verantwortlicher und die UG Auftragsverarbeiterin nach Art. 28; erreichbar sind dort die Maske für die Lohnstammdaten samt Art-9-Merkmalen und die Sachbezüge, nicht aber die Übergabe an eine Kanzlei. |
| Betroffeneninformation | Für T6 trifft die Pflicht nach Art. 13 die UG selbst; die Beschäftigten-Informationsseite ist bereitgestellt. Für die übrigen Mandanten trifft sie den Mandanten als Arbeitgeber. 🔴 Bei den Art-9-Merkmalen ist die Information kein Nebenpunkt: sie sind der Teil, den die betroffene Person am ehesten nicht erwartet. |
| Offen | ✅ Erledigt 18.09.2026, zwei der drei Punkte vom 17.09.: (1) Der AVV nennt die Datenkategorien seit der Fassung 2026-09-17 in § 2.1 — Lohnvorbereitung, Steuer-Identifikationsnummer, Steuerklasse, Sozialversicherungsnummer, Krankenkasse, Bankverbindung und die Art-9-Merkmale (Konfession, Schwerbehinderung, Elterneigenschaft). (2) Die Lohndatei-Prüfung speichert die Empfänger-IBAN nicht mehr im Klartext, sondern als versionierten Kennwert (lohndatei_empfaenger.iban_kennwert, kennwert_version). ⚠️ Weiter offen, anwaltlich zu klären: ob § 26 Abs. 3 BDSG die Erhebung der Elterneigenschaft im Beschäftigungsverhältnis ohne gesonderte Einwilligung trägt, wenn der Beitragszuschlag der einzige Zweck ist. |
V-32 — Abwesenheiten (Urlaub, Krankheit, Elternzeit) (2026-09-18)
| Feld | Wert |
|---|---|
| Nummer | V-32 |
| Bezeichnung | Abwesenheitsanträge und genehmigte Abwesenheiten der Beschäftigten |
| Zweck | Urlaubs- und Einsatzplanung (wer ist wann nicht verfügbar), Genehmigung durch die Leitung, Entgeltfortzahlung und Lohnvorbereitung. Beschäftigte stellen den Antrag selbst (mobil unter /zeit/abwesenheit oder im Büro), die Leitung entscheidet; Antragsteller und Leitung werden benachrichtigt. |
| Rechtsgrundlage | Art. 6 Abs. 1 lit. b DSGVO (Durchführung des Arbeitsverhältnisses) und lit. c (Entgeltunterlagen, § 28f Abs. 1 SGB IV; Lohnkonto, § 41 Abs. 1 EStG). Für die Art der Abwesenheit „Krankheit" (Gesundheitsdatum): Art. 9 Abs. 2 lit. b DSGVO i. V. m. § 26 Abs. 3 BDSG. „Elternzeit" ist keine besondere Kategorie, wird aber gleich geschützt (siehe unten). 🔴 Seit 23.09.2026 ohne § 26 Abs. 1 BDSG (EuGH C-34/21). |
| Betroffene | Beschäftigte der Mandanten, auch ausgeschiedene, solange die Frist läuft. |
| Datenkategorien | Am Schema erhoben (18.09.2026). employee_time_off: Person (Zugang), Art (vacation, sick, training, parental, unpaid, other), erster und letzter Tag, halber erster/letzter Tag, Status (offen, genehmigt, abgelehnt, storniert), freie Notiz, entscheidende Person und Zeitpunkt. Keine Diagnose — die Anwendung fragt keine ab; die freie Notiz kann aber Angaben enthalten, die die Person selbst hineinschreibt. Altbestand: leave_requests (nicht mehr beschrieben, bleibt bis Fristablauf). Ergänzt 23.09.2026: urlaub_mitwirkungshinweise (Migration 36550000): vom Betrieb hinterlegt, wann und in welcher Form er zur Urlaubsnahme aufgefordert und auf den Verfall hingewiesen hat (BAG 19.02.2019 – 9 AZR 423/16), append-only, Widerruf mit Grund; user_availability_exceptions: von der Person selbst gemeldete Tage (ganz/zeitweise nicht/nur von–bis) ohne Grund-Feld, sichtbar für die Einsatzplanung. |
| 🔴 Besondere Kategorien (Art. 9) | Die Art ist bei „Krankheit" ein Gesundheitsdatum; bei „Elternzeit" ist sie keine besondere Kategorie, berührt aber das Familienleben und steht hinter derselben Sperre; die Notiz kann Gesundheitsangaben enthalten. Beide sind für Kolleg:innen nicht lesbar (siehe TOMs). |
| Empfänger | Innerhalb des Mandanten: die Person selbst und die Leitung (owner, admin, manager) mit Art und Notiz — 🔴 Betreiber-Entscheidung 23.09.2026 (Audit AW.5A, A14): bewusst so, die Freigabe je Schutzkategorie der Personalakte gilt hier nicht; Vorgesetzte planen Vertretung und Rückkehr. Die Eingabemasken sagen, wer die Notiz sieht, und bitten, keine Diagnosen einzutragen; alle übrigen Mitglieder nur „abwesend" samt Zeitraum, soweit die Einsatzplanung es braucht. Extern: nur beim Mandanten „NexDeck Zentrale" die Steuerkanzlei, und zwar über die Fehlzeiten-Datei des Monatspakets (V-31). Sonst keine. |
| Drittland-Transfer | Keiner. Supabase EU (Frankfurt), Benachrichtigungen per Web-Push bzw. In-App. |
| Löschfristen | 72 Monate, Norm § 41 Abs. 1 Satz 9 EStG · § 28f Abs. 1 SGB IV, Klasse nachweis_sonstig (Freigabe zur Prüfung, kein automatischer Löschlauf), Anker end_date — der letzte Tag der Abwesenheit, nicht der Antragstag. svPruefungBindet: eine späte Betriebsprüfung kann die Aufbewahrung im Einzelfall verlängern. |
| TOMs | Mandantentrennung per RLS; der auditor_viewer ist ausgeschlossen. Art und Notiz sind für authenticated auf Spaltenebene gesperrt (Migration 35870000); gelesen wird über abwesenheiten_im_mandanten() (Migration 35860000), die sie nur der Person selbst, der Leitung und dem Super-Admin liefert, allen anderen absent und keine Notiz. Serverseitige Leser mit service_role maskieren nach derselben Regel (canSeeTypeFor). Die Benachrichtigung an die Leitung über einen neuen Antrag nennt die Art nicht. Einzelheiten TOM § 7.11. |
| Verantwortlichkeit | Der Mandant als Arbeitgeber ist Verantwortlicher, die UG Auftragsverarbeiterin (Art. 28). Für die eigenen Beschäftigten (Mandant „NexDeck Zentrale") ist die UG selbst Verantwortliche nach Art. 30 Abs. 1. |
| Betroffeneninformation | /privacy/employees (Stand 18.09.2026) nennt Art, Zweck, Rechtsgrundlage, Sichtbarkeit und Speicherdauer. Für die übrigen Mandanten trifft die Pflicht nach Art. 13 den Mandanten. |
| 🔴 Vorfall, festgehalten | Die Spaltensperre für Art und Notiz bestand seit Mai 2026 (Migration 20260513210000). Am 03.09.2026 gab Migration 34380000 die ganze Tabelle wieder frei, weil sie die Spaltenrechte für einen fehlenden Tabellen-Grant hielt. Bis zum 18.09.2026 konnten angemeldete Mitglieder eines Mandanten Art und Notiz der Abwesenheiten ihrer Kolleg:innen über die Programmierschnittstelle abrufen — gemessen in einer zurückgerollten Transaktion. Gemessen am 18.09.2026: in der gesamten Datenbank steht keine einzige Abwesenheit mit Art „Krankheit" oder „Elternzeit". Betreiber-Einordnung vom selben Tag: alle Mandanten außer „NexDeck Zentrale" sind Testmandanten, und dort ist der Betreiber selbst die einzige beschäftigte Person. Es gab also nichts, das hätte offengelegt werden können; eine Meldung nach Art. 33 DSGVO entfällt mangels Verletzung. |
V-33 — Personalakte, Fristen-Erinnerungen und Unterweisungen (2026-09-22)
| Feld | Wert |
|---|---|
| Nummer | V-33 |
| Bezeichnung | Dokumente der Personalakte, Fristen je beschäftigter Person, Unterweisungen im Arbeitsschutz samt Kenntnisnahme, Einsichtsprotokoll, Vermerke über Ein- und Austrittsschritte |
| Zweck | Der Arbeitgeber führt die Personalakte, überwacht Fristen (Probezeit, Befristung, sechs Monate seit Eintritt, Gültigkeit von Nachweisen) und weist nach, dass er unterwiesen hat (§ 12 ArbSchG, § 4 Abs. 1 DGUV Vorschrift 1). 🔴 NexDeck bewertet nichts — die Erinnerungen nennen Datum und Anlass und keine Rechtsfolge; die Kenntnisnahme in der App ist keine Unterschrift. |
| Rechtsgrundlage | Art. 6 Abs. 1 lit. b DSGVO (Durchführung des Arbeitsverhältnisses) und lit. c (Aufzeichnungspflichten des Arbeitgebers, u. a. § 12 ArbSchG, § 4 Abs. 1 DGUV V1, § 14 Abs. 2 GefStoffV, § 14 Abs. 3 BioStoffV, § 63 Abs. 6 StrlSchV), jeweils i. V. m. der Fachnorm. Für die Vorsorgebescheinigung: Art. 9 Abs. 2 lit. b DSGVO i. V. m. § 26 Abs. 3 BDSG und § 6 Abs. 3 Nr. 3 ArbMedVV. 🔴 Seit 23.09.2026 ohne den Zusatz „Art. 88 DSGVO i. V. m. § 26 Abs. 1 BDSG": nach EuGH C-34/21 (30.03.2023) trägt die allgemeine Klausel des Abs. 1 nur, soweit sie eine spezifischere Vorschrift nach Art. 88 ist; die Fachnormen tragen die Verarbeitung ohnehin. § 26 Abs. 3 für Art-9-Daten bleibt. ⚠️ F4-1. |
| Betroffene | Beschäftigte der Mandanten, auch ausgeschiedene, solange eine Frist läuft; zusätzlich Personen, die eine Unterweisung durchgeführt haben (Name als Freitext, auch externe Fachkräfte für Arbeitssicherheit). Bestand am 22.09.2026 gemessen: unterweisungen, unterweisung_teilnehmer, unterweisung_bestaetigungen je 0 Zeilen; die Verarbeitung ist gebaut und erreichbar, sie hat noch keinen Bestand. |
| Datenkategorien | Am Schema erhoben (22.09.2026). personalakte_dokumente: Datei samt Dokumentart (13 erlaubte Arten, CHECK aus Migration 35970000), Titel, Dokumentdatum, Gültigkeitsdatum, Dateiname, Größe, Prüfsumme, Fassung, Aufbewahrungsklasse, Anker, Prüftermin und dessen Entscheidung samt Begründung. employee_profiles: Eintrittsdatum, Probezeit (Dauer und Ende), Austrittsdatum. employment_contracts: Befristung. unterweisungen: Thema, Inhalt, Datum, unterweisende Person, vorgesehene Wiederholung, Angabe des Betriebs zur Unterschriftspflicht, Vermerk über das unterschriebene Papier (Datum, Ablageort), Rückzug samt Grund. unterweisung_teilnehmer: Zuweisung. unterweisung_bestaetigungen: Person, Zeitpunkt (Server), SHA-256 des gelesenen Textes. personalakte_einsichten: wer wann welches Dokument geöffnet hat. Ergänzt 23.09.2026 (AW.5e, Migration 36070000): checkliste_schritte: Bezeichnung, Hinweis und Phase eines Schritts, den der Betrieb sich selbst gibt (kein Personenbezug, gilt mandantenweit); checkliste_erledigungen: die betroffene Person, der Schlüssel des Schritts, der Tag der Erledigung (vom Menschen angegeben, rückwirkend möglich), eine freiwillige Notiz, Zeitpunkt und Urheber des Vermerks (vom Trigger gesetzt) sowie eine etwaige Rücknahme mit Grund. 🔴 Erfassbar sind nur die beiden Schritte, zu denen es sonst kein Feld gibt — An- und Abmeldung zur Sozialversicherung (§ 28a Abs. 1 SGB IV, erledigt die Steuerkanzlei) — und die eigenen Schritte des Betriebs. Die übrigen zehn Punkte der Ein-/Austrittsliste werden bei jedem Aufruf aus dem vorhandenen Bestand abgeleitet und nicht gespeichert. Ergänzt 23.09.2026 (Migration 36230000): an einem eigenen Schritt, für welche Rollen und Anstellungsarten er gilt (kein Personenbezug); an einem Vermerk die Art erledigt oder entfaellt — ein „entfällt" braucht eine Begründung in der Notiz und ist nur für eigene Schritte zulässig. Ergänzt 23.09.2026 (Migration 36510000): am Qualifikations- oder Befähigungsnachweis die Bestätigung der ablegenden Person samt Zeitpunkt, dass die Unterlage keine Untersuchungsergebnisse, Befunde oder Eignungsaussagen enthält, und eine zweite Bestätigung, wenn Titel oder Dateiname ein Warnwort tragen. |
| 🔴 Besondere Kategorien (Art. 9) | Die Vorsorgebescheinigung nach § 6 Abs. 3 Nr. 3 ArbMedVV („dass, wann, aus welchem Anlass"). Sie wird wie ein Gesundheitsdatum behandelt; eine Aussage zur rechtlichen Einordnung im Einzelfall ist damit nicht verbunden — keine amtliche Stelle ordnet sie ausdrücklich ein (Recherche 22.09.2026 mit Gegenprobe). Ausdrücklich gesperrt sind Arbeitsunfähigkeitsbescheinigung, Ergebnis und Befund der Vorsorge, Biomonitoring, Eignungsuntersuchung und Unterlagen des Eingliederungsmanagements (CHECK, Migration 35970000). 🔴 Grenze, ehrlich benannt: die Sperre wirkt auf die gewählte Dokumentart, nicht auf den Inhalt einer Datei. |
| Empfänger | Keine externen. Innerhalb des Mandanten: Inhaber und Administratoren (Akte und Unterweisungen; Gesundheits-, Bewertungs- und Entgeltunterlagen seit 23.09.2026 nur Inhaber und Administratoren mit Freigabe der Kategorie), die betroffene Person für das Eigene — mit einer Ausnahme: die Vermerke über Ein- und Austrittsschritte sehen ausschließlich Inhaber und Administratoren, nicht die betroffene Person selbst (Verwaltungsvorgang, kein Selbstauskunftsfeld; so auch im AVV benannt). Erinnerungen gehen als Glocke mit role_required: 'admin' heraus, die Zuweisung einer Unterweisung als Glocke an die betroffene Person selbst. |
| Drittland-Transfer | Keiner. Datenbank Supabase EU (Frankfurt); Dateien AWS S3, Bucket nexdeck-captures in eu-central-1, serverseitig mit AES-256 verschlüsselt, ohne öffentlichen Zugriff (gemessen 22.09.2026). |
| Löschfristen | Klasse nachweis_sonstig, kein automatischer Löschlauf. personalakte_dokumente: Frist je Zeile (Aufbewahrungsklasse, Anker, Prüftermin) — eine Abmahnung hat einen Prüftermin statt eines Löschdatums (BAG 2 AZR 782/11). personalakte_einsichten: 72 Monate (Art. 5 Abs. 2 DSGVO, § 22 Abs. 2 Nr. 5 BDSG). Unterweisungen: offene Frist, mit Begründung. Keine allgemeine Norm nennt eine Dauer; ausdrückliche Zahlen stehen nur in § 63 Abs. 6 StrlSchV (5 bzw. 1 Jahr) und TRGS 555 Nr. 5.3 Abs. 7 („mindestens zwei Jahre", nur Gefahrstoffe). Die Dauer wählt der Betrieb; seit dem 22.09.2026 kann er sie umsetzen (Löschweg mit Begründung, protokolliert). Ein-/Austrittsvermerke: Klasse nachweis_sonstig, kein automatischer Löschlauf. § 28f Abs. 1 SGB IV bindet Entgeltunterlagen an die nächste Betriebsprüfung und nennt damit kein Enddatum; für die selbst festgelegten Schritte gibt es gar keine Norm. Die Obergrenze setzt Art. 5 Abs. 1 lit. e DSGVO. 🔴 checkliste_schritte trägt selbst keine personenbezogenen Daten und wäre für sich genommen Inhaltsdatum — sie teilt die Frist der Vermerke trotzdem, weil diese mit ON DELETE CASCADE an ihr hängen: wer die Zeile löscht, löscht die Nachweise mit. Deshalb wird ein Schritt stillgelegt statt gelöscht. |
| TOMs | Mandantentrennung per RLS; der auditor_viewer ist auf allen drei Unterweisungstabellen für SELECT, INSERT, UPDATE und DELETE ausgeschlossen. Lesen der Akte: Inhaber/Administrator oder die eigene Zeile; kein DELETE über die Programmierschnittstelle. Unterweisungen sind nach dem Anlegen unveränderbar (Trigger), Zuweisungen und Kenntnisnahmen append-only über append_only_riegel — Trigger, nicht Policy, deshalb auch gegen service_role. 🔴 Bestätigen kann nur die zugewiesene Person, erzwungen über einen Fremdschlüssel auf die Zuweisung. 🔴 Das Einsichtsprotokoll ist fail-closed: scheitert der Protokolleintrag, gibt die Anwendung das Dokument nicht heraus (seit 22.09.2026; vorher wurde der Fehler nur geloggt). Löschen einer Unterweisung nur über loesche_unterweisung: Rolle, Mandant, Grund ≥ 10 Zeichen, Aufbewahrungssperre fail-closed, Eintrag in audit_logs in derselben Transaktion. Ein-/Austrittsvermerke (23.09.2026): nur owner/admin des eigenen Mandanten, der Prüfer für SELECT, INSERT, UPDATE und DELETE ausgeschlossen; die Zugehörigkeit der Person zum Mandanten hängt an einem zusammengesetzten Fremdschlüssel auf profiles (id, tenant_id) und hält damit auch gegen service_role. 🔴 Ein abgeleiteter Schritt ist nicht darstellbar: ein CHECK lässt genau zwei Schlüssel zu, weshalb kein zweiter Schreiber auf eine Tatsache entstehen kann, die das System bereits kennt. Vermerke sind append-only (Trigger), Zeitpunkt und Urheber setzt die Datenbank, eine Korrektur ist eine Rücknahme mit Grund. |
| Verantwortlichkeit | Der Mandant als Arbeitgeber ist Verantwortlicher, die UG Auftragsverarbeiterin (Art. 28; AVV § 2 Abs. 2.1 seit Fassung 2026-09-22, die Ein-/Austrittsvermerke seit Fassung 2026-09-23). Für die eigenen Beschäftigten (Mandant „NexDeck Zentrale") ist die UG selbst Verantwortliche nach Art. 30 Abs. 1. |
| Betroffeneninformation | Für T6 die Beschäftigten-Informationsseite; für die übrigen Mandanten trifft die Pflicht nach Art. 13 den Mandanten. Die betroffene Person sieht ihre Akte und ihre Unterweisungen selbst und kann eine Auskunft nach Art. 15 als Datei erzeugen — sie führt die drei Unterweisungstabellen seit dem 22.09.2026 mit. |
| Offen | ✅ Rechteschranke je Dokumentart seit 23.09.2026 (Migration 36200000): vier Schutzkategorien — Gesundheit/Vorsorge, Verhalten/Bewertung, Entgelt/Steuer (einschließlich „Sonstiges"), übrige Akte. Ein Administrator führt ohne Freigabe nur die übrige Akte; die drei anderen gibt der Inhaber je Person und Kategorie frei (personalakte_freigaben, append-only, Entzug statt Löschung). Öffnen von Gesundheits- und Bewertungsunterlagen: die Anwendung gibt die Datei nur nach einem Protokolleintrag mit Anlass heraus; einen Eintrag ohne Anlass weist ein Trigger ab (hält auch service_role). Die Datenbank selbst beschränkt den Zugriff auf Inhaber und Freigegebene — den Anlass verlangt sie beim Lesen der Dokumentzeile nicht (Stand 23.09.2026, Audit AW.5A). Erinnerungen nennen dort weder Art noch Titel. ✅ Vorsorgekartei und JArbSchG-Nachweise stehen jetzt in V-34. ⏳ Ob eine Kenntnisnahme in der App eine gesetzlich verlangte Unterschrift ersetzt, ist offen — deshalb der Weg über das unterschriebene Papier. |
V-34 — Vorsorgekartei und Nachweise nach dem Jugendarbeitsschutzgesetz (2026-09-23)
| Feld | Wert |
|---|---|
| Nummer | V-34 |
| Bezeichnung | Vorsorgekartei nach § 3 Abs. 4 ArbMedVV; Stichtag der ersten Beschäftigung und ärztliche Bescheinigungen nach §§ 32–35, 39 Abs. 2 JArbSchG; Abschluss je Person (Aushändigung, Übertragung an den Unfallversicherungsträger, Löschnachweis); Einsichtsprotokoll |
| Zweck | Der Arbeitgeber führt die Vorsorgekartei (dass, wann, aus welchem Anlass Vorsorge stattfand) und überwacht die Fristen der Erst- und Nachuntersuchung Jugendlicher. 🔴 NexDeck bewertet nichts — die Stichtage sind aus den erfassten Daten gerechnet, die Hinweise nennen Norm und Datum, keine Rechtsfolge im Einzelfall. |
| Rechtsgrundlage | Art. 6 Abs. 1 lit. c DSGVO i. V. m. § 3 Abs. 4 ArbMedVV bzw. §§ 32, 33, 41 JArbSchG; zusätzlich Art. 9 Abs. 2 lit. b DSGVO i. V. m. § 26 Abs. 3 BDSG (Behandlung als Gesundheitsdaten, strengere Lesart; EuGH C-667/21: Art. 9 und Art. 6 zugleich). ⚠️ F3-1. |
| Betroffene | Beschäftigte der Mandanten; bei den JArbSchG-Nachweisen Jugendliche (15 bis 17 Jahre). Bestand am 23.09.2026: alle fünf Tabellen 0 Zeilen. |
| Datenkategorien | vorsorgekartei: Tag, Art (Pflicht/Angebot/Wunsch, nachgehend nur bei Angebot — CHECK), Anlass als Tätigkeit, Fundstelle im Anhang, nächster Termin oder „offen". jarbschg_personen: Tag der ersten Beschäftigung überhaupt (T0), festgehaltener Grund nach § 32 Abs. 2. jarbschg_bescheinigungen: Art nach Anlage 4 JArbSchUV, Untersuchungs- und Vorlagetag, Gefährdungsvermerk mit Auswahl aus zwölf Arbeiten (CHECK) und Freitext „Sonstige", behördliche Zulassung, Aushändigungstag. hr_gesundheit_abschluesse: Aushändigung der Kopie, Einwilligung und Übertragung an den UV-Träger (nur Vorsorgekartei, nur mit Einwilligung — CHECK), Löschzeitpunkt. hr_gesundheit_einsichten: wer wann mit welchem Anlass eingesehen oder exportiert hat. 🔴 Keine Spalte für Befund, Diagnose, Eignung, „Bedenken", Impfstatus oder das wesentliche Ergebnis — die Migration prüft das bei der Anlage selbst. Das Geburtsdatum wird nicht abgeschrieben, sondern aus der Lohnakte gelesen. |
| 🔴 Besondere Kategorien (Art. 9) | Beides wird als Gesundheitsdatum behandelt (ErwG 35: auch Angaben über Krankheitsrisiken; EuGH C-21/23: ein mittelbarer Schluss genügt). Keine amtliche Stelle ordnet die beiden Bescheinigungen ausdrücklich ein (Recherche 23.09.2026). |
| Empfänger | Keine externen, außer auf Veranlassung des Mandanten: Kopie an die zuständige Behörde auf Anordnung (§ 3 Abs. 4 Satz 3 ArbMedVV, CSV-Export mit protokolliertem Anlass) und — nur mit Einwilligung — an den Unfallversicherungsträger (§ 5 Abs. 3 ArbMedVV). Innerhalb des Mandanten: Inhaber und Administratoren mit Freigabe „Gesundheit und Vorsorge", die betroffene Person für das Eigene. Erinnerungen nennen weder Person noch Art des Termins. |
| Drittland-Transfer | Keiner. Datenbank Supabase EU (Frankfurt). |
| Löschfristen | 🔴 Ereignisgebunden, automatisch. Vorsorgekartei: am Tag nach dem Ende der Beschäftigung (§ 3 Abs. 4 Satz 2 ArbMedVV; AMR 6.1 Nr. 2 Abs. 4 nimmt die Kartei aus der 40-Jahre-Regel aus). JArbSchG: zum früheren von Beschäftigungsende und 18. Geburtstag (§ 41 Abs. 1 JArbSchG). Täglicher Lauf hr_gesundheit_loeschlauf (03:30), Löschen und Löschnachweis in einer Transaktion; jedes DELETE außerhalb scheitert (Trigger, auch gegen service_role). Löschnachweis und Einsichtsprotokoll: 72 Monate ab Löschung bzw. Einsicht (Art. 5 Abs. 2 DSGVO). ⚠️ F1-1 (Aufschub bei Rechtsstreit), F1-2 (Nachweis ohne Inhalt), F2-2 (Löschung mit 18 bei fortbestehender Beschäftigung). |
| TOMs | RLS Kategorie G über personalakte_darf_kategorie; Prüfer ausgeschlossen; Person und Mandant einer Zeile fest (Trigger); Einsichtsprotokoll append-only, fremde Einsicht nur mit Anlass (CHECK); fail-closed: ohne Protokollzeile keine Daten — seit 23.09.2026 auch in der Datenbank (Lesen nur mit eigenem Protokolleintrag der letzten 60 Minuten, Migration 36250000). Funktion gesperrt, bis der Inhaber der AVV-Fassung 2026-09-23.2 zugestimmt hat (§ 11 Abs. 2 AVV). Wächter tests/compliance/gesundheitsnachweise-riegel.test.ts mit echten Schreibversuchen, mutationsgeprüft. |
| Verantwortlichkeit | Der Mandant als Arbeitgeber ist Verantwortlicher, die UG Auftragsverarbeiterin (AVV § 2.1 Buchstaben f und g seit Fassung 2026-09-23.2). Für die eigenen Beschäftigten (T6) ist die UG selbst Verantwortliche. |
| Betroffeneninformation | Pflicht des Mandanten nach Art. 13. Die Auskunft nach Art. 15 führt alle fünf Tabellen mit. |
| Offen | ✅ Seit 23.09.2026 (Migration 36240000): die Vorsorgebescheinigung in der Personalakte teilt die Löschung der Kartei — Titel, Dateiname und Bemerkung werden im selben Lauf überschrieben, die Datei danach in S3 gelöscht (alle Versionen); die inhaltsleere Zeile bleibt als Nachweis. ⏳ Die Einsatzplanung sieht keine abgeleitete Einsatzbeschränkung (F2-1, strengere Lesart bis zur Antwort). |