Datenschutzerklärung

1. Einleitung und Verantwortlicher

Wir nehmen den Schutz Ihrer persönlichen Daten sehr ernst. Wir behandeln Ihre personenbezogenen Daten vertraulich und entsprechend der gesetzlichen Datenschutzvorschriften (DSGVO) sowie dieser Datenschutzerklärung.

2. Welche Daten wir verarbeiten und warum

2.1 Beim Besuch der Webseite & Web-App

Beim Aufruf unserer Plattform werden durch unseren Hosting-Provider technisch notwendige Logfiles erfasst (IP-Adresse, Browser, Zeitstempel), um die Sicherheit und Stabilität des Systems zu gewährleisten.

Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (Berechtigtes Interesse an Sicherheit).

2.2 Bei Registrierung und Nutzung (SaaS)

Wir verarbeiten Bestandsdaten (Name, Firma, Adresse, E-Mail), die Sie bei der Registrierung angeben, sowie die Daten, die Sie im Rahmen der Nutzung in das System eingeben (Kundendaten Ihrer Endkunden, Projektdaten, Mitarbeiterdaten, Chat-Inhalte, Dokumente).

Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung).

2.3 Anmeldung über Drittanbieter (Social Login / OAuth)

Speicherung: Die übermittelten Daten werden in Ihrem NexDeck-Profil gespeichert. Wir speichern keine Passwörter der Drittanbieter. Die Authentifizierung erfolgt über sichere OAuth 2.0 Token, die verschlüsselt in unserer Datenbank abgelegt werden.

Anbieter und Datenschutz:

• Google: Google Ireland Limited, Gordon House, Dublin 4, Irland. Datenschutzerklärung
• Microsoft: Microsoft Ireland Operations Limited, Dublin, Irland. Datenschutzerklärung
• Apple: Apple Distribution International Ltd., Cork, Irland. Datenschutzerklärung

Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung) bzw. Art. 6 Abs. 1 lit. a DSGVO (Einwilligung durch aktive Auswahl des Login-Anbieters).

2.4 Mobile App (iOS & Android)

Unsere App nutzt Funktionen Ihres Endgeräts, jedoch nur nach Ihrer expliziten Freigabe:

• Kamera: Zur Erfassung von Baustellen-Fotos und Beleg-Scans.
• Standort (GPS) — Einzelabfrage (Foto-EXIF, Geotag): Beim bewussten Aufnehmen eines Fotos, Lieferscheins oder einer Fahrzeug-Inspektion erfassen wir optional die aktuelle Position als Metadatum. Einzel-Abfrage durch Sie ausgelöst, keine Hintergrund-Erfassung.
• Standort (GPS) — Zeiterfassung: Während aktiver Zeiterfassung kann Ihre Position kontinuierlich erfasst werden, wenn Sie den GPS-Schalter in der Zeiterfassung selbst aktivieren. Diese Funktionalität ist ein bereits bestehender Teil der App. Bei Deaktivierung des Zeiterfassungs-Timers stoppt automatisch auch das Positions-Tracking.
• Standort (GPS) — Workforce-Tracking (Pre-Go-Live Infrastruktur): Wir haben die Infrastruktur für kontinuierliches GPS-Tracking während Einsätzen vorbereitet (Session 17.3-B, Stand April 2026). Diese Funktion ist derzeit nicht verdrahtet — es fließen keine Live-GPS-Daten. Die Aktivierung setzt vor ihrer Nutzung voraus: (1) Ihr Arbeitgeber schaltet GPS tenant-weit frei und weist eine Betriebsratsvereinbarung nach (BetrVG § 87 Abs. 1 Nr. 6); (2) Sie erteilen in Ihrem Profil eine explizite, jederzeit widerrufbare Einwilligung (Art. 6 Abs. 1 lit. a DSGVO). Siehe auch Impressum für Kontaktdaten bei Rückfragen.
• LiDAR / Tiefensensoren: Zur Erstellung von Raumaufmaßen. Hierbei werden reine Distanzdaten verarbeitet, keine biometrischen Scans.
• Push-Benachrichtigungen:Um Sie über Statusänderungen (z.B. "Rechnung bezahlt", neuer Einsatz zugewiesen) zu informieren.

Rechtsgrundlage: Art. 6 Abs. 1 lit. a DSGVO (Einwilligung) bzw. lit. b (Vertragserfüllung). Für Mitarbeiter-bezogene Standortverarbeitungen zusätzlich § 26 BDSG und BetrVG § 87 Abs. 1 Nr. 6. Speicherdauer GPS-Live-Positionen: maximal 24 Stunden; aggregierte Fahrzeit-Statistik ohne Einzelkoordinaten: max. 90 Tage.

2.4a Kunden-Benachrichtigungen im Auftrag unserer Tenants

Als Auftragsverarbeiter unserer Tenants versenden wir optional Kunden- Benachrichtigungen (z.B. „Auf dem Weg"-Email mit Ankunftszeit), wenn der Monteur den entsprechenden Status setzt. Voraussetzung sind drei voneinander unabhängige Zustimmungen:

• Der Tenant hat den Email-Kanal tenant-weit aktiviert.
• Der Endkunde hat zuvor eine ausdrückliche Einwilligung in Terminbenachrichtigungen erteilt (opt-in, DSGVO Art. 6 Abs. 1 lit. a oder lit. b Vertragserfüllung).
• Der Versand fällt nicht in eine tenant-konfigurierte Ruhezeit (Default 20:00–07:00 Europe/Berlin).

Jede Benachrichtigung enthält einen funktionierenden Widerrufs-Link (Art. 7 Abs. 3 DSGVO). Email-Versand über AWS SES (Frankfurt) mit Audit-Log in activity_log. Speicherdauer Email-Metadaten: bis zu 10 Jahre (§ 147 AO / GoBD für Geschäftsbriefe).

2.5 Marketing, Vertrieb & Demos

Wenn Sie Interesse an unserem Produkt bekunden (z.B. über ein Kontaktformular, Demo-Buchung oder Newsletter-Anmeldung), verarbeiten wir Ihre Kontaktdaten, um Ihnen NexDeck vorzustellen.

• Newsletter: Der Versand erfolgt nur nach Ihrer expliziten Einwilligung (Double-Opt-In). Sie können sich jederzeit abmelden.
• CRM-System: Zur Verwaltung unserer Kundenbeziehungen speichern wir Lead-Daten in unserem internen CRM.

Rechtsgrundlage: Art. 6 Abs. 1 lit. a DSGVO (Einwilligung) bzw. Art. 6 Abs. 1 lit. f DSGVO (Berechtigtes Interesse bei B2B-Kontakten).

2.6 E-Mail-Tracking und Engagement-Analyse

Mandanten (Tenants) können optional E-Mail-Tracking für Geschäftsdokumente (Rechnungen, Angebote, Mahnungen) aktivieren. Tracking ist standardmäßig deaktiviert und erfordert eine explizite Aktivierung durch den Mandanten.

Erhobene Daten

• Zeitpunkt der E-Mail-Öffnung (opened_at)
• Anzahl der Öffnungen (open_count)
• Geklickte Links in E-Mails (URL, Zeitpunkt)
• IP-Adresse des Empfängers (nur bei aktivem Tracking)
• User-Agent des E-Mail-Clients

Rechtsgrundlage

Der Mandant wählt bei Aktivierung eine von zwei Rechtsgrundlagen:

• Einwilligung (Art. 6 Abs. 1 lit. a DSGVO):Tracking wird nur für Kontakte aktiviert, die ausdrücklich zugestimmt haben. Die Einwilligung wird mit Zeitstempel und Herkunft dokumentiert.
• Berechtigtes Interesse (Art. 6 Abs. 1 lit. f DSGVO):Im B2B-Bereich kann Tracking auf Basis einer dokumentierten Interessenabwägung für alle Empfänger aktiviert werden.

Transparenz

E-Mails mit aktivem Tracking enthalten einen Hinweis im Fußbereich mit Verweis auf diese Datenschutzerklärung.

Widerspruch und Opt-Out

• Für Mandanten:Tracking kann jederzeit in den Einstellungen unter "Dokumente → E-Mail-Tracking" deaktiviert werden.
• Für Empfänger: Kontaktieren Sie den absendenden Mandanten oder wenden Sie sich an support@nexdeck.de, um das Tracking für Ihre E-Mail-Adresse zu deaktivieren. Per-Kontakt-Einwilligungen können im CRM des Mandanten widerrufen werden.

Speicherdauer und Auftragsverarbeiter

Speicherdauer: Tracking-Daten werden so lange gespeichert wie das zugehörige Geschäftsdokument (10 Jahre für Rechnungen gemäß § 147 AO, 6 Jahre für Angebote/Geschäftsbriefe).
Auftragsverarbeiter: Unipile S.A.S. (Frankreich, EU) verarbeitet E-Mail-Tracking-Daten im Rahmen der bestehenden Auftragsverarbeitungsvereinbarung (AVV).

2.7 Kontakt-Synchronisation und Auto-Matching

Bei Verbindung externer Konten (E-Mail, LinkedIn, WhatsApp) werden Kontaktdaten automatisch mit bestehenden Kundendaten abgeglichen:

• E-Mail-Adresse (exakter Abgleich)
• Telefonnummer (normalisierter Abgleich)
• Firmenname (unscharfer Abgleich)

Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an effizienter Kundenverwaltung).
Es werden nur bereits im System vorhandene Daten abgeglichen. Es findet keine Anreicherung durch externe Dienste statt.

2.8 Automatisierte Lead-Bewertung (Lead Scoring)

Wir verwenden ein automatisiertes Bewertungssystem für Geschäftskontakte:

• Basisdaten (Vollständigkeit des Profils)
• Engagement (E-Mail-Antworten, Terminvereinbarungen, Angebote)
• Aktualität (Zeitraum seit letztem Kontakt)

Die Bewertung dient der Priorisierung von Vertriebsaktivitäten und hat keine rechtlichen Auswirkungen.

Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an effizienter Vertriebssteuerung).
Ihre Rechte nach Art. 22 DSGVO: Sie können der automatisierten Bewertung jederzeit widersprechen. Kontaktieren Sie uns dafür unter den in Abschnitt 1 genannten Kontaktdaten.
Das Lead Scoring kann pro Mandant in den Einstellungen deaktiviert werden.

2.8a Automatisierte Banking-Reconciliation (Bank-Transaktions-Abgleich)

Sofern Sie Ihr Bankkonto via Stripe Financial Connections verbunden haben (siehe Abschnitt zu Stripe Financial Connections weiter unten), führen wir einen automatisierten Abgleich Ihrer eingehenden Bank-Transaktionen mit offenen Rechnungen durch. Der Abgleich nutzt einen Score-basierten Algorithmus (Betragsmatch, Referenz-Erkennung in Buchungstext, Kunden-Name, Datum):

• Score 95–100: Auto-Match — Rechnung wird automatisch als bezahlt markiert (rechtswirksam: Mahnwesen-Worker überspringt diese Rechnung).
• Score 70–94: Vorschlag — wird im Banking-UI als manuelle Match-Empfehlung angezeigt.
• Score < 70: Keine Empfehlung — Transaktion bleibt unmatched.

Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung — Sie haben uns mit der automatisierten Rechnungs-Abgleichung beauftragt).
Ihre Rechte nach Art. 22 DSGVO (CJEU Schufa-Urteil 2023-12-07): Da der Auto-Match-Score eine Entscheidung mit Rechtswirkung treibt (Rechnung gilt als bezahlt), greift Art. 22 DSGVO. Sie können daher:

• Auto-Reconciliation komplett deaktivieren: Unter Einstellungen → Banking → "Automatisches Matching deaktivieren". Bank-Transaktionen werden dann ausschließlich als manuell zu bestätigende Vorschläge angezeigt.
• Score-Schwelle erhöhen: Default 95, einstellbar zwischen 70 (mehr Auto-Matches) und 100 (nur perfekte Matches).
• Jeden Auto-Match manuell aufheben ("Match rückgängig"-Button im Banking-UI). Rückgängig-Operationen werden im GoBD-konformen Audit-Log dokumentiert.

Jeder Auto-Match wird im reconciliation_audit_log mit Score-Breakdown (Betrag, Referenz, Kunde, Datum), Zeitstempel und Match-Type („auto" vs „manual") protokolliert.

2.9 Kunden-Gesamtansicht (Customer 360 View)

Für die effiziente Kundenbetreuung aggregieren wir folgende bereits vorhandene Daten in einer Gesamtansicht:

• Umsatzkennzahlen (Rechnungen, offene Forderungen)
• Projektinformationen und -status
• Kommunikationsverlauf (E-Mails, Anrufe, Nachrichten)
• Angebote und Deals

Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertragsdurchführung) bzw. Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse).
Es werden keine externen Datenquellen hinzugezogen.

2.10 Eingangsbelege: Automatische Erkennung & Lieferanten-Zuordnung

Wenn Sie das Feature „E-Mail zu Beleg" aktivieren, werden eingehende E-Mail-Anhänge (PDF, JPG, PNG) automatisch verarbeitet:

• OCR (KI-basiert): Anhänge werden mit Google Gemini 2.5 Flash (europe-west3 Frankfurt, Auftragsverarbeiter) analysiert. Extrahierte Daten: Lieferant, Rechnungsnummer, Datum, Betrag, USt.
• Auto-Verknüpfung mit Kunden/Leads: Die Absender-E-Mail-Adresse des Belegs wird mit Ihren bestehenden Kunden- und Lead-Datensätzen abgeglichen (clients.email,contact_email,leads.contact_email). Bei einer Übereinstimmung wird der Beleg automatisch dem entsprechenden Kunden/Lead zugeordnet.
• Confidence-Gate: Auto-Verknüpfung erfolgt nur bei KI-Confidence ≥ 70 %. Bei unsicherer OCR bleibt der Beleg für manuelle Zuordnung.

Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an effizienter Buchhaltung) sowie Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung Buchhaltungs-Software).
Ihre Rechte nach Art. 22 DSGVO: Die Auto-Verknüpfung stellt eine automatisierte Entscheidung dar, hat aber keine Rechtswirkung — die Buchung erfolgt erst durch Ihre manuelle Bestätigung. Sie können:

• Email-zu-Beleg deaktivieren: Unter Einstellungen → Belegerfassung → „Email-Anhang-Erkennung" deaktivieren.
• Auto-Verknüpfung pro Beleg aufheben: Im Beleg-Review zeigt ein 🤖-Hinweis die KI-Verknüpfung. Per Klick aufheben und manuell ändern.

KI-Act Art. 50 Disclosure: Auto-verknüpfte Belege sind in der UI mit „🤖 KI-verknüpft" gekennzeichnet. Der OCR-Vorschlag wird im receipt_ai_audit_log mit AI-Confidence, Modell, Verarbeitungs-Zeit und Sender-Email protokolliert (GoBD-konform).

2.10b Vendor-Auto-Import — Belege von vertrauenswürdigen Absendern

Sie können bei einzelnen Lieferanten in NexDeck eine E-Mail-Whitelist hinterlegen (Einstellungen → Integrationen → Vendor-Auto-Import). Eingehende E-Mails von diesen Absendern werden dann automatisch als Beleg in die Belegerfassung übernommen — ohne dass Sie ein Label manuell vergeben müssen.

• Tier A — Auto-Import: Exakte Absender-Adresse (z.B. rechnung@vodafone.de) + Owner-Opt-In plus erfolgreiche DKIM- und SPF-Authentifizierung durch den Mailserver + PDF-Anhang + Filename-Hinweis (rechnung/invoice/RG-/…). Nur dann wird der Beleg automatisch importiert.
• Tier B — Vorschlag: Domain-Treffer (z.B. vodafone.de) oder ≥ 3 historische Belege vom selben Absender. Beleg landet als „zu prüfen" im Review, NICHT auto-importiert.
• Anti-Spoofing: Sub-Domains wie vodafone.de.evil.com werden technisch von einem echten Sub-Domain-Treffer wie mail.vodafone.de unterschieden und nicht akzeptiert. Bei DKIM-Fail erfolgt automatisches Downgrade auf Tier B (Review-Pflicht).

Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an effizienter Beleg-Verarbeitung) sowie Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung Buchhaltungs-Software). Default ist deaktiviert — Sie müssen pro Lieferant explizit das Opt-In aktivieren.

Art. 22 DSGVO (Automatisierte Entscheidung): Der Import ist eine rein deterministische Regel ohne KI/Profiling. Die eigentliche Verbuchung erfolgt nicht automatisch — jeder Beleg muss von Ihnen vor der Buchung in der DATEV-Übergabe manuell bestätigt werden (GoBD-Pflicht). Sie können die Whitelist jederzeit unter Einstellungen → Integrationen → Vendor-Auto-Import bearbeiten oder das Opt-In für einen Lieferanten widerrufen.

Speicherdauer: Die Whitelist-Einträge (Domain / E-Mail-Adresse / Opt-In-Status) werden so lange gespeichert, wie der Lieferant in Ihrem Account existiert. Bei Vendor-Löschung werden die Whitelist-Felder mitgelöscht. Sender-E-Mail-Adressen auf importierten Belegen unterliegen der GoBD-Aufbewahrungsfrist von 10 Jahren (identisch zu allen anderen Belegen).

Ergänzung 2026-05-26 — Email-Domain-Discovery: Zusätzlich zum oben beschriebenen Opt-In-Mechanismus kann ein Owner oder Admin manuell eine automatische Domain-Erkennung auslösen (Inngest-Workflow vendor-domain-discovery/run). Dieser Workflow analysiert die Header-Domains historischer Lieferanten-Mails in incoming_invoices.source_email_from und schreibt erkannte Business-Domains in das Feld clients.email_domains[]. Generische E-Mail-Provider (gmail.com, gmx.de, web.de, t-online.de, outlook.com etc. — 24-Domain-Blocklist) werden hart ausgefiltert, um falsche Lieferanten-Zuordnungen zu verhindern. Der Workflow ist nicht-destruktiv: bereits manuell vom Tenant gepflegte Domains werden nicht überschrieben, sondern nur leere Felder befüllt. Rate-Limit 1×/Tenant/Stunde. Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an effizienter Stammdaten-Pflege). Audit-Trail wird in audit_log mit den Events vendor.domain_discovery_triggered, vendor.domain_discovery_completed und vendor.domains_discovered geführt (10 Jahre Aufbewahrung gem. § 257 HGB / § 147 AO).

2.11 Offline-Modus und lokale Datenspeicherung

Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung) in Verbindung mit Art. 32 DSGVO (Sicherheit der Verarbeitung). Details zu den eingesetzten technischen und organisatorischen Maßnahmen finden Sie in unseren Technischen und Organisatorischen Maßnahmen (TOMs).

3. Einsatz von Künstlicher Intelligenz (KI)

Ein Kernbestandteil von NexDeck sind intelligente Assistenzfunktionen. Wir setzen hierbei auf "Enterprise Grade"-Sicherheit.

3.1 Beleg-Scanner & Dokumentenanalyse (Google Vertex AI / Gemini)

Für den Beleg-Scanner und die automatische Rechnungserfassung nutzen wir Google Cloud Vertex AI mit dem Modell Gemini 2.5 Flash (Anbieter: Google Cloud EMEA Limited, Irland).

3.2 Chat-Assistent & Finance BI (Anthropic Claude)

Für den KI-gestützten Chat-Assistenten nutzen wir Claude-Modelle von Anthropic, ausschließlich über folgende EU-Anbieter geleitet:

1. Primär: Google Cloud Vertex AI (europe-west1, Belgien)
2. Fallback: AWS Bedrock EU (eu-central-1, Frankfurt/Deutschland)

Kein US-Fallback: Sollten beide EU-Anbieter gleichzeitig ausfallen, wird die Verarbeitung bewusst unterbrochen (DSGVO Hard Fail) — wir routen niemals stillschweigend in die USA. Die Anthropic Direct API ist seit dem 17.04.2026 nicht mehr im Einsatz.

3.3 NEX Sales Call Assistant

Bei aktivierter Telefonie nutzen wir optional NEX, einen KI-Sales-Assistenten, fuer kontextuelle Vorschlaege rund um Anrufe (Pre-Call-Briefing, Outcome-Vorschlag, Folge-Aktionen, Datenlueckenerkennung, Kampagnen-Insights). Aktivierung erfolgt ausschliesslich durch den Tenant-Admin im Super-Admin-Switchboard pro Feature (`feature.nex.sales_briefing`, `feature.nex.outcome_suggestions`, etc. — Default OFF).

• Modelle: Claude Haiku (Briefing, Tags, Follow-up) + Claude Sonnet (Outcome) — alle ueber Vertex AI EU (europe-west1 Belgien). Bedrock EU (eu-central-1 Frankfurt) als Fallback.
• Datenkategorien: Lead-Stammdaten, Aktivitaets-Snapshots, Call-Notes des Sales-Users, Outcome. KEIN Call-Audio, KEINE Transkripte.
• PII-Pseudonymisierung: Vor jedem LLM-Call werden Namen, E-Mails, Telefonnummern, IBANs serverseitig durch Platzhalter ersetzt und im Modell-Output wieder zurueckgesetzt.
• Human-in-the-Loop (KI-Act Art. 14): NEX schreibt nichts autonom — alle Vorschlaege erfordern explizite Bestaetigung durch den Sales-User.
• Tagesbudget: Pro Tenant gibt es ein konfigurierbares Tageslimit fuer AI-Kosten (`tenant_settings.ai_budget_cents_daily`, Default 5 EUR/Tag). Bei Erschoepfung blockieren NEX-Skills automatisch.
• Audit-Trail: Jeder NEX-Call wird in `activity_log` mit `actor_type='nex_assistant'` + Cost-Cents protokolliert (10 Jahre Retention, Verfahrensverzeichnis V-17).

3.4 Sprachein- und -ausgabe (Deepgram / Azure TTS)

Für die Spracheingabe (Speech-to-Text) nutzen wir Deepgram Inc. (USA) ausschließlich über den EU-Endpoint (api.eu.deepgram.com). Audiodaten werden nicht dauerhaft gespeichert. Übermittlung auf Basis von SCCs.

Für die Sprachausgabe (Text-to-Speech) nutzen wir Microsoft Azure Cognitive Services (Microsoft Ireland Operations Ltd., West Europe / Niederlande). Der Anbieter behält sich vor, bei Kapazitätsengpässen oder Qualitätsverbesserungen gleichwertige alternative TTS-Dienstleister einzusetzen (siehe AGB § 11b und Subprozessor-Liste /subprocessors).

Für die Batch-Transkription von Sprachnotizen (asynchron, z.B. nach Upload einer Sprachaufnahme) nutzen wir Microsoft Azure OpenAI Whisper (Sweden Central, EU). Audiodateien werden nach Transkription entsprechend der konfigurierten Aufbewahrungsfrist gelöscht. Transfergrundlage: EU-Datenresidenz + Microsoft Product Terms.

3.4a Sprachgesteuertes Aufmaß (Voice-Aufmaß)

Tenants können für ihre Mitarbeiter und Monteure ein sprachgesteuertes Aufmaß aktivieren: Maße werden auf der Baustelle per Push-to-Talk diktiert und in Text umgewandelt (z. B. „Wohnzimmer, Wand drei Meter zwanzig hoch“).

Keine Audio-Speicherung, kein Stimmprofil. Das Audiosignal wird ausschließlich flüchtig im Arbeitsspeicher verarbeitet und sofort in Text umgewandelt (On-the-fly-Transkription). Es wird keine Audiodatei gespeichert, kein Stimmprofil (Voiceprint) erstellt, keine Sprecher-Identifikation und keine Sprecher-Trennung (Diarization) durchgeführt. Gespeichert wird ausschließlich das Transkript der Maßangaben als Teil Ihres Aufmaß-/Projektdatensatzes. Vor der Speicherung erfolgt eine akustische Rückbestätigung (Text-to-Speech-Readback), die Sie freigeben.

Die Sprache-zu-Text-Umwandlung erfolgt durch Deepgram Inc. (USA) ausschließlich über den EU-Endpoint (api.eu.deepgram.com); die Verarbeitung findet in AWS-EU-Regionen statt, ein Drittland-Transfer der Audio- oder Transkriptdaten findet im Normalbetrieb nicht statt (Standardvertragsklauseln als Rückfall-Absicherung; Zero Data Retention, Modell-Verbesserung deaktiviert). Die akustische Rückbestätigung erfolgt über Microsoft Azure Cognitive Services (Microsoft Ireland Operations Ltd., West Europe / Niederlande, EU). Beide werden im Rahmen der bestehenden Auftragsverarbeitung eingesetzt (siehe Sub-Prozessor-Liste unter /subprocessors).

Soweit das Aufmaß durch Mitarbeiter eines Tenants erfolgt, verarbeitet der Tenant als Verantwortlicher auf Grundlage von Art. 6 Abs. 1 lit. b DSGVO (Durchführung des Arbeitsverhältnisses bzw. des Kundenauftrags), hilfsweise Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an effizienter, fehlerarmer Maßerfassung). § 26 BDSG wird hierfür nicht herangezogen. Eine automatisierte Entscheidung mit Rechtswirkung im Sinne von Art. 22 DSGVO findet nicht statt. Die mikrofonseitige Geräte-Freigabe ist eine technische Berechtigung Ihres Endgeräts und keine datenschutzrechtliche Einwilligung.

3.5 Google Cloud Dienste (Document AI + Cloud Run)

Neben Vertex AI (siehe 3.1, 3.2) nutzen wir weitere Google-Cloud-Services auf Basis desselben Google-Cloud-DPA:

• Google Document AI (EU-Region, europe-west3 Frankfurt) — Layout-Parser für die automatische Erkennung von Belegen und Rechnungen (OCR, Struktur-Erkennung).
• Google Cloud Run (EU-Region) — gehosteter XSD-Validator für die Prüfung von E-Rechnungen (ZUGFeRD 2.2 / XRechnung). Daten bleiben während der Validierung in der EU.

Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung) + Google Cloud DPA + EU-Datenresidenz.

Rechtsgrundlage (Sprachfunktionen, siehe 3.4 / 3.4a):Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung), hilfsweise lit. f DSGVO (berechtigtes Interesse). Die Freigabe des Mikrofons durch Ihr Endgerät ist eine technische Geräte-Berechtigung und keine datenschutzrechtliche Einwilligung im Sinne von Art. 6 Abs. 1 lit. a DSGVO.

3a. EU-KI-Verordnung (AI Act) — Transparenz und Risikoklassifizierung

NexDeck unterliegt als Anbieter KI-gestützter Funktionen der EU-Verordnung über Künstliche Intelligenz (Verordnung (EU) 2024/1689, „AI Act“). Wir setzen die Anforderungen wie folgt um:

Risikoklassifizierung: Begrenztes Risiko (Limited Risk)

Die KI-Funktionen von NexDeck (Chat-Assistent, Beleg-Scanner, Smart Drafts, Sprachassistent) sind als „Limited Risk“ gemäß Art. 6 und Anhang III der KI-Verordnung eingestuft. Begründung:

• Keine biometrische Identifikation oder Kategorisierung
• Keine kritische Infrastruktur-Steuerung
• Keine Kreditwürdigkeitsprüfung oder Scoring
• Keine Strafverfolgung oder Migrationskontrolle
• Assistenzfunktionen ohne eigenständige Entscheidungsbefugnis („Human in the Loop“)
• Alle KI-generierten Inhalte sind Vorschläge, die vom Nutzer geprüft werden müssen

Transparenzpflichten (Art. 50 AI Act)

Eingesetzte KI-Systeme und Zweck

Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung) und lit. f (berechtigtes Interesse an Produktverbesserung). Die Transparenzpflichten werden gemäß Art. 50 der EU-KI-Verordnung (Verordnung (EU) 2024/1689) erfüllt, die ab dem 02.08.2026 gelten.

4. Infrastruktur & Weitergabe an Dritte

Wir hosten unsere Systeme nicht auf eigenen Servern, sondern nutzen spezialisierte Cloud-Infrastruktur. Mit allen Anbietern haben wir Verträge zur Auftragsverarbeitung (AVV gemäß Art. 28 DSGVO) geschlossen.

Sofern Daten an Anbieter in den USA übermittelt werden, erfolgt dies auf Grundlage des EU-U.S. Data Privacy Frameworks (DPF) oder Standardvertragsklauseln (SCC).

4.1 Optionale Kunden-Integrationen (kein Unterauftragnehmer)

Folgende Dienste können Sie optional mit NexDeck verbinden. Hierbei verwenden Sie Ihre eigenen Zugangsdaten und schließen den Vertrag direkt mit dem jeweiligen Anbieter. NexDeck fungiert dabei lediglich als technische Schnittstelle, nicht als Auftragsverarbeiter:

• Sipgate: VoIP-Telefonie-Integration (sipgate GmbH, Düsseldorf)
• Weitere Buchhaltungs-Integrationen (z.B. DATEV-Export) können durch den Nutzer optional aktiviert werden. Eine aktuelle Liste verfügbarer Integrationen finden Sie in Ihrem Admin-Bereich unter „Integrationen“.

API-Schlüssel und Tokens werden verschlüsselt in Ihrer Mandanten-Instanz gespeichert und bei Trennung der Verbindung vollständig gelöscht.

4.2 Telefonie-Integration (optional, nur bei aktivierter Sipgate-Anbindung)

Wenn ein Tenant die Sipgate-Integration aktiviert, verarbeitet NexDeck folgende Metadaten eingehender und ausgehender Telefonate:

• Eingehende und ausgehende Rufnummer
• Zeitstempel (Start, Antwort, Ende)
• Gesprächsdauer
• Zuordnung zu Lead, Kunde oder Projekt (sofern die Nummer bekannt ist)
• Verantwortlicher Nutzer (Bearbeiter des Gesprächs)

Keine Gesprächsaufzeichnung: Inhalte von Telefongesprächen werden nicht aufgezeichnet oder transkribiert. Die Audio- Verarbeitung verbleibt vollständig bei Sipgate; NexDeck empfängt ausschließlich Webhook-Metadaten über die Sipgate Push-API.

Widerspruchsrecht (Art. 21 DSGVO): Betroffene können bei dem jeweiligen Tenant (Verantwortlicher) jederzeit schriftlich der Verarbeitung widersprechen.

4.3 E-Mail-Archivierung (BCC, gesetzliche Pflicht)

Versendete Rechnungen, Angebote, Mahnungen und geschäftsrelevante E-Mails werden als BCC-Kopie in das interne E-Mail-Postfach des Tenants archiviert. Dies ist eine gesetzliche Aufbewahrungspflicht und keine Opt-in-Funktion.

4e.1 Transaktionaler E-Mail-Versand (Phase 1, ab Mai 2026)

Optional verifizierbare Tenant-Sending-Domain für E-Mail-Versand unter eigener Geschäftsadresse (z.B. info@meine-firma.de). Versand erfolgt über AWS Simple Email Service (SES) in der Region eu-north-1 (Stockholm). Bounces, Complaints und Versand-Events werden erfasst und für Zustellbarkeits-Monitoring + GoBD-Pflicht-Log ausgewertet.

Datenarten: Versand-Metadaten (Absender, Empfänger, Betreff, Header), Versand-Events (Send/Delivery/Bounce/Complaint/Reject), Diagnostic-Codes bei Bounces (gekürzt auf 200 Zeichen, keine vollständigen Mailserver-Antworten), unterdrückte Empfänger-Adressen in einer Suppression-Liste. Keine vollständige Speicherung des E-Mail-Bodiesaußer im GoBD-Pflicht-Log document_email_log(10 Jahre).

Rechtsgrundlagen: Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung bei Versand von Rechnungen/Angeboten/Mahnungen); Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse bei Zustellbarkeits-Monitoring + Bounce-Hygiene zur Sicherung der E-Mail-Reputation).

Open-/Click-Tracking ist standardmäßig deaktiviert. Aktivierung nur über bewusstes Opt-in im Settings-Modul mit Acknowledgement der TDDDG-§25-Pflichten. Bei B2C-Empfängern ist die Einwilligung der Endkunden zusätzlich durch den Tenant einzuholen (NexDeck stellt die technische Infrastruktur, nicht die Consent-Erhebung).

Aufbewahrung: Versand-Events 10 Jahre (email_events + GoBD-Pflicht), Audit-Log 10 Jahre, Suppression-Einträge bis manuelle Owner-Freigabe oder Tenant-Löschanfrage.

Sub-Prozessor: AWS EMEA SARL (Amazon Web Services), Standort Stockholm. Standardvertragsklauseln (SCC 2021) für etwaige Drittland-Übermittlungen. AWS unterliegt dem US CLOUD Act — Details und Transfer Impact Assessment in unseren AVV-Anlagen.

Rechtsgrundlage: Art. 6 Abs. 1 lit. c DSGVO i.V.m. HGB § 257 / AO § 147 (Aufbewahrungspflicht für Geschäftsbriefe und Rechnungen, 6–10 Jahre).

Keine Öffnungs-/Klicktracking standardmäßig: E-Mails werden ohne Tracking-Pixel und ohne Link-Redirects versendet. Ein optionales Öffnungstracking kann durch den Tenant-Administrator explizit aktiviert werden (siehe Abschnitt 4.4).

4e.2 Unifizierte Kommunikations-Timeline (Phase 2, ab Mai 2026)

Versendete E-Mails und ausgelöste Versand-Events (Send/Delivery/ Bounce/Complaint/Reject) werden pro CRM-Entity (Lead, Client, Projekt, Invoice, Proposal) in einer chronologisch sortierten Timeline-Komponente sichtbar gemacht. Dies bündelt drei bereits vorhandene Quellen (timeline_events, email_events, document_email_log) in einer einzigen Lese-Ansicht — es entstehen keine neuen personenbezogenen Datenarten, lediglich eine User-Interface-Sichtbarkeit auf existierende Audit-Daten.

Optionales Open-/Click-Tracking: Bei vom Tenant-Administrator aktiviertem Tracking erscheinen Open-/ Click-Pillen am Document-Detail (Invoice/Proposal). Bei nicht aktiviertem Tracking (Default) bleibt die Timeline ohne Open/Click-Daten — sie zeigt dann nur Send/Delivery/Bounce/ Complaint.

Bounce-Bridge: Wenn ein Bounce-Event eintrifft, wird in der CRM-Timeline der betroffenen Entity ein begleitender timeline_events.email_bounced-Eintrag geschrieben, sodass Owner und Team sofort sehen, dass eine an den Kunden gesendete E-Mail nicht zugestellt werden konnte. Aufbewahrung der Timeline-Einträge: 10 Jahre (GoBD-Pflicht-Log).

RLS-Schutz: Die Timeline ist strikt tenant-isoliert (RLS-Policies auf den drei Quell-Tabellen) — kein Cross-Tenant-Read möglich. Sichtbarkeit zusätzlich eingeschränkt nach Rollen-/Permission-Modell (siehe Abschnitt 3 „Berechtigungen").

Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung — Nachvollziehbarkeit der Geschäfts- Korrespondenz) sowie Art. 32 Abs. 1 lit. d DSGVO (Nachweisbarkeit als TOM).

4e.3 Gemeinsames Team-Postfach (Shared Inbox, Phase 3A-Core Pilot)

Optional kann ein Tenant ein bestehendes E-Mail-Postfach (z.B. info@meine-firma.de) via OAuth oder App-Passwort über den Subprozessor Unipile (Frankreich) anbinden. Mehrere vom Tenant autorisierte Nutzer können dann eingehende Mails gemeinsam lesen, Antworten verfassen, Zuweisungen vornehmen und Statusänderungen durchführen.

Datenarten: E-Mail-Inhalte (Subject, Plain-Text- und HTML-Body), Header (From/To/CC/Reply-To/Message-ID), Anhänge mit Metadaten (Dateiname, MimeType, Größe — siehe Phase 3C unten), Zustelldaten, Thread-Status, Zuweisungen, Lese-/Antwort-/Statusänderungs-Audits.

NexDeck protokolliert jeden lesenden, antwortenden und administrativen Zugriff auf das Team-Postfach in einem revisionssicheren Audit-Log mit 10 Jahren Aufbewahrung (Art. 32 Abs. 1 lit. d DSGVO „Nachweisbarkeit", § 257 HGB).

Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse des Tenants an Team-basierter Geschäftskommunikation) sowie Auftragsverarbeitung gemäß Art. 28 DSGVO zwischen NexDeck und Tenant (AVV Modul A). Sub-Verarbeitung durch Unipile (siehe Subprozessor-Liste). Bei vom Tenant gewähltem US-Provider (Google Workspace, Microsoft 365) liegt die Drittland-Bewertung beim Tenant.

Tenant-Verantwortung: Der jeweilige Tenant regelt die interne Berechtigungsvergabe, dokumentiert Mitarbeiter-Informationspflichten (TDDDG § 26 BDSG), prüft Betriebsrat-Mitbestimmung (§ 87 Abs. 1 Nr. 6 BetrVG) und nimmt seine Endkunden in einer eigenen Datenschutzerklärung mit, dass eingehende E-Mails über das NexDeck-Team-Postfach laufen.

Aufbewahrung: Mail-Bodies und Anhänge gemäß § 257 HGB (Geschäftsbriefe 6 Jahre, Buchungsbelege/Rechnungen 10 Jahre). Audit-Log-Einträge 10 Jahre. Lösch- und Pseudonymisierungs- Konzept (Phase 3D LIVE seit v2.11.0): 5-Zustände-Lifecycle (active → soft_deleted → archived → pseudonymized → hard_deleted) mit Tombstone-Pattern bei Soft-Delete (Body-Wipe + 10y-Audit-Trail). Art. 17 DSGVO Komplett-Pseudonymisierung verfügbar via Support- Ticket-Workflow. Legal-Hold-Override blockt jede Lösch-Aktion bei rechtlicher Aufbewahrungspflicht. Auto-Legal-Hold-Heuristik schützt GoBD-relevante Mails (PDF-Anhänge, Rechnung/Mahnung- Absender) vor versehentlicher Löschung.

Body-Encryption-at-Rest (gestaffelter Rollout, Stand Mai 2026): AES-256-GCM-Verschlüsselung in der EU- Datenbank ist aktiv für interne Notizen (Phase 3B LIVE) und Antwort-Vorlagen (Phase 3D LIVE). Bei fehlender Schlüssel-Konfiguration wird der Speicher-Pfad bewusst hart blockiert (Plan §13.7), kein Plaintext-Fallback. Für eingehende Kunden-Mails aus angebundenen Provider-Postfächern (Phase 3A-Core Pilot) erfolgt die Speicherung aktuell noch unverschlüsselt at-rest; Inbound-Verschlüsselung und Backfill der Bestands-Mails sind Bestandteil der laufenden Hardening-Phase (§ 13.7). Übertragung ist in allen Fällen TLS 1.2+ verschlüsselt.

Teamarbeit am Thread (Phase 3B):

• Interne Notizen: Mitarbeitende mit Lese-Zugriff können team-interne Notizen an einem Thread hinterlassen. Diese sind ausschließlich teamintern sichtbar (Datenbank-Schema- Constraint blockt jede Outbound-Verarbeitung). Notizen werden mit Body-Encryption-at-Rest (AES-256-GCM) gespeichert. Audit- Event shared_inbox.internal_note_created protokolliert User + Thread + Notiz-Länge (KEIN Notiz-Inhalt im Audit-Log).
• CRM-Auto-Verknüpfung: Eingehende Mails werden automatisch mit existierenden Lead-, Projekt- oder Client- Datensätzen verknüpft, sofern die Absender-Adresse exakt einer hinterlegten Kontakt-E-Mail entspricht. Diese Verknüpfung ist eine technische Hilfsfunktion ohne Rechtswirkung im Sinne von Art. 22 DSGVO — Owner können sie jederzeit manuell ändern. Reihenfolge des Matchings: Lead → Projekt → Kunde → Lieferant (Stand 2026-05-25: Vendor-Match viaclients.roles = 'vendor' + Domain-/Email-Whitelist, Rechtsgrundlage Art. 6 Abs. 1 lit. f berechtigtes Interesse Belegerfassung-Effizienz + lit. c §147 AO/§257 HGB).
• Quick-Actions: Auf Basis der verknüpften Entity werden im Thread-Detail kontextuelle Aktionen angeboten — bei Kunden z.B. "Rechnung erstellen", "Termin anlegen"; bei Lieferanten "Belegerfassung öffnen (Lieferant vorausgewählt)". Diese öffnen lediglich die jeweilige Editor-Seite — kein automatischer Versand und keine automatische Speicherung finden statt.

Team-Kollaboration und Statistik (Phase 3C):

• Presence-Tracking (Kollisions-Warnung): Wenn Mitarbeitende gleichzeitig denselben Thread öffnen, signalisiert die UI das per Avatar-Ring (gelb = beobachtet, rot = tippt Reply). Erfasst werden ausschließlich kurzlebige Metadaten (User-ID, Thread-ID, Tipp-Indikator, letzter Heartbeat), Aufbewahrung maximal 5 Minuten, automatischer Cleanup-Cron. Es findet keine forensische Auswertung dieser Daten statt und kein Audit-Log-Eintrag bei reinem View-only-Verhalten. Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (Vermeidung doppelter Antworten).
• Anhang-Download: Beim Herunterladen eines Mail-Anhangs wird ein Audit-Event shared_inbox.attachment_downloaded mit User-ID, Thread-ID, Attachment-ID, Größe, MimeType und einer gehashten Datei-Kennung (SHA-256-Truncate, KEIN Klartext-Dateiname) geschrieben — Aufbewahrung 10 Jahre (Art. 32 Abs. 1 lit. d DSGVO). Die Übertragung erfolgt über Unipile (Streaming-Durchleitung, kein dauerhafter Speicher beim Subprozessor).
• Antwort-Vorlagen (Saved Replies): Tenants können textuelle Antwort-Vorlagen anlegen (Owner/Admin pflegen). Diese sind Tenant-eigene Inhalte, gelten nicht als Drittpersonen-Korrespondenz, werden im Klartext in der EU-Datenbank gespeichert (keine Body-Encryption) und sind ausschließlich teamintern sichtbar. Tenant ist Verantwortlicher für den Inhalt der Vorlagen. Manuelle Löschung jederzeit möglich, kein Auto-Delete.
• Manuelle Thread-Verknüpfung: User mit Assign-Berechtigung können Threads manuell mit Lead/Client/ Projekt verknüpfen. Audit-Event shared_inbox.thread_linked protokolliert die Aktion (10 Jahre Aufbewahrung).
• KPI-Aggregat (Team-Übersicht): Die Inbox-Statistik zeigt aggregierte Werte über das Team (offene Threads, in 7 Tagen erledigte Threads, Eingangs- volumen, Median-Antwortzeit der letzten 30 Tage). Die Median-Antwortzeit wird nur berechnet, wenn mindestens drei verschiedene Reply-Autoren im Window aktiv waren — andernfalls wird der Wert als „nicht ausreichend aggregierbar" suppressed. Diese Hürde stellt sicher, dass keine individuelle Leistungs- oder Verhaltenskontrolle einzelner Mitarbeitender möglich ist (§ 87 Abs. 1 Nr. 6 BetrVG, § 26 BDSG). Es handelt sich nicht um eine automatisierte Einzelfallentscheidung im Sinne von Art. 22 DSGVO.

Lebenszyklus + Datenminimierung (Phase 3D):

• Soft-Delete (Tombstone-Pattern): User mit entsprechender Berechtigung können einzelne Nachrichten als gelöscht markieren. Body-Inhalte (Klartext + verschlüsselte Kopie) werden dabei unwiderruflich entfernt. Eine Tombstone- Zeile bleibt für die Audit-Trail-Aufbewahrungsfrist (10 Jahre) — mit User-ID, Zeitstempel und optionalem Lösch-Grund (max. 256 Zeichen). DSGVO Art. 17 Datenminimierung. Weitere automatisierte Lebenszyklus-Stufen (Archiv, Pseudonymisierung, finale Löschung) sind in Phase 4 geplant und derzeit nicht aktiv — die Tombstone-Metadaten bleiben 10 Jahre erhalten.
• Komplett-Löschung nach Art. 17 DSGVO: Bei einem Auskunfts- oder Lösch-Antrag eines Endkunden kann der Tenant über das Support-Ticket-System eine Komplett-Pseudo- nymisierung des Tombstones beantragen (Absender, Empfänger, Betreff → `[redacted-by-art17]`), sofern keine GoBD-/HGB- Aufbewahrungspflicht entgegensteht. Audit-Event wird geschrieben.
• Antwort-Vorlagen-Platzhalter:Platzhalter wie `{{customer_name}}` in Saved-Replies werden im Browser des Nutzers (Client-Side) vor Versand mit konkreten Werten ersetzt. Der finale Mail-Body wird erst beim Versand vom Server an SES übergeben — NexDeck-Server sehen nur den bereits substituierten Text.
• Legal Hold: Owner/Admin können einzelne Nachrichten unter Legal Hold stellen — blockt jede Lösch-/ Pseudonymisierungs-Aktion (für Beweis-/Compliance-Zwecke). Audit-Event protokolliert wer wann setzt/löst.
• Klassifikation eingehender Mails (5 Buckets): Eingehende E-Mails werden automatisch in eine von fünf Klassen einsortiert: echte Kundennachricht (human), Auto-Antwort, Bounce/Zustellfehler, Mailing-Liste, oder unbekannt. Die UI- Voreinstellung „nur Kunden-Mails" blendet Auto/Bounce/Listen aus — keine forensische Auswertung der Klassifikation, nur Workflow-Hilfe.
• Multi-User-Notification bei interner Notiz: Wenn ein Team-Mitglied eine interne Notiz an einen Thread hinterlegt, erhalten andere Team-Mitglieder mit Lese-Zugriff auf das Postfach (sowie der Connection-Owner und der/die zugewiesene Bearbeitende) eine System-Notification mit Hinweis auf den Thread. Der Notiz-Inhalt und auch die Notiz-Länge werden NICHT in die Notification kopiert. Die Notification-Metadaten enthalten die User-ID des/der Notiz-Autor:in (Identifizierungs- Information zu Rückfrage- und Audit-Zwecken). Hard-Cap von 25 Empfängern pro Note verhindert Notification-Storms.
• Antwort-Vorlagen Body-Encryption: Tenant- eigene Antwort-Vorlagen werden seit Phase 3D mit AES-256-GCM at-rest verschlüsselt (konsistent zu E-Mail-Bodies). Legacy- Klartext-Vorlagen aus Phase 3C bleiben für Backwards-Compat, werden bei nächster Bearbeitung verschlüsselt überschrieben.

4.4 E-Mail-Öffnungs- und Klicktracking (optional, Opt-in)

Tenant-Administratoren können über das Admin-Interface ein optionales Öffnungs- und Klicktracking aktivieren. Diese Funktion ist standardmäßig deaktiviert und wird erst nach expliziter Opt-in-Bestätigung des Tenant-Admins eingesetzt.

Widerrufsrecht (Art. 7 Abs. 3 DSGVO): Der Tenant-Admin kann das Tracking jederzeit über das Admin-Interface deaktivieren. Der Widerruf ist dabei genauso einfach wie die Einwilligung. Ab Widerruf werden keine neuen Tracking-Pixel mehr in versendete E-Mails eingefügt. Bereits versendete Tracking-Pixel können technisch nicht rückgängig gemacht werden.

4a. Adress-Eingabe, Geocoding und Kartendarstellung

Adress-Autocomplete (Google Maps Platform)

Wenn Sie in einem Adressfeld zu tippen beginnen (z. B. beim Anlegen eines Kunden, eines Projekts oder eines Leads), übermitteln wir Ihre Eingabe an die Google Maps Platform (Vertragspartner für EU/EEA-Kunden: Google Ireland Limited, Mutterkonzern Google LLC, USA), um Ihnen Adress-Vorschläge anzuzeigen. Bei Auswahl eines Vorschlags wird die strukturierte Adresse einschließlich der Geo-Koordinaten in Ihre NexDeck-Datenbank übernommen und nicht erneut bei Google nachgefragt.

Wichtig zur rechtlichen Einordnung: Google Maps Platform verarbeitet diese Daten als eigenständiger Verantwortlichernach Art. 4 Nr. 7 DSGVO — NICHT als unser Auftragsverarbeiter. Es besteht kein Auftragsverarbeitungsvertrag (AVV); stattdessen gelten die Google Controller-Controller Terms sowie die Google-Datenschutzerklärung. Google ist DPF-zertifiziert und trägt seit 2024 die Pflichten aus den EU-Standardvertragsklauseln für EU-Kundenverbindungen eigenständig.

Wir übermitteln an Google ausschließlich den von Ihnen eingegebenen Adress-Suchbegriff sowie technisch unvermeidbare Verbindungs-Metadaten (IP-Adresse, User-Agent, Session-Token zur Sitzungs-basierten Abrechnung). Keine Klarnamen, Tenant-IDs, Kunden-Datensatz-IDs oder Geschäftskontext werden an Google weitergegeben.

Rechtsgrundlage:Art. 6 Abs. 1 lit. f DSGVO — berechtigtes Interesse an Adress-Validierung und betriebseffizienter Stammdaten-Erfassung. Die Datenverarbeitung lässt sich nicht mehr nachträglich aufheben (Klick-basierte aktive Eingabe durch Sie). Eine Einwilligung ist nicht erforderlich, da die Datenübermittlung im Rahmen Ihrer aktiven Adress-Eingabe als zwingende technische Voraussetzung für die Funktion erfolgt.

Reverse-Geocoding (Geoapify, Admin-only)

Wenn ein Super-Admin eine bestehende Geo-Koordinate manuell überprüft oder bei einem Bestandsdaten-Import historische Koordinaten in eine strukturierte Adresse umgewandelt werden müssen, nutzen wir den Reverse-Geocoding-Dienst der KEPTAGO LTD (Geschäftssitz Cyprus, EU; Hosting der API auf Hetzner-Servern in Deutschland und Finnland über den EU-Endpoint api-eu.geoapify.com). Der Dienst wird ausschließlich in Admin-Workflows verwendet — bei der normalen Adress-Eingabe von Endkunden kommt er nicht zum Einsatz.

Geoapify ist unser Auftragsverarbeiter nach Art. 28 DSGVO; der entsprechende Auftragsverarbeitungsvertrag (DPA) ist bei Nutzung der API verbindlich. Übermittelt werden ausschließlich geographische Koordinaten (Lat/Lng), keine personenbezogenen Klardaten. Geoapify speichert Anfrage-Metadaten lt. eigenem DPA maximal 24 Stunden (in Verdachtsfällen bis zu 2 Monaten).

Rechtsgrundlage:Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an Datenqualität).

Kartendarstellung (OpenFreeMap + Protomaps-Fallback)

Zur Visualisierung von Projekt- und Tour-Standorten auf einer Karte beziehen wir das Kartenmaterial primär von OpenFreeMap (gemeinnützige Open-Source-Initiative, Community-Hosting). Bei Ausfall des Primary-Anbieters greift automatisch ein Fallback auf vorgefertigtes Kartenmaterial (Protomaps PMTiles), das wir auf eigener AWS-EU-Infrastruktur in Frankfurt hosten — keine zusätzlichen Drittanbieter in dieser Fallback-Kette.

In beiden Fällen werden ausschließlich allgemeine Kartenausschnitte ausgeliefert; es werden keine personenbezogenen Daten an OpenFreeMap oder andere Karten-Provider übertragen, abgesehen von der technisch unvermeidbaren IP-Adresse und User-Agent des aufrufenden Browsers.

Navigation (Deep-Link, kein Daten-Sharing)

Wenn Sie auf „Route starten" klicken, öffnet NexDeck Ihre bevorzugte Navigations-App (Apple Maps, Google Maps, Waze) mit der Zieladresse vorbelegt. Die anschließende Navigation erfolgt unter der Datenschutzerklärung der jeweiligen App; NexDeck verarbeitet dabei keine weiteren Daten.

4b. Datenmigration aus Buchhaltungssystemen (optional, nur bei aktivem Wizard)

Wenn Sie als Tenant Bestandsdaten aus einem externen Buchhaltungssystem in NexDeck übernehmen möchten, stellen wir Ihnen einen Migrations-Wizard bereit. Die nachfolgenden Verarbeitungen finden ausschließlich dann statt, wenn Sie im Wizard aktiv einen API-Schlüssel des jeweiligen Anbieters eintragen. Ohne diese Aktion wird keine Verbindung zu Lexware Office oder sevDesk aufgebaut.

Rollenverteilung (Art. 4 Nr. 7 / Art. 28 DSGVO): Sie sind Verantwortlicher der bei Lexware Office bzw. sevDesk gespeicherten Daten — Sie beauftragen uns mit deren einmaligem Lesezugriff zur Migration. Wir sind dabei Auftragsverarbeiter für das temporäre Staging der gelesenen Daten in unseren EU-Servern.

Lexware Office (Haufe-Lexware GmbH & Co. KG, Freiburg)

Wenn Sie Bestandsdaten aus Lexware Office in NexDeck migrieren, lesen wir mit Ihrem API-Schlüssel einmalig folgende Datenkategorien: Kontakte / Kunden, Ausgangsrechnungen, Eingangsbelege, Buchungskategorien, Artikel. Die Daten werden temporär in einem Staging-Bereich auf EU-Servern gespeichert (max. 30 Tage) und nach Ihrer Freigabe in Ihre NexDeck-Instanz übernommen oder gelöscht.

Sitz Lexware: Munzinger Str. 9, 79111 Freiburg im Breisgau, Deutschland (DE-EU). Es findet kein Drittland-Transfer statt — Lexware ist in Deutschland gehostet.

Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung — Portierung Ihrer eigenen Geschäftsdaten). Ihr bestehender Vertrag und AVV mit Lexware ( lexware.de/avv) bleibt davon unberührt.

sevDesk GmbH (Karlsruhe)

Analog zu Lexware Office oben: Wenn Sie Bestandsdaten aus sevDesk in NexDeck migrieren, lesen wir mit Ihrem API-Token einmalig dieselben Datenkategorien (Kontakte / Kunden, Ausgangsrechnungen, Eingangsbelege, Buchungskategorien, Artikel). Die Daten werden temporär in einem Staging-Bereich auf EU-Servern gespeichert (max. 30 Tage) und nach Ihrer Freigabe in Ihre NexDeck-Instanz übernommen oder gelöscht.

Sitz sevDesk: Am Sandfeld 11c, 76149 Karlsruhe, Deutschland (DE-EU). Es findet kein Drittland-Transfer statt — sevDesk ist in Deutschland gehostet.

Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung — Portierung Ihrer eigenen Geschäftsdaten). Ihr bestehender Vertrag und AVV mit sevDesk ( sevdesk.de/avv) bleibt davon unberührt.

Speicherdauer Staging und KI-Schema-Mapping

Die in den Staging-Tabellen abgelegten Daten werden spätestens 30 Tage nach Anlage der Migrations-Sitzung automatisch gelöscht. Sobald Sie auf „Übernehmen" klicken, werden die Daten in Ihre Live-Tabellen übernommen und das Staging sofort geleert. Bei „Migration abbrechen" erfolgt die Löschung ebenfalls sofort.

Während des Wizards kommt zur Erkennung der Spalten- und Kategorienzuordnung unsere KI-Komponente Vertex AI Claude Sonnet (Belgien) zum Einsatz. Es werden ausschließlich Spalten-Header und maximal fünf PII-redaktierte Beispielzeilen an die KI übermittelt — niemals Bulk-Daten (Datenminimierung Art. 5 DSGVO). Details siehe Abschnitt 3a.

Aufnahme in Subprozessor-Listing: Lexware Office und sevDesk sind als optionale Datenquellen / Migrations-Schnittstellen in der Subprozessor-Liste geführt. Diese Auflistung dient der Transparenz; im klassischen Sinne des Art. 28 DSGVO handelt es sich nicht um Subprozessoren von NexDeck, sondern um Drittsysteme, mit denen Sie selbst eine Vertragsbeziehung haben.

4c. Kalender, Disposition und Ressourcen-Planung

Für die Termin- und Einsatzplanung („Plantafel"), die Echtzeit-Synchronisation zwischen Disponent:innen und Mitarbeiter:innen sowie für Push-, Standort- und Arbeitszeitfunktionen verarbeiten wir zusätzliche Daten. Die nachfolgenden Verarbeitungen finden ausschließlich für angemeldete Tenant-Nutzer:innen statt, nicht für Besucher:innen unserer Website.

4c.1 Realtime-Benachrichtigungen via Supabase Realtime

Sobald Termine, Aufträge oder Crew-Zuordnungen geändert werden, übermitteln wir die Änderung in Echtzeit (WebSocket) an die jeweils berechtigten Sitzungen (Disponent:in, betroffene Worker-Sessions). Hierfür nutzen wir den Realtime-Dienst unseres Datenbank-Anbieters Supabase (EU, Frankfurt). Die Auslieferung erfolgt über rollen-spezifische Channels (z. B. realtime-{tenantId}-worker-{userId}), so dass eine Sitzung ausschließlich Daten erhält, die nach unserer Rollen- und Sichtbarkeits-Logik für sie freigegeben sind.

Redaction-Layer: Bevor ein Realtime-Event an Worker-Sessions ausgeliefert wird, läuft es server-seitig durch eine redaktierte Datenbank-View (z. B. appointments_redacted_worker): Fremde Privat-Termine werden als „Belegt" angezeigt, sensible Felder (Kunde, Adresse, Beschreibung) werden je nach Sichtbarkeits-Modus entfernt oder durch generische Werte ersetzt (vgl. Abschnitt 3a der Datenschutzhinweise für Beschäftigte).

Versionierung (Manipulationsschutz): Jedes Realtime-Event trägt zwei Versions-Zähler: payload_version (Inhalts-Version des Termin-Datensatzes) und redaction_version (Version des Sichtbarkeits-/Redaction-Regelwerks zum Zeitpunkt der Auslieferung). Empfangende Clients verwerfen Events mit veralteten Versionen — so wird verhindert, dass ein Worker-Client Daten anzeigt, die nach einer zwischenzeitlichen Berechtigungs-Änderung nicht mehr für ihn freigegeben wären.

Datenkategorien: Termin-Metadaten (Anfang/Ende, Status, Crew-Zuordnung), redaktierte Termin-Inhalte je nach Sichtbarkeits-Modus, Empfänger-User-ID, Tenant-ID, Versions-Zähler, Auth-Token (kurzlebig).Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung — Einsatzplanung als Kernfunktion der SaaS-Leistung) für Disponent:innen-Sicht; Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an Team-Koordination) i.V.m. § 26 Abs. 1 BDSG für die Mitarbeitenden-Sicht.Speicherdauer: Realtime-Events selbst werden nicht persistiert; sie werden nach Auslieferung verworfen. Der zugrundeliegende Datensatz unterliegt den allgemeinen Speicherdauern (Abschnitt 6).

4c.2 Push-Benachrichtigungen via OneSignal

Wenn Sie Push-Benachrichtigungen aktiviert haben (Browser-Permission bzw. native App-Permission), versenden wir betriebliche Benachrichtigungen (z. B. neuer Termin, Terminänderung, Crew-Zuordnung) über unseren Push-Dienstleister OneSignal (EU-Rechenzentren, Niederlande). Bevor eine Push gesendet wird, prüft die Plattform server-seitig, ob für den Empfänger eine gültige Permission UND ein gültiges Device-Token vorliegen. Liegt eine Permission nicht (mehr) vor, wird der Versand stillschweigend übersprungen.

Zustell-Status & Retry-Backoff: Für jeden Push-Versand protokollieren wir intern delivery_status (queued / delivered / failed / dropped) und attempt_count. Bei vorübergehenden Fehlern (z. B. APNs/FCM kurzzeitig nicht erreichbar) erfolgt ein 5-Stufen-Retry-Backoff (gestaffelt nach Sekunden, Minuten, Stunden — Max-Alter 24 h). Danach wird der Versand als endgültig fehlgeschlagen markiert; eine erneute Zustellung erfolgt nur bei einem neuen, auslösenden Ereignis. Diese Statusdaten dienen ausschließlich der Zustellbarkeits-Analyse und Idempotenz (Vermeidung von Doppel-Pushes) und werden nach 90 Tagen automatisch gelöscht.

Deep-Linking-Pattern: Jede Push enthält einen Deep-Link mit tenant_id, Ressource-Typ (z. B. appointment, crew_assignment) und Ressource-ID. Beim Tap öffnet sich automatisch die entsprechende Detail-Ansicht innerhalb der Mandanten-isolierten Anwendung. Die Push-Payload (Titel + Text) wird vor dem Versand durch unseren 3-Stufen-Sanitizer (push-sanitizer.ts) gefiltert; je nach Tenant-Einstellung (push_privacy_mode) erscheint entweder der Original-Text, ein generischer Kategorie-Hinweis oder nur „Neue NexDeck-Benachrichtigung".

Datenkategorien: Device-Token, Push-Payload (sanitisiert), Externer User-Hash (Supabase-UUID, keine Klarnamen), Zustellungs-Status und Versuchsanzahl, Tenant-/Ressource-IDs für Deep-Linking.Rechtsgrundlage: Art. 6 Abs. 1 lit. a DSGVO (Einwilligung — Browser-/Native-Permission) i.V.m. § 25 TDDDG (technische Speicherung Subscription-Token); für Beschäftigte zusätzlich § 26 Abs. 2 BDSG (Einwilligung im Beschäftigungsverhältnis). Der Widerruf ist jederzeit über die Geräte-Systemeinstellungen oder über Einstellungen → Datenschutz möglich.Subprozessor: OneSignal, Inc. (siehe Subprozessor-Liste). Android-Transport via Google FCM, iOS-Transport via Apple APNs.

4c.3 Standortdaten für Routing und Distance-Matrix

Für die Routenplanung und für Disposition-Funktionen wie „nächstgelegene:r verfügbare:r Mitarbeiter:in" speichern wir zu jedem Einsatztermin eine Einsatzadresse sowie die zugehörigen geografischen Koordinaten (Breitengrad / Längengrad). Diese sind in den Tabellen appointment_site_details (Felder site_address, site_address_lat, site_address_lng) hinterlegt. Die Geokodierung erfolgt bei Speicherung der Adresse einmalig (Geoapify, EU — siehe Abschnitt 4a) und wird anschließend zur Vermeidung wiederholter Anfragen lokal vorgehalten.

Distance-Matrix-Cache: Für die Berechnung von Fahrzeiten und Entfernungen zwischen Mitarbeiter:innen-Standort und Einsatzort nutzen wir die Distance-Matrix-API der Google Maps Platform. Ergebnisse werden in einem tenant-isolierten Cache (max. 30 Tage) vorgehalten, um die API-Last und Kosten zu reduzieren sowie Offline-Robustheit zu gewährleisten. Google Maps Platform ist als eigenständige:r Verantwortliche:r eingestuft (Datenempfänger D-1 in unserer Subprozessor-Liste), nicht als Auftragsverarbeiter.

Live-GPS (Echtzeit-Mitarbeiter-Position während eines Einsatzes) ist eine separate, opt-in-pflichtige Funktion. Dazu siehe ausführlich Abschnitt 2.7 (GPS & Workforce-Tracking) sowie die Datenschutzhinweise für Beschäftigte. Für die hier beschriebene Adress- und Routing-Funktion werden keine Live-Positionen verarbeitet, sondern ausschließlich die statisch hinterlegte Einsatzadresse.

Datenkategorien: Einsatzadresse (Straße, Postleitzahl, Ort, Land), Geokoordinaten (Lat/Lng), Distance-Matrix-Cache-Einträge (Origin/Destination, Fahrzeit, Distanz).Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung — Routing und Disposition sind Kernfunktionen der vertraglich vereinbarten SaaS-Leistung).Speicherdauer: Einsatzadresse + Koordinaten so lange wie der zugehörige Termin im System bleibt (analog Abschnitt 6); Distance-Matrix-Cache max. 30 Tage.

4c.4 Arbeitszeiterfassung (Work / Pause / Travel)

Wenn Ihr Arbeitgeber die Arbeitszeiterfassung aktiviert hat, erfassen Mitarbeiter:innen pro Einsatztermin Zeit-Einträge in der Tabelle appointment_time_entries. Pro Eintrag werden Start- und Endzeit sowie eine Kategorie protokolliert:

• work — produktive Arbeitszeit am Einsatzort
• pause — gesetzliche oder selbstgewählte Pause (§ 4 ArbZG)
• travel — An- und Abfahrtszeit zwischen Einsätzen

Die Zeit-Einträge werden für die Lohnabrechnung, für die Erfüllung der gesetzlichen Aufzeichnungspflicht nach § 17 MiLoG und für die Einhaltung des Arbeitszeitgesetzes (ArbZG) (Höchstarbeitszeit, Ruhepausen, Ruhezeit) verwendet. Hinweis zum EuGH-Urteil C-55/18 („CCOO") sowie BAG-Beschluss 1 ABR 22/21 (13.09.2022): Arbeitgeber sind verpflichtet, ein objektives und verlässliches System zur Erfassung der täglichen Arbeitszeit ihrer Beschäftigten einzurichten. NexDeck stellt hierfür die technische Grundlage bereit; verantwortlich für die konkrete Anordnung und Umsetzung ist Ihr Arbeitgeber.

Datenkategorien: User-ID, Tenant-ID, Termin-Referenz, Start- und End-Zeitstempel, Kategorie (work/pause/travel), optionale Bemerkung, Geräte-Quelle (Web/Mobile).Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung Arbeitsvertrag) i.V.m. § 26 Abs. 1 BDSG (Beschäftigtendatenschutz) UND Art. 6 Abs. 1 lit. c DSGVO i.V.m. § 17 MiLoG / ArbZG / § 9 GewO (rechtliche Verpflichtung des Arbeitgebers zur Arbeitszeit-Aufzeichnung).Speicherdauer: Mindestens 2 Jahre nach Ablauf des Kalenderjahres der Aufzeichnung (§ 17 Abs. 2 MiLoG), sofern Ihr Arbeitgeber keine längeren Aufbewahrungspflichten anwendet (z. B. § 147 AO für Lohnunterlagen mit steuerlicher Relevanz: 6 Jahre).Mitbestimmung: Soweit ein Betriebsrat besteht, ist die Einführung der elektronischen Zeiterfassung gemäß § 87 Abs. 1 Nr. 6 BetrVG mitbestimmungspflichtig. Verantwortlich für diese Prüfung ist Ihr Arbeitgeber.

Detaillierte Hinweise für Mitarbeiter:innen (Sichtbarkeit zwischen Kolleg:innen, Need-to-know-Prinzip, Beschwerderecht): Datenschutzhinweise für Beschäftigte.

4c.5 Kapazitäts-Aggregation (user_capacity_daily)

Auf Basis der unter §4c.4 erfassten Arbeitszeit, der hinterlegten individuellen Verfügbarkeit (Wochenplan) und genehmigter Urlaubs- bzw. Abwesenheitseinträge erzeugen wir eine materialisierte tagesgenaue Aggregations-View (user_capacity_daily). Sie enthält pro Mitarbeiter:in und Datum: verfügbare Stunden (aus Wochenplan-Fallback), geplante Termin-Stunden (aus appointments), Urlaubsstunden (aus employee_time_off) sowie die daraus berechnete Auslastung. Diese Aggregation dient ausschließlich der operativen Disposition und Kapazitätsplanung durch berechtigte Rollen (owner / admin / manager / dispatcher).

Datenkategorien:Pseudonymisierte User-ID + Datum + 4 Stundenwerte (Verfügbarkeit, Geplant, Urlaub, Auslastungs-Quote). KEIN Klarname & KEIN Standort in der View. Klar-Identifizierung erfolgt erst im UI durch Join auf profiles.full_name.

Rechtsgrundlagen:Art. 6 Abs. 1 lit. b DSGVO (Durchführung des Arbeitsverhältnisses — Schichtplanung & Personaleinsatzplanung) i.V.m. Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse Betriebsorganisation), zusätzlich Art. 88 DSGVO i.V.m. § 26 BDSG (Beschäftigtendatenschutz).

Mitbestimmungspflicht: Soweit ein Betriebsrat besteht, ist die Einführung einer aggregierten Leistungs- und Auslastungs-Auswertungauf Basis personenbezogener Daten gemäß § 87 Abs. 1 Nr. 6 BetrVG (technische Einrichtung zur Verhaltens- oder Leistungskontrolle) mitbestimmungs­pflichtig. Verantwortlich für die Prüfung & Durchführung der Mitbestimmungs-Verfahren ist Ihr Arbeitgeber (Tenant) — NexDeck stellt lediglich die technische Infrastruktur als Auftragsverarbeiter.

Sichtbarkeit: Worker / Member / Sales-Partner sehen NUR ihre eigenen Aggregations-Zeilen (RLS-Policy user_capacity_daily_secure mit auth.uid() = user_id-Filter). Eine Team-Übersicht ist nur für owner / admin / manager / dispatcher verfügbar — dort werden vollständige Namen angezeigt für operative Dispositions-Zwecke.

Speicherdauer: Die View selbst ist eine reine Aggregation aus den Quell-Tabellen (appointments + employee_time_off + user_availability). Sie wird bei Bedarf neu berechnet und enthält keine eigenständigen historischen Daten. Die zugrunde liegenden Quell-Tabellen haben ihre eigenen Speicherdauern (siehe §4c.4 und Aufbewahrungsklauseln der AGB).

Keine Profilbildung im Sinne von Art. 22 DSGVO: Die Aggregation liefert tagesbezogene Soll/Ist-Stunden für Disponenten — sie wird NICHT für automatisierte Einzelentscheidungen oder Profiling gegenüber Mitarbeiter:innen verwendet. Bewertungen und Personal­entscheidungen bleiben menschlich begründet beim Arbeitgeber.

4d. Audit-Trail interne Verwaltungsaktionen (Forensik & GoBD)

NexDeck schreibt zu jeder sicherheits- oder steuerrelevanten Verwaltungsaktion einen unveränderlichen Audit-Trail-Eintrag in die Tabelle audit_logs. Dieser Trail dient Forensik (DSGVO Art. 32 TOMs & § 26 BDSG Beschäftigtendatenschutz) und GoBD-Pflicht (§ 257 HGB Aufbewahrungsfristen) gleichzeitig.

Geloggte Pflicht-Events(nicht-abschließend): Rollen-Änderungen, Permission-Override-Änderungen, Reassign von Terminen, Genehmigung von Sales-Bookings & Urlaubsanträgen, Finalisierung & Stornierung von Rechnungen, Sync-Modus-Änderungen, Privacy-Flag-Toggle, Hard-Delete-Aktionen, abgelehnte Zugriffsversuche (HTTP 403), Login-Events (Erfolg + Fehlversuch), Tenant-Setting-Änderungen.

Datenkategorien pro Audit-Eintrag:

• Aktion (z. B. invoice_finalized, tenant_admin.update_member_role)
• Auslösender User (Pseudonym-ID, nicht Klarname)
• Tenant-ID (Mandant)
• Ressource-Typ & -ID (z. B. invoice / project / user_account)
• Vorher/Nachher-Snapshot betroffener Felder (JSONB)
• IP-Adresse (aus x-forwarded-for) — Best-Effort, bei Background-Jobs leer
• User-Agent des aufrufenden Browsers — Best-Effort, bei Background-Jobs leer
• Zeitstempel (Server-Zeit, UTC)

Rechtsgrundlagen:

• Art. 6 Abs. 1 lit. c DSGVO i. V. m. § 257 HGB & GoBD — rechtliche Verpflichtung zur lückenlosen Buchführung & Belegnachvollziehbarkeit
• Art. 6 Abs. 1 lit. f DSGVO — berechtigtes Interesse Plattform-Sicherheit & Tampering-Schutz (IP/User-Agent zur Abuse-Forensik)
• Art. 32 DSGVO (TOMs) — angemessene technische Maßnahmen zur Sicherstellung der Vertraulichkeit, Integrität, Verfügbarkeit & Belastbarkeit
• § 26 Abs. 1 BDSG — Beschäftigtendatenschutz (Überwachung dienstlicher Handlungen ist erforderlich für die Durchführung & Beendigung des Beschäftigungsverhältnisses, keine vorbereitende Verhaltens- oder Leistungskontrolle)

Speicherdauer (Plan §7 GoBD-Compliance):

• 10 Jahreab Eintragserstellung, sofern der zugehörige Geschäftsvorfall steuerrelevant ist (§ 257 Abs. 4 HGB) — entspricht der Aufbewahrungsfrist für Rechnungen, Bankbelege & Buchungsdaten
• 6 Jahre für Audit-Events ohne unmittelbaren Steuer-Bezug (z. B. Login-Events, abgelehnte Zugriffsversuche) — entspricht § 257 Abs. 4 HGB für Handelsbriefe
• Die audit_logs-Tabelle ist append-only — UPDATE & DELETE sind hard-blockiert per RLS-Policy. Bei DSGVO Art. 17 Lösch-Anspruch wird auf manuelle Anfrage des Tenant-Owners hin der User-Reference-Eintrag durch einen Hash ersetzt (Pseudonymisierung per Service-Role-Skript) — anders wäre die GoBD-Nachvollziehbarkeit verletzt. Eine automatisierte Pseudonymisierung von IP-Adresse & User-Agent nach Ablauf der Aufbewahrungsfrist befindet sich aktuell in Entwicklung und ist als Sprint-Item für eine kommende Iteration vorgesehen

Externe Auditor-Zugriffe: Im Falle einer Wirtschaftsprüfung oder GoBD-Audit erhält der Auditor einen pseudonymisierten Read-Only-Zugriff über den Audit-Export-Endpunkt (Rolle auditor_viewer) — Exports enthalten Hash-Referenzen statt User-Klarnamen, keine inhaltlichen Termindetails, nur Audit-Metadaten. Exports sind mit Watermark + per-Export-Salt versehen und in audit_exports dokumentiert (Rate-Limit 5/Tag pro Auditor, max. 10.000 Rows / 90 Tage Range pro Export). Eine dedizierte Auditor-UI-Oberfläche befindet sich in Entwicklung; bis zur Fertigstellung erfolgt der Zugriff über den API-Endpunkt /api/admin/audit-export.

Zugriffsbeschränkungen: Auf den Audit-Trail haben innerhalb des Tenants nur Owner / Admin / Auditor-Viewer-Rollen Lese-Zugriff. Mitarbeiter (worker / member / sales_partner) sehen ihren Audit-Trail NICHT, wohl aber alle Verarbeitungs-Hinweise dieser Datenschutzerklärung sowie ihr Auskunftsrecht (Art. 15 DSGVO) gegenüber dem Tenant.

4f. DATEV-Export-Verarbeitung, Versand an Steuerberater und Fehler-Monitoring

4f.1 DATEV-Export-Verarbeitung

Zweck: Wir stellen eine technische Funktion zur Generierung von Buchungsstapel-Exporten im DATEV-EXTF-Format bereit. Zweck der Verarbeitung ist die strukturierte Übergabe von Buchhaltungsdaten an den Steuerberater oder das Buchhaltungssystem des Tenants. NexDeck ist kein DATEV-Partner und nicht„DATEV-zertifiziert“ (vgl. AGB § 12r.1).

Datenkategorien:

• Buchungssätze (Konto, Gegenkonto, Betrag, Belegfeld 1, Belegfeld 2, BU-Schlüssel, Steuersatz)
• Mandanten- und Beraternummer (vom Tenant in den Einstellungen hinterlegt)
• Belegmetadaten (Rechnungsnummer, Belegdatum, Fälligkeitsdatum)
• Tenant-Stammdaten (Firma, Anschrift, USt-IdNr.)
• Empfänger-/Kontaktdaten der Buchungen (Kunden, Lieferanten)

Rechtsgrundlage:Art. 6 Abs. 1 lit. b DSGVO (Vertragsdurchführung Tenant ↔ Kunde) sowie Art. 6 Abs. 1 lit. c DSGVO (steuerliche Aufzeichnungs- und Aufbewahrungspflichten des Tenants nach § 147 AO, § 257 HGB, GoBD).

Speicherdauer:

• DATEV-Export-Dateien selbst: 10 Jahre (steuerrelevant, AO § 147)
• Versand-Audit-Logs (datev_export_sent_log): 10 Jahre
• Download-Access-Logs (datev_export_download_access_log): 7 Tage Klartext-IP, danach automatische Maskierung auf /24 (IPv4) bzw. /48 (IPv6) für die restliche Aufbewahrungsdauer von 90 Tagen (Sicherheits-Monitoring, Art. 6 Abs. 1 lit. f DSGVO)

Zugriff: Tenant-User mit entsprechender RBAC- Berechtigung (admin / finance / auditor_viewer) via RLS-Policy; NexDeck-Support nur via dokumentierten Break-Glass-Zugriff (vgl. Sektion 4d sowie support_access_log). Sensible Resources (Export-Dateien, Beleg-PDFs, Rechnungs-PDFs, vollständige Bank-Transaktionen) unterliegen einer Vier-Augen-Pflicht (durchgesetzt via DB-CHECK- Constraint).

4f.2 Versand an Steuerberater (Secure Download Gateway)

DATEV-Export-Dateien werden nicht als E-Mail-Anhang versendet. Stattdessen erhält der Steuerberater eine E-Mail- Benachrichtigung mit einem zeitlich begrenzten, widerruflichen Download-Link. Diese Architektur dient der Reduzierung des Datenexpositions-Risikos (E-Mail-Postfächer können kompromittiert werden, Anhänge bleiben dort dauerhaft).

• Download-Token: kryptografisch zufällig (256 Bit, base64url), wird in der Datenbank nur als SHA-256-Hash gespeichert. Der Klartext-Token ist ausschließlich in der E-Mail an die hinterlegte StB-Adresse zu lesen.
• Token-Gültigkeit: standardmäßig 7 Tage (konfigurierbar zwischen 30 und 365 Tagen), danach automatische Invalidierung.
• Manuelle Widerruflichkeit: Der Tenant kann jeden Download-Link über die Export-Historie sofort widerrufen.
• E-Mail-Whitelist: Versand erfolgt nur an explizit hinterlegte und durch Doppel-Verify bestätigte Steuerberater-Adressen (tenant_settings.tax_advisor_email_whitelist).
• Audit-Logging: Jeder Aufruf des Download- Links wird in der append-only Tabelle datev_export_download_access_log protokolliert (IP-Adresse, User-Agent, Erfolg/Fehler, Zeitstempel). Race-Conditions beim Access-Counter werden über atomare SQL-UPDATE-Funktion (increment_datev_token_access) verhindert.

4f.3 Fehler- und Performance-Monitoring (Sentry)

Zweck: NexDeck verwendet Sentry.io zur Erkennung von Software-Fehlern und Performance-Problemen im Produktivbetrieb (Stabilität und Sicherheit der Plattform).

Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse von NexDeck an Stabilität, Verfügbarkeit und Sicherheit des Dienstes) sowie Art. 32 DSGVO (technische und organisatorische Sicherheitsmaßnahmen).

Datenkategorien (mit Minimierungs-Bestreben):

• Stacktraces des fehlgeschlagenen Code-Pfads
• IP-Adressen(teilweise — abhängig von HTTP-Header-Verfügbarkeit; werden serverseitig nicht aktiv übermittelt, können aber aus Sentry-Default-Integration kommen)
• Browser-/Geräte-Info (User-Agent)
• Tenant-ID und User-ID als pseudonyme UUIDs (kein Klartext-E-Mail als User-Identifier)
• Breadcrumbs: durch zentralen Scrubber (src/lib/sentry/scrubbers.ts) auf sensitive Felder gefiltert — IBAN, BIC, tax_id, vat_id, customer_email, BU-Schlüssel, Beträge, Authorization-Header, Cookies, Download-Tokens und Query- Parameter wie token / download / verify / magic werden vor dem Versand redaktiert (53 Unit-Tests verifizieren das Verhalten).

Minimierungs-Bestreben (Pflicht-Maßnahme): Kein Volltext von Belegen, keine Klartext-Kontonummern, keine Steuerdaten in Events, keine Klartext-Download-Tokens. Default-Integrationen Console und Dom werden deaktiviert; maxBreadcrumbs=30 reduziert das Ring-Buffer-Volumen.

Empfänger: Functional Software, Inc. (Sentry.io). Sentry betreibt EU-Ingest in Frankfurt (o4509633585610752.ingest.de.sentry.io). Konzern-Sitz USA; Datenübermittlung an US-Konzernteile auf Basis EU-SCCs 2021/914 + EU-US Data Privacy Framework. Sentry ist Auftragsverarbeiter von NexDeck (vollständige Einordnung in der AVV-Anlage Subprozessoren-Liste).

Speicherdauer:30–90 Tage in Sentry- Project-Settings konfiguriert. Keine Default-Backup-Verlängerung.

Widerspruchsrecht: Da die Sentry-Verarbeitung auf Art. 6 Abs. 1 lit. f DSGVO basiert, kann jede betroffene Person nach Art. 21 DSGVO Widerspruch einlegen. Anfragen über datenschutz@nexdeck.de.

DATEV ist eingetragene Marke der DATEV eG, Nürnberg. NexDeck steht in keiner gesellschaftsrechtlichen oder partnerschaftlichen Verbindung zur DATEV eG. Die DATEV-Schnittstelle wird ausschließlich deskriptiv im Sinne von § 23 Abs. 1 Nr. 3 MarkenG genannt.

4a. Öffentliche Terminbuchung (optional pro Tenant)

Tenants (Unternehmen, die NexDeck nutzen) können optional ein öffentliches Buchungs-Widget aktivieren (verfügbar unter/book/[tenant-slug]/[event-slug]). Wenn Sie als Endkunde einen Termin über dieses Widget buchen, verarbeiten wir Ihre Daten wie folgt:

Verantwortlicher: Der jeweilige Tenant (Anbieter), nicht NexDeck. NexDeck ist Auftragsverarbeiter gem. Art. 28 DSGVO und stellt die technische Infrastruktur bereit. Die Verantwortlichkeit für die Verarbeitung Ihrer Booking-Daten liegt bei dem Anbieter, dessen Public-Booking-Slug Sie aufrufen.

Datenkategorien (von Ihnen aktiv eingegeben):

• Name (Pflicht)
• E-Mail-Adresse (Pflicht; ggf. Magic-Link-Bestätigung erforderlich)
• Telefonnummer (optional)
• Unternehmensname (optional)
• Nachricht / Anliegen (optional, max. 2.000 Zeichen)
• Gewählter Terminslot

Technisch erhobene Anti-Abuse-Daten (Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO — berechtigtes Interesse Plattform-Schutz):

• IP-Adresse (für Rate-Limit, max. 90 Tage Audit-Trail)
• User-Agent (für Abuse-Forensik)
• Anti-Bot-Verification-Hash (SHA-256 von ALTCHA-Payload, nicht der Original-Token)
• Honeypot-Status (Bot-Detection-Flag)
• Embed-Origin-URL falls iframe-Embed (für CSP-Audit)

Eingesetzte Auftragsverarbeiter:

• ALTCHA Self-Hosted (Anti-Bot-Schutz, cookie-less) — Proof-of-Work-Mechanismus läuft komplett auf NexDecks eigener Infrastruktur (Vercel Frankfurt). KEIN externer Subprozessor, kein Drittland-Transfer, keine Cookies, kein Browser-Fingerprinting. Open-Source unter MIT-Lizenz (Library `altcha-lib`).
• AWS SES (Magic-Link-Email, Frankfurt eu-central-1) — Versand der Bestätigungs-Email
• Upstash (Frankfurt) — Rate-Limiting-Counter (IP-Hashes, ≤ 1 Stunde TTL)
• Supabase (Frankfurt eu-central-1) — persistente Speicherung der Buchungs-Anfrage

Rechtsgrundlagen:

• Art. 6 Abs. 1 lit. b DSGVO (Vertragsanbahnung) — für Ihre Kontaktdaten + Nachricht; der Termin selbst ist Vertragsanbahnung mit dem Tenant
• Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse Anti-Abuse) — für IP, User-Agent, ALTCHA-Proof-Hash, Honeypot-Flag

Speicherdauer:

• Bestätigte Buchung: 90 Tage in der Booking-Request-Tabelle + weitere Aufbewahrung als regulärer Termin gem. Tenant-Settings (typisch 10 Jahre bei steuerrelevantem Vorgang)
• Blockierte/Unverifizierte Anfragen: 30 Tage für Abuse-Forensik, danach Löschung
• Magic-Link-Token: 24h Gültigkeit, danach unbrauchbar

Ihre Rechte: Sie können jederzeit Auskunft (Art. 15 DSGVO), Berichtigung (Art. 16) oder Löschung (Art. 17) verlangen. Wenden Sie sich primär an den jeweiligen Tenant (der Anbieter, dessen Booking-Slug Sie genutzt haben) — er ist Verantwortlicher. NexDeck unterstützt als Auftragsverarbeiter bei der Erfüllung Ihrer Rechte. Bei Fragen: privacy@nexdeck.de.

iframe-Embed-Hinweis: Tenants können das Buchungs-Widget via iframe in ihre eigene Website einbetten. Auch in diesem Fall gilt: die Verarbeitung Ihrer Daten erfolgt durch den Tenant (Verantwortlicher) und NexDeck (Auftragsverarbeiter). Der iframe-Host (Tenant-Website) ist KEIN eigener Datenverarbeiter dieser konkreten Buchungs-Daten — wohl aber für seine eigene Website-Telemetrie. Bitte beachten Sie die Datenschutzerklärung der einbettenden Website zusätzlich.

5. Ihre Rechte

Sie haben jederzeit das Recht auf:

• Auskunft über Ihre gespeicherten Daten (Art. 15 DSGVO)
• Berichtigung falscher Daten (Art. 16 DSGVO)
• LöschungIhrer Daten ("Recht auf Vergessenwerden"), sofern keine Aufbewahrungspflichten bestehen (Art. 17 DSGVO)
• Einschränkung der Verarbeitung (Art. 18 DSGVO)
• Datenübertragbarkeit (Art. 20 DSGVO)
• Widerspruch gegen die Verarbeitung (Art. 21 DSGVO)
• Beschwerde bei einer Aufsichtsbehörde (Art. 77 DSGVO) – z.B. LDI NRW

Für weitere Anfragen wenden Sie sich bitte an: support@nexdeck.de

6. Speicherdauer

• Während der Vertragslaufzeit: Wir speichern Ihre Daten so lange, wie Sie einen aktiven Account bei uns haben.
• Nach Kündigung: Ihre Inhaltsdaten werden 30 Tage nach Vertragsende unwiderruflich gelöscht (Karenzzeit für Datenexport). Eine Kündigung können Sie jederzeit über den Kündigungs-Button auf www.nexdeck.app/kuendigen einreichen (§ 312k BGB).
• Steuerrecht: Rechnungen und steuerrelevante Belege müssen wir gesetzlich 10 Jahre aufbewahren (§ 147 AO).

7. Datensicherheit

Wir nutzen moderne Verschlüsselungsverfahren:

• SSL/TLS für die Übertragung
• AES-256 für die Datenbank
• Besonders sensible Daten (API-Token, OAuth-Credentials) werden zusätzlich isoliert und verschlüsselt gespeichert
• Row Level Security (RLS) auf Datenbankebene für strikte Mandantentrennung

8. Cookies

Wir verwenden verschiedene Arten von Cookies. Sie können Ihre Einwilligung jederzeit in unseren Cookie-Einstellungen anpassen.