Technische und organisatorische Maßnahmen (Art. 32 DSGVO)

Entwurf, juristische Prüfung ausstehend. Version 1.0, Stand 04.10.2026. Dieses Dokument wurde ohne anwaltliche Prüfung erstellt und darf nicht ohne Freigabe durch eine Anwältin oder einen Anwalt verwendet werden.

Anlage 1 zu den Auftragsverarbeitungsverträgen von preqo
Verantwortlich für dieses Dokument: [Firmenname] [Rechtsform], [Straße und Hausnummer], [PLZ] [Ort], [Land]

preqo betreibt keine eigenen Rechenzentren. Datenbank, Authentifizierung und Dateispeicher laufen bei Supabase im Rechenzentrum Frankfurt am Main (AWS, Region eu-central-1), Serverfunktionen bei Vercel in der Region Frankfurt (fra1). Physische Maßnahmen werden durch diese Unterauftragsverarbeiter erbracht und durch deren Zertifizierungen nachgewiesen. Die folgenden Maßnahmen beschreiben, was preqo selbst umsetzt und was durch Unterauftragsverarbeiter abgedeckt ist.

1. Vertraulichkeit (Art. 32 Abs. 1 lit. b)

1.1 Zutrittskontrolle

• Rechenzentren: Zutrittskontrolle durch die Infrastrukturbetreiber (AWS über Supabase, Vercel) mit Zertifizierungen nach [Zertifizierungen Infrastruktur] (zum Beispiel ISO/IEC 27001, SOC 2 Typ II). Nachweise liegen bei preqo vor.
• Büroräume von preqo: [Zutrittsregelung Büro] (zum Beispiel verschlossene Räume, Schlüsselregelung, Besucher nur in Begleitung).
• Auf Arbeitsplatzrechnern werden keine personenbezogenen Kundendaten dauerhaft gespeichert.

1.2 Zugangskontrolle

• Anmeldung über Supabase Auth mit E-Mail und Passwort, Google oder Microsoft.
• Zwei-Faktor-Authentifizierung (TOTP) für alle Nutzer verfügbar, verpflichtend für Plattform-Admins, Agentur-Admins und Kunden-Admins.
• Kontosperre nach fünf fehlgeschlagenen Anmeldeversuchen.
• Passwort-Zurücksetzen mit neutraler Antwort (kein Hinweis darauf, ob ein Konto existiert), Link 60 Minuten gültig.
• Begrenzte Sitzungsdauer und Abmeldung bei Inaktivität: [Sitzungsdauer].
• API-Schlüssel im Format mit Präfix, serverseitig nur als SHA-256-Hash gespeichert, mit Scopes eingeschränkt und jederzeit widerrufbar.
• Zugriff über MCP nur per OAuth 2.1 mit Token-Prüfung gegen die Schlüssel des Autorisierungsservers.
• Administrative Zugänge zu Supabase, Vercel und weiteren Diensten nur mit MFA und persönlichem Konto.

1.3 Zugriffskontrolle

• Rechte werden pro Membership vergeben. Ein Nutzer kann Mitglied mehrerer Workspaces mit jeweils unterschiedlicher Rolle sein (zum Beispiel Kunden-Admin, Vertrieb, Nur lesen).
• Doppelte Prüfung: Die Anwendung prüft jede Operation gegen die Rechte-Matrix der Membership. Zusätzlich erzwingt die Datenbank Row Level Security (RLS) pro Workspace, sodass Datensätze anderer Workspaces auch bei einem Anwendungsfehler nicht lesbar sind.
• Rechte werden ausschließlich serverseitig geprüft, nie nur in der Oberfläche.
• Sensible Rechte sind gesondert: Export von Leads, Löschung betroffener Daten, Anhören von Aufzeichnungen, Konfiguration der KI.
• Dateispeicher (Aufzeichnungen, Exporte, Objektdateien) ist privat, mit RLS, Pfade beginnen mit der Workspace-ID. Zugriff nur über signierte, zeitlich begrenzte URLs.
• Zugriffe mit erhöhten Rechten (Service-Pfad) nur für Provisionierung, Webhooks, zeitgesteuerte Aufgaben, Support und Seed. Jede Nutzung erzeugt einen Audit-Eintrag mit Grund.
• Support-Zugriffe nur mit Pflichtgrund, begrenzter Dauer, sichtbarem Hinweis im Workspace und Protokoll. Keine Identitätsübernahme von Nutzern.

1.4 Trennungskontrolle (Mandantentrennung)

• Jeder Kunde erhält einen eigenen Workspace. Alle mandantenbezogenen Tabellen tragen eine Workspace-ID und sind durch RLS getrennt.
• Agenturen greifen auf Workspaces ihrer Kunden nur über die hinterlegte Agenturzuordnung zu. Jeder solche Zugriff wird auditiert.
• Getrennte Umgebungen für Entwicklung, Test und Produktion. In Entwicklung und Test werden ausschließlich Demo- oder synthetische Daten verwendet.

1.5 Pseudonymisierung (Art. 32 Abs. 1 lit. a)

• Transkripte von KI-Anrufen werden nach Ablauf der festgelegten Frist oder auf Weisung pseudonymisiert: Namen, Telefonnummern, E-Mail-Adressen, Anschriften und weitere identifizierende Angaben werden durch Platzhalter ersetzt.
• IP-Adressen aus Funnels werden nur gehasht gespeichert.
• Auswertungen und Statistiken auf Plattformebene verwenden aggregierte Daten ohne Personenbezug.

2. Integrität (Art. 32 Abs. 1 lit. b)

2.1 Weitergabekontrolle und Verschlüsselung

• Transportverschlüsselung: ausschließlich HTTPS mit TLS 1.2 oder höher, HSTS aktiviert.
• Verschlüsselung ruhender Daten: Datenbank, Backups und Dateispeicher werden beim Infrastrukturbetreiber mit AES-256 verschlüsselt.
• Geheimnisse (API-Schlüssel externer Dienste, Signaturschlüssel) liegen nur in geschützten Umgebungsvariablen, nicht im Quellcode.
• Webhooks externer Anbieter werden per Signatur geprüft.
• Exporte für Betroffene oder Kunden werden über signierte URLs mit begrenzter Gültigkeit (höchstens 7 Tage) bereitgestellt.
• Keine Drittanfragen im Browser: Schriften sind selbst gehostet, Logos werden aus dem eigenen Speicher geladen. Funnels arbeiten ohne Cookies.

2.2 Eingabekontrolle und Audit-Log

• Ein Audit-Log protokolliert sicherheits- und datenschutzrelevante Vorgänge mit Zeitpunkt, handelnder Person, Kanal (Web, API, MCP, System), Workspace und Objekt, insbesondere: Anmeldungen, Rechteänderungen, Agentur- und Support-Zugriffe, Nutzung des Service-Pfads, Exporte, Löschungen, Einwilligungen und Widerrufe, Annahme von Rechtsdokumenten, Erstellung und Widerruf von API-Schlüsseln, Verbindungen von MCP-Clients.
• Das Audit-Log ist für Anwendungsnutzer nicht veränderbar. Aufbewahrung: [Aufbewahrung Audit-Log].
• Änderungen an Leads werden als Ereignisse in einer Zeitleiste festgehalten.

3. Verfügbarkeit und Belastbarkeit (Art. 32 Abs. 1 lit. b und c)

3.1 Verfügbarkeit

• Tägliche automatische Backups der Datenbank durch Supabase, Point-in-Time-Recovery: [Status Point-in-Time-Recovery]. Backups verbleiben in der EU.
• Aufbewahrung von Backups: [Aufbewahrung Backups (Tage)] Tage.
• Überwachung der Verfügbarkeit und Fehlerprotokollierung: [Monitoring-Dienst].

3.2 Belastbarkeit

• Serverlose Ausführung mit automatischer Skalierung.
• Begrenzung von Anfragen (Rate Limiting) pro API-Schlüssel und Nutzer, Schutz der Funnel-Endpunkte durch Rate Limit, Domainprüfung und Honeypot.
• Idempotenz für schreibende API- und MCP-Aufrufe sowie Webhooks, um doppelte Verarbeitung zu verhindern.
• Kontingentgrenzen für KI-Anrufe mit Warnstufen bei 75, 90 und 100 Prozent.

3.3 Wiederherstellung (Art. 32 Abs. 1 lit. c)

• Wiederherstellung aus Backups nach dokumentiertem Verfahren. Ziel für Wiederherstellungszeit: [Wiederherstellungszeit (RTO)], Ziel für maximalen Datenverlust: [Maximaler Datenverlust (RPO)].
• Wiederherstellungstest mindestens [Intervall Wiederherstellungstest].
• Infrastruktur und Datenbankschema sind als Code versioniert und reproduzierbar.

4. Löschkonzept

• Aufbewahrungsfristen (Retention) werden pro Workspace festgelegt, mit Voreinstellungen aus dem Blueprint. Standardwerte: Leads [Aufbewahrung Leads], Aufzeichnungen [Aufbewahrung Aufzeichnungen], Transkripte bis zur Pseudonymisierung [Aufbewahrung Transkripte].
• Ein täglicher automatischer Lauf löscht abgelaufene Leads, entfernt Aufzeichnungen aus dem Speicher und pseudonymisiert Transkripte.
• Es gibt keine Papierkörbe. Löschungen in der Oberfläche, über die API oder MCP erfolgen nach ausdrücklicher Bestätigung sofort und endgültig.
• Löschanträge Betroffener werden über eine eigene Funktion umgesetzt, die alle zugehörigen Daten einschließlich Dateien entfernt und den Vorgang protokolliert. Der Protokolleintrag enthält keine gelöschten Inhalte.
• Daten in Backups werden mit Ablauf der Backup-Aufbewahrung überschrieben.
• Einwilligungsnachweise werden nach Widerruf so lange aufbewahrt, wie es zum Nachweis der Rechtmäßigkeit erforderlich ist: [Aufbewahrung Einwilligungsnachweise].

5. Datenschutz-Management und Auftragskontrolle (Art. 32 Abs. 1 lit. d)

• Benannte Verantwortliche für Datenschutz und Informationssicherheit: [Verantwortliche Datenschutz].
• Datenschutzbeauftragter, soweit erforderlich: [Datenschutzkontakt].
• Verzeichnis von Verarbeitungstätigkeiten als Auftragsverarbeiter (Art. 30 Abs. 2 DSGVO).
• Verpflichtung aller Beschäftigten auf Vertraulichkeit, Schulung bei Eintritt und mindestens jährlich.
• Prozess für Datenschutzverletzungen mit Meldung an Auftraggeber innerhalb der vertraglichen Frist.
• Rechtsdokumente (AVV, TOM, Unterauftragsverarbeiter, Einwilligungstexte) werden versioniert, mit Inhalts-Hash gespeichert und erst nach anwaltlicher Freigabe verwendet. Annahmen werden mit Zeitstempel, Version und Hash protokolliert.
• Unterauftragsverarbeiter werden vor Beauftragung geprüft (Sitz, Verarbeitungsort, Zertifizierungen, Vertrag nach Art. 28). Telefonie- und KI-Anbieter nur mit Verarbeitung in der EU. Änderungen werden allen Kunden vorab mitgeteilt.
• Datenschutz durch Technikgestaltung (Art. 25 DSGVO): Datenminimierung in Funnel-Vorlagen, Einwilligungsschritt in Funnels nicht löschbar, Pflichtlinks zu Impressum und Datenschutz vor Veröffentlichung, KI-Offenlegung nicht abschaltbar, Aufzeichnung standardmäßig aus.
• Überprüfung dieser Maßnahmen mindestens jährlich und bei wesentlichen Änderungen.