Technische und organisatorische Maßnahmen nach Art. 32 DSGVO

Die Verarbeitung findet in Rechenzentren nach ISO 27001 statt. Physischen Zutritt haben ausschließlich Beschäftigte des Rechenzentrumsbetreibers. Eigene Hardware wird nicht betrieben.

• Hauptressourcen in der Region europe-west3 (Frankfurt): Anwendung, Datenbank, Analysespiegel, Sprachmodell des Datenassistenten und die Protokolle der Anwendung
• davon getrennt: Verwaltungs- und Systemprotokolle der Cloud-Plattform in globalen Protokollbereichen des Anbieters, die sich nicht in eine Region legen lassen (bis zu 400 Tage; ein weiterer globaler Bereich mit sieben Tagen, in den die Protokolle der Anwendung nicht geschrieben werden)
• davon getrennt: Protokolle, die die Anbieter für den Betrieb ihrer Dienste selbst führen, nach deren Bedingungen
• möglich: Zugriffe von Konzerngesellschaften und Dienstleistern der Anbieter von außerhalb der EU für Verwaltung und Support; Anlage 2 nennt sie je Anbieter mit Übermittlungsgrundlage

• Anmeldung mit E-Mail und Passwort oder mit einem Passkey; Passwörter werden mit Argon2id gehasht und nie im Klartext gespeichert
• Bestätigung in zwei Schritten, für jedes Nutzerkonto verfügbar und von der Person selbst einzuschalten; die Software erzwingt sie nicht. Zweiter Schritt ist ein Code aus einer Authenticator-App nach RFC 6238 oder ein Passkey. Ein Code wird einmal angenommen, in seinem Zeitschritt von dreißig Sekunden und je einem Schritt davor und danach, damit eine abweichende Uhr nicht aussperrt
• Passkeys nach WebAuthn: Beim Anlegen und bei der Anmeldung ohne Passwort muss das Gerät die Person prüfen (PIN, Fingerabdruck oder Gesicht). Den privaten Schlüssel erhält der Auftragnehmer nicht; er speichert den öffentlichen Schlüssel mit Kennung, Name, Zähler und Verwaltungsangaben. Ein Passkey gilt nur für die Adresse des Portals. Jede Aufgabe gilt einmal und höchstens fünf Minuten, gespeichert nur als Prüfsumme und nach Einlösung oder Ablauf gelöscht. Konten der Plattformadministration und des Supports können keine Passkeys anlegen; ein gesperrtes Nutzerkonto meldet auch ein Passkey nicht an
• privilegierte Konten des Auftragnehmers: Die Plattformadministration meldet sich nur über einzeln berechtigte Konten in Google Workspace an, wo ein zweiter Faktor erzwungen ist; die Konten bei Cloud-, Code-, Mail- und Zahlungsanbietern tragen ebenfalls einen zweiten Faktor
• Sperrung der Anmeldung mit Passwort nach zehn Fehlversuchen für fünfzehn Minuten; die Anmeldung mit einem Passkey bleibt möglich
• optional Anmeldung über das Unternehmenskonto (Single Sign-on) mit Domainnachweis
• Sitzungen laufen ab; eine Person kann alle ihre Sitzungen zugleich beenden, und eine Sperre des Zugangs beendet sie ebenfalls

• Rollen mit abgestuften Rechten: Admin, Analyse, Lesezugriff
• Mandantentrennung zusätzlich in der Datenbank über Row-Level Security; ein Zugriff ohne Mandantenkontext liefert keine Zeile. Die Tabellen gehören einer eigenen Eigentümerrolle, die Dienste verbinden sich mit einer Rolle ohne Eigentumsrechte und prüfen beim Start, dass sie die Filter nicht umgeht
• API-Schlüssel mit begrenzten Rechten und Ablaufdatum; ein abgelaufener Schlüssel wird abgewiesen
• Zugangsdaten zu Diensten des Auftraggebers (Schlüssel und Token von Werbekonten, weiteren Kostenquellen und E-Mail-Plattformen, Ziele der Rückgabe, Adressen von Slack und Teams, Signiergeheimnisse von Zahlungsanbietern und Webhooks, die Google Search Console) und die Adresse einer Tabelle, aus der Kosten gelesen werden: mit AES-256-GCM verschlüsselt und an Mandant und Zweck gebunden; der Hauptschlüssel liegt im Secret Manager. Sie werden nicht protokolliert und im Portal nicht vollständig angezeigt; das Signiergeheimnis eines Webhooks zeigt das Portal einmal beim Anlegen. Beim Trennen wird das Zugangsdatum gelöscht.
• Support-Zugriff nur, solange der Mandant ihn in seinen Einstellungen erlaubt (voreingestellt eingeschaltet, jederzeit abschaltbar; das Abschalten beendet laufende Zugriffe), nur zur Bearbeitung eines Anliegens des Auftraggebers oder einer Störung, befristet, mit Begründung eigens protokolliert und im Änderungsprotokoll des Mandanten angezeigt

• Transport ausschließlich über TLS; HSTS ist gesetzt
• Trackingelemente sind signiert; es gibt keinen offenen Redirect und einen Schutz gegen Wiedereinspielung
• serverseitige Ereignisse können signiert übermittelt werden; die Signatur wird gegen den rohen Rumpf geprüft
• eine Weitergabe an Werbeplattformen findet nur auf ausdrückliche Einstellung des Mandanten statt; zur Werbezuordnung geht die Klickkennung der jeweiligen Plattform hinaus, je Ziel dazu die Kennung des Ereignisses und gegebenenfalls die Bestellnummer zur Meldung und Dublettenprüfung sowie Wert, Währung und Zeitpunkt; eigene Personen- oder Gerätekennungen gehen nicht hinaus

Änderungen an Einstellungen, Zugängen, Kampagnen, Trackingelementen und Datenschutzvorgängen werden mit Person, Zeitpunkt und – wo angegeben – Begründung protokolliert. Das Protokoll ist im Produkt einsehbar und wird 180 Tage aufbewahrt; wird ein Vorfall untersucht, wird der benötigte Ausschnitt gesondert gesichert.

Weitere Auftragsverarbeiter werden vertraglich nach Art. 28 DSGVO gebunden, vor dem Einsatz geprüft und in der Anlage „weitere Auftragsverarbeiter“ offengelegt. Ein neuer unmittelbarer Auftragsverarbeiter wird 30 Tage vor seinem Einsatz angekündigt, Änderungen weiterer Stufen nach Abschnitt 7 des Vertrags.

• tägliche Sicherung der Datenbank; in der Produktionsumgebung zusätzlich Wiederherstellung auf einen Zeitpunkt der letzten sieben Tage. Die Wiederherstellung aus der täglichen Sicherung in eine neue Instanz ist am 16.09.2026 in der Entwicklungsumgebung in der Cloud geprüft worden, in der Produktionsumgebung noch nicht; die Wiederherstellung auf einen Zeitpunkt ist noch nicht geprüft. Eine Wiederholung je Quartal ist vorgesehen
• Verarbeitung über eine Warteschlange mit Wiederholung und Fehlerspeicher: Fällt ein Verarbeitungsschritt aus, bleiben angenommene Ereignisse in der Warteschlange und werden nachgeholt. Das schützt nicht vor jedem Verlust: Was während eines Ausfalls der Annahme nicht ankommt, lässt sich nicht nachträglich erheben, und nach einer Wiederherstellung aus einer Sicherung können Daten seit dem Wiederherstellungspunkt fehlen
• Begrenzung der Annahmerate je Mandant, damit ein einzelner Absender den Betrieb nicht beeinträchtigt
• Benachrichtigung des Mandanten, wenn keine Daten mehr ankommen – fehlende Messzeit lässt sich nicht nachträglich erheben

Daten verschiedener Mandanten werden logisch getrennt und zusätzlich durch Row-Level Security abgesichert. Test- und Produktivdaten liegen in getrennten Umgebungen; Testdaten fließen in keinen Bericht und lassen sich jederzeit zurücksetzen.

• keine IP-Adressen im Ereignisbestand, auch nicht als Prüfsumme; bei der Übertragung und zur Begrenzung der Anfragen werden sie verarbeitet, zur Begrenzung höchstens zehn Minuten im Arbeitsspeicher
• Klartext-E-Mail-Adressen und Telefonnummern führen zur Ablehnung des Ereignisses
• kein Fingerprinting, keine probabilistische Zuordnung
• ohne passende Einwilligung wird kein Werbeereignis gespeichert, auch nicht roh

Eine Maßnahme, die niemand nachhält, ist eine Absicht. Deshalb steht hier auch der Takt.

• Rechteprüfung: Mitgliedschaften und Rollen vierteljährlich, erteilte Supportzugriffe monatlich, Dienstkonten bei jeder Änderung an der Infrastruktur
• Eintritt, Wechsel, Austritt: Zugriff nur über ein benanntes Konto mit zweitem Faktor; beim Austritt Mitgliedschaften entfernen, Sitzungen widerrufen und Zugangsdaten wechseln – am letzten Arbeitstag, nicht danach
• Schwachstellen: automatische Meldungen zu Abhängigkeiten, Behandlung nach Schwere (kritisch spätestens sieben Tage, hoch dreißig), jede Auslieferung baut neu
• Wirksamkeit: Mandantentrennung, Einwilligung, Sperrliste, Löschwege und Ratenbegrenzung haben eigene Tests, die vor jeder Auslieferung laufen

Die Datenbankinstanz hat eine öffentliche Adresse. Erreichbar ist sie trotzdem nicht: Die Liste erlaubter Netze enthält keines, jede Verbindung muss verschlüsselt sein, und die Anwendung verbindet sich über den Socket des Connectors. Der Connector allein wäre kein Beleg – die Freigabe ist es.

Wiederherstellungsproben: Am 16.09.2026 wurde in der Entwicklungsumgebung in der Cloud die tägliche Sicherung in eine neue Instanz wiederhergestellt, mit Anmeldung und Bericht gegen den zurückgespielten Bestand. Am 24.09.2026 wurde ebenda mit einer echten Sicherung auf einer gesonderten Instanz geprobt, dass Löschungen, Widersprüche und Widerrufe seit dem Sicherungszeitpunkt vor der Freigabe nachgezogen werden. In der Produktionsumgebung ist noch keine Probe gelaufen, und die Wiederherstellung auf einen Zeitpunkt ist nicht geprüft.

Ein externer Penetrationstest steht aus. Was hier offen ist, bleibt offen genannt, solange es offen ist.