Technische und Organisatorische Maßnahmen

Nicht anwendbar. QuoteXelerator, eine HubSpot-Marketplace-Anwendung betrieben von Nomadyr UG (haftungsbeschränkt), betreibt keine eigenen physischen Server. Die gesamte Infrastruktur wird über Cloud-Dienste bereitgestellt. Die physische Zugangskontrolle obliegt den Unterauftragsverarbeitern:

• Supabase: Hosting in Frankfurt, Deutschland (AWS eu-central-1). SOC 2 Type 2 zertifiziert. AWS dokumentiert die folgenden physischen Sicherheitsmaßnahmen: Multi-Faktor-Authentifizierung an Zugangspunkten, CCTV-Videoüberwachung sowie 24/7-Sicherheitspersonal (Quelle: aws.amazon.com/compliance/data-center/).
• Vercel: Serverless Functions in Frankfurt, Deutschland. SOC 2 Type 2 zertifiziert. Infrastruktur wird in zertifizierten Rechenzentren betrieben.

• Starke Passwörter und Zwei-Faktor-Authentifizierung (2FA) für alle Administratorzugänge
• Individuelle Administratorkonten, keine gemeinsam genutzten Zugangsdaten
• Supabase-Dashboard-Zugang via 2FA
• Vercel-Dashboard-Zugang via 2FA
• GitHub-Repository-Zugang via 2FA und SSH-Schlüsselauthentifizierung
• API-Schlüssel werden als Umgebungsvariablen gespeichert, niemals im Quellcode
• Regelmäßige Überprüfung und Rotation der Zugriffsrechte
• Prinzip der minimalen Berechtigung (Least Privilege) für alle Systemzugänge
• Automatische Session-Timeouts bei Inaktivität

• Rollenbasierte Zugriffskontrolle (RBAC) in der Anwendung
• Datenisolation pro Kunde auf Datenbankebene durch Row-Level Security (RLS) Policies
• HubSpot OAuth nutzt minimale Berechtigungen (Scopes): Es werden ausschließlich die für die Angebotstransformation erforderlichen Berechtigungen angefordert
• Sensible Felder (OAuth-Tokens, Rezeptkonfigurationen, Angebots-Snapshots) werden auf Anwendungsebene mit pro Kundenportal eindeutigen Schlüsseln verschlüsselt. Diese Felder können auch bei direktem Datenbankzugriff nicht im Klartext gelesen werden
• Kundenkennungen verwenden opake, nicht-sequenzielle Referenzen zur Verhinderung von Enumeration
• Datenbankzugriffsberechtigungen sind strikt eingeschränkt: Anwendungsrollen verfügen ausschließlich über die minimal erforderlichen Berechtigungen (SELECT, INSERT, UPDATE) auf die jeweiligen Tabellen
• Zugriffsprotokollierung für alle administrativen Aktionen
• Keine direkten Datenbankzugriffe im laufenden Betrieb; alle Datenmanipulationen erfolgen über die Anwendungsschicht

Kundennutzen. Damit Sie sich darauf verlassen können: Bevor technische Protokolle für die Fehlersuche oder die Verbesserung des Dienstes verwendet werden, werden personenbezogene Daten wie E-Mail-Adressen, Zugriffstoken und bekannte Geheimnisformate automatisch entfernt. Wir und die unterstützenden KI-Werkzeuge sehen ausschließlich den anonymisierten technischen Kontext einer Fehlermeldung, niemals Ihre Kundendaten. Die Schwärzung erfolgt mustergestützt; ein Restrisiko verbleibt und wird durch kurze Aufbewahrungsfristen, vertragliche Schutzmaßnahmen (Standardvertragsklauseln Modul 3, ausdrückliche Trainingsausschlüsse) und Verschlüsselung im Transit begrenzt.

Die Schwärzungs-Pipeline ist in sieben kooperierenden Schichten aufgebaut. Jede Schicht adressiert ein anderes Versagensszenario: Muster-Fehlschläge, Schema-Drift, Überlängen, fehlender Audit-Trail, stille Leaks, Regression sowie Beobachtbarkeit. Die Kombination macht ein PII-Leak unwahrscheinlich und für uns sichtbar.

Layer 1: Mustergestützte Schwärzung (Bereinigung bei Ingestion).

• Bereinigung bei Ingestion. Sämtliche technischen Protokolle und Vorfallsdaten durchlaufen vor der Speicherung eine deterministische, pattern-basierte Schwärzungsroutine.
• Erfasste Muster. Die Schwärzungsroutine ersetzt die folgenden PII- und Geheimnis-Muster vor dem Verlassen des Systems durch Platzhalter-Tokens:

  Muster	Ersatz
  E-Mail-Adressen	a***@redacted
  Bearer-Tokens	Bearer [REDACTED]
  Stripe-API-Schlüssel	sk_[REDACTED], pk_[REDACTED]
  HubSpot Private App Tokens	pat-[REDACTED]
  JSON Web Tokens	[REDACTED_JWT]
  Lange Hex-Sequenzen (HMAC/SHA-256-Digests)	[REDACTED_HEX]
  IBAN (EU 27 Länder)	[REDACTED_IBAN]
  Internationale Telefonnummern	[REDACTED_PHONE]
  Deutsche USt-IdNr / EU-VAT-IDs	[REDACTED_VAT_DE] / [REDACTED_VAT_EU]
  Deutsche Steuernummer	[REDACTED_TAX_DE]
  AWS-Access-/Session-Keys	[REDACTED_AWS_KEY]
  Anthropic-Schlüssel	[REDACTED_ANTHROPIC]
  GitHub-PATs	[REDACTED_GITHUB]
  Cookie- / Set-Cookie-Header	[REDACTED_COOKIE]

• Rekursive Anwendung. Wird rekursiv auf verschachtelte JSON-Werte angewendet; Objekt-Schlüssel bleiben erhalten, damit die technische Struktur weiterhin debuggbar ist.
• Request-Pfad-Bereinigung. Query-Strings auf Vorfalls-Request-Pfaden durchlaufen vor der Speicherung dieselbe Schwärzungsroutine; der Pfad-Anteil bleibt unverändert für die Triage erhalten.
• Logger-Hashing. Der interne Logger hasht zusätzlich Kunden-E-Mail-Kennungen und protokolliert weder Klartext-Quote-Inhalte noch Deal- oder Line-Item-Daten.
• Status: präventiv, nicht absolut. Ungewöhnliche oder kundenspezifisch formatierte Token können von der Pattern-Erkennung allein verpasst werden; deshalb ist die Inhalts-Schwärzung Teil eines mehrschichtigen Schutzes. Die Kombination reduziert die Wahrscheinlichkeit eines Leaks; verbleibendes Risiko wird durch kurze Retention und die vertragliche No-Training-Klausel begrenzt.

Layer 2: Feld-Allowlist (architektonische Prävention). Eine Allowlist legt fest, welche Felder an das LLM gehen. Unbekannte Felder werden bereits zur Kompilierzeit zurückgewiesen. Variable Inhalte (z. B. das details-Feld) werden vor dem Versand auf eine geschlossene Auswahl bekannt-unbedenklicher Schlüssel reduziert: Endpoint, HTTP-Status, Retry-Anzahl, Dauer, Modul, Funktion. Freitext-Felder sind als „bereinigt" markiert, sodass roher Inhalt den Egress-Pfad nicht erreicht.

Layer 3: Egress-Schema-Validierung. Vor jeder Übertragung prüft ein striktes Schema, dass nur erwartete Felder mit gültigem Inhalt und innerhalb harter Längen-Caps enthalten sind. Unbekannte Felder, Überlängen und ungültige Werte blockieren die Übertragung fail-closed. Verstöße werden ausschließlich nach Feldname protokolliert, nie nach Inhalt.

Layer 4: Transmission-Audit-Log. Jede Übertragung an das LLM wird in einer Audit-Tabelle protokolliert: Vorfalls-Referenz, Zeitstempel, Zielmodell, SHA-256-Hash der bereinigten Anfrage, Größe und Validierungs-Status. Klartext-Inhalte werden nicht gespeichert. Auf schriftliche Anfrage an legal@quotexelerator.com erhalten Verantwortliche ihren Portal-Audit-Trail als CSV-Export.

Layer 5: Egress-Block-Alarm. Sollte die Egress-Prüfung jemals eine Übertragung blockieren (d. h. ein Leak rutschte durch die Layer 1-3), wird der Vorgang abgebrochen und sofort ein E-Mail-Alarm an unseren internen Datenschutzkontakt versandt. Der Alarm enthält Vorfalls-ID, Hash und das matchende Muster, niemals Roh-Werte. Untersuchung und Pattern-Aktualisierung erfolgen unverzüglich nach Kenntniserlangung (Eingang des Alarms).

Layer 6: Wöchentliche Canary-Regressionstests. Ein wöchentlicher CI-Job prüft die Schwärzungs-Pipeline mit synthetischen Test-Payloads aus den bekannten PII-Mustern (siehe Tabelle oben). Wenn auch nur ein Muster nicht erkannt wird, öffnet das System automatisch ein Security-Incident-Ticket.

Layer 7: Stichproben-Sichtprüfung. Etwa 5 % der bereinigten Anfragen werden vollständig zur periodischen Sichtprüfung gespeichert. Die Stichprobenauswahl erfolgt kryptographisch zufällig, sodass sie nicht gezielt gesteuert werden kann. Dies ergänzt den Hash-basierten Audit-Trail um inhaltliche Verifikation.

• Wirkung. Wir, die KI-gestützten Vorfallsuntersuchungswerkzeuge sowie externe Vorfallsuntersuchungs-Systeme sehen ausschließlich bereinigten technischen Kontext, niemals Roh-Kundendaten.
• Schichten-Zusammenspiel. Die sieben Schichten wirken zusammen: Inhalts-Schwärzung, Feld-Allowlist, Schema-Validierung, Audit-Trail, proaktive Alarmierung, Regressions-Canaries und Inhalts-Stichprobe. Diese Kombination macht ein PII-Leak unwahrscheinlich und für uns sichtbar.
• Restrisiko anerkannt. Restrisiko (unbekannte PII-Formate, Sub-Pattern-Treffer, Vendor-seitige Kompromittierung, Ausfall einzelner Layer) bleibt anerkannt.
• Restrisiko-Begrenzung. Kurze Aufbewahrungsfristen bei Anthropic (Inferenz-Logs und Trust-and-Safety-Logs), vertragliche No-Training-Zusage gemäß Anthropic Commercial Terms, Verschlüsselung im Transit (TLS 1.2+), Standardvertragsklauseln Modul 3 (2021/914), dokumentierte Transfer-Impact-Analyse.

Wir nutzen KI-gestützte Code-Werkzeuge (z. B. Claude Code) bei der Entwicklung. Diese Werkzeuge übertragen während der Nutzung Code- und Kontextdaten an ihren jeweiligen Anbieter (z. B. Anthropic) zur Verarbeitung. Gemäß interner Richtlinie werden produktive Kundendaten niemals in diese Werkzeuge eingegeben. Verbundene Konnektoren zu Supabase greifen ausschließlich auf bereits geschwärzte Vorfallsdatensätze zu (siehe §3a). Aus diesem Grund werden diese Werkzeuge nicht als kundenseitige Unterauftragsverarbeiter geführt.

• Alle Daten werden verschlüsselt übertragen (TLS 1.2+)
• Alle Daten werden im Ruhezustand verschlüsselt (AES-256)
• Anwendungsschicht-Verschlüsselung stellt sicher, dass sensible Daten auch bei unbefugtem Datenbankzugriff geschützt bleiben. Schlüssel sind pro Kundenportal kryptografisch isoliert
• Keine Klartext-Zugangsdaten, Zugriffstokens oder Authentifizierungsgeheimnisse werden in der Datenbank gespeichert
• Die gesamte QuoteXelerator-Infrastruktur (Datenbank, Compute) wird in der EU gehostet (Frankfurt, Deutschland). QuoteXelerator repliziert keine CRM-Bestandsdaten (Kontakte, Unternehmen, Konversationen, E-Mails); für Audit- und Idempotenz-Zwecke werden ausschließlich verschlüsselte Snapshots der verarbeiteten Angebote sowie Referenzen auf erstellte Deal Line Items gespeichert. Lese- und Schreibzugriffe auf das HubSpot-Portal erfolgen direkt per OAuth nach dem Minimal-Footprint-Prinzip
• Stripe-Zahlungsdaten werden über Stripe Payments Europe, Ltd. (Dublin) verarbeitet. Keine Zahlungsmittelinformationen werden in der QuoteXelerator-Datenbank gespeichert
• HTTPS wird für alle Endpunkte erzwungen; unverschlüsselte HTTP-Verbindungen werden automatisch umgeleitet
• Standardisierte HTTP-Sicherheitsheader werden bei allen Antworten gesetzt

• Vollständige Audit-Protokollierung aller Datenänderungen mit Zeitstempel und Benutzerkennung
• Anwendungsseitige Protokollierung jeder Angebotstransformation
• Unveränderliche Snapshots für jedes verarbeitete Angebot; Änderungen an verarbeiteten Daten sind nachvollziehbar und rückverfolgbar
• Nachverfolgung von Änderungen an Deal Line Items nach der Erstellung
• Audit-Protokolle können nicht durch Anwendungsbenutzer modifiziert oder gelöscht werden (Append-Only-Prinzip)
• Protokollierung aller administrativen Aktionen, einschließlich Konfigurationsänderungen

• Kundendaten werden ausschließlich für den vertraglich vereinbarten Zweck (Angebotstransformation) verarbeitet
• Auftragsverarbeitungsverträge (AVV) mit allen Unterauftragsverarbeitern
• Keine Verwendung von Kundendaten für Training, Marketing oder sekundäre Zwecke
• Weisungsgebundene Verarbeitung gemäß Art. 28 Abs. 3 lit. a DSGVO
• Datenminimierung: Es werden nur die für den Verarbeitungszweck erforderlichen Daten erhoben und verarbeitet
• Keine Replikation von CRM-Bestandsdaten (Kontakte, Unternehmen, Konversationen, E-Mails); gespeichert werden ausschließlich verschlüsselte Angebots-Snapshots und Referenzen auf erstellte Deal Line Items für Audit- und Compliance-Zwecke. Zugriffe auf das HubSpot-Portal erfolgen direkt per OAuth

• Automatisierte tägliche Backups mit mehrtägiger Aufbewahrung, verwaltet durch den Infrastrukturprovider
• Redundante Bereitstellung über die EU-Region
• Serverlose Architektur (Serverless) eliminiert Single Points of Failure; Anfragen werden automatisch auf verfügbare Ressourcen verteilt
• Monitoring und Alerting für Ausfälle und Leistungsanomalien
• Automatische Skalierung bei erhöhtem Datenaufkommen
• Regelmäßige Überprüfung der Wiederherstellungsfähigkeit

• Logische Trennung der Kundendaten durch datenbankbasierte Isolationspolicies (Row-Level Security)
• Jeder Kunde hat isolierte Daten auf Datenbankebene; kein Kunde kann auf Daten eines anderen Kunden zugreifen
• Pro-Portal eindeutige Verschlüsselungsschlüssel stellen sicher, dass Daten selbst bei Umgehung der Datenbankisolierung ohne den entsprechenden Schlüssel nicht lesbar sind
• Mandantenisolierung wird durch automatisierte Tests überprüft
• Getrennte Umgebungen für Entwicklung, Staging und Produktion

• Verschlüsselungsschlüssel werden außerhalb der Anwendungsdatenbank verwaltet und sind dort nicht zugänglich
• Jedes Kundenportal ist kryptografisch isoliert; Daten eines Portals können nicht im Kontext eines anderen Portals entschlüsselt werden
• Bei Kontolöschung werden die verschlüsselten Daten des Kunden unwiderruflich gelöscht; ohne diese Daten ist eine Entschlüsselung nicht mehr möglich

• Endbenutzer-Authentifizierung erfolgt ausschließlich über HubSpot OAuth 2.0; QuoteXelerator speichert keine Benutzerpasswörter
• OAuth-Tokens werden verschlüsselt gespeichert und sind im Klartext nicht lesbar
• Token-Refresh erfolgt automatisch und sicher über die OAuth-2.0-Spezifikation
• Benutzer können den Zugriff jederzeit über ihr HubSpot-Portal widerrufen
• Keine Session-Daten werden serverseitig in persistentem Speicher abgelegt; die serverlose Architektur verwendet zustandslose Authentifizierung

• Serverlose Architektur: Keine dauerhaft laufenden Server, die als Angriffsfläche dienen könnten
• Jede Funktion wird in einer isolierten Umgebung ausgeführt und nach der Ausführung beendet
• Kein offener SSH-, RDP- oder anderer Remote-Verwaltungszugang
• API-Endpunkte sind über Web Application Firewall (WAF) geschützt
• DDoS-Schutz durch den Infrastrukturprovider auf Netzwerkebene
• Standard-Browser-Sicherheitsheader (u. a. Content Security Policy) sind konfiguriert

• Versionskontrolle über Git mit geschütztem Hauptzweig (Branch Protection)
• Code-Reviews vor der Zusammenführung in den Produktionszweig
• Automatisierte Abhängigkeitsprüfung auf bekannte Sicherheitslücken (Vulnerability Scanning)
• Regelmäßige Aktualisierung aller Abhängigkeiten und Frameworks
• Eingabevalidierung auf Anwendungsebene für alle benutzerbezogenen Daten
• Schutz vor OWASP-Top-10-Schwachstellen (SQL-Injection, XSS, CSRF) durch parametrisierte Abfragen und sichere Programmierstandards
• Kein Speichern von Geheimnissen (Secrets) im Quellcode; alle Konfigurationswerte werden über Umgebungsvariablen injiziert
• Automatisierte Build- und Deployment-Pipelines mit Integritätsprüfungen

• Definierter Prozess zur Erkennung, Klassifizierung und Bearbeitung von Sicherheitsvorfällen
• Meldung von Datenschutzverletzungen an den Verantwortlichen unverzüglich nach Kenntniserlangung gemäß Art. 33 DSGVO und dem AVV
• Dokumentation aller Vorfälle, einschließlich Ursachenanalyse und ergriffener Gegenmaßnahmen
• Monitoring und automatisierte Alarmierung bei ungewöhnlichen Zugriffsmustern oder Fehlerhäufungen
• Regelmäßige Überprüfung und Aktualisierung der Vorfallsreaktionsprozesse
• Kontakt bei Sicherheitsvorfällen: security@quotexelerator.com

• HubSpot-OAuth-Scopes werden auf das absolute Minimum beschränkt, das für die Angebotstransformation erforderlich ist
• Keine Replikation von CRM-Kontakten, Konversationen oder anderen CRM-Bestandsdaten; QuoteXelerator liest und schreibt direkt im HubSpot-Portal des Kunden
• Verarbeitete Angebotsdaten werden als verschlüsselte Snapshots gespeichert; Rohdaten werden nach der Transformation nicht dauerhaft vorgehalten
• Metadaten werden ausschließlich in aggregierter, anonymisierter Form für die Verbesserung des Dienstes verwendet
• Automatische Datenlöschung nach Vertragsende gemäß den im AVV festgelegten Fristen

Die kanonische, versionierte Liste der Unterauftragsverarbeiter wird in AVV Anlage 3 (v1.0, 17. Mai 2026) geführt. Die folgende Übersicht dient nur der Orientierung; Anlage 3 ist im Konfliktfall maßgeblich.

• Supabase Inc. / Supabase Pte. Ltd., 970 Toa Payoh North #07-04, Singapore 318992 (genaue Vertragsentität gemäß unterzeichneter DPA): primäre Postgres-Datenbank, Authentifizierung, Storage. Verarbeitung in AWS eu-central-1, Frankfurt. Übermittlungsmechanismus: SCCs Modul 3 (extra-EU-Vertragsentität); der tatsächliche Datenfluss bleibt im Normalbetrieb in der EU. SOC 2 Type II + ISO 27001 (siehe Trust-Portal des Anbieters für aktuelle Scope-IDs).
• Vercel, Inc. (340 S Lemon Ave #4133, Walnut, CA 91789, USA): Anwendungshosting und serverlose Funktionen. Funktionsausführung in Frankfurt (fra1); Edge-Metadaten (IP-Adressen, HTTP-Header) werden jedoch am US-Edge für DDoS- und WAF-Schutz verarbeitet. Übermittlungsmechanismus: SCCs Modul 3 in Verbindung mit dem EU-US Data Privacy Framework (Belt-and-Suspenders). SOC 2 Type II + ISO 27001 + DPF.
• Resend, Inc. (San Francisco, CA, USA): transaktionale E-Mail-Zustellung (Abonnement-Bestätigungen, Zahlungsfehler, Stornierungen, Founding-Member-Mails, Wartelisten-Bestätigungen). Konto-, Log- und E-Mail-Metadaten werden bei Resend in den USA gespeichert, unabhängig von der gewählten Versandregion. Outbound-SMTP-Traffic ist EU-routbar (Irland), die Persistenz der Metadaten ist es nicht. Übermittlungsmechanismus: SCCs Modul 3 in Verbindung mit dem EU-US DPF (Resend DPF-Zertifizierung Feb./März 2025). AVV vorhanden.
• Anthropic, PBC (US): KI-Inferenz für die Vorfallsuntersuchung (siehe §3a). Eingaben werden vor Übermittlung PII-bereinigt und nicht zum Modelltraining genutzt (Anthropic Commercial Terms). Übermittlung: SCCs Modul 3. TIA auf Anfrage. Zertifizierungen: ISO 27001:2022, ISO 42001:2023, SOC 2 Type I+II, HIPAA-ready.
• GitHub B.V. (Amsterdam, Niederlande; Microsoft Regional Model): Quellcode-Verwaltung sowie GitHub Actions für den Vorfallsuntersuchungs-Workflow. Sieht ausschließlich bereinigte Vorfallsdaten. Übermittlungsmechanismus: SCCs Modul 3 + EU-US DPF. ISO 27001 + ISO 27018 + SOC 2.
• HubSpot Ireland Limited (Ground Floor, Two Dockland Central, Guild Street, Dublin 1, Irland): Doppelrolle: (a) eigener Auftragsverarbeiter des Reseller-Kunden für Daten, die in seinem HubSpot-Portal verbleiben (insoweit nicht Unterauftragsverarbeiter der Nomadyr UG); (b) Unterauftragsverarbeiter der Nomadyr UG für Portaldaten, die per OAuth in Supabase übernommen werden (Deal-IDs, Kontakt-E-Mail für Benachrichtigungen, Line-Item-Snapshots, OAuth-/Refresh-Tokens). Übermittlungsmechanismus: EU-Angemessenheit, sofern das Kundenportal HubSpots EU-Residenz-Option nutzt; andernfalls SCCs Modul 3 + EU-US DPF (HubSpot, Inc., USA). SOC 2 Type II + ISO 27001 + ISO 27018 + DPF.

Selbständige Verantwortliche (keine Unterauftragsverarbeiter). Stripe Payments Europe, Limited (1 Grand Canal Street Lower, Dublin, D02 H210, Irland) verarbeitet Zahlungsdaten als selbständiger Verantwortlicher gemäß Art. 4 Nr. 7 DSGVO für Zahlungsabwicklung, Betrugsprävention und AML/KYC. Stripe ist somit kein Unterauftragsverarbeiter der Nomadyr UG. Maßgeblich ist die DPA von Stripe unter stripe.com/legal/dpa sowie die DTA unter stripe.com/legal/dta. PCI DSS Level 1 zertifiziert.

Übermittlungsmechanismus. Supabase verarbeitet Daten in Frankfurt (eu-central-1). Vercel-Funktionen sind auf Frankfurt (fra1) gepinnt, jedoch werden Edge-Metadaten am US-Edge für DDoS-/WAF-Schutz verarbeitet. Stripe agiert als selbständiger Verantwortlicher für Zahlungsdaten; maßgeblich ist die Stripe-eigene DPA. Jede Übermittlung erfolgt auf Grundlage der Standardvertragsklauseln Modul 3 (Durchführungsbeschluss (EU) 2021/914) zuzüglich des EU-US Data Privacy Framework, soweit aktiv. Ein Restrisiko aus US-Überwachungsgesetzen (FISA 702, EO 12333, Cloud Act) wird offen anerkannt und durch Verschlüsselung im Transit und im Ruhezustand, Datenminimierung, pattern-basierte Schwärzung (§3a), vertragliche No-Training-Zusagen sowie kurze Aufbewahrungsfristen begrenzt.

Benachrichtigung. Der Verantwortliche erhält mindestens 30 Kalendertage vor Hinzuziehung oder Austausch eines Unterauftragsverarbeiters eine Vorabinformation; die Widerspruchsfrist beträgt 10 Werktage gemäß der Benachrichtigungsklausel des AVV.