Verzeichnis von Verarbeitungstätigkeiten (Art. 30 DSGVO)

Dieses Dokument wird in mehreren Sprachen veröffentlicht. Bei Abweichungen zwischen den Sprachfassungen ist die polnische Fassung verbindlich.

Fassung 1.2 · Stand: 29. Oktober 2026

1. Wie dieses Verzeichnis zu lesen ist

Dies ist das Verzeichnis von Verarbeitungstätigkeiten nach Art. 30 DSGVO für formexposed. Es ist keine Datenschutzerklärung und keine Werbung. Seine Aufgabe ist es, einer Aufsichtsbehörde, einem Kunden, der uns als Auftragsverarbeiter prüft, oder der nächsten Person, die eine Frage beantworten muss, zu zeigen, was tatsächlich verarbeitet wird, wo es liegt, wer es erhält und wie lange es bleibt. Wir veröffentlichen es, weil ein Prüf- und Überwachungsdienst für Formulare selbst prüfbar sein sollte.

Drei Regeln haben die Abfassung bestimmt.

1. Gemessen statt beabsichtigt. Eine Aussage über Datenfelder, Fristen, Empfänger oder Schutzmaßnahmen steht nur dort, wo der Programmcode, das Datenbankschema oder eine Messung sie trägt. Was geplant ist, heißt „geplant“. Was ab Werk ausgeschaltet ist, heißt „ab Werk aus“. Wo wir etwas nicht belegen können, sagen wir das.
2. Die Aufbewahrung wird zweimal angegeben. Einmal je Verarbeitung und einmal in Abschnitt 6 als Gesamtbild: welcher nächtliche Lauf welche Daten löscht und welche Daten er nicht erfasst. Ein Verzeichnis, das eine Löschfrist behauptet, die nur für einen Teil der Daten gilt, ist schlechter als eines, das den offenen Punkt benennt.
3. Offene Punkte stehen im Text, nicht in einer Fußnote. Abschnitt 8.1 nennt Maßnahmen, die noch nicht umgesetzt sind, Abschnitt 10 die offenen Punkte mit den geplanten Maßnahmen. Ein Verzeichnis ist ein Arbeitsmittel, keine Bescheinigung.

Datenfelder statt Tabellennamen. Je Verarbeitung nennen wir die gespeicherten Daten als verständliche Felder. Der Name der Datenbanktabelle steht in Klammern dahinter, damit ein Prüfer die Stelle findet, zum Beispiel „Anmeldeversuche (login_attempts)“. Die Feldlisten wurden aus dem Datenbankschema abgeleitet, nicht aus der Erinnerung.

Fristen als Platzhalter. Wo eine Frist im Verwaltungsbereich einstellbar ist, steht sie hier so, wie der nächtliche Lauf sie liest: Die Zahl, die Sie sehen, kommt aus derselben Einstellung, nach der gelöscht wird. Fest im Programm stehende Fristen nennen wir als Zahl.

Messgrundlage. Schema, Code und Einstellungen wurden am 11. Oktober 2026 auf dem Entwicklungssystem gemessen, das dem Produktivsystem in Code und Schema entspricht. Zeilenzahlen aus dem Entwicklungssystem geben wir nicht an; sie enthalten Testdaten und sagen über den Betrieb nichts aus.

Bewusst weggelassen. Dieses Verzeichnis nennt keine Rechnernamen, internen Netzadressen, Ports, Benutzernamen oder Softwareversionen unserer Server. Solche Angaben helfen einem Angreifer und keinem Betroffenen. Aus demselben Grund beschreiben wir offene Punkte bei der Absicherung unserer eigenen Server nur allgemein (Abschnitt 8.1): Das Risiko benennen wir, den Weg dorthin nicht. Einer Aufsichtsbehörde legen wir die Einzelheiten auf Anfrage vor.

Rechtsnatur. Dieses Verzeichnis ist die Dokumentation, die wir nach Art. 30 DSGVO für die Aufsichtsbehörde führen; veröffentlicht wird es freiwillig. Es ist nicht Bestandteil eines Vertrags und begründet keine Zusicherung, Garantie oder Beschaffenheitsvereinbarung gegenüber Kunden oder Dritten. Was wir Kunden schulden, regeln die Allgemeinen Geschäftsbedingungen, der Auftragsverarbeitungsvertrag und dessen Anlagen; für diese Pflichten gehen sie diesem Verzeichnis vor. Das Verzeichnis beschreibt den Stand zum Datum dieser Fassung. Einordnungen wie „offener Punkt“ oder „Bewertung“ geben unsere eigene Einschätzung wieder und nehmen keine rechtliche Würdigung durch eine Aufsichtsbehörde oder ein Gericht vorweg; als „geplant“ bezeichnete Maßnahmen sind Vorhaben ohne zugesagten Termin.

2. Der Rechtsträger und warum dieses Verzeichnis zwei Hälften hat

Feld	Eintrag
Rechtsträger	LW IT Solutions Company Lukas Wójcik, Einzelunternehmen, eingetragen im polnischen Gewerberegister (CEIDG); Inhaber Lukas Wójcik
Anschrift	al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polen
Steuerliche Kennungen	NIP 7252266190, USt-IdNr. PL7252266190
Kontakt	contact@lukaswojcik.com; das Support-Fenster (Fragezeichen in der Navigation); die Kontaktseite
Dienst	formexposed: Prüfung, Überwachung und Absicherung von Kontaktformularen auf Websites (App unter formexposed.com, Landingpage unter form.exposed)
Vertreter nach Art. 27 DSGVO	Entfällt. Der Rechtsträger ist in der Union (Polen) niedergelassen.
Datenschutzbeauftragter	Nicht benannt. Die Bewertung nach Art. 37 steht in Abschnitt 9.
Zuständige Aufsichtsbehörde	Prezes Urzędu Ochrony Danych Osobowych (UODO), ul. Moniuszki 1A, 00-014 Warszawa
Hosting	Eigene Server in Polen: ein Webserver mit Anwendung und Datenbank und ein Scan-Server mit lokalem Sprachmodell im selben internen Netz. Kein Rechenzentrum oder Cloud-Anbieter eines Dritten.

formexposed nimmt gegenüber verschiedenen Personengruppen verschiedene Rollen ein. Wer sie vermischt, bekommt ein Verzeichnis, das für keine Gruppe stimmt.

• Verantwortlicher (Teil B, Art. 30 Abs. 1). Für die Daten unserer eigenen Kunden und ihrer Teammitglieder (Konto, Anmeldung, Abrechnung, Support, Protokolle), für Besucher unserer eigenen Website, für Prüfungen ohne Konto (kostenloser Check, Header-Werkzeug, Studie, Interessenten-Prüfung) und für die Missbrauchsabwehr sind wir selbst verantwortlich.
• Auftragsverarbeiter (Teil A, Art. 30 Abs. 2). Für personenbezogene Daten Dritter, die ein Kunde in den Dienst einbringt oder die bei einer Leistung für ihn anfallen, handeln wir in seinem Auftrag: Kopien echter Formularmails in der Zustellungsprüfung, Abonnenten seines Kundenportals, Empfänger seiner Alarme, Personen, die auf seinen geprüften Seiten zufällig sichtbar sind, Zugangsdaten seines Testkontos, sein eingefügter Formular-Code. Grundlage ist der Auftragsverarbeitungsvertrag, der bei der Registrierung mit allen Kunden geschlossen wird.
• Nur beim Kunden. Einige Funktionen des WordPress-Plugins und der TYPO3-Erweiterung verarbeiten Daten ausschließlich auf der Website des Kunden, ohne dass sie uns erreichen (Quarantäne, Rettungsnetz, Rechenrätsel, Speicherfristen, lokale Zähler, Recorder). Sie sind keine Verarbeitung durch uns und stehen deshalb in keinem der beiden Teile. Wir beschreiben sie dennoch am Ende von Teil A, damit die Grenze sichtbar ist.

Die Trennung ist im Code angelegt, nicht nur im Text: Die Zustellungsprüfung schreibt aus einer echten Formularmail nur Zeitpunkt, Zuordnung und Echtheitsergebnis in die Datenbank; die Bildschirmfotos der Browserprüfungen maskieren Eingabefelder; Testkonto-Zugangsdaten werden so verschlüsselt, dass der Webserver sie nicht mehr lesen kann. Die Einzelheiten stehen bei den Einträgen.

Die Abschnitte 6 bis 11 gelten für beide Hälften: Aufbewahrung, automatisierte Entscheidungen, technische und organisatorische Maßnahmen, Datenschutzbeauftragter, offene Punkte und die Pflege dieses Verzeichnisses.

Umfang. Dieses Dokument ist der Teil des Verzeichnisses, der den Dienst formexposed betrifft. Verarbeitungen desselben Rechtsträgers für andere Dienste werden in deren eigenem Verzeichnis geführt; die allgemeine Buchhaltung und Unternehmensverwaltung außerhalb des Dienstes sind nicht Gegenstand dieses Teils.

3. Teil A – Art. 30 Abs. 2: Verarbeitungen im Auftrag der Kunden

A.0 Beteiligte

Feld	Eintrag
Auftragsverarbeiter	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polen; contact@lukaswojcik.com
Verantwortliche	Die Kunden von formexposed: Unternehmen und Agenturen, die Domains im Konto führen und Funktionen nutzen, bei denen Daten Dritter anfallen. Bei Agenturen kann zusätzlich deren Endkunde Verantwortlicher sein; die Agentur handelt dann ihm gegenüber als Auftragsverarbeiter und wir als weiterer Auftragsverarbeiter.
Liste der Verantwortlichen	Bestandteil dieses Verzeichnisses, geführt in elektronischer Form (Art. 30 Abs. 3 DSGVO) im System des Dienstes und in dieser öffentlichen Fassung nicht abgedruckt, weil sie personenbezogene Daten der Kunden enthält und mit jedem neuen Kunden veralten würde: Eigentümer jedes Arbeitsbereichs mit Name, E-Mail-Adresse und Firma aus dem Kundenkonto (Anschrift und USt-IdNr. nur bei Stripe) (users, workspaces, workspace_users), dazu die Domains des Arbeitsbereichs (domains). Einer Aufsichtsbehörde stellen wir sie auf Anfrage als Auszug bereit.
Vertreter und Datenschutzbeauftragte der Verantwortlichen	Ein eigenes Feld dafür gibt es im System nicht. Hat ein Kunde einen Vertreter nach Art. 27 DSGVO oder einen Datenschutzbeauftragten benannt, kann er ihn uns mitteilen; die Mitteilung führen wir zusammen mit der Liste der Verantwortlichen.
Vertreter des Auftragsverarbeiters	Entfällt (in Polen niedergelassen).
Datenschutzbeauftragter	Nicht benannt (Abschnitt 9).
Weisungen	Die Weisung ergibt sich aus dem Auftragsverarbeitungsvertrag und aus den Einstellungen, die der Kunde selbst vornimmt: Er schaltet die Zustellungsprüfung ein, legt Alarmziele an, hinterlegt ein Testkonto, richtet ein Kundenportal ein. Ohne diese Handlung findet die jeweilige Verarbeitung nicht statt.
Technische und organisatorische Maßnahmen	Abschnitt 8 und die Seite Technische und organisatorische Maßnahmen gelten für jede Verarbeitung in Teil A. Besondere Maßnahmen stehen beim jeweiligen Eintrag.

A.1 Zustellungsprüfung – Kontrollkopie von Formularmails

Feld	Eintrag
Zweck	Prüfen, ob die Mail aus dem Kontaktformular des Kunden tatsächlich versandt wird und wie sie authentisiert ist (SPF, DKIM, DMARC, Ausrichtung). Nach einer angenommenen aktiven Test-Einsendung muss deren Kopie binnen einer einstellbaren Wartezeit (derzeit 3 Stunden) im Kontrollpostfach ankommen, sonst entsteht der Alarm „Testmail nicht angekommen“. Aus den Kopfzeilen werden außerdem die Echtheit der Formularmail, der genutzte Mail-Dienst und die Versand-Adresse für die Blocklisten-Prüfung abgeleitet.
Voraussetzung	Bezahlter Tarif, verifizierte Domain, vom Kunden eingeschaltet. Der Kunde trägt eine eigene Kontrolladresse mit Kennung (Form „delivery+Kennung@…“) als Blindkopie in die Benachrichtigung seines Formulars ein. Ohne eingerichtetes Kontrollpostfach ist die Funktion nicht verfügbar.
Kategorien betroffener Personen	Besucher der Website des Kunden, die sein Formular absenden; Personen, deren Daten ein Besucher in die Nachricht schreibt; Mitarbeiter des Kunden, die als Empfänger in den Kopfzeilen stehen.
Kategorien personenbezogener Daten	Im Kontrollpostfach (beim Mail-Dienstleister): die vollständige Kopie jeder Formularmail, also auch echte Anfragen mit Name, E-Mail-Adresse, Telefonnummer und Freitext, bis zur Löschung. Vom Abruf gelesen: die Kopfzeilen und höchstens die ersten 8 KB des Textes. In der Datenbank: Zeitpunkt des Eingangs, Zuordnung zur Domain und gegebenenfalls zum Testlauf (delivery_log); das letzte Echtheitsergebnis je Domain mit SPF-, DKIM- und DMARC-Ergebnis, Ausrichtung, Absender-Domain, signierenden Domains und der Adresse des versendenden Mailservers (Echtheitsfeld der Domain in domains). Inhalt, Betreff und Absenderadresse des Besuchers werden nicht in die Datenbank geschrieben.
Hinweis zur Absender-Domain	Trägt ein Formular die Adresse des Besuchers als Absender ein (eine Fehlkonfiguration, die die Prüfung gerade aufdecken soll), steht im Echtheitsergebnis die Domain dieser Adresse, nicht die Adresse selbst. Bei einer persönlichen Domain eines Besuchers kann auch das ein personenbezogenes Datum sein. Es wird beim nächsten Eingang überschrieben.
Herkunft	Das Formular auf der Website des Kunden, über die vom Kunden eingetragene Blindkopie.
Rechtsgrundlage (vom Verantwortlichen bestimmt)	Bestimmt der Kunde. Unser Textvorschlag für seine Datenschutzerklärung stützt die Kopie auf Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse am zuverlässigen Empfang von Anfragen). Der Kunde informiert seine Besucher über diesen Datenfluss; der Auftragsverarbeitungsvertrag verpflichtet ihn dazu.
Empfänger	Der Mail-Dienstleister, der das Kontrollpostfach führt (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). Die Kopie geht direkt dorthin: Sie kommt nur an, wenn die MX-Einträge unserer Domain auf dieses Postfach zeigen (die Liste vor dem Start prüft das); über eine Weiterleitung erreicht sie das Postfach nicht. Der Kunde sieht auf der Domain-Seite nur Zeitpunkt, Zuordnung und Echtheitsergebnis. Verschlechtert sich das Echtheitsergebnis, nennt der Alarm an den Kunden und an die von ihm gewählten Kanäle die Absender-Domain, wenn sie nicht zur Website gehört (A.3, 4.1).
Drittland	Abhängig vom Mail-Dienstleister; siehe Abschnitt 4. Der Vertrag mit dem vorgesehenen Dienstleister und die Übermittlungsgrundlage sind noch nicht dokumentiert.
Frist	Die Mail wird nach erfolgreicher Verarbeitung zur Löschung markiert und im selben Lauf aus dem Postfach entfernt, auch wenn sie keiner Domain zugeordnet werden kann. Der Abruf läuft mit dem Statuslauf alle fünf Minuten, solange die Überwachung im Verwaltungsbereich eingeschaltet ist (srv/cron_status.php, cfg/zustellung_lib.php). Scheitert der Abruf oder das Löschen, bleibt die Mail bis zum nächsten erfolgreichen Lauf im Postfach. Die Zuordnungen in delivery_log löscht derselbe Abruf nach 180 Tagen. Das Echtheitsergebnis lebt mit der Domain.
Was der Nachweis belegt	Nur der Eingang der Kopie, die dem konkreten Testlauf zugeordnet ist, im Kontrollpostfach. Er beweist weder den Eingang beim eigentlichen Empfänger noch einen Eintrag im CRM. Eine native Bestätigung aus HubSpot wird nicht angeboten.
TOM	Abschnitt 8. Besonders: Inhalt wird nur im Arbeitsspeicher ausgewertet; keine Speicherung von Text, Betreff oder vollständigen Absenderadressen; Löschung unabhängig davon, ob eine Zuordnung gelang.

Die Zustellungsprüfung ist die einzige Funktion, bei der echte Nachrichten von Besuchern unserer Kunden bei uns ankommen. Deshalb ist sie Auftragsverarbeitung, nicht eine Leistung in eigener Verantwortung, und deshalb ist die Zeit im Postfach die eigentliche Risikogröße: Im Normalfall sind es Minuten, bei einer Störung des Abrufs so lange, bis er wieder läuft. Kopien sollen keine besonderen Kategorien personenbezogener Daten enthalten; technisch verhindern können wir das nicht, denn was ein Besucher schreibt, entscheidet er.

A.2 Kundenportal und Monatsbericht an Abonnenten

Feld	Eintrag
Zweck	Eine Agentur (Business-Tarif) zeigt ihren Endkunden unter eigener Marke den Zustand ihrer Domains (Portal unter einer Zufallsadresse, optional mit Passwort, optional unter einer eigenen Subdomain der Agentur). Der Endkunde kann dort selbst einen monatlichen Bericht per E-Mail bestellen. Der Bericht geht im Namen der Agentur hinaus.
Kategorien betroffener Personen	Endkunden der Agentur und deren Mitarbeiter, die den Bericht bestellen; Personen, die das Portal aufrufen.
Kategorien personenbezogener Daten	Abonnent: E-Mail-Adresse, Sprache, Bestätigungskennung, Zeitpunkt der Bestellung und IP-Adresse bei der Bestellung, Zeitpunkt der Bestätigung (Double-Opt-in), Zeitpunkt der Abmeldung, zuletzt versandter Monat (client_subscribers). Portal: Name, Auswahl der Domains, Zufallskennung, Passwort nur als Hash, anlegende Person, Zeitpunkt, Widerruf (client_portals). Aufrufe des Portals erscheinen im Seitenaufrufprotokoll (B.2).
Herkunft	Vom Abonnenten selbst im Portal eingegeben.
Rechtsgrundlage (vom Verantwortlichen bestimmt)	Einwilligung des Abonnenten, eingeholt im Double-Opt-in-Verfahren; Verantwortliche ist die Agentur. Wir schreiben niemandem, der sich nicht selbst eingetragen und bestätigt hat.
Empfänger	Die Agentur (sieht ihre Abonnenten); der Mail-Dienstleister (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) für Bestätigungsmail und Bericht.
Drittland	Über den Mail-Dienstleister; siehe Abschnitt 4.
Frist	Nächtlicher Löschlauf (cfg/fristen_lib.php, Teil „Portal-Abonnenten“): nie bestätigte Bestellungen nach 30 Tagen; abgemeldete Abonnenten drei Jahre nach der Abmeldung, als Nachweis der früheren Einwilligung. Bestätigte, nicht abgemeldete Abonnenten bleiben, solange der Arbeitsbereich der Agentur besteht. Ein widerrufenes Portal wird nur gesperrt, nicht gelöscht; seine Abonnenten erhalten keine Berichte mehr, ihre Daten bleiben aber stehen (Abschnitt 10). Mit dem Arbeitsbereich gehen Portale und Abonnenten sofort (fe_arbeitsbereich_daten_loeschen()). Versandte Berichte stehen 30 Tage im Postausgang (B.25).
TOM	Abschnitt 8. Besonders: Portal-Passwort nur als Hash, Rateversuche begrenzt (zehn je Portal und IP-Adresse, 50 je Portal in 15 Minuten); Abmeldung mit einem Klick in jeder Mail; Portal zeigt nur Zustand und Kennzahlen, keine Einzelbefunde mit Belegen.

A.3 Alarmempfänger, Quittierende und Zuständige des Kunden

Feld	Eintrag
Zweck	Meldungen über Störungen und Veränderungen an die Ziele, die der Kunde für eine Domain anlegt: E-Mail, Webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram. Je Ziel sofort, täglich oder wöchentlich gesammelt, dazu Ziele nur für Eskalationen. Jede Problem-Meldung wird ein Vorfall, den der Empfänger über einen Link quittieren kann. Für überwachte Formulare kann der Kunde eine zuständige Person und ein Fälligkeitsdatum festlegen.
Kategorien betroffener Personen	Mitarbeiter und Dienstleister des Kunden, die er als Alarmziel einträgt oder als Zuständige benennt; Personen, die einen Vorfall quittieren. Teammitglieder mit eigenem Konto stehen zusätzlich in Teil B.
Kategorien personenbezogener Daten	Alarmziel: Kanal, Zieladresse (E-Mail-Adresse, Webhook- oder Chat-Adresse, Telegram-Chat-Kennung), gewählte Ereignisse, Versandart, Signaturgeheimnis für Webhooks, letzter Versand und letzter Fehler (alerts). Versandprotokoll: Ziel, Ereignisse, Status, Fehler, Zeitpunkt (alert_log). Sammelwarteschlange: Meldungszeilen und Link bis zum Versand (alert_queue). Vorfall: Titel, Meldungszeilen, Link, Quittier-Kennung, Zeitpunkt und Name oder E-Mail-Adresse der quittierenden Person, wie sie im Formular eingetragen wird, sonst die Adresse des angemeldeten Mitglieds (alert_incidents). Zustellversuche der Eskalation je Vorfall und Ziel: Zahl der Versuche (höchstens fünf), Zeitpunkte des letzten und des nächsten Versuchs und des Erfolgs, Verweis auf die Mail im Postausgang, Fehler (Tabelle alert_escalation_deliveries). Zuständigkeit: Konto der zuständigen Person und Fälligkeit (in monitored_forms).
Inhalt der Meldungen	Domain, Ereignis, kurze Erläuterung und ein Link zur Domain-Seite. Keine Inhalte von Besuchernachrichten.
Herkunft	Vom Kunden eingetragen; der Quittierende trägt seinen Namen selbst ein; die Telegram-Chat-Kennung entsteht, wenn der Empfänger im Bot „Start“ drückt (B.32).
Rechtsgrundlage (vom Verantwortlichen bestimmt)	Bestimmt der Kunde; regelmäßig die Organisation seiner eigenen Betriebsabläufe (Art. 6 Abs. 1 lit. b oder f DSGVO im Verhältnis zu seinen Mitarbeitern und Dienstleistern).
Empfänger	Die Betreiber der gewählten Kanäle; siehe 4.1. E-Mail-Alarme über den Mail-Dienstleister (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Drittland	Je nach gewähltem Kanal; mehrere Anbieter sitzen in den USA, Telegram außerhalb der EU ohne Angemessenheitsbeschluss. Siehe 4.1.
Frist	Versandprotokoll nach 90 Tagen (nächtlich, fe_alert_log_aufraeumen() aus srv/cron_status.php). Sammelmeldungen 30 Tage nach dem Versand (cfg/kanal_lib.php, bei jedem Sammelversand). Vorfälle, solange sie ungelöst sind; behobene 180 Tage nach der Behebung (cfg/vorfall_lib.php, Eskalationslauf), mit ihnen die Zustellversuche der Eskalation. Alarmziele und Zuständigkeiten bis zur Löschung durch den Kunden oder mit der Domain.
TOM	Abschnitt 8. Besonders: Webhooks mit Signatur über ein eigenes Geheimnis je Ziel; Quittieren erst nach einem Klick (POST), damit Link-Vorschauen in Chat-Programmen nichts auslösen; Alarme in einer Wartungsphase werden nur protokolliert, nicht versandt.

A.4 Zufällig sichtbare Personen auf geprüften Kundenseiten und in Bildschirmfotos

Feld	Eintrag
Zweck	Die Prüfung der Domains im Konto des Kunden (Scan, Monitoring, aktive Prüfung) liest dessen öffentliche Seiten und fotografiert Formulare. Was die Seite selbst anzeigt, kann Personen betreffen, die mit der Prüfung nichts zu tun haben. Diese Daten fallen beiläufig an; Zweck der Prüfung sind sie nicht.
Kategorien betroffener Personen	Personen, deren Name, Foto oder Kontaktdaten auf der geprüften Seite stehen (Ansprechpartner neben dem Formular, Team-Fotos auf der Startseite, Impressumsangaben).
Kategorien personenbezogener Daten	Bildschirmfotos: der sichtbare Bereich der Startseite, jedes sichtbare Formular als Ausschnitt und das Bild der Folgeseite nach einer aktiven Test-Einsendung; abgelegt als Dateien außerhalb des Web-Verzeichnisses, in der Datenbank nur der Verweis (scan_screenshots). Formularaufbau: Seitenadresse, Selektor, Feldnamen, Feldtypen, Feldbeschriftungen, Pflicht- und Sichtbarkeitsmerkmal, Beschriftungen der Absende-Knöpfe (forms, Feld „Feldkarte“); keine Feldwerte. Den Anfang verborgener Felder (bis 24 Zeichen) und Datenattribute (bis 60 Zeichen) liest der Scanner nur während der Prüfung, um Zeitstempel und Token zu erkennen; gespeichert wird nur das Ergebnis. Befunde mit Belegen (findings), Zusammenfassung mit Seitentiteln (scans). Steht eine E-Mail-Adresse als Empfänger im Formular, wird nur ihre Domain gespeichert, nie die Adresse.
Herkunft	Die öffentlichen Seiten der Domain des Kunden, abgerufen vom Scanner.
Rechtsgrundlage (vom Verantwortlichen bestimmt)	Bestimmt der Kunde für die Inhalte seiner eigenen Website. Für uns ist die Verarbeitung Teil der beauftragten Prüfung.
Empfänger	Der Kunde; bei Agenturen deren Endkunde über Portal oder White-Label-Bericht; jeder, der einen Berichtslink erhält (Berichte unter Zufallsadressen, nicht in Suchmaschinen). Ein lokales Sprachmodell auf eigenem Server erhält bei unklarem Formulartyp den Formularaufbau mit Seitentitel, Seitenadresse und sichtbarem Text des Formulars (bis 400 Zeichen) zur Einordnung; Bilder erhält es nicht.
Drittland	Keines.
Frist	Prüfergebnisse einer Domain höchstens 13 Monate, die letzte fertige Prüfung je Domain bleibt (nächtlicher Löschlauf, Teil „alte Prüfergebnisse“). Mit dem Prüfergebnis gehen Formulare, Befunde, Bildverweise und die Bilddateien. Mit der Domain gehen diese Daten sofort (Löschkette in B.15; Ausnahmen in Abschnitt 6.4).
Grenze der Maskierung	Die Bildschirmfotos der vollen Prüfung maskieren nichts: Sie zeigen, was die Seite jedem Besucher zeigt. Formularfelder sind beim Abruf leer, weil der Scanner nichts einträgt; vorbelegte Werte wären sichtbar. Hinter einem Login werden keine Bildschirmfotos aufgenommen (A.5). Die Bilder der Browserprüfungen maskieren Eingabefelder (A.6).
TOM	Abschnitt 8. Besonders: Bilder nur über den Bericht abrufbar, eine fremde Bildkennung liefert „nicht gefunden“; Berichte mit noindex; jede Prüfung läuft in einem eigenen, abgeschotteten Container.

Bei Prüfungen ohne Konto (kostenloser Check, Studie, Interessenten-Prüfung) fallen dieselben Daten an. Dort gibt es keinen Kunden, in dessen Auftrag wir handeln; diese Fälle stehen deshalb in Teil B (B.5, B.7, B.8).

A.5 Testkonto-Zugangsdaten für den Scan hinter dem Login

Feld	Eintrag
Zweck	Formulare lesen, die erst nach einer Anmeldung erscheinen (Kundenbereich, Mitgliederbereich). Der Scanner meldet sich mit einem Testkonto an, das der Kunde auf seiner eigenen Website angelegt hat, und liest die angegebenen Seiten. Er sendet außer dem Anmeldeformular nichts ab, führt dort keinen aktiven Test durch, nimmt keine Bildschirmfotos auf und besucht keine Abmelde-, Lösch- oder Kündigungsadressen. Trägt das Anmeldeformular ein CAPTCHA, bricht er ab; CAPTCHAs werden nicht umgangen.
Voraussetzung	Verifizierte Domain, bezahlter Tarif, Rolle Eigentümer oder Admin, ausdrückliche Bestätigung, dass es sich um ein Testkonto handelt. Höchstens fünf Seiten, alle auf derselben Domain.
Kategorien betroffener Personen	Die Person, auf die das Testkonto lautet (sollte niemand sein; der Kunde soll ein Funktionskonto verwenden); Personen, deren Daten auf den Seiten hinter der Anmeldung stehen.
Kategorien personenbezogener Daten	Benutzername und Passwort des Testkontos, nur verschlüsselt; ein Hinweis auf den Benutzernamen (erstes Zeichen und Länge); Anmeldeadresse, Liste der Seiten, Namen der Anmeldefelder, Erfolgsmerkmal, anlegende Person, Zeitpunkte, letztes Ergebnis als kurzer Code (domain_logins). Für einen laufenden Auftrag eine Kopie des Chiffretexts (Feld „Login-Paket“ in scan_jobs). Aus den Seiten hinter der Anmeldung: Formularaufbau wie in A.4, ohne Bildschirmfotos und ohne Cookies.
Herkunft	Vom Kunden im Konto eingegeben.
Rechtsgrundlage (vom Verantwortlichen bestimmt)	Bestimmt der Kunde. Er sichert zu, dass er über das Testkonto verfügen darf.
Empfänger	Keine. Weder Kunde noch Support noch Programmierschnittstelle können die Zugangsdaten auslesen; die Oberfläche zeigt nur den Hinweis auf den Benutzernamen.
Drittland	Keines.
Schutz der Zugangsdaten	Benutzername und Passwort werden beim Speichern sofort mit dem öffentlichen Schlüssel des Scan-Servers verschlüsselt (X25519, HKDF-SHA256, AES-256-GCM; die Domain ist als Zusatzdaten gebunden, ein Chiffretext lässt sich nicht an eine andere Domain hängen). Den privaten Schlüssel hat nur der Scan-Server. Webserver, Datenbank und Sicherungen enthalten nur Chiffretext; auch wir können ihn dort nicht entschlüsseln. Der Scan-Server entschlüsselt erst für den Lauf, gibt die Zugangsdaten nur über die Standardeingabe in den abgeschotteten Prüf-Container, löscht die Kopie im Auftrag sofort und schreibt sie in kein Ergebnis, Protokoll oder Fehlertext. Auf dem Weg zur Website des Kunden schützt sie nur die Verschlüsselung dieser Website; die Grenzen dieses Transports stehen in Abschnitt 10.
Frist	Hinterlegte Zugangsdaten bis zur Löschung durch den Kunden. Beim Löschen wird der Chiffretext mit Zufallsdaten gleicher Länge überschrieben und die Zeile gelöscht; wartende Aufträge werden geleert (fe_login_loeschen()). Mit der Domain geht die Zeile über einen Fremdschlüssel. Kopien in Aufträgen leert der Scan-Server nach dem Lauf; was übrig bleibt (Auftrag abgebrochen, Scan-Server ausgefallen), leert der Statuslauf spätestens nach einer Stunde (fe_login_aufraeumen(), Teil „login_jobs“). In Datenbanksicherungen steht der Chiffretext, bis die Sicherung nach 14 Tagen abläuft.
TOM	Abschnitt 8. Besonders: asymmetrische Verschlüsselung mit getrennten Schlüsseln; Sperrliste für Abmelde- und Löschpfade; keine Bildschirmfotos hinter der Anmeldung; Funktion nur für bezahlte Tarife und verifizierte Domains; jede Änderung im Aktivitätsprotokoll (ohne Zugangsdaten).

Wir haben bewusst keinen Weg gebaut, Zugangsdaten zum Server, zum CMS-Administrationsbereich oder zu Hosting-Konten des Kunden zu hinterlegen. Das Testkonto ist ein Besucherkonto auf der Website des Kunden, kein Zugang zu seinem System.

A.6 Konfigurierte Formularwege, Browserprüfungen und unabhängige Sonde

Feld	Eintrag
Zweck	Ein überwachtes Formular wird in einem echten Browser (Chromium, WebKit oder beide) bis vor das Absenden durchlaufen: Seite laden, vorgeschaltete Klicks ausführen (höchstens fünf, nie auf ein Eingabefeld oder einen Absende-Knopf), Felder mit erkennbar synthetischen Werten füllen (etwa eine Adresse unter der reservierten Endung .invalid), Mehrschritt-Formulare weiterschalten. Die Browserprüfung sendet nichts ab; das Absenden ist im Browser technisch blockiert. Daneben Zeitmessungen und optische Vergleiche des Formulars.
Kategorien betroffener Personen	Wie A.4 (Personen, die auf der Formularseite sichtbar sind); Mitarbeiter des Kunden, die als Zuständige eingetragen sind (A.3).
Kategorien personenbezogener Daten	Konfiguration: Formularadresse, Selektoren, Einstiegsadresse, Klickschritte, Browserwahl, Bezeichnung, Kritikalität, Zuständigkeit, Fälligkeit (monitored_forms). Ergebnisse je Lauf: Zustand, technischer Fehlergrund, bereinigte Fehlerhinweise, Netzwerk- und Zeitmessungen, ein Bild des Formulars als JPEG von höchstens 32 KB mit maskierten Eingabefeldern (form_browser_runs). Beobachtungen je Prüfung (form_observations), Zeitreihen (form_performance). Aufträge mit Zielliste (Felder „Ziele“ und „Ergebnis“ in scan_jobs).
Testzugänge	Hat der Kunde ein Testkonto hinterlegt (A.5), nutzt die volle Prüfung es auch für konfigurierte Formularwege. Die eigenständigen Browserprüfungen zwischen zwei vollen Prüfungen arbeiten nach dem gemessenen Code ohne Testkonto.
Unabhängige Sonde	Vorgesehen ist eine zweite Prüfstelle an einem anderen Standort, die vor einem Alarm gegenprüft. Sie erhielte Domain, bereinigte Konfiguration und Auftragskennung, keine Eingaben von Besuchern und keine Zugangsdaten. Sie ist derzeit nicht eingerichtet (ab Werk aus). Ohne Sonde gibt es keinen Nachweis von einem zweiten Standort; ein Alarm beruht dann auf der eigenen Messung.
Herkunft	Vom Kunden konfiguriert; Ergebnisse aus dem Abruf der Kundenseite.
Rechtsgrundlage (vom Verantwortlichen bestimmt)	Bestimmt der Kunde für Inhalte seiner Website und für die Zuständigkeiten seiner Mitarbeiter.
Empfänger	Der Kunde; bei eingerichteter Sonde deren Betreiber (heute niemand).
Drittland	Keines.
Frist	Ergebnisse der Browserläufe, erledigte Browser-Aufträge und Zeitreihen nach 13 Monaten (nächtlicher Löschlauf, Teile „browser_runs“, „browser_jobs“, „form_performance“). Konfigurationen, bis die Domain gelöscht wird (einzeln lassen sie sich ändern oder abschalten, nicht löschen); mit der Domain gehen sie samt Läufen, Beobachtungen und Zeitreihen über Fremdschlüssel.
Was die Messung belegt	Zeiten und Zustände aus unserem Prüf-Browser. Sie messen nicht, was echte Besucher erleben, und belegen weder Abschlussquoten noch verlorene Anfragen.
TOM	Abschnitt 8. Besonders: Absenden technisch unterbunden; nur Adressen derselben Domain; maskierte Bilder; abgeschotteter Prüf-Container.

A.7 „Fix it for me“ – eingefügter Formular-Code

Feld	Eintrag
Zweck	Der Kunde fügt den Code seines Formulars ein; ein Sprachmodell auf unserer eigenen Hardware baut das Schutzmodul ein. Zurück kommen die geänderte Datei, ein Patch, das Ergebnis einer Syntaxprüfung und die Angabe, ob der Prüfaufruf tatsächlich eingebaut ist. Ohne eingefügten Code liefert der Dienst ein fertiges Modul mit den Feldnamen aus dem letzten Scan.
Kategorien betroffener Personen	Personen, deren Daten zufällig im eingefügten Code stehen (etwa eine Empfängeradresse, Namen in Kommentaren, Zugangsdaten zu einem Mailserver).
Kategorien personenbezogener Daten	Der eingefügte Code, höchstens 30.000 Zeichen. In der Datenbank nur ein Eintrag im Aktivitätsprotokoll (Aktion „fix_ai“ mit Arbeitsbereich und Zeitpunkt), der die Tagesgrenze von derzeit zehn Aufrufen je Arbeitsbereich zählt.
Herkunft	Vom Kunden eingefügt.
Rechtsgrundlage	Durchführung des Vertrags mit dem Kunden (Art. 6 Abs. 1 lit. b DSGVO) für den Code selbst; für zufällig enthaltene Daten Dritter bestimmt der Kunde.
Empfänger	Keine. Das Sprachmodell läuft auf dem eigenen Scan-Server im internen Netz; kein externer KI-Dienst, auch nicht als Rückfall.
Drittland	Keines.
Frist	Der Code wird nicht gespeichert. Für die Syntaxprüfung entsteht eine temporäre Datei, die unmittelbar danach gelöscht wird. Der Eintrag im Aktivitätsprotokoll wird nach 365 Tagen gelöscht.
Hinweis an den Kunden	Code, der Passwörter, API-Schlüssel oder personenbezogene Daten enthält, sollte vor dem Einfügen bereinigt werden. Wir prüfen den Inhalt nicht.
TOM	Abschnitt 8. Besonders: nur Eigentümer und Admins bezahlter Tarife; der eingefügte Code wird dem Modell als Daten gekennzeichnet übergeben und nie ausgeführt; kein Upload auf fremde Server.

A.8 White-Label-Marke und Ansprechpartner der Agentur

Feld	Eintrag
Zweck	Berichte, Kurzbefunde, Nachweis-Protokolle und das Kundenportal einer Agentur (Business-Tarif) erscheinen unter ihrer Marke, auf Wunsch unter einer eigenen Subdomain der Agentur.
Kategorien betroffener Personen	Ansprechpartner der Agentur, deren Name oder Kontaktdaten in der Kontaktzeile stehen.
Kategorien personenbezogener Daten	Firmenname, Website, Kontaktzeile, Hinweistext an den Endkunden, Akzentfarbe, Darstellung, Logo-Datei, Schalter für den Hinweis auf formexposed, eigene Domain mit Nachweiskennung und Prüfstatus (workspace_branding).
Herkunft	Von der Agentur eingegeben.
Rechtsgrundlage	Durchführung des Vertrags mit der Agentur (Art. 6 Abs. 1 lit. b DSGVO). Soweit die Kontaktzeile Mitarbeiter der Agentur nennt, bestimmt die Agentur die Grundlage.
Empfänger	Jeder, dem die Agentur einen Bericht, Kurzbefund oder Portal-Link gibt.
Drittland	Keines.
Frist	Bis zur Änderung durch die Agentur; mit dem Arbeitsbereich gehen Marke und Logo-Datei (fe_arbeitsbereich_daten_loeschen()). Eine eigene Domain, deren DNS-Nachweis sieben Tage lang nicht stimmt, wird abgeschaltet. Die eigene Domain ist ab Werk aus.
TOM	Abschnitt 8.

A.9 Zählwerte, Zustandsmerkmale und Feldfehler aus Plugin und Erweiterung

Feld	Eintrag
Zweck	Das WordPress-Plugin und die TYPO3-Erweiterung melden einmal am Tag Zahlen über die Formulare der verbundenen Website: abgewehrte Einsendungen je Grund, Einsendungen, versandte und gescheiterte Mails, Zustandsmerkmale der Formular-Einstellungen, gespeicherte Anfragen je Quelle und Frist. Optional, ab Werk aus: Formularereignisse und Feldfehler-Kategorien je Feldposition. Daraus entstehen „Schutz in Zahlen“, Monatsbericht, Funkstille-Alarm und Hinweise auf riskante Einstellungen.
Einordnung	Die Zahlen sind so gebaut, dass sie keine Person beschreiben. Wir führen sie in Teil A, weil sie aus Ereignissen auf der Website des Kunden entstehen, die dessen Besucher auslösen; personenbezogen sind sie nach unserer Auffassung allenfalls in Grenzfällen (eine Website mit sehr wenigen Einsendungen an einem Tag). Die Übermittlung selbst (Schlüssel, Versionen, Host) steht in Teil B (B.20).
Kategorien betroffener Personen	Besucher der Website des Kunden, die ein Formular absenden.
Kategorien personenbezogener Daten	Tageszahlen je Host: abgewehrt gesamt und je Grund, Einsendungen, Mails versandt und gescheitert, Fehlerkategorie des Mailversands (nur eine von vier Kategorien, nie der Fehlertext, weil er Empfängeradressen enthalten kann), reCAPTCHA-Antwortzahlen, gelöschte und freigegebene Anfragen (plugin_stats). Zustand: Versionen einer festen Liste von Formular-, CAPTCHA- und Mail-Plugins, Einstellungsmerkmale als Zahlen, Speicherfristen (plugin_health). Änderungsmeldungen: Name und Version eines aktualisierten Plugins (plugin_changes). Optional: Zähler je Formular und Tag mit Fehlerkategorien je Feldposition (form_metrics). Nie: Eingaben, Feldnamen, Passwörter, Dateien, E-Mail-Adressen, Namen, IP-Adressen oder dauerhafte Kennungen von Besuchern.
Herkunft	Das Plugin auf der Website des Kunden, über eine Programmierschnittstelle mit dem Verbindungsgeheimnis der Website.
Rechtsgrundlage (vom Verantwortlichen bestimmt)	Bestimmt der Kunde; er entscheidet über die Aktivierung der optionalen Zählungen und über die Information seiner Besucher.
Empfänger	Der Kunde. Domains aus Links in abgewehrten Nachrichten gehen in den Schwarmschutz (B.21).
Drittland	Keines.
Frist	Tageszahlen, Änderungsmeldungen und Formular-Zähler nach 13 Monaten (nächtlicher Löschlauf, Teile „plugin_stats“ und „form_metrics“). Zustandsmerkmale werden bei jeder Meldung überschrieben. Alle Plugin-Daten eines Hosts gehen, sobald keine Domain im System den Host mehr führt (sofort beim Löschen der letzten Domain; Altbestand nächtlich, Teil „orphan_hosts“).
Was die Zahlen belegen	Was das Plugin gezählt hat. Sie belegen weder Abschlussquoten noch verlorene Anfragen.
TOM	Abschnitt 8. Besonders: Annahme nur mit gebundenem Schlüsselpaar der Website; nur bekannte Schlüssel und Zahlen werden übernommen, alles andere verworfen; Tage außerhalb eines Fensters von 14 Tagen werden abgewiesen.

A.10 Grenze: was nur auf der Website des Kunden bleibt

Die folgenden Funktionen des WordPress-Plugins und der TYPO3-Erweiterung verarbeiten Daten ausschließlich auf dem Server des Kunden. Sie erreichen uns nicht, und wir haben keinen Zugriff darauf. Verantwortlich ist allein der Website-Betreiber; er entscheidet über Aktivierung, Fristen und die Information seiner Besucher. Das Plugin schlägt ihm dafür Absätze für seine Datenschutzerklärung vor.

Funktion	Was lokal verarbeitet wird	Frist auf der Kundenseite
Quarantäne	Gestoppte Einsendungen mit Grund, freigebbar per Mail an die Adresse der Website	14 Tage
Rettungsnetz	Einsendungen, deren Formularmail gescheitert ist, zum erneuten Versand (ab Werk an)	30 Tage
Rechenrätsel statt reCAPTCHA	Rechenaufgabe im Browser des Besuchers, kein Dienst eines Dritten (ab Werk aus)	–
Speicherfristen	Löschen gespeicherter Anfragen in Formular-Plugins nach der vom Betreiber gewählten Frist (ab Werk aus)	wie eingestellt
Begrenzung von Anfragen	eine kurzzeitig aus der IP-Adresse abgeleitete Kennung, nicht an uns übertragen	kurzzeitig
Lokale Tageszähler	Zählerstände vor der Übermittlung	höchstens 14 Tage
Recorder für Administratoren	technische Selektoren und Navigationsschritte im Sitzungsspeicher des Browsers eines angemeldeten Administrators; Eingaben werden nicht gelesen. Übertragen wird nur die ausgewählte Konfiguration (dann A.6)	höchstens 15 Minuten
Besucherhilfe	gesondert aktivierbar; speichert keine Entwürfe und sendet nicht automatisch erneut	–
Beobachtung neuer Spamregeln	zusätzliche Treffer werden lokal gezählt, ohne automatische Aktivierung	sieben Tage

A.11 Formularschutz (formconfirmed)

Feld	Eintrag
Zweck	Bewertung von Einsendungen über Formulare auf Websites des Kunden, um automatisierte Einsendungen zu erkennen: Ausgabe und Prüfung von Aufgaben (Rechennachweis), Einmal-Prüfzeichen, Ausfüllzeit, Fallenfeld, gehäufte Anfragen; auf Wunsch des Kunden Bewertung des Nachrichtentextes durch ein Sprachmodell. Nur für Kunden, die den Formularschutz einschalten.
Kategorien betroffener Personen	Besucher der Websites des Kunden, die eine Seite mit geschütztem Formular aufrufen oder es absenden.
Kategorien personenbezogener Daten	IP-Adresse (gespeichert nur gekürzt und mit täglich wechselndem Schlüssel gehasht), Adresse und Domain der Seite, Zeitpunkte und Ausfüllzeit, Fallenfeld ausgefüllt ja/nein, Browserkennung im Protokoll des Webservers; nur bei eingeschalteter Inhaltsprüfung der Nachrichtentext (nur im Arbeitsspeicher).
Herkunft	Browser des Besuchers (Aufgabe, Prüfzeichen); Server des Kunden (Prüfanfrage, gegebenenfalls Text).
Empfänger	Der Kunde (Punktzahl, Aktion, Gründe). Keine weiteren; keine Unterauftragsverarbeiter für diese Verarbeitung.
Drittland	Keines.
Frist	Gehashte Kennung 1 Stunde; verbrauchte Prüfzeichen höchstens 11 Minuten; Prüfergebnisse ohne IP-Adresse und ohne Text 30 Tage; Tageszahlen 400 Tage; Protokoll des Webservers 14 Tage; Text keine Speicherung.
TOM	Abschnitt 8; zusätzlich Kürzung und Hash mit Tagesschlüssel, signierte Aufgaben, Einmal-Verwendung, Sprachmodell auf eigener Hardware ohne Protokoll des Textes.

4. Teil A – Empfänger, Unterauftragsverarbeiter und Drittlandübermittlungen

Die folgende Tabelle nennt die Empfänger, die wir selbst einschalten und die Daten aus Teil A erhalten können. Die maßgebliche, fortgeschriebene Liste ist die Seite Unterauftragsverarbeiter; weicht sie von dieser Tabelle ab, ist das ein Befund und kein Formatierungsproblem.

Empfänger	Was er erhält	Drittland	Grundlage	Stand
Namecheap, Inc. (Private Email), Phoenix, Arizona, USA	Kontrollpostfach der Zustellungsprüfung (A.1); Versand von Alarm-Mails (A.3), Bestätigungen und Berichten an Portal-Abonnenten (A.2)	Verarbeitungsort noch zu prüfen; siehe Seite „Unterauftragsverarbeiter“	Auftragsverarbeitungsvertrag; Übermittlungsgrundlage noch zu prüfen	Offen. Der einschlägige Vertrag, die tatsächlichen Verarbeitungsorte und die Übermittlungsgrundlage sind noch nicht dokumentiert. Dieses Verzeichnis bestätigt weder eine Zertifizierung noch einen abgeschlossenen Vertrag.
Namecheap, Inc. (Registrar, DNS; bis zur Einrichtung des Postfachs E-Mail-Weiterleitung)	Bis zur Einrichtung des Postfachs allgemeine eingehende Mail an Adressen unserer Domain; nicht die Kopien der Zustellungsprüfung, die nur bei direkt auf das Postfach zeigenden MX-Einträgen ankommen (A.1)	USA	zu prüfen: Zertifizierung nach dem EU-US Data Privacy Framework oder Standardvertragsklauseln	In Nutzung; Grundlage offen.
Eigener Scan-Server mit lokalem Sprachmodell	Formularaufbau zur Einordnung (A.4), eingefügter Code (A.7), entschlüsselte Testzugänge nur im Lauf (A.5)	–	Eigenbetrieb, kein Dritter	In Nutzung.
Unabhängige Sonde an einem zweiten Standort	Domain, bereinigte Konfiguration, Auftragskennung (A.6)	je nach Standort	vor Inbetriebnahme festzulegen	Nicht eingerichtet.

Hosting: kein Dritter. Anwendung, Datenbank, Bildschirmfotos und Sicherungen liegen auf eigenen Servern in Polen. Bei einem Wechsel zu einem Rechenzentrum oder Cloud-Anbieter ist dieser Absatz neu zu fassen.

4.1 Vom Kunden gewählte Alarmkanäle

Neben den Empfängern, die wir einschalten, gibt es Kanäle, die der Kunde für seine Alarme wählt (A.3). Die Übermittlung löst unser Server aus; Ziel und Anbieter bestimmt der Kunde. Die Auswahl eines Kanals hebt unsere eigenen Pflichten als Auftragsverarbeiter nicht auf. Rolle, Vertrag und erforderliche Garantien für Drittländer sind für den jeweiligen Anbieter festzulegen; für die Chat-Dienste ist das noch nicht abgeschlossen (offene Frage der anwaltlichen Prüfung).

Kanal	Was hinausgeht	Sitz des Anbieters
E-Mail	Domain, Ereignis, Erläuterung, Link; an die eingetragene Adresse	über Namecheap, Inc. (Private Email), Phoenix, Arizona, USA
Webhook an eine frei gewählte Adresse	Ereignis als JSON (Domain, Ereignisse, Zeilen, Link, Zeitstempel), signiert mit dem Geheimnis des Ziels	vom Kunden bestimmt
Slack, Discord, Microsoft Teams, Google Chat	dieselbe Meldung als Chat-Nachricht an die eingetragene Webhook-Adresse	überwiegend USA
Telegram	vom Kunden gewähltes Ziel; die Nachricht verschicken wir über unseren Bot an die verknüpfte Chat-Kennung	außerhalb der EU, kein Angemessenheitsbeschluss; Übermittlungsgrundlage offene Frage der anwaltlichen Prüfung

In keinem Fall geht der Inhalt einer Besuchernachricht hinaus. Die Meldungen tragen Domain, Ereignis und Link.

5. Teil B – Art. 30 Abs. 1: Verarbeitungen in eigener Verantwortung

Verantwortlicher für alles in diesem Teil: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polen, contact@lukaswojcik.com. Kein Vertreter erforderlich (in der Union niedergelassen). Kein Datenschutzbeauftragter benannt (Abschnitt 9). Technische und organisatorische Maßnahmen: Abschnitt 8 und die Seite Technische und organisatorische Maßnahmen. Wie Betroffene ihre Rechte ausüben, beschreibt die Seite Auskunft, Löschung und Ihre weiteren Rechte; Kontoinhaber können ihre Daten selbst als Datei herunterladen (Einstellungen).

Wo wir uns auf berechtigte Interessen stützen (Art. 6 Abs. 1 lit. f DSGVO), nennen wir das Interesse und den Grund, warum ein milderes Mittel nicht reicht. Die Abwägung ist unsere Bewertung; sie ist Teil der anwaltlichen Prüfung.

B.1 Besucher unserer Website – Webserver-Protokolle

Feld	Eintrag
Zweck	Betrieb und Sicherheit der Website und der App: Auslieferung, Fehlersuche, Erkennen von Angriffen und Überlast.
Kategorien betroffener Personen	Alle, die eine Seite von formexposed.com oder form.exposed aufrufen, einschließlich Besuchern von Kundenseiten, deren Browser unser Siegel-Bild lädt (B.18), Empfängern, die einen Bericht- oder Quittier-Link öffnen, und Websites, deren Plugin unsere Schnittstelle aufruft.
Kategorien personenbezogener Daten	Vollständige IP-Adresse, Zeitpunkt, angeforderte Adresse, Statuscode, übertragene Bytes, Herkunftsseite (Referrer), Browserkennung (User-Agent).
Wo gespeichert	Zugriffsprotokolle des vorgeschalteten Proxys und des Webservers als Dateien auf dem Webserver, nicht in der Datenbank.
Herkunft	Der Browser oder das Programm, das die Anfrage stellt.
Rechtsgrundlage	Art. 6 Abs. 1 lit. f DSGVO. Interesse: sicherer und störungsfreier Betrieb. Abwägung: Ohne vollständige Adresse lassen sich wiederholte Zugriffe desselben Absenders nicht zuordnen und Angriffe nicht abwehren; eine gekürzte Adresse trägt diese Unterscheidung nicht. Die Protokolle werden nicht mit anderen Daten zusammengeführt und nach kurzer Frist gelöscht.
Empfänger	Keine.
Drittland	Keines.
Frist	14 Tage: tägliche Rotation mit 14 Ständen, danach überschrieben (Systemdienst zur Protokollrotation, nicht der nächtliche Löschlauf der Anwendung).
TOM	Abschnitt 8.

B.2 Seitenaufrufprotokoll der Anwendung

Feld	Eintrag
Zweck	Sicherheit und Missbrauchserkennung (wer ruft was wie oft auf), Nachvollziehbarkeit von Kontozugriffen, einfache Nutzungsstatistik ohne Analysedienst.
Kategorien betroffener Personen	Alle Besucher der Website und Nutzer der App bei echten Seitenaufrufen (keine Hintergrundabrufe, keine Formularübermittlungen).
Kategorien personenbezogener Daten	Vollständige IP-Adresse, daraus beim Schreiben abgeleitetes Land (lokale Geo-Datenbank, keine Abfrage bei einem Dritten), Konto-Kennung bei angemeldeten Nutzern, aufgerufene Adresse und Herkunftsseite (Zugangskennungen darin, etwa von Report- oder Portal-Links, unkenntlich gemacht), Browserkennung, daraus abgeleitet Geräteart, Betriebssystem und Browser, Sprache, Zeitpunkt (access_logs). Während der „Ansicht als Kunde“ (B.14) wird keine Konto-Kennung gesetzt, damit die Aufrufe des Supports nicht im Protokoll des Kunden stehen.
Herkunft	Die Anfrage des Browsers.
Rechtsgrundlage	Art. 6 Abs. 1 lit. f DSGVO. Interesse: Missbrauchsabwehr und Nachvollziehbarkeit. Abwägung: wie B.1; die Frist ist länger, weil Missbrauchsmuster über Wochen sichtbar werden. Ob die IP-Adresse gekürzt oder die Frist verkürzt werden sollte, ist eine offene Frage der anwaltlichen Prüfung.
Empfänger	Keine. Kontoinhaber erhalten ihre eigenen Aufrufe im Datenexport.
Drittland	Keines.
Frist	60 Tage (nächtlich zwischen 03:00 und 03:05 Uhr, srv/cron_status.php, Einstellung „Seitenaufruf-Protokoll“).
TOM	Abschnitt 8. Die IP-Adresse wird aus einer weitergereichten Kopfzeile nur übernommen, wenn die Anfrage vom eigenen vorgeschalteten Proxy kommt, und dann nur der Eintrag, den dieser Proxy angehängt hat; sonst könnte jeder seine Herkunft frei angeben.

B.3 Cookies und Speicher im Browser

Feld	Eintrag
Zweck	Technisch erforderliche Speicherung: Sitzung, Schutz gegen Anfragefälschung (CSRF), Zählen der Limits für Prüfungen ohne Konto, Anmeldung, auf Wunsch angemeldet bleiben, Darstellung hell oder dunkel.
Kategorien betroffener Personen	Besucher und Nutzer von formexposed.com.
Kategorien personenbezogener Daten	Sitzungscookie bpid (Sitzungskennung; endet mit dem Schließen des Browsers; HttpOnly, SameSite=Lax, Secure bei HTTPS). Cookie bp_remember nur nach Wahl von „Angemeldet bleiben“ (Auswahlkennung und Prüfwert; 30 Tage). Lokaler Speicher bp_theme (hell, dunkel oder System). Im Verwaltungsbereich zusätzlich lokale Anzeigeeinstellungen der Betreiber. Für die Limits wird aus der Sitzungskennung ein Hash gebildet; die Kennung selbst wird nicht gespeichert.
Nicht gesetzt	Keine Analyse-, Werbe- oder Wiedererkennungs-Cookies. Das Partnerprogramm (B.33) arbeitet ohne Cookie. Das Siegel-Bild auf Kundenseiten setzt kein Cookie (B.18). reCAPTCHA kann beim Absenden eines geschützten Formulars Cookies von Google setzen (B.23).
Rechtsgrundlage	Zugriff auf das Endgerät: unbedingt erforderlich für den vom Nutzer gewünschten Dienst (§ 25 Abs. 2 Nr. 2 TDDDG; Art. 399 Abs. 3 PKE). Verarbeitung: Art. 6 Abs. 1 lit. b DSGVO (Konto) und lit. f (Sicherheit, Limits).
Empfänger	Keine.
Drittland	Keines.
Frist	Sitzung; 30 Tage für den Merker. Abgelaufene Merker in der Datenbank löscht der nächtliche Lauf (remember_tokens); beim Abmelden, beim Passwortwechsel und beim Widerruf eines Geräts sofort.
TOM	Abschnitt 8.

B.4 Kostenloser Check ohne Konto – Annahme, Limits und Missbrauchsbeobachtung

Feld	Eintrag
Zweck	Jeder kann eine Domain ohne Konto prüfen lassen. Damit das Eingabefeld nicht zur Waffe gegen fremde Websites wird, gelten gestaffelte Grenzen: eine anonyme Prüfung je Domain in sieben Tagen (danach derselbe Bericht), Grenzen je IP-Adresse und je Sitzung in 24 Stunden, ein Tageslimit für das ganze System, Sperre für sehr junge Domains, Blocklist und Opt-out, nur öffentliche Adressen. Auffällige Muster werden festgehalten und dem Betreiber gemeldet. Die Grenzen je IP-Adresse, je Sitzung und für das ganze System gelten, jeweils gesondert gezählt, auch für die Prüfung aus dem Plugin ohne Konto (ein Plugin mit gebundenem Schlüsselpaar zählt je Website statt je Adresse) und für das Opt-out (B.30); das kostenlose Header-Werkzeug (B.9) hat eigene Grenzen je IP-Adresse und Tag und für das ganze System.
Kategorien betroffener Personen	Personen, die eine Prüfung, ein Header-Werkzeug oder ein Opt-out anstoßen; Server, auf denen ein Plugin installiert ist.
Kategorien personenbezogener Daten	Protokoll jeder Anfrage: Quelle (Check, Plugin, Header-Werkzeug, Opt-out), vollständige IP-Adresse, Hash der Sitzungskennung, geprüfter Host, Land aus der IP-Adresse, angenommen oder abgewiesen mit Grund, Zeitpunkt (check_throttle). Auffälligkeiten: Art (IP-Adresse, Sitzung, Land, System), Schlüssel (bei Art „IP“ die vollständige IP-Adresse), Muster, Schwere, Kurzbeschreibung, Zeitpunkte der Erkennung und der Erledigung, erledigende Person (abuse_flags). Auftrag: Host, Modus, Vertrauensstufe und ein gekürzter Sitzungs-Hash als Auftraggeber-Kennung (scan_jobs). Bericht: Zufallskennung, Host, Sprache, Ablauf, erster Aufruf, Zahl der Aufrufe (reports). Zwischengespeichertes Domainalter aus der Registry-Auskunft (domain_age_cache).
Herkunft	Eingabe der Person; ihre Anfrage; Registry-Auskunft (RDAP) für das Domainalter.
Rechtsgrundlage	Durchführung der angefragten Prüfung: Art. 6 Abs. 1 lit. b DSGVO (Nutzung des kostenlosen Checks nach den Allgemeinen Geschäftsbedingungen); hilfsweise lit. f. Limits und Beobachtung: Art. 6 Abs. 1 lit. f. Interesse: verhindern, dass der Dienst als Werkzeug gegen fremde Websites oder als Spam-Schleuder genutzt wird. Abwägung: Ohne Zuordnung zur Adresse und zur Sitzung ließen sich die Grenzen nicht durchsetzen; die Frist von sieben Tagen ist so kurz wie die längste Grenze, die daraus gezählt wird.
Empfänger	Google (reCAPTCHA beim Absenden, B.23). Für das Domainalter fragt der Scanner den RDAP-Weiterleitungsdienst rdap.org ab, der an die zuständige Registry weiterleitet; übermittelt wird nur der Domainname. Der Betreiber erhält bei einer Auffälligkeit ein Signal über Telegram ohne jede Variable (kein Host, keine Adresse). Den Bericht sieht, wer seinen Zufallslink hat.
Drittland	USA über reCAPTCHA (B.23).
Frist	Anfrageprotokoll 7 Tage (nächtlich, srv/cron_status.php). Erledigte Auffälligkeiten 90 Tage nach der Erledigung; unerledigte bleiben, bis jemand sie erledigt (Abschnitt 10). Anonyme Berichte laufen nach 30 Tagen ab; danach löscht der nächtliche Lauf Bericht, Auftrag, Prüfergebnis, Formulare, Befunde und Bilder (fe_reports_aufraeumen()). Ein Administrator kann Einträge einer Adresse von Hand freigeben; das löscht deren Protokoll der letzten 24 Stunden.
TOM	Abschnitt 8. Notaus für alle anonymen Prüfungen im Verwaltungsbereich; Druckausgleich, der bei Stau keine neuen kostenlosen Prüfungen annimmt.

B.5 Crawler-Prüfung fremder Websites

Feld	Eintrag
Zweck	Sicherheitsprüfung öffentlicher Kontaktformulare: Schutzmaßnahmen gegen Spam und Missbrauch, Datenschutz- und Barrierefreiheitsmerkmale, eingebundene Drittanbieter-Skripte, Verhalten nach Ablehnung im Cookie-Banner, mobile Darstellung. Gilt für Prüfungen ohne Konto (B.4), für Domains im Konto, die noch nicht verifiziert sind, und als Grundlage für Studie (B.7) und Interessenten-Prüfung (B.8). Für verifizierte Domains im Konto handeln wir im Auftrag (A.4).
Verhalten des Crawlers	Eigene Kennung mit Verweis auf die Crawler-Seite; liest vor der Prüfung die robots.txt und bricht ab, wenn ein Verbot die Startseite erfasst (ebenso bei nicht erreichbarer robots.txt oder Serverfehler); Verbote für einzelne Unterpfade werden nicht gesondert beachtet. Formular-Puls, Nachweisabruf, Header-Werkzeug und die Suche nach offen liegenden Dateien lesen die robots.txt nicht. Höchstens acht öffentliche Seiten je Prüfung, dazu bis zu drei Seiten mit Klick auf „Ablehnen“ im Cookie-Banner, bis zu drei Seiten in Telefonansicht, bei verifizierten Domains aktive Proben und bis zu fünf Seiten hinter einem Login (A.5); die Seiten werden nacheinander geladen, nicht parallel; nur öffentliche Adressen, keine internen Netze, Weiterleitungen werden erneut geprüft; Blocklist und Opt-out werden vor der Annahme und im Scanner ein zweites Mal geprüft. Passiv: Ohne Eigentumsnachweis wird für Kunden nichts abgesendet (Ausnahme: interne Prüfungen eigener Test- und Demodomains, B.6).
Kategorien betroffener Personen	Betreiber der geprüften Websites (soweit natürliche Personen, etwa Einzelunternehmer); Personen, die auf den geprüften Seiten zufällig sichtbar sind.
Kategorien personenbezogener Daten	Wie A.4: Seitenadressen und -titel, Formularaufbau (Feldnamen, -typen und -beschriftungen, keine Feldwerte), Schutzmaßnahmen, Drittanbieter-Skripte (Adressen; Konto-Kennungen von Pixeln und Aufzeichnungswerkzeugen werden vor dem Speichern ersetzt), Cookie-Banner-Verhalten, Bildschirmfotos (sichtbarer Bereich der Startseite, Formulare). Steht eine Empfängeradresse im Formular, nur deren Domain (scans, forms, findings, scan_screenshots).
Herkunft	Öffentlich abrufbare Seiten.
Rechtsgrundlage	Art. 6 Abs. 1 lit. f DSGVO. Interesse: die angefragte Sicherheitsprüfung durchführen; Website-Betreiber auf Schwachstellen hinweisen, die ihren Besuchern schaden können. Abwägung: Gelesen wird nur, was jeder Besucher sieht, in geringem Umfang und ohne Absenden; der Betreiber kann seine Domain jederzeit ohne Nachweis dauerhaft ausschließen. Die Information nach Art. 14 DSGVO erfolgt über die Crawler-Seite, das Opt-out und die Datenschutzerklärung; ob das nach Art. 14 Abs. 5 lit. b genügt, ist eine offene Frage der anwaltlichen Prüfung.
Empfänger	Wer den Bericht anstößt und jeder, dem er den Zufallslink gibt; das lokale Sprachmodell auf eigenem Server bei unklarem Formulartyp (Formularaufbau, Seitentitel und -adresse, sichtbarer Text des Formulars). Lückenwarnungen aus Plugin-Versionen erscheinen nie in anonymen Berichten.
Drittland	Keines.
Frist	Anonym: 30 Tage (B.4). Interessenten-Prüfung: 90 Tage (B.8). Studie: bis zur Veröffentlichung (B.7). Domain im Konto: höchstens 13 Monate, die letzte Prüfung bleibt; mit der Domain sofort. Interne Prüfungen des Betreibers ohne Domain und ohne Bericht (etwa von der Kommandozeile angelegt): keine Frist (Abschnitt 10). Temporäre Dateien auf dem Scan-Server werden nach jedem Lauf gelöscht.
TOM	Abschnitt 8. Besonders: eigener Prüf-Container mit entzogenen Rechten, schreibgeschütztem Dateisystem, Speichergrenze und eigenem Netz; doppelte Zielprüfung.

B.6 Aktive Test-Einsendungen

Feld	Eintrag
Zweck	Prüfen, ob ein Kontaktformular eine Einsendung ohne Schutz annimmt, ob CAPTCHA, Falle (Honeypot), Token, Prüfung der E-Mail-Adresse und Mengenbegrenzung serverseitig greifen und ob Kopfzeilen eingeschleust werden können.
Voraussetzung	Für Kunden nur für Domains, deren Verfügungsbefugnis nachgewiesen ist (DNS-Eintrag, Meta-Tag, Datei oder verbundenes Plugin); daneben legt der Betreiber über ein internes Kommandozeilen-Werkzeug Prüfungen mit der Stufe „verifiziert“ für eigene Test- und Demodomains an. Nur bei globalem Schalter an, nur für ein Formular, das sicher als allgemeines Kontaktformular eingeordnet ist. Nie bei Bestellung, Buchung, Anmeldung, Newsletter, Zahlung, Datei-Upload, Pflichtfeldern mit echten Personendaten oder Domains von Behörden, Gesundheits- und Bildungseinrichtungen.
Kategorien betroffener Personen	Mitarbeiter des Kunden, die die Formularmails empfangen.
Kategorien personenbezogener Daten	Die Test-Einsendung enthält keine Personendaten: Absender „FormExposed Security Scanner“, eine eigene Absenderadresse beziehungsweise eine Adresse unter .invalid, ein gekennzeichneter Betreff und ein Text in der Sprache der Seite mit Verweis auf Crawler-Seite und Opt-out und der Prüfnummer. Bei uns gespeichert: Antwort der Seite, Befunde, ein Bild der Folgeseite (wie A.4).
Umfang	Höchstens fünf Einsendungen je Prüfung (Einstellung, Vorgabe 5); wiederkehrend in der Prüffrequenz des Tarifs, im höchsten Tarif täglich.
Herkunft	Auftrag des Kunden.
Rechtsgrundlage	Durchführung des Vertrags mit dem Kunden (Art. 6 Abs. 1 lit. b DSGVO); die Einsendungen gehen an das Formular des Kunden selbst. Für die Empfänger beim Kunden: dessen Organisation.
Empfänger	Der Kunde (seine Formularmail).
Drittland	Keines durch uns.
Frist	Ergebnisse wie A.4.
TOM	Abschnitt 8. Header-Injection wird nur erkannt, nie mit echtem Empfänger ausgeführt; die Prüfung der E-Mail-Adresse nutzt nur eine Domain, die es nicht geben kann.

B.7 Studie „Formular-Sicherheitsindex“

Feld	Eintrag
Zweck	Statistik über den Schutz von Kontaktformularen in einem Land oder einer Branche. Veröffentlicht werden nur Summen, ohne Namen von Websites, Segmente erst ab 20 Seiten mit Formular.
Kategorien betroffener Personen	Betreiber der Websites auf der Liste; zufällig sichtbare Personen.
Kategorien personenbezogener Daten	Wie B.5, nur passiv. Dazu die Liste: Host, Segment, Status, Auftrag (study_domains); Studie mit Titel, Land, Ergebnis-Summen (studies).
Herkunft	Eine vom Betreiber zusammengestellte Liste öffentlicher Websites; die Seiten selbst.
Rechtsgrundlage	Art. 6 Abs. 1 lit. f DSGVO. Interesse: statistische Aussagen über den Stand der Formularsicherheit. Abwägung: passiv, gedrosselt (wenige Aufträge je Lauf), Blocklist und Opt-out gelten, Veröffentlichung nur in Summen, Rohdaten werden gelöscht.
Empfänger	Die Öffentlichkeit, nur Summen.
Drittland	Keines.
Frist	Rohdaten (Prüfergebnisse, Formulare, Befunde, Bilder, Aufträge) werden bei der Veröffentlichung gelöscht (fe_studie_veroeffentlichen()). Die Liste der Hosts mit Segment bleibt danach stehen; für sie und für nie veröffentlichte Studien gibt es keine Frist (Abschnitt 10). Welche Listen geprüft und ob Studien veröffentlicht werden, entscheidet der Betreiber.
TOM	Abschnitt 8.

B.8 Interessenten-Prüfung (Akquise-Modus für Agenturen)

Feld	Eintrag
Zweck	Eine Agentur (Business-Tarif) prüft passiv die Website eines Interessenten und erhält einen Kurzbefund unter ihrer Marke und den passiven Bericht. Wir schreiben niemanden an; den Link gibt die Agentur selbst weiter.
Kategorien betroffener Personen	Betreiber der geprüften Website; zufällig sichtbare Personen; Mitarbeiter der Agentur, die die Prüfung anstoßen.
Kategorien personenbezogener Daten	Wie B.5, nur passiv. Dazu: Arbeitsbereich, anstoßende Person, Host, Zufallskennung des Berichts, Zeitpunkt (prospect_checks).
Herkunft	Eingabe der Agentur; öffentliche Seiten.
Rechtsgrundlage	Art. 6 Abs. 1 lit. f DSGVO (unser Interesse an der Erbringung der Leistung und das Interesse der Agentur an einer fundierten Ansprache). Die Rolle zwischen Agentur und uns und die Pflichten der Agentur bei der Weitergabe sind offene Fragen der anwaltlichen Prüfung: Schickt die Agentur den Befund ungefragt per E-Mail oder ruft sie an, ist das nach Art. 398 PKE und § 7 Abs. 2 UWG auch unter Unternehmen einwilligungsbedürftige Direktwerbung. Das ist Sache der Agentur; die Allgemeinen Geschäftsbedingungen verpflichten sie dazu.
Empfänger	Die Agentur und jeder, dem sie den Link gibt.
Drittland	Keines.
Frist	Bericht und Prüfergebnis laufen nach 90 Tagen ab und werden dann vom nächtlichen Lauf gelöscht (fe_reports_aufraeumen()); der Eintrag der Prüfung wird nach 90 Tagen im täglichen Schwarm-Lauf ab 04:00 Uhr gelöscht (srv/cron_status.php). Mit dem Arbeitsbereich sofort.
TOM	Abschnitt 8. Kontingent je Monat (Einstellung, Vorgabe 30); dieselbe Seite binnen sieben Tagen liefert denselben Befund; Opt-out gilt.

B.9 Header-Werkzeug ohne Konto

Feld	Eintrag
Zweck	Kostenlose Note (A+ bis F) für die Sicherheits-Kopfzeilen der Startseite einer Domain. Zwei Abrufe, kein Browser, kein Formular, keine Einsendung.
Kategorien betroffener Personen	Personen, die das Werkzeug nutzen; Betreiber der geprüften Domain.
Kategorien personenbezogener Daten	Anfrageprotokoll wie B.4 (Quelle „headers“, IP-Adresse, Sitzungs-Hash, Host). Ergebnis: Host, Note, Punkte, ausgewertete Kopfzeilen (header_checks).
Rechtsgrundlage	Art. 6 Abs. 1 lit. f DSGVO, wie B.4 und B.5.
Empfänger	Google (reCAPTCHA, B.23).
Drittland	USA über reCAPTCHA.
Frist	Anfrageprotokoll 7 Tage; Ergebnisse nach derzeit 90 Tagen (nächtlicher Löschlauf, Teil „header_checks“, Einstellung „headers_keep_days“). Für Domains im Konto wird die Note täglich neu bestimmt und mit der Domain gespeichert.
TOM	Abschnitt 8. Grenzen je IP-Adresse und Tag; Opt-out gilt.

B.10 Kundenkonten

Feld	Eintrag
Zweck	Betrieb der Kundenkonten, Arbeitsbereiche und Tarife.
Kategorien betroffener Personen	Kunden (Unternehmer) und ihre Teammitglieder mit eigenem Konto.
Kategorien personenbezogener Daten	E-Mail-Adresse und normalisierte Form, Passwort nur als Hash, Vorname (Pflicht), Nachname und Firma (soweit angegeben); Anschrift und USt-IdNr. speichert die Anwendung nicht, sie werden nur bei Stripe angegeben (B.26); Status, Sprache, Darstellung, Währung, Tarif und Abrechnungsstatus, Stripe-Kunden- und Abo-Kennung, Ende der Abrechnungsperiode, Kündigung zum Periodenende, Bestätigungs- und Zurücksetz-Kennungen mit Ablauf, neue E-Mail-Adresse bis zur Bestätigung, Zeitpunkt der Registrierung, letzte Anmeldung und letzte IP-Adresse, Zeitpunkt des Widerrufs aller Sitzungen, Zwei-Faktor-Daten (B.11), Monatsbericht an/aus, Zeitpunkt der Erinnerungsmail, Freischaltungen durch Codes, Empfehlungscode und Empfehlung (users). Arbeitsbereiche mit Name, Zeitpunkten, Status (workspaces); Mitgliedschaft mit Rolle und Beitrittsdatum (workspace_users).
Herkunft	Registrierung und Einstellungen durch die Person; Abrechnungsstatus von Stripe.
Rechtsgrundlage	Art. 6 Abs. 1 lit. b DSGVO (Vertrag). Letzte IP-Adresse: lit. f (Kontosicherheit).
Empfänger	Stripe (B.26); Mail-Dienstleister für Kontomails (B.25). Mitglieder desselben Arbeitsbereichs sehen Name, E-Mail-Adresse und Rolle der anderen Mitglieder.
Drittland	Über Stripe und den Mail-Dienstleister.
Frist	Bis zur Löschung durch den Kontoinhaber. Dabei gehen eigene Arbeitsbereiche, die niemand sonst nutzt, mit allen Domains und deren Daten; Arbeitsbereiche mit weiteren Mitgliedern gehen an ein anderes Mitglied über, zuerst an Administratoren, unter ihnen an das dienstälteste. Mitgliedschaften, Merker, Geräte, API-Schlüssel, offene Telegram-Codes, Rückmeldungen zu Berichten (B.35) und die Kontozeile werden gelöscht; ein laufendes bezahltes Abo wird vorher bei Stripe sofort beendet, ohne Erstattung (www/ajax.php, fe_konto_reste_loeschen()). Eine Kündigung im Abrechnungsbereich wirkt dagegen zum Ende der Periode; danach läuft das Konto im kostenlosen Tarif weiter. Was bleibt, steht in Abschnitt 6.4. Nie bestätigte Konten ohne Anmeldung werden nach 30 Tagen gelöscht, außer ein weiteres Mitglied hängt an ihrem Arbeitsbereich (nächtlicher Löschlauf, Teil „pending_accounts“). Eine Löschung inaktiver Konten gibt es nicht. Endet der Vertrag über das Konto auf andere Weise, etwa durch unsere Kündigung, löschen wir das Konto spätestens 30 Tage nach dem Vertragsende; das geschieht derzeit von Hand (zugesagt im Auftragsverarbeitungsvertrag).
TOM	Abschnitt 8.

B.11 Anmeldung, Geräte, zweiter Faktor und Aktivitätsprotokoll

Feld	Eintrag
Zweck	Schutz der Konten: Begrenzung von Anmelde- und anderen Passwortversuchen, Anzeige und Widerruf angemeldeter Geräte, Zwei-Faktor-Anmeldung, Nachvollziehbarkeit von Änderungen.
Kategorien betroffener Personen	Kontoinhaber und Teammitglieder; Personen, die eine Anmeldung, eine Registrierung oder das Passwort eines Kundenportals versuchen.
Kategorien personenbezogener Daten	Anmeldeversuche: IP-Adresse, eingegebene E-Mail-Adresse, Erfolg, Zeitpunkt (login_attempts). Geräte: Hash der Sitzungskennung (nie die Kennung selbst), Verknüpfung zum Merker, IP-Adresse, Browserkennung, daraus Browser, Betriebssystem, Geräteart, Zeitpunkte von Anmeldung, letzter Aktivität und Widerruf, bei der „Ansicht als Kunde“ die Kennung des Supports (login_sessions). Merker für „Angemeldet bleiben“: Auswahlkennung, Prüfwert, Ablauf (remember_tokens). Zwei-Faktor: Geheimnis verschlüsselt, Zeitpunkt der Aktivierung, zuletzt genutzter Zeitschritt, Wiederherstellungscodes nur als Hash (in users). Aktivitätsprotokoll: Konto, Arbeitsbereich, Aktion, Ziel, Einzelheiten, IP-Adresse, Land, Zeitpunkt (audit_logs). Versuchszähler für Anmeldung, zweiten Faktor, Passwortbestätigung, Zurücksetzen des Passworts, Registrierung und Passwörter von Kundenportalen: ein HMAC-Schlüssel aus Zweck und Konto-Kennung (bei unbekannter Adresse oder beim Zurücksetzen der kleingeschriebenen E-Mail-Adresse), IP-Adresse, Konto und IP-Adresse zusammen oder Portal-Kennung (auch zusammen mit der IP-Adresse), Zahl der Versuche, Ablauf; E-Mail- und IP-Adresse stehen dort nicht im Klartext (Tabelle auth_attempt_buckets).
Rechtsgrundlage	Art. 6 Abs. 1 lit. b DSGVO in Verbindung mit Art. 32 (Geräteliste, zweiter Faktor) und lit. f (Anmeldeversuche, Aktivitätsprotokoll). Interesse: Konten gegen Übernahme schützen, Änderungen belegen (Art. 5 Abs. 2). Abwägung: Eine gekürzte Adresse beantwortet die Frage „war ich das?“ nicht; das Aktivitätsprotokoll muss einen Streit überdauern, der erst Monate später entsteht.
Empfänger	Keine. Der Kontoinhaber sieht seine Geräte und erhält Anmeldeversuche, Geräte und Aktivitäten im Datenexport; während einer „Ansicht als Kunde“ erscheinen dort weder IP-Adresse noch Browser des Supports.
Drittland	Keines.
Frist	Anmeldeversuche 7 Tage; nach erfolgreicher Anmeldung werden die fehlgeschlagenen Versuche derselben Adresse sofort gelöscht. Versuchszähler mit dem Ende ihres Zeitfensters (derzeit 15 Minuten, für Zurücksetzen und Registrierung eine Stunde); abgelaufene löscht der nächste Zugriff und der nächtliche Lauf. Geräte 90 Tage nach der letzten Nutzung beziehungsweise nach dem Widerruf (nächtlicher Löschlauf, Teil „sessions“), mit dem Konto sofort. Merker mit Ablauf nach 30 Tagen. Aktivitätsprotokoll 365 Tage (nächtlich); beim Löschen eines Kontos bleiben seine Einträge bis zum Fristende bestehen (Abschnitt 6.4).
TOM	Abschnitt 8.

B.12 Nachweis des Vertragsschlusses

Feld	Eintrag
Zweck	Belegen, welche Fassung der Allgemeinen Geschäftsbedingungen, des Auftragsverarbeitungsvertrags und der Datenschutzerklärung ein Kunde bei der Registrierung angenommen beziehungsweise zur Kenntnis genommen hat, und dass er den Dienst für sein Unternehmen nutzt.
Kategorien betroffener Personen	Kunden.
Kategorien personenbezogener Daten	Je Dokument: Konto, Dokument, Fassung (Hash des angezeigten Textes), Anlass, IP-Adresse, Browserkennung, Zeitpunkt (legal_consents). Die angezeigte Fassung selbst mit vollem Text, Sprache, Titel und Adresse einmal je Fassung (legal_versions; enthält keine Personendaten).
Rechtsgrundlage	Art. 6 Abs. 1 lit. b und f DSGVO (Nachweis des Vertragsschlusses, Abwehr von Ansprüchen).
Empfänger	Keine. Der Kontoinhaber erhält seine Nachweise im Datenexport.
Drittland	Keines.
Frist	Solange das Konto besteht; nach Löschung des Kontos vier Jahre ab der Zustimmung, dann nächtlich gelöscht (srv/cron_status.php). Begründung im Code: drei Jahre Verjährung ab Jahresende, aufgerundet. Ob das polnische Recht eine andere Frist nahelegt, gehört zur anwaltlichen Prüfung.
TOM	Abschnitt 8. Fehlt eines der drei Dokumente, ist die Registrierung geschlossen.

B.13 Team-Einladungen

Feld	Eintrag
Zweck	Weitere Personen in einen Arbeitsbereich einladen.
Kategorien betroffener Personen	Eingeladene.
Kategorien personenbezogener Daten	E-Mail-Adresse, Rolle, Einladungskennung, einladende Person, Ablauf, Zeitpunkt der Annahme (workspace_invites); die Einladungsmail im Postausgang (B.25).
Herkunft	Vom einladenden Mitglied eingegeben.
Rechtsgrundlage	Art. 6 Abs. 1 lit. b DSGVO im Verhältnis zum Kunden; gegenüber der eingeladenen Person lit. f (Interesse des Kunden, sein Team einzubinden).
Empfänger	Mail-Dienstleister (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Drittland	Über den Mail-Dienstleister.
Frist	Eine Einladung gilt 14 Tage und nur, solange die einladende Person Eigentümer oder Admin des Arbeitsbereichs ist. Nicht angenommene Einladungen nach Ablauf, angenommene 30 Tage nach der Annahme (nächtlich, srv/cron_status.php und Teil „invites“ in cfg/fristen_lib.php). Mit dem Arbeitsbereich sofort.
TOM	Abschnitt 8.

B.14 „Ansicht als Kunde“ durch den Support

Feld	Eintrag
Zweck	Ein Superadmin sieht die Anwendung so, wie ein Kunde sie sieht, um eine Supportfrage zu klären („bei mir fehlt der Knopf“).
Kategorien betroffener Personen	Der betroffene Kunde; der Superadmin.
Kategorien personenbezogener Daten	Alles, was der Kunde in der Anwendung sieht. Protokolliert: eine eigene Gerätezeile mit Kennung des Superadmins (login_sessions), Beginn und Ende im Aktivitätsprotokoll (audit_logs).
Rechtsgrundlage	Art. 6 Abs. 1 lit. b DSGVO (Support als Teil der Leistung), hilfsweise lit. f.
Grenzen	Höchstens eine Stunde, danach vollständige Abmeldung. Auch das Beenden der Ansicht meldet den Superadmin vollständig ab, einschließlich der Sitzung, aus der er kam; in den Verwaltungsbereich kommt er nur mit einer neuen Anmeldung mit Passwort und zweitem Faktor. Endet sofort, wenn der Superadmin zurückgestuft oder gesperrt wird. Gesperrt ist alles, was das Konto des Kunden verändert: Passwort, E-Mail-Adresse, zweiter Faktor, Geräte, Abo, Export, Löschen, Übergabe. Der Verwaltungsbereich ist während der Ansicht zu. Der Kunde sieht den Zugriff in seiner Geräteliste und im Datenexport als Support-Zugriff.
Empfänger	Keine.
Drittland	Keines.
Frist	Gerätezeile 90 Tage, Aktivitätsprotokoll 365 Tage.
TOM	Abschnitt 8.

B.15 Domains, Eigentumsnachweis und Überwachung

Feld	Eintrag
Zweck	Die Kernleistung für Kunden: Domains im Konto führen, Verfügungsbefugnis nachweisen, regelmäßig prüfen und Veränderungen erkennen. Dazu gehören der Formular-Puls (leichter Abruf ohne Browser alle 10 bis 30 Minuten je nach Tarif), der tägliche Mail-DNS- und Zertifikatswächter, das Ablaufdatum der Domain, Blocklisten, offen liegende Dateien, Versionen von außen, Skript-Inventar, optische Veränderung des Formulars, Störungen von CAPTCHA- und Mail-Anbietern und der Lückenwächter für Formular-Plugins.
Kategorien betroffener Personen	Kunden und ihre Teammitglieder; Betreiber der Domains, soweit natürliche Personen.
Kategorien personenbezogener Daten	Domain mit Host, öffentlicher Kennung, Notiz, Kundenlabel, Nachweisart und -kennung, Prüffrequenz, Überwachung an/aus, Wartungsfenster, Anfragewert, Kennungen für Siegel, Zustellungsprüfung und Deploy-Hook, Plugin-Schlüssel, Zustände und letzte Ergebnisse der Wächter (DNS, Zertifikat, Echtheit der Formularmail, Blocklisten, offene Dateien, Kopfzeilen, Versionen) (domains). Puls je Formularseite (form_pulse). Lücken aus Plugin-Versionen (vuln_hits). Skript-Inventar mit Adresse, Hash, Größe, Freigabe mit freigebender Person und Begründung (script_inventory, script_changes). Prüfungen wie A.4. Für offene Dateien werden Pfad, Schwere und Art gespeichert, nie der Inhalt.
Abrufe bei Dritten	DNS-Abfragen (SPF, DMARC, MX, Nachweis-Eintrag). Registry-Auskunft über RDAP nach dem Verzeichnis der IANA: nur der Domainname. DNS-Blocklisten (SpamCop, PSBL, Mailspike, SURBL; Spamhaus nur mit hinterlegtem Zugang, derzeit nicht): IP-Adressen des Web- und des Mailservers und der Domainname, keine Daten von Besuchern. Google Web Risk nur, wenn eingerichtet (derzeit nicht): die Adresse der Startseite. Zeitstempel-Stelle: nur ein Hashwert (B.19). WPVulnerability: nur die Kennung eines Plugins oder Themes beziehungsweise die WordPress-Version; den Abgleich mit der installierten Plugin-Version machen wir selbst. Statusseiten von Cloudflare, hCaptcha, Google Cloud, SendGrid, Mailgun und Brevo: es wird nichts übermittelt außer dem Abruf selbst.
Herkunft	Kunde; Abrufe der Kundenseite; öffentliche Verzeichnisse.
Rechtsgrundlage	Art. 6 Abs. 1 lit. b DSGVO.
Empfänger	Die genannten Dienste erhalten keine personenbezogenen Daten unserer Kunden, soweit Domainnamen und Server-Adressen eines Unternehmens keine sind; bei Einzelunternehmern kann der Domainname ein personenbezogenes Datum sein. Mitglieder des Arbeitsbereichs sehen die Domain.
Drittland	Die Abrufe können Dienste in Drittländern erreichen (etwa Registry-Auskünfte, Blocklisten). Übermittelt wird nur, was in der Zeile „Abrufe bei Dritten“ steht.
Frist	Bis zur Löschung der Domain. Dann löscht fe_domain_loeschen() sofort Prüfergebnisse, Formulare, Befunde, Bilder, Berichte, Aufträge, Alarmziele und -protokoll, Vorfälle, Telegram-Codes, Zustellungen, Puls, Lücken und Nachweise; über Fremdschlüssel überwachte Formulare, Browserläufe, Testkonto und Formular-Zähler; die Plugin-Daten des Hosts, wenn keine andere Domain ihn führt. Ebenfalls gelöscht werden Skript-Inventar und Skript-Änderungen der Domain; eine eigene Frist haben sie nicht (Abschnitt 6.4). Prüfergebnisse höchstens 13 Monate, die letzte bleibt.
TOM	Abschnitt 8. Wächter für offene Dateien und Versionen nur für verifizierte Domains, höchstens ein Abruf je Pfad, nur die ersten 8 KB; ungefragt fremde Pfade abzuklopfen wäre ein Angriffswerkzeug.

B.16 Alarme, Vorfälle und Eskalation gegenüber dem Kontoinhaber

Feld	Eintrag
Zweck	Den Kunden über Störungen und Veränderungen informieren, Wartungsfenster beachten, Vorfälle quittieren und eskalieren. Soweit die Ziele Dritte sind, handeln wir im Auftrag (A.3); soweit es der Kontoinhaber selbst ist, steht es hier.
Kategorien betroffener Personen	Kontoinhaber und Teammitglieder als Empfänger.
Kategorien personenbezogener Daten	Wie A.3. Meldungen erscheinen in der Sprache des Kontoinhabers.
Rechtsgrundlage	Art. 6 Abs. 1 lit. b DSGVO.
Empfänger	Mail-Dienstleister; gewählte Chat-Dienste (4.1).
Drittland	Je nach Kanal (4.1).
Frist	Wie A.3: Versandprotokoll 90 Tage, Sammelmeldungen 30 Tage nach Versand, Vorfälle bis zur Behebung und danach 180 Tage. Alarmziele mit der Domain.
TOM	Abschnitt 8.

B.17 Monatsbericht an Konten

Feld	Eintrag
Zweck	Am 1. eines Monats ab 08:00 Uhr (Nachholen bis zum 3.) eine Mail je Konto über alle seine Domains: Stufe, Punktzahl und Veränderung, Alarme, abgewehrte Bots, Mailversand, Vergleichswert.
Kategorien betroffener Personen	Aktive Kontoinhaber mit eingeschaltetem Monatsbericht.
Kategorien personenbezogener Daten	E-Mail-Adresse, Sprache, Kennzahlen der Domains.
Rechtsgrundlage	Art. 6 Abs. 1 lit. b DSGVO (Teil der Leistung). In den Einstellungen abbestellbar; zentral abschaltbar.
Empfänger	Mail-Dienstleister (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Drittland	Über den Mail-Dienstleister.
Frist	Keine eigene Speicherung; die Mail steht 30 Tage im Postausgang (B.25).
TOM	Abschnitt 8.

B.18 Siegel und öffentliche Bestätigungsseite

Feld	Eintrag
Zweck	Ein Kunde kann ein Siegel-Bild auf seiner Website einbinden und auf eine öffentliche Bestätigungsseite verlinken. „Geschützt“ zeigt das Siegel nur, wenn die Domain verifiziert ist, die Überwachung läuft und die letzte fertige Prüfung höchstens 45 Tage alt ist und „geschützt“ oder „teilweise geschützt“ ergab; sonst zeigt es neutral „Formularprüfung“. Die Bestätigungsseite nennt Stufe und Datum, keine Einzelbefunde.
Kategorien betroffener Personen	Besucher der Website des Kunden, deren Browser das Bild lädt; Besucher der Bestätigungsseite.
Kategorien personenbezogener Daten	Beim Laden des Bildes: IP-Adresse, Zeitpunkt, angeforderte Adresse, Herkunftsseite und Browserkennung im Webserver-Protokoll (B.1). Die Bildadresse startet keine Sitzung, setzt kein Cookie und schreibt nicht in das Seitenaufrufprotokoll. Die Bestätigungsseite ist eine normale Seite (B.2, B.3).
Rechtsgrundlage	Art. 6 Abs. 1 lit. f DSGVO. Interesse: das Bild ausliefern und den Betrieb sichern. Ob zwischen Kunde und uns für die Übertragung der Besucher-IP eine gemeinsame Verantwortung im Sinne der Rechtsprechung zu eingebundenen Inhalten Dritter besteht und eine Vereinbarung nach Art. 26 nötig ist, ist eine offene Frage der anwaltlichen Prüfung. Der Kunde erhält einen Textvorschlag für seine Datenschutzerklärung.
Empfänger	Keine.
Drittland	Keines.
Frist	14 Tage (Webserver-Protokoll). Das Bild wird eine Stunde zwischengespeichert. Mit dem Ausschalten des Siegels verliert die Kennung ihre Gültigkeit.
TOM	Abschnitt 8.

B.19 Nachweis-Protokoll und Zeitstempel

Feld	Eintrag
Zweck	Ein Protokoll je Domain und Monat (bezahlte Tarife): was geprüft wurde, mit welchem Ergebnis, was gemeldet wurde und was sich geändert hat, als Beleg für Rechenschaftspflicht, Versicherer oder Lieferantenprüfung. Jede Fassung erhält eine Prüfnummer; eine öffentliche Seite bestätigt Domain, Zeitraum und Kennzahlen, keine Einzelheiten. Seit 07.10.2026 bestätigt eine Zeitstempel-Stelle nach RFC 3161 den Zeitpunkt.
Kategorien betroffener Personen	Kunden; mittelbar Personen, die im Protokoll als Freigebende oder Quittierende genannt sein können.
Kategorien personenbezogener Daten	Domain, Monat, Prüfnummer, Inhalts-Hash (SHA-512), Zusammenfassung und Daten des Protokolls, Zeitstempel-Antwort, Zeitstempel-Stelle und -Zeit, Fehlversuche (proof_docs).
Rechtsgrundlage	Art. 6 Abs. 1 lit. b DSGVO.
Empfänger	Die Zeitstempel-Stelle (vorgegeben Certum, Ersatz DigiCert) erhält nur den Hash des Protokolls, nicht seinen Inhalt. Öffentlich: Kennzahlen über die Bestätigungsseite. Der Kunde und jeder, dem er Protokoll oder Prüfnummer gibt.
Drittland	Keine Übermittlung personenbezogener Daten: ein Hash lässt keinen Rückschluss auf den Inhalt zu. Die Ersatz-Stelle hat ihren Sitz in den USA.
Frist	Bis zur Löschung der Domain (fe_domain_loeschen()). Der Zeitstempel ist kein qualifizierter Zeitstempel nach eIDAS.
TOM	Abschnitt 8.

B.20 Plugin und Erweiterung: Prüfung, Verbinden und Übermittlung

Feld	Eintrag
Zweck	Das WordPress-Plugin und die TYPO3-Erweiterung können eine Prüfung anfordern (auch ohne Konto), sich mit einem Konto verbinden (Installation gilt mit einem Klick im Konto als Eigentumsnachweis), Schutzfunktionen freischalten, täglich Zahlen melden (A.9), Mailfehler und Wartungsmodus sofort melden.
Kategorien betroffener Personen	Kunden; Betreiber von Websites, die das Plugin ohne Konto nutzen.
Kategorien personenbezogener Daten	Je Host: Plugin- und CMS-Version, Zahl der Prüfungen, letzte Berichtskennung, Hash des Verbindungsgeheimnisses, erster und letzter Kontakt (plugin_sites). Einmal-Codes zum Verbinden als Hash mit Ablauf (plugin_connect_tokens). Rollout-Codes einer Agentur als Hash mit Präfix, Bezeichnung, Nutzungen, anlegender Person (workspace_connect_codes). Anfrageprotokoll mit der IP-Adresse des aufrufenden Servers (B.4). Der Plugin-Schlüssel steht öffentlich im Kopf der Website; er ist ein Hash des Geheimnisses, das Geheimnis selbst wird nur als Hash gespeichert und nie zurückgegeben.
Rechtsgrundlage	Art. 6 Abs. 1 lit. b DSGVO (Konto); ohne Konto lit. f (angefragte Prüfung, Missbrauchsabwehr).
Empfänger	Keine.
Drittland	Keines.
Frist	Daten eines Hosts gehen, sobald keine Domain ihn mehr führt; die Zeile eines Plugins ohne Konto erst nach 90 Tagen ohne Kontakt (nächtlicher Löschlauf, Teil „orphan_hosts“). Einmal-Codes einen Tag nach Ablauf. Rollout-Codes mit dem Arbeitsbereich.
TOM	Abschnitt 8. Seit 27.09.2026 nimmt der Server nur Schlüsselpaare an, die an die Website gebunden sind; ältere, ungebundene Verbindungsgeheimnisse wurden gelöscht.

B.21 Schwarmschutz

Feld	Eintrag
Zweck	Gemeinsame Spam-Abwehr: Verbundene Websites melden die Domains von Links in Nachrichten, die ihre Schutzschicht gestoppt hat. Eine Domain, die an mindestens drei Websites mit mindestens fünf Treffern binnen sieben Tagen auftaucht, kommt auf eine Liste, die an alle verbundenen Websites zurückgeht; deren Schutzschicht legt Nachrichten mit solchen Links in die Quarantäne, nie ins Nichts.
Kategorien betroffener Personen	Inhaber der gemeldeten Link-Domains, soweit natürliche Personen (etwa Betreiber einer Spam-Seite unter eigenem Namen). Absender und Empfänger der Nachrichten nicht: Adressen, Texte und Namen werden nicht gemeldet.
Kategorien personenbezogener Daten	Signale: Art, Domain, meldender Host, Tag, Treffer (swarm_signals). Liste: Art, Domain, Zahl der Websites und Treffer, Zeitpunkte (swarm_list). Nie gelistet werden große Dienste, Domains unserer Kunden und Ausnahmen des Betreibers.
IP-Netze	Vorbereitet ist das Teilen von IP-Netzen (/24, /48). Es ist ausgeschaltet und das Plugin meldet keine; eingeschaltet wird es erst nach rechtlicher Prüfung, weil IP-Adressen personenbezogen sind.
Rechtsgrundlage	Art. 6 Abs. 1 lit. f DSGVO. Interesse: Schutz der Formulare aller Kunden vor Spam-Wellen. Abwägung: nur Domains, Mindestzahlen gegen Vergiftung, kein Verlust von Nachrichten, Streichen jederzeit möglich.
Empfänger	Alle verbundenen Websites (die Liste der Domains).
Drittland	Je nach Standort der verbundenen Websites; die Liste kann auch Websites außerhalb des EWR erreichen. Personenbezogen ist sie nur in Grenzfällen (Domains natürlicher Personen). Die Übermittlungsgrundlage nach Kapitel V DSGVO für diese Fälle ist noch festzulegen (offene Frage der anwaltlichen Prüfung).
Frist	Signale 30 Tage (täglicher Schwarm-Lauf ab 04:00 Uhr, cfg/swarm_lib.php). Die Liste wird täglich neu berechnet; was die Schwelle nicht mehr erreicht, fällt heraus.
TOM	Abschnitt 8.

B.22 API-Schlüssel, Programmierschnittstelle und MCP-Server

Feld	Eintrag
Zweck	Zugriff eigener Werkzeuge des Kunden (REST-API, Zapier, Make, MCP-Server für KI-Assistenten) auf seine Domains, Prüfungen und Vorfälle.
Kategorien betroffener Personen	Kunden, die Schlüssel anlegen.
Kategorien personenbezogener Daten	Schlüssel nur als Hash, Präfix, Bezeichnung, Zeitpunkte von Anlage, letzter Nutzung und Widerruf (api_keys). Aufrufe je Minute (api_usage).
Rechtsgrundlage	Art. 6 Abs. 1 lit. b DSGVO.
Empfänger	Das Werkzeug, das der Kunde mit dem Schlüssel ausstattet; der Kunde bestimmt es.
Drittland	Je nach Werkzeug des Kunden.
Frist	Schlüssel bis zum Widerruf, mit dem Konto sofort; Schlüssel ohne Konto (Altbestand) nächtlich. Aufrufzähler nach einem Tag (gelegentlich beim Aufruf bereinigt).
TOM	Abschnitt 8.

B.23 reCAPTCHA und eigener Formularschutz

Feld	Eintrag
Zweck	Abwehr automatisierter Zugriffe auf unsere eigenen Formulare: kostenloser Check, Header-Werkzeug, Opt-out, Anmeldung, Registrierung, Passwort vergessen und zurücksetzen, Support und Kontakt. Daneben ein eigener Schutz ohne Dritte: Falle (verstecktes Feld), signierte Zeitprüfung und CSRF-Token. Seit 29. Oktober 2026 zusätzlich unser Formularschutz formconfirmed (Rechennachweis und Einmal-Prüfzeichen) beim kostenlosen Check, der Registrierung, der Anmeldung und „Passwort vergessen“.
Kategorien betroffener Personen	Personen, die diese Formulare absenden.
Kategorien personenbezogener Daten	Bei Google: IP-Adresse, Browser- und Gerätedaten, Verhaltensdaten, Google-Cookies. Bei uns: die Bewertung von Google (Punktzahl und Aktion) nur im Augenblick der Prüfung, ohne Speicherung, auch nicht, wenn eine Einsendung abgelehnt wird. Beim eigenen Formularschutz: IP-Adresse (gespeichert nur gekürzt und gehasht), Seite, Zeitpunkte, Fallenfeld ausgefüllt ja/nein; keine Inhalte.
Zeitpunkt	Das Skript von Google lädt erst beim Absenden eines geschützten Formulars, nicht beim Aufruf der Seite. Der eigene Formularschutz holt seine Aufgabe beim Aufruf der Seite und rechnet, sobald das Formular benutzt wird. Auf dem Entwicklungssystem ist reCAPTCHA ausgeschaltet.
Rechtsgrundlage	Art. 6 Abs. 1 lit. f DSGVO. Interesse: Schutz vor Bots, besonders beim kostenlosen Check, der sonst gegen fremde Websites eingesetzt werden könnte. Ob für den Zugriff auf das Endgerät eine Einwilligung nach § 25 TDDDG oder Art. 399 PKE nötig ist, obwohl das Skript erst beim Absenden lädt, ist eine offene Frage der anwaltlichen Prüfung. Der eigene Formularschutz setzt keine Cookies, speichert nichts im Browser und bildet keinen Fingerabdruck; er soll reCAPTCHA auf Dauer ersetzen.
Empfänger	Google Ireland Limited; Google LLC. Beim eigenen Formularschutz keine.
Drittland	USA (nur reCAPTCHA). Grundlage: Zertifizierung nach dem EU-US Data Privacy Framework beziehungsweise Standardvertragsklauseln; im Einzelnen zu dokumentieren.
Frist	reCAPTCHA: bei uns keine Speicherung; bei Google nach dessen Regeln. Eigener Formularschutz: gehashte Kennung 1 Stunde, verbrauchte Prüfzeichen höchstens 11 Minuten, Prüfergebnisse ohne IP-Adresse 30 Tage.
Ausfall	Antwortet Google nicht innerhalb von drei Sekunden oder nicht verwertbar, wird die Einsendung abgelehnt; ebenso ein leerer Token und eine Antwort für eine andere Aktion als die des Formulars. Nur bei ausgeschaltetem reCAPTCHA entfällt die Prüfung. Beim eigenen Formularschutz wird eine Einsendung ohne gültiges Prüfzeichen abgelehnt; war der Dienst für die Aufgabe nicht erreichbar, wird sie zugelassen.
TOM	Abschnitt 8.

B.24 Support und Kontaktformular

Feld	Eintrag
Zweck	Anfragen über das Support-Fenster und die Kontaktseite entgegennehmen und beantworten. Beide nutzen denselben Weg und dieselbe Tabelle.
Kategorien betroffener Personen	Anfragende, angemeldet oder nicht.
Kategorien personenbezogener Daten	Konto (falls angemeldet; dann gilt die Adresse des Kontos, nicht die eingegebene), E-Mail-Adresse, Anlass aus einer festen Liste, Text bis 4.000 Zeichen, Status, vollständige IP-Adresse, Land, Browserkennung, Herkunftsseite (nur eigene Pfade), Sprache, Zeitpunkte von Eingang und Antwort (support_requests); Eintrag im Aktivitätsprotokoll (ohne Text); Eingangsbestätigung an den Anfragenden im Postausgang (B.25), mit dem Text bis 2.000 Zeichen nur bei angemeldeten Absendern, bei Anfragen ohne Anmeldung ohne den Text.
Rechtsgrundlage	Art. 6 Abs. 1 lit. b DSGVO, soweit die Anfrage einen Vertrag betrifft; sonst lit. f. Vollständige IP-Adresse: lit. f (Begrenzung auf drei Anfragen je Stunde und Adresse, Missbrauchsabwehr).
Empfänger	Mail-Dienstleister (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) für Bestätigung und Antwort. Telegram erhält ein festes Signal ohne jede Variable („es liegt eine neue Supportanfrage vor“) und damit keine personenbezogenen Daten.
Drittland	Über den Mail-Dienstleister.
Frist	24 Monate (nächtlicher Löschlauf, Teil „support“); von Hand früher. Beim Löschen eines Kontos bleiben Anfragen bis zum Fristende stehen (Abschnitt 6.4).
TOM	Abschnitt 8. reCAPTCHA, eigener Formularschutz, Ratenbegrenzung.

B.25 E-Mail-Versand (Postausgang)

Feld	Eintrag
Zweck	Transaktionsmails: Bestätigung der Registrierung und neuer E-Mail-Adressen, Passwort zurücksetzen, Einladungen, Alarme, Monatsberichte, Portal-Bestätigungen und -Berichte, Support-Bestätigungen und -Antworten, Erinnerungen zur Testphase und zur Einrichtung, Betriebsmeldungen an die Betreiber. Keine Werbung, keine Mails an Personen, die sich nicht selbst eingetragen haben oder vom Kunden als Empfänger eingetragen wurden.
Kategorien betroffener Personen	Empfänger dieser Mails.
Kategorien personenbezogener Daten	Empfängeradresse, Betreff, vollständiger Inhalt, Antwortadresse, Zweck, Versandweg, Status, Fehler, Versuche, Zeitpunkte (mail_outbox). Der Inhalt kann Bestätigungs- und Zurücksetz-Links mit gültigen Kennungen enthalten.
Rechtsgrundlage	Art. 6 Abs. 1 lit. b DSGVO; für Betriebsmeldungen lit. f.
Empfänger	Namecheap, Inc. (Private Email), Phoenix, Arizona, USA (Versand); der Kontoinhaber sieht seine versandten Mails im Datenexport (ohne Inhalt).
Drittland	Je nach Verarbeitungsort des Mail-Dienstleisters; Vertrag und Übermittlungsgrundlage sind noch zu dokumentieren (Abschnitt 4).
Frist	30 Tage (nächtlich, srv/cron_status.php). Die Frist ist bewusst die kürzeste der Protokolle: Ein langes Sendeprotokoll wäre eine Sammlung gültiger Schlüssel. Der Statuslauf prüft alle fünf Minuten, ob ein erneuter Versuch fällig ist.
Stand	Der Mail-Versand ist vor dem Start einzurichten. Bis der Mail-Dienstleister mit Sitz und Grundlage feststeht, zeigen die Rechtstexte eine Markierung.
TOM	Abschnitt 8. Gescheiterte Mails werden in wachsenden Abständen erneut versucht und nach einer Höchstzahl von Versuchen aufgegeben.

B.26 Zahlungen und Abrechnung

Feld	Eintrag
Zweck	Abschluss und Verwaltung der Abos (monatlich oder jährlich im Voraus), Testphase von 14 Tagen ohne Karte mit Erinnerung drei Tage vor dem Ende, Zahlung auf Rechnung für Jahresabos (ab Werk aus), Freischaltungen über Hoster- und Partner-Codes ohne Zahlung, Rechnungsstellung, steuerliche Aufbewahrung.
Kategorien betroffener Personen	Kunden.
Kategorien personenbezogener Daten	Bei Stripe: E-Mail-Adresse, Name, Rechnungsanschrift, USt-IdNr., Zahlungsdaten, Rechnungen; als Metadaten unsere Konto-Kennung und der Tarif. Bei uns: Stripe-Kunden- und Abo-Kennung, Tarif, Status, Ende der Periode, Kündigung zum Periodenende (users); eingegangene Stripe-Ereignisse nur mit Kennung, Art, Status und Zeitpunkten, ohne Inhalt (stripe_events); Einlösungen von Hoster-Codes mit Konto, Kampagne und Ablauf (bundle_redemptions). Kartendaten erreichen uns nie.
Herkunft	Kunde im Bezahlvorgang von Stripe; Ereignisse von Stripe.
Rechtsgrundlage	Art. 6 Abs. 1 lit. b DSGVO; für die steuerliche Aufbewahrung lit. c.
Empfänger	Stripe Payments Europe Limited (Irland); Stripe, Inc. (USA). Stripe handelt für Teile der Zahlungsabwicklung in eigener Verantwortung; die genaue Rollenverteilung ist Teil der anwaltlichen Prüfung.
Drittland	USA über Stripe, Inc.; Grundlage Data Privacy Framework beziehungsweise Standardvertragsklauseln nach den Bedingungen von Stripe.
Frist	Abrechnungsfelder mit dem Konto; ein laufendes Abo wird vor der Kontolöschung beendet. Rechnungen und Abrechnungsunterlagen nach polnischem Steuerrecht fünf Jahre ab dem Ende des Jahres, in dem die Steuerzahlungsfrist ablief; sie liegen bei Stripe und sind im Kundenportal von Stripe abrufbar. Stripe-Ereignisse und Code-Einlösungen haben keine Frist (Abschnitt 6.4).
TOM	Abschnitt 8. Annahme von Stripe-Ereignissen nur mit gültiger Signatur; jedes Ereignis wird einmal verarbeitet.

B.27 Sicherungen

Feld	Eintrag
Zweck	Wiederherstellung nach einem Fehler: falsches Löschen, beschädigte Migration.
Kategorien betroffener Personen	Alle Personen, deren Daten in der Datenbank stehen.
Kategorien personenbezogener Daten	Vollständiger, komprimierter Auszug der Anwendungsdatenbank. Bildschirmfotos und Logo-Dateien liegen außerhalb der Datenbank und sind nicht Teil dieser Sicherung. Testkonto-Zugangsdaten stehen darin nur als Chiffretext (A.5).
Ablauf	Nächtlich um 03:00 Uhr, nach dem Löschlauf, damit die Sicherung nicht mitnimmt, was die Fristen gerade gelöscht haben. Der Auszug wird erst behalten, wenn er am Inhalt geprüft ist (Ausgangscode, Tabellenzahl, Abschlusszeile). Sonntags spielt eine Wiederherstellungsprobe die neueste Sicherung in eine Wegwerf-Datenbank ein und vergleicht Tabelle für Tabelle. Scheitert etwas, gibt es ein Signal und eine Mail an die Betreiber.
Rechtsgrundlage	Art. 6 Abs. 1 lit. f DSGVO in Verbindung mit Art. 32 Abs. 1 lit. c.
Empfänger	Keine.
Drittland	Keines.
Frist	14 Tage; ältere Auszüge werden erst nach einer erfolgreichen neuen Sicherung entfernt (cfg/backup_lib.php). Löschungen, die in dieser Zeit stattfinden, erreichen die Sicherung erst mit ihrem Ablauf; wird aus einer Sicherung wiederhergestellt, werden Löschaufträge danach erneut angewandt.
Ort	Die Sicherungen liegen derzeit am selben Standort wie die Datenbank und sind nicht gesondert verschlüsselt; eine verschlüsselte Kopie an einem zweiten Standort ist geplant (Abschnitte 8.1 und 10).
TOM	Abschnitt 8.

B.28 Fehlerprotokoll und Fehleralarm

Feld	Eintrag
Zweck	Fehler finden und beheben, bevor ein Kunde sie meldet. Neue Fehlerarten und Fehlerwellen werden den Betreibern gemeldet, dazu eine Tagesübersicht ab 08:00 Uhr.
Kategorien betroffener Personen	Nutzer, bei deren Anfrage ein Fehler entsteht; mittelbar Personen, deren Daten in einer Fehlermeldung stehen.
Kategorien personenbezogener Daten	Stufe, Quelle, Meldung, Kontext als JSON, Konto-Kennung der Sitzung, Zeitpunkt (error_logs). Fehlerarten: Fingerabdruck, Muster (aus dem E-Mail-Adressen, Adressen, Zahlen und Kennungen entfernt sind), eine unveränderte Beispielmeldung bis 2.000 Zeichen, erstes und letztes Auftreten, Anzahl (error_kinds).
Rechtsgrundlage	Art. 6 Abs. 1 lit. f DSGVO (Betriebssicherheit, Art. 32).
Empfänger	Die Betreiber per Mail über den Mail-Dienstleister: bei einer neuen Fehlerart Quelle und Rohtext der Meldung bis 400 Zeichen (nicht bereinigt), dazu die tägliche Übersichtsmail; bei einer Fehlerwelle geht nur das Telegram-Signal hinaus. Telegram erhält nur feste Sätze ohne Variable („Eine neue Fehlerart ist aufgetreten“, „Viele Fehler in kurzer Zeit“).
Drittland	Über den Mail-Dienstleister.
Frist	Fehlerprotokoll 90 Tage (nächtlich). Fehlerarten ohne Frist (Abschnitt 10). Der Fehleralarm ist auf dem Produktivsystem an, auf dem Entwicklungssystem aus.
TOM	Abschnitt 8.

B.29 Betriebssignale und Statusüberwachung

Feld	Eintrag
Zweck	Ausfälle bemerken: alle fünf Minuten Prüfung der Komponenten (Startseite, Datenbank, Plattenplatz, Herzschlag des Scanners, Rückstau der Warteschlange), Statusseite, Signal bei Störung und Entwarnung, Herzschlag an einen externen Überwachungsdienst, damit auch ein vollständiger Ausfall auffällt; Stau vor dem Scanner.
Kategorien betroffener Personen	Keine im Regelfall.
Kategorien personenbezogener Daten	Keine. Tageszeilen je Komponente mit Zahl der Prüfungen und letztem Fehler (system_status_logs), Herzschlag des Scanners (scanner_heartbeat), Tageskennzahlen ohne Personenbezug (daily_stats). Die Signale an Telegram sind feste Sätze ohne Variable; der Herzschlag ist ein Abruf ohne Inhalt.
Rechtsgrundlage	Entfällt mangels personenbezogener Daten; vorsorglich Art. 6 Abs. 1 lit. f.
Empfänger	Telegram (feste Sätze); der externe Überwachungsdienst (nur der Abruf); die Betreiber per Mail.
Drittland	Telegram außerhalb der EU; es werden keine personenbezogenen Daten übermittelt.
Frist	Statuszeilen 400 Tage (nächtlich).
TOM	Abschnitt 8.

B.30 Opt-out – Domain ausschließen

Feld	Eintrag
Zweck	Jeder kann jede Domain ohne Nachweis dauerhaft von Prüfungen ausschließen; die Sperre wirkt sofort für alle Prüfwege (kostenloser Check, Plugin ohne Konto, Studie, Interessenten-Prüfung, Header-Werkzeug) und auch für Domains zahlender Kunden mit Eigentumsnachweis; deren laufende Überwachung endet mit der nächsten fälligen Prüfung. Sie gilt für die Domain und ihre www-Variante, nicht für andere Subdomains. Aufgehoben wird sie nur durch uns, auf Anfrage und mit Nachweis. Damit Missbrauch (etwa ein Wettbewerber, der fremde Domains sperrt) erkennbar und rückgängig zu machen ist, wird die Sperre protokolliert.
Kategorien betroffener Personen	Personen, die eine Domain ausschließen.
Kategorien personenbezogener Daten	Domain, freiwilliger Grund bis 250 Zeichen, Quelle, IP-Adresse, Land, Browserkennung, Zeitpunkt; bei Aufhebung Zeitpunkt, aufhebende Person und Grund (blocklist). Anfrageprotokoll wie B.4.
Rechtsgrundlage	Für den Ausschluss Art. 6 Abs. 1 lit. f DSGVO. Interesse: den Wunsch, eine Domain nicht prüfen zu lassen, dauerhaft und für alle Prüfwege zu beachten. Ist die ausschließende Person selbst betroffen, setzt der Ausschluss zugleich ihren Widerspruch nach Art. 21 um (Art. 6 Abs. 1 lit. c). Für Adresse, Land und Browserkennung lit. f (Missbrauchserkennung).
Empfänger	Google (reCAPTCHA, B.23).
Drittland	USA über reCAPTCHA.
Frist	IP-Adresse, Land und Browserkennung nach 12 Monaten (nächtlicher Löschlauf, Teil „optout_ip“). Der Ausschluss selbst bleibt dauerhaft, damit er wirkt.
TOM	Abschnitt 8. Viele Sperren aus einem Land in kurzer Zeit erzeugen eine Auffälligkeit (B.4).

B.31 Erinnerung nach der Registrierung

Feld	Eintrag
Zweck	Eine einzige Mail zwei bis 14 Tage nach der Registrierung an bestätigte Konten ohne bestätigte Domain: „Website hinzufügen“ beziehungsweise „Domain bestätigen“. Kein Angebot, kein Preis, kein Upgrade; mit dem Hinweis, dass sie nicht wiederkommt. Werktags 09 bis 18 Uhr, höchstens 50 je Lauf.
Kategorien betroffener Personen	Neue Kontoinhaber.
Kategorien personenbezogener Daten	E-Mail-Adresse, Sprache, Zeitpunkt des Versands (Feld „Erinnerung versandt“ in users), Domain und Bestätigungsstand.
Rechtsgrundlage	Art. 6 Abs. 1 lit. b DSGVO (Hinweis zur Einrichtung des eigenen Kontos). Ob die Mail als Mitteilung zum Vertragsverhältnis gilt oder als kommerzielle Information, die eine Einwilligung bräuchte (Art. 10 UŚUDE, Art. 398 PKE, § 7 UWG), ist eine offene Frage der anwaltlichen Prüfung; der Betreiber kann sie zentral abschalten.
Empfänger	Mail-Dienstleister (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Drittland	Über den Mail-Dienstleister.
Frist	Der Zeitpunkt lebt mit dem Konto; die Mail 30 Tage im Postausgang.
TOM	Abschnitt 8. Der Zeitpunkt wird vor dem Versand gesetzt, damit ein Abbruch keine zweite Mail auslöst.

B.32 Telegram-Bot für Kunden-Alarme

Feld	Eintrag
Zweck	Ein Telegram-Chat wird als Alarmziel verknüpft: Der Kunde erhält einen Link zu unserem Bot mit einem Einmal-Code; drückt der Empfänger „Start“, liest unser Server den Code aus den neuen Nachrichten an den Bot und merkt sich die Chat-Kennung. Ein offener Zugang bei uns (Webhook) ist dafür nicht nötig.
Kategorien betroffener Personen	Kunden und die Personen, deren Telegram-Chat verknüpft wird.
Kategorien personenbezogener Daten	Einmal-Code, Domain, anlegendes Konto, Ereignisse, Versandart, Chat-Kennung, Zeitpunkte (telegram_links); die Chat-Kennung als Ziel (alerts). Telegram liefert mit der Nachricht weitere Profilangaben; ausgewertet und gespeichert werden nur Code und Chat-Kennung.
Rechtsgrundlage	Art. 6 Abs. 1 lit. b DSGVO; für Dritte als Empfänger A.3.
Empfänger	Telegram.
Drittland	Außerhalb der EU, kein Angemessenheitsbeschluss; die Wahl trifft der Kunde (4.1). Grundlage und Hinweis sind offene Fragen der anwaltlichen Prüfung.
Frist	Ein Code ist 30 Minuten gültig; Verknüpfungszeilen werden beim Anlegen eines neuen Codes nach einem Tag gelöscht, offene Codes mit dem Konto und der Domain. Die Chat-Kennung als Ziel bis zur Löschung des Alarmziels oder der Domain.
TOM	Abschnitt 8.

B.33 Partnerprogramm und Freischalt-Codes

Feld	Eintrag
Zweck	Ein Konto kann über einen Empfehlungscode neue Kunden werben und erhält eine Provision auf deren bezahlte Rechnungen für eine begrenzte Zahl von Monaten. Der Code reist in der Adresse bis zur Registrierung; es wird kein Cookie gesetzt. Hoster und Partner können Codes ausgeben, die einen Tarif für eine Zeit ohne Zahlung freischalten; eine Woche vor dem Ende erhält der Kunde eine Erinnerung.
Stand	Das Partnerprogramm ist ab Werk aus, bis die Partnerbedingungen stehen.
Kategorien betroffener Personen	Partner und geworbene Kunden.
Kategorien personenbezogener Daten	Empfehlungscode, werbender Partner und Zeitpunkt der Empfehlung (in users); Provision mit Partner, Kunde, Stripe-Rechnungskennung, Betrag, Währung, Provision, Status, Zeitpunkten (partner_commissions). Freischaltung mit Tarif, Ende, Quelle, Erinnerung (in users); Kampagnen und Einlösungen (bundle_campaigns, bundle_redemptions).
Rechtsgrundlage	Art. 6 Abs. 1 lit. b DSGVO (Partnervertrag); für den Kunden lit. f (Abrechnung der Provision, ohne Weitergabe seiner Daten an den Partner über die Provisionshöhe hinaus); steuerliche Belege lit. c.
Empfänger	Der Partner sieht seine Provisionen.
Drittland	Keines.
Frist	Empfehlung und Freischaltung mit dem Konto. Provisionen und Einlösungen haben keine Frist im Code; als Buchhaltungsbelege unterliegen Provisionen der steuerlichen Aufbewahrung (Abschnitt 6.4).
TOM	Abschnitt 8.

B.34 Meldestelle für Sicherheitslücken

Feld	Eintrag
Zweck	Entgegennahme von Hinweisen auf Schwachstellen in formexposed, nach den Regeln auf der Seite Sicherheit und in /.well-known/security.txt.
Kategorien betroffener Personen	Meldende Personen; Personen, deren Daten eine Meldung als Beleg enthält.
Kategorien personenbezogener Daten	E-Mail-Adresse, Name, Inhalt der Meldung und Anhänge, wie die meldende Person sie schickt. Die Meldung erreicht uns per E-Mail an die dort genannte Adresse; die Anwendung speichert sie nicht.
Rechtsgrundlage	Art. 6 Abs. 1 lit. f DSGVO (Sicherheit des Dienstes, Art. 32); soweit eine Meldung personenbezogene Daten Dritter als Beleg enthält, ebenfalls lit. f mit dem Ziel, die Lücke zu schließen.
Empfänger	Mail-Dienstleister und, bis zur Einrichtung des Postfachs, die Domain-Weiterleitung bei Namecheap (Abschnitt 4).
Drittland	Über Mail-Dienstleister und, bis zur Umstellung, die Weiterleitung.
Frist	Eine Frist ist nicht festgelegt und nicht technisch durchgesetzt (Abschnitt 10). Die Frist legt der Betreiber noch fest; naheliegend wäre, Belegdaten Dritter nach dem Schließen der Lücke zu löschen und die Korrespondenz wie Supportanfragen zu behandeln.
TOM	Abschnitt 8.

B.35 Rückmeldung zu einem Bericht

Feld	Eintrag
Zweck	Meldungen unter einem Bericht („Stimmt in diesem Bericht etwas nicht?“) entgegennehmen, um Fehler der Formularerkennung zu finden. Der Superadmin ordnet sie ein (neu, bestätigt, behoben, verworfen) und kann die Prüfdaten des Berichts als Testfall herunterladen (Formulare mit Feldern, Gründen und Befunden, ohne Bildschirmfotos und ohne aktiv gesendete Texte).
Kategorien betroffener Personen	Personen, die einen Bericht ansehen, angemeldet oder nicht.
Kategorien personenbezogener Daten	Kategorie und Prüfung aus festen Listen, Seitenadresse bis 500 Zeichen, Text bis 1.000 Zeichen, Sprache, Zeitpunkt, Kennung des Berichts, Prüfung, Host; Konto-Kennung, falls angemeldet; HMAC-SHA256 der IP-Adresse mit geheimem Schlüssel für die Begrenzung; Status, Bearbeiter, Zeitpunkt der Bearbeitung (report_feedback). Aktivitätsprotokoll: Statuswechsel und Herunterladen eines Testfalls. Keine E-Mail-Adresse, keine IP-Adresse im Klartext.
Rechtsgrundlage	Art. 6 Abs. 1 lit. f DSGVO (Fehler der Erkennung finden und beheben; Begrenzung gegen Missbrauch).
Empfänger	Keine.
Drittland	Keins.
Frist	24 Monate (nächtlicher Löschlauf, Teil „report_feedback“); die Prüfsumme der IP-Adresse nach 2 Tagen geleert (Teil „report_feedback_ip“); beim Löschen eines Kontos sofort. Heruntergeladene Testfälle enthalten keine Angaben zur meldenden Person.
TOM	Abschnitt 8. Eigener Formularschutz (Falle, signierte Zeit, CSRF), höchstens 5 Meldungen je Stunde und 20 je Tag je Prüfsumme, 10 je Bericht; Lesen nur für Superadmins.

6. Aufbewahrung – was der nächtliche Löschlauf erfasst und was nicht

Es gibt eine automatische Löschung, und sie hat einen Ort. Ein Statuslauf (srv/cron_status.php) wird alle fünf Minuten über die Krontabelle des Webservers gestartet, auf dem Produktivsystem wie auf dem Entwicklungssystem. Er prüft die Komponenten, holt die Zustellungsprüfung ab, plant Prüfungen und verschickt Alarme. Einmal am Tag, im Fenster von 03:00 bis 03:04 Uhr, löscht er nach Fristen und legt danach die Sicherung an. Seit dem 27.09.2026 ruft er dabei zusätzlich den Fristenlauf in cfg/fristen_lib.php auf (fe_fristen_lauf()), dessen Teile unabhängig voneinander laufen: Scheitert einer, laufen die anderen weiter, und der Fehler steht im Fehlerprotokoll.

Beleg, dass der Lauf läuft: Der Sicherungsstatus des Entwicklungssystems weist für den 11.10.2026 eine erfolgreiche Sicherung um 03:00 Uhr aus; die Sicherung entsteht im selben Block unmittelbar nach dem Löschen. Ein Protokoll je gelöschter Tabelle schreibt der Lauf nur auf die Standardausgabe, die die Krontabelle verwirft; eine dauerhafte Aufzeichnung, was wann gelöscht wurde, gibt es nicht (Abschnitt 10).

Die Fristen, die als Platzhalter erscheinen, stehen im Verwaltungsbereich unter den Aufbewahrungseinstellungen. Dieselben Einstellungen liest der Lauf; die Texte zeigen deshalb immer die Frist, nach der tatsächlich gelöscht wird.

6.1 Vom täglichen Lauf erfasst

Daten	Frist und Auslöser	Ort im Code
Seitenaufrufprotokoll (access_logs)	60 Tage	srv/cron_status.php
Aktivitätsprotokoll (audit_logs)	365 Tage	srv/cron_status.php
Fehlerprotokoll (error_logs)	90 Tage	srv/cron_status.php
Postausgang (mail_outbox)	30 Tage	srv/cron_status.php
Merker „Angemeldet bleiben“ (remember_tokens)	nach Ablauf (30 Tage)	srv/cron_status.php
Nicht angenommene Einladungen (workspace_invites)	nach Ablauf (14 Tage)	srv/cron_status.php
Anmeldeversuche (login_attempts); Versuchszähler (auth_attempt_buckets)	7 Tage; Zähler mit Ablauf ihres Zeitfensters (derzeit 15 Minuten, für Zurücksetzen und Registrierung eine Stunde), auch beim nächsten Zugriff	srv/cron_status.php
Anfrageprotokoll der Prüfungen ohne Konto (check_throttle)	7 Tage	srv/cron_status.php
Einmal-Codes zum Verbinden des Plugins (plugin_connect_tokens)	1 Tag nach Ablauf	srv/cron_status.php
Erledigte Auffälligkeiten (abuse_flags)	90 Tage nach Erledigung	srv/cron_status.php
Abgelaufene Berichte samt Prüfergebnis, Formularen, Befunden, Bildern und Auftrag (nur ohne Domain im Konto)	anonym 30 Tage, Interessenten 90 Tage	fe_reports_aufraeumen()
Versandprotokoll der Alarme (alert_log)	90 Tage	fe_alert_log_aufraeumen()
Statuszeilen (system_status_logs)	400 Tage	srv/cron_status.php
Zustimmungsnachweise gelöschter Konten (legal_consents)	sobald das Konto gelöscht ist und die Zustimmung 4 Jahre zurückliegt	srv/cron_status.php
Waisen gelöschter Domains: Prüfergebnisse, Aufträge, Alarmdaten, Vorfälle, Telegram-Codes, Zustellungen, Puls, Lücken, Nachweise, Skript-Inventar und Skript-Änderungen	sofort beim nächsten Lauf	fe_fristen_lauf(), Teile „orphan_scans“, „orphan_rows“
Plugin-Daten von Hosts ohne Domain; Plugin-Zeile ohne Konto	sofort; Zeile nach 90 Tagen ohne Kontakt	Teil „orphan_hosts“
Ergebnisse des Header-Werkzeugs (header_checks)	derzeit 90 Tage	Teil „header_checks“
Prüfergebnisse einer Domain mit Formularen, Befunden, Bildern, Berichten, Aufträgen	13 Monate; die letzte fertige je Domain bleibt	Teil „old_scans“
Browserläufe, erledigte Browser-Aufträge, Zeitreihen (form_browser_runs, scan_jobs, form_performance)	13 Monate	Teile „browser_runs“, „browser_jobs“, „form_performance“
Formular-Zähler (form_metrics), Plugin-Tageszahlen und Änderungsmeldungen (plugin_stats, plugin_changes)	13 Monate	Teile „form_metrics“, „plugin_stats“
Angemeldete Geräte (login_sessions)	90 Tage nach letzter Nutzung oder Widerruf	Teil „sessions“
Angenommene Einladungen	30 Tage nach Annahme	Teil „invites“
Supportanfragen (support_requests)	24 Monate	Teil „support“
Rückmeldungen zu Berichten (report_feedback)	24 Monate; Prüfsumme der IP-Adresse 2 Tage	Teile „report_feedback“ und „report_feedback_ip“
PDF-Fassungen von Berichten im Zwischenspeicher (var/pdf)	7 Tage	Teil „pdf_cache“
IP-Adresse, Land und Browserkennung im Opt-out (blocklist)	12 Monate; der Ausschluss bleibt	Teil „optout_ip“
Portal-Abonnenten (client_subscribers)	unbestätigt 30 Tage; abgemeldet 3 Jahre	Teil „subscribers“
Nie bestätigte Konten samt Arbeitsbereich	30 Tage ohne Anmeldung, außer ein weiteres Mitglied hängt daran	Teil „pending_accounts“
API-Schlüssel ohne Konto (Altbestand)	sofort	Teil „api_keys“

6.2 Außerhalb des Fensters um 03:00 Uhr

Daten	Frist und Auslöser	Ort im Code
Kopien im Kontrollpostfach der Zustellungsprüfung	nach Verarbeitung, alle fünf Minuten	fe_zustellung_abholen()
Zuordnungen der Zustellungsprüfung (delivery_log)	180 Tage, bei jedem Abruf	fe_zustellung_abholen()
Testkonto-Chiffretext in Aufträgen (scan_jobs)	nach dem Lauf, spätestens nach einer Stunde	Scan-Server; fe_login_aufraeumen()
Vorfälle (alert_incidents) samt Zustellversuchen der Eskalation	solange ungelöst; 180 Tage nach Behebung	fe_vorfaelle_aufraeumen() in cfg/vorfall_lib.php
Versandte Sammelmeldungen (alert_queue)	30 Tage nach Versand	cfg/kanal_lib.php
Schwarm-Signale (swarm_signals)	30 Tage, täglich ab 04:00 Uhr	cfg/swarm_lib.php
Interessenten-Prüfungen (prospect_checks)	90 Tage, täglich ab 04:00 Uhr	srv/cron_status.php
Telegram-Verknüpfungscodes (telegram_links)	1 Tag, beim Anlegen eines neuen Codes	cfg/kanal_lib.php
Aufrufzähler der API (api_usage)	1 Tag, gelegentlich beim Aufruf	cfg/agentur_lib.php
Erledigte Anbieter-Störungen (provider_incidents), Lücken-Zwischenspeicher (vuln_cache)	90 bzw. 30 Tage; keine Personendaten	cfg/anbieter_lib.php, cfg/luecken_lib.php
Studien-Rohdaten	bei Veröffentlichung	fe_studie_veroeffentlichen()
Sicherungen	14 Tage, nach einer erfolgreichen neuen Sicherung	cfg/backup_lib.php
Webserver-Protokolle	14 Tage	Protokollrotation des Systems

6.3 Beim Löschen durch den Kunden

• Domain löschen (fe_domain_loeschen()): Prüfergebnisse mit Formularen, Befunden und Bilddateien, Berichte, Aufträge, Alarmziele, Versandprotokoll, Sammelwarteschlange, Vorfälle, Telegram-Codes, Zustellungen, Puls, Lücken, Nachweis-Protokolle, die Domain aus Kundenportalen mit fester Auswahl; über Fremdschlüssel überwachte Formulare mit Browserläufen, Beobachtungen und Zeitreihen, Testkonto, Formular-Zähler; Plugin-Daten des Hosts, wenn keine andere Domain ihn führt. Ebenfalls mitgelöscht werden Skript-Inventar und Skript-Änderungen der Domain; eine eigene Frist haben sie nicht (Abschnitte 6.4 und 10). Daten, die aus der Zeit vor dem 27.09.2026 ohne zugehörige Domain verblieben sind, räumt der nächtliche Lauf ab (Teile „orphan_scans“, „orphan_rows“).
• Arbeitsbereich löschen (fe_arbeitsbereich_daten_loeschen()): zusätzlich Marke samt Logo, Kundenportale samt Abonnenten, Rollout-Codes, Interessenten-Prüfungen; dazu Einladungen und Mitgliedschaften.
• Konto löschen: laufendes bezahltes Abo bei Stripe sofort beenden, ohne Erstattung; eigene Arbeitsbereiche übergeben oder löschen; Mitgliedschaften, Merker, Geräte, API-Schlüssel mit Zählern, offene Telegram-Codes und die Kontozeile löschen.
• Testkonto löschen (fe_login_loeschen()): Chiffretext überschreiben, Zeile löschen, wartende Aufträge leeren.

6.4 Was der Lauf nicht erfasst

Diese Liste ist die wichtigere. Sie nennt Daten, für die es keine automatische Frist gibt oder die eine Löschung überleben.

Daten	Was gilt	Bewertung
Kontodaten einschließlich letzter IP-Adresse (users)	bis zur Löschung durch den Kontoinhaber; keine Löschung inaktiver Konten	Vertragsdaten; eine Regel für dauerhaft inaktive Konten ohne Abo fehlt
Aktivitätsprotokoll, Seitenaufrufe, Fehlerprotokoll eines gelöschten Kontos	bleiben mit Konto-Kennung und IP-Adresse bis zum Ende ihrer Frist	gewollt (Nachweis über Handlungen auch nach Kündigung); Kennung zeigt auf kein Konto mehr
Supportanfragen eines gelöschten Kontos	bleiben bis 24 Monate mit der alten Konto-Kennung	gewollt; die Kennung wird nicht geleert
Zustimmungsnachweise eines gelöschten Kontos	bis die Zustimmung 4 Jahre zurückliegt (gerechnet ab der Zustimmung, nicht ab der Kontolöschung)	gewollt (Abschnitt B.12)
Unerledigte Auffälligkeiten mit IP-Adresse (abuse_flags)	bis jemand sie erledigt	offener Punkt (Abschnitt 10)
Fehlerarten mit unveränderter Beispielmeldung (error_kinds)	keine Frist	offener Punkt (Abschnitt 10)
Skript-Inventar und Skript-Änderungen (script_inventory, script_changes)	keine eigene Frist; bleiben, solange die Domain besteht, und werden mit ihr gelöscht	offener Punkt (Abschnitt 10)
Abonnenten widerrufener Kundenportale	bis zur Löschung des Arbeitsbereichs	offener Punkt (Abschnitt 10)
Widerrufene API-Schlüssel und Rollout-Codes	bis Konto oder Arbeitsbereich gelöscht wird	nur Hashes, Präfix und Bezeichnung; gering
Liste der Studien-Hosts (study_domains), nie veröffentlichte Studien	keine Frist	offener Punkt (Abschnitt 10)
Interne Prüfungen ohne Domain und ohne Bericht (Prüfergebnisse, Formulare, Befunde, Bildschirmfotos)	keine Frist; kein Löschweg erfasst sie	offener Punkt (Abschnitt 10)
Provisionen, Code-Einlösungen, Stripe-Ereignisse	keine Frist	Buchhaltungsbezug; Frist nach Steuerrecht festzulegen
Zwischengespeichertes Domainalter (domain_age_cache)	keine Frist	nur Domainname und Registrierungsdatum
Echtheitsergebnis der Formularmail mit Absender-Domain	mit der Domain; bei jedem Eingang überschrieben	siehe A.1
Ausschlüsse im Opt-out	dauerhaft	gewollt; ohne Dauer wirkt kein Ausschluss
E-Mails im Postfach der Meldestelle und im allgemeinen Postfach	keine technische Frist	offener Punkt (Abschnitt 10)

6.5 Außerhalb der Datenbank

• Bildschirmfotos liegen als Dateien außerhalb des Web-Verzeichnisses und werden mit ihrem Prüfergebnis gelöscht (alle Löschwege oben löschen auch die Dateien).
• Logo-Dateien der Marke werden beim Ersetzen und mit dem Arbeitsbereich gelöscht.
• Auf dem Scan-Server entsteht je Auftrag ein temporäres Verzeichnis mit Ergebnis und Bildern; es wird nach jedem Lauf gelöscht, auch nach einem Fehler.
• Sicherungen liegen auf dem Webserver (B.27).
• Webserver-Protokolle mit voller IP-Adresse werden 14 Tage gehalten (B.1).

7. Automatisierte Entscheidungen, Profiling und Bewertung

formexposed bewertet Websites, nicht Menschen. Eine Entscheidung, die gegenüber einer Person rechtliche Wirkung entfaltet oder sie in ähnlicher Weise erheblich beeinträchtigt (Art. 22 Abs. 1 DSGVO), trifft der Dienst nach unserer Bewertung nicht. Es gibt aber automatisierte Bewertungen und automatische Sperren. Wir nennen sie, damit die Einordnung nachprüfbar ist.

Mechanismus	Was er tut	Wen er betrifft
Punktzahl und Urteil einer Prüfung	Gewichtete Summe fehlender Schutzschichten (CAPTCHA, Falle, Token, Zeitprüfung, wirkungsloses CAPTCHA, bekannte offene Konstellation), 0 bis 100; daraus „offen“, „teilweise geschützt“ oder „geschützt“. Das Urteil der Website richtet sich nach dem schlechtesten Kontaktformular, das die Regeln (nicht das Sprachmodell) als solches erkannt haben; ohne Kontaktformular gibt es kein Urteil. Die Gewichte sind im Verwaltungsbereich einstellbar.	Website-Betreiber; bei Einzelunternehmern mittelbar eine Person. Das Urteil hat keine Rechtsfolge; es ist ein Befund mit Belegen und Anleitung.
Einordnung des Formulartyps	Regeln zuerst, ein lokales Sprachmodell nur, wenn die Regeln „unbekannt“ liefern. Entscheidet, ob eine aktive Test-Einsendung erlaubt ist (nur bei einem von den Regeln sicher erkannten Kontaktformular). Vom Sprachmodell eingeordnete Formulare werden nie abgesendet und zählen nicht für Punktzahl und Urteil.	Kunde und Empfänger seiner Formularmails; Schutzwirkung: im Zweifel wird nichts abgesendet.
Siegel	Zeigt „geschützt“ nur unter festen Bedingungen (B.18), sonst neutral.	Kunde; keine Wirkung auf Besucher.
Grenzen und Sperren beim kostenlosen Check, Header-Werkzeug und Opt-out	Weisen Anfragen ab, wenn Grenzen je Adresse, Sitzung, Domain oder System erreicht sind, die Domain zu jung oder unbekannt alt ist oder auf der Blocklist steht.	Anfragende; Wirkung: eine kostenlose Leistung wird für Stunden bis Tage verweigert. Ein Administrator kann eine Adresse freigeben; Anfragen über die Kontaktseite erreichen einen Menschen.
Auffälligkeiten	Muster (viele Domains von einer Adresse, Stoßanfragen, viele Ablehnungen, viele Opt-outs aus einem Land, Tageslimit erreicht) werden festgehalten und gemeldet. Sie sperren nicht selbst; die Sperren ergeben sich aus den Grenzen.	Anfragende.
Anmeldesperre	Nach derzeit acht fehlgeschlagenen Anmeldungen einer Adresse in 15 Minuten wird die Anmeldung von dieser Adresse vorübergehend abgewiesen. Zusätzlich zählen alle Anmeldeversuche, erfolgreiche eingeschlossen, je Konto und IP-Adresse (derzeit acht), je Konto über alle Adressen (deutlich mehr, gegen verteiltes Raten) und je IP-Adresse (derzeit 80) in 15 Minuten sowie Codes des zweiten Faktors (zehn je Konto in 15 Minuten); darüber wird abgewiesen. Fehlversuche von einer fremden Adresse sperren den Inhaber eines Kontos deshalb nicht mehr aus. Ebenso begrenzt sind Passwortbestätigungen (fünf je Konto in 15 Minuten), Mails zum Zurücksetzen (drei je Adresse in der Stunde, bei unveränderter Antwort), Registrierungen (zehn je IP-Adresse in der Stunde) und Versuche am Passwort eines Kundenportals (zehn je Portal und IP-Adresse, 50 je Portal in 15 Minuten).	Personen, die sich anmelden, registrieren oder ein Kundenportal öffnen; Wirkung zeitlich begrenzt, Passwort-Zurücksetzen bleibt möglich.
reCAPTCHA-Schwelle	Lehnt Einsendungen unter einer Punktzahl von Google ab; Schwelle je Einsatzpunkt (für Check und Opt-out derzeit 0,7). Abgelehnt werden auch Antworten für eine andere Aktion und Einsendungen, zu denen Google nicht innerhalb von drei Sekunden antwortet.	Personen, die unsere Formulare absenden; Wirkung: erneuter Versuch oder Weg über die Kontaktseite.
Schwarmschutz	Setzt eine Link-Domain automatisch auf eine Liste, wenn Mindestzahlen erreicht sind; Schutzschichten verbundener Websites legen Nachrichten mit solchen Links in die Quarantäne.	Absender von Nachrichten an Kundenseiten. Wirkung: die Nachricht wird zurückgehalten, nicht gelöscht, und kann vom Website-Betreiber freigegeben werden. Die Entscheidung über die Nachricht trifft dessen Plugin auf seiner Website, nicht wir.
Vergleichswerte	„Besser geschützt als X % der geprüften Seiten“, nur aus Summen ab 20 Hosts.	Website-Betreiber; keine Wirkung.

Am nächsten an Art. 22 kommt die Schutzschicht des Plugins auf Kundenseiten, die Einsendungen automatisch zurückhält. Sie ist eine Verarbeitung des Website-Betreibers auf seinem Server (A.10). Sie löscht nichts, sondern legt in die Quarantäne, und der Betreiber kann jede Nachricht freigeben. Eine Profilbildung über Besucher findet weder dort noch bei uns statt; es gibt keine Besucherkennung, die eine Nachricht mit einer anderen verbindet.

8. Technische und organisatorische Maßnahmen (Art. 32) – allgemeine Beschreibung

Dieser Abschnitt ist die allgemeine Beschreibung nach Art. 30 Abs. 1 lit. g und Abs. 2 lit. d DSGVO. Die ausführliche Fassung steht auf der Seite Technische und organisatorische Maßnahmen. Jede Maßnahme unten ist im Code oder in der Konfiguration belegt. Maßnahmen, die noch nicht umgesetzt sind, stehen im selben Abschnitt (8.1), damit die Beschreibung vollständig ist.

Bereich	Wirksame Maßnahme
Transportverschlüsselung	HTTPS für Website, App und Schnittstellen; HSTS; Sitzungs- und Merker-Cookies nur über HTTPS, HttpOnly, SameSite=Lax.
Zugangskontrolle	Passwörter nur als Hash, neue mit mindestens zehn Zeichen und höchstens 72 Byte; Anmeldesperre nach wiederholten Fehlversuchen und Versuchsgrenzen je Konto und IP-Adresse zusammen, je Konto und je IP-Adresse, sodass Fehlversuche von einer fremden Adresse den Inhaber nicht aussperren; Versuchsgrenzen auch für Passwortbestätigungen, Zurücksetzen (mit gleicher Antwort und Antwortzeit), Registrierungen und Portal-Passwörter; Zwei-Faktor-Anmeldung (TOTP) mit verschlüsseltem Geheimnis, Schutz gegen Wiederverwenden eines Codes und gehashten Wiederherstellungscodes; neue Sitzungskennung bei jeder Anmeldung, nicht vom Server ausgegebene Kennungen werden nicht angenommen; „Angemeldet bleiben“ nicht für Superadmins, jedes Merkmal nur einmal gültig; eine Änderung der E-Mail-Adresse macht einen offenen Link zum Zurücksetzen ungültig; Geräte einzeln oder alle widerrufbar; in der Geräteliste nur der Hash der Sitzungskennung.
Zugriffskontrolle	Rollen je Arbeitsbereich (Eigentümer, Admin, Leser); Rechte werden am Objekt geprüft, nie an einer Kennung aus dem Formular; Testkonto, „Fix it for me“ und aktive Prüfungen nur für Eigentümer und Admins; „Ansicht als Kunde“ zeitlich begrenzt und für kontoverändernde Handlungen gesperrt, ihr Ende meldet vollständig ab, zurück in den Verwaltungsbereich nur mit Passwort und zweitem Faktor; Einladungen nur gültig, solange die einladende Person Eigentümer oder Admin ist; Adressen von Webhooks und Chat-Kanälen für Leser nur gekürzt auf den Host; der Hostname einer verifizierten Domain lässt sich nicht ändern.
Anwendungssicherheit	CSRF-Token; vorbereitete Datenbankanweisungen; eigener Formularschutz (Falle, signierte Zeitprüfung); reCAPTCHA an den öffentlichen Formularen; Ratenbegrenzung für Support, Prüfungen und Schnittstellen; je Arbeitsbereich nur ein Aufruf von „Fix it for me“ zur selben Zeit, damit das Kontingent auch bei gleichzeitigen Anfragen gilt; Content-Security-Policy mit Rahmenschutz, die nur Skripte mit der Freigabe (Nonce) der jeweiligen Antwort ausführen lässt; IP-Adresse aus weitergereichten Kopfzeilen nur vom eigenen Proxy und nur aus dem von ihm angehängten Eintrag; Zugangskennungen im Seitenaufrufprotokoll unkenntlich gemacht.
Geheimnisse	API-Schlüssel, Rollout-Codes, Verbindungsgeheimnisse des Plugins, Einmal-Codes und Portal-Passwörter nur als Hash; Testkonto-Zugangsdaten asymmetrisch verschlüsselt, privater Schlüssel nur auf dem Scan-Server; Webhooks signiert; Stripe-Ereignisse nur mit gültiger Signatur.
Datenminimierung	Zustellungsprüfung speichert keine Inhalte und keine vollständigen Absenderadressen; Empfängeradressen in Formularen nur als Domain; Konto-Kennungen in Skript-Adressen werden ersetzt; Plugin-Zahlen nur aus festen Listen; Fehlertexte des Mailversands nur als Kategorie; Telegram-Signale ohne Variable; Bilder der Browserprüfung mit maskierten Eingaben; keine Bildschirmfotos hinter einer Anmeldung.
Abschottung des Scanners	Jede Prüfung in einem eigenen Container: alle Linux-Fähigkeiten entzogen, keine Rechteausweitung, schreibgeschütztes Dateisystem, Speicher- und Prozessgrenze, eigenes Netz; Zielprüfung gegen private und lokale Netze vor der Annahme und im Scanner, auch nach Weiterleitungen; Service Worker gesperrt, WebSocket-Verbindungen geschlossen. Abrufe des Webservers (Nachweis, Header-Werkzeug, Dateisuche, Puls, RDAP, Zertifikate, Webhooks und Chat-Alarme) nur auf den üblichen Web-Ports und nur zu genau der geprüften Adresse, Webhooks und Chat-Alarme nur über HTTPS.
Ablage	Bildschirmfotos außerhalb des Web-Verzeichnisses, nur über den Bericht abrufbar; Berichte unter Zufallsadressen mit noindex; Sicherungsverzeichnis nur für den Dienst lesbar.
Verfügbarkeit und Wiederherstellung	Nächtliche Sicherung mit Inhaltsprüfung, wöchentliche Wiederherstellungsprobe, Alarm bei Fehlschlag; Komponentenprüfung alle fünf Minuten mit Signal und Mail; externer Herzschlag; Notaus für anonyme Prüfungen; Druckausgleich bei Stau.
Nachvollziehbarkeit	Aktivitätsprotokoll für Anmeldungen, Änderungen, Löschungen, Support-Zugriffe und Freigaben; Fehlerprotokoll mit Alarm.
Löschung	Fristen an einer Stelle im Code, aus denselben Einstellungen wie die Texte (Abschnitt 6); Löschketten für Domain, Arbeitsbereich und Konto, mit den Ausnahmen aus Abschnitt 6.4.
Betroffenenrechte	Datenexport aller Kontodaten als Datei mit einem Klick, nach einer Positivliste der Felder, ohne Geheimnisse.
Organisation	Verwaltungsbereich nur für Konten mit Superadmin-Recht, gesperrt während der „Ansicht als Kunde“; Entwicklungs- und Produktivsystem getrennt, das Entwicklungssystem hinter einer zusätzlichen Zugangssperre; Übertragung von Rechtstexten nach Freigabe über ein Werkzeug, das Entwürfe und Platzhalter verweigert.

8.1 Noch nicht umgesetzte Maßnahmen

• Keine Verschlüsselung der Datenbank im Ruhezustand (gemessen am 11.10.2026). Ausnahme sind die Testkonto-Zugangsdaten und das Zwei-Faktor-Geheimnis, die auf Feldebene verschlüsselt sind.
• Interne Verbindungen nicht durchgehend verschlüsselt. Verbindungen innerhalb unseres internen Netzes sind nicht durchgehend verschlüsselt. Testkonto-Zugangsdaten gehen dort nur als Chiffretext.
• Keine Sicherung an einem zweiten Standort. Die Sicherungen liegen derzeit am selben Standort wie die Datenbank und sind nicht gesondert verschlüsselt; eine verschlüsselte Kopie an einem zweiten Standort ist geplant. Bis dahin schützen sie vor einem falschen Löschbefehl, nicht vor dem Verlust des Standorts.
• Härtung der Serververwaltung nicht abgeschlossen. Die Absicherung der Verwaltungszugänge unserer Server entspricht noch nicht dem Stand, den wir für den Betrieb vorsehen; die Härtung wird fortgesetzt. Einzelheiten veröffentlichen wir nicht, weil sie einem Angreifer helfen würden; einer Aufsichtsbehörde legen wir sie auf Anfrage vor.
• Kein fachliches Leseprotokoll im Verwaltungsbereich. Schreibende Handlungen stehen im Aktivitätsprotokoll; wer welche Supportanfrage oder welchen Bericht nur angesehen hat, ergibt sich allein aus dem Seitenaufrufprotokoll (60 Tage).
• Kein dauerhaftes Löschprotokoll. Was der nächtliche Lauf gelöscht hat, wird nicht festgehalten (Abschnitt 6).
• Keine unabhängige zweite Prüfstelle. Die Sonde an einem zweiten Standort ist nicht eingerichtet (A.6).

9. Datenschutzbeauftragter – Bewertung nach Art. 37 DSGVO

Ergebnis: Nach unserer Bewertung besteht keine Pflicht zur Benennung. Die Bewertung ist Teil der anwaltlichen Prüfung und wird wiederholt, sobald sich einer der unten genannten Umstände ändert.

Art. 37 Abs. 1 verlangt eine Benennung in drei Fällen.

• Buchstabe a (Behörde oder öffentliche Stelle) entfällt.
• Buchstabe b (Kerntätigkeit, die eine umfangreiche regelmäßige und systematische Überwachung von Personen erfordert): Unsere Kerntätigkeit ist die regelmäßige, systematische Prüfung von Websites und Formularen, nicht die Beobachtung von Personen. Wir erstellen keine Besucherprofile, setzen keine Wiedererkennung ein und verbinden keine Nachricht mit einer anderen. Die Zustellungsprüfung (A.1) lässt echte Besuchernachrichten durch unser Postfach laufen, wertet aber nur Kopfzeilen und die ersten 8 KB zur Zuordnung aus und speichert keine Inhalte; sie beobachtet Zustellwege, nicht Menschen. Kundenkonten und Protokolle sind der Geschäftstätigkeit beigeordnet.
• Buchstabe c (umfangreiche Verarbeitung besonderer Kategorien nach Art. 9 oder von Daten über Straftaten nach Art. 10 als Kerntätigkeit): nicht erfüllt. Besondere Kategorien können beiläufig in Kopien von Formularmails (A.1), auf Seiten hinter einem Login (A.5) oder in eingefügtem Code (A.7) auftreten; eine beiläufige Erfassung ist keine Kerntätigkeit.

Art. 37 Abs. 4 erlaubt dem nationalen Recht weitere Fälle. Ob das polnische Recht für uns eine Benennung verlangt, lassen wir anwaltlich bestätigen.

Auslöser für eine neue Bewertung: die Aktivierung des Schwarmschutzes mit IP-Netzen; eine Funktion, die Besucher über mehrere Nachrichten oder Websites hinweg wiedererkennt; die Speicherung von Inhalten aus der Zustellungsprüfung; ein Kunde, dessen Formulare überwiegend besondere Kategorien betreffen (Gesundheit, Bewerbungen), mit eingeschalteter Zustellungsprüfung in großem Umfang; der erste Beschäftigte mit Zugriff auf Kundendaten. Eine freiwillige Benennung bleibt möglich; dann gelten Art. 37 bis 39 vollständig.

Davon getrennt: Ob für einzelne Verarbeitungen eine Datenschutz-Folgenabschätzung nach Art. 35 nötig ist, beantwortet die Seite Datenschutz-Folgenabschätzung. Ihre Schwellwertprüfung kommt zu dem Ergebnis, dass eine Folgenabschätzung für den Schwarmschutz (B.21) und für Studien in der angelegten Größe (B.7) erforderlich ist und von uns durchgeführt wird, und dass sie für die Zustellungsprüfung (A.1) in der typischen Konstellation erforderlich ist, als Pflicht des Kunden, den wir dabei unterstützen.

10. Offene Punkte und geplante Maßnahmen

Die folgenden Punkte sind am Code, am Schema oder an der Konfiguration belegt, nicht vermutet. Sie beschreiben den Stand zum Datum dieser Fassung; die Einordnung ist unsere eigene und nimmt keine rechtliche Würdigung vorweg. Geordnet sind sie nach ihrem Gewicht für die betroffenen Personen, nicht danach, wie leicht sie zu beheben sind. Die geplanten Maßnahmen und ihr Vorrang stehen in der Datenschutz-Folgenabschätzung.

Offener Punkt	Was belegt ist	Bedeutung
Mail-Dienstleister ohne dokumentierten Vertrag	Für Namecheap, Inc. (Private Email), Phoenix, Arizona, USA sind Vertrag, Verarbeitungsorte und Übermittlungsgrundlage nicht dokumentiert. Über diesen Dienstleister laufen Kontomails, Alarme und das Kontrollpostfach mit echten Besuchernachrichten.	Maßgeblich sind Art. 28 Abs. 2 und 4 und Kapitel V DSGVO. Abschluss und Dokumentation sind vor dem Start vorgesehen.
Grundlagen für Chat-Dienste und reCAPTCHA offen	Alarme an Telegram (kein Angemessenheitsbeschluss), Slack, Discord, Microsoft Teams und Google Chat; reCAPTCHA ohne Einwilligungsabfrage.	Offene Fragen der anwaltlichen Prüfung; bis dahin sind Hinweis und Grundlage nicht abschließend.
Kontrollpostfach kann bei Störungen Nachrichten halten	Gelöscht wird nach erfolgreicher Verarbeitung; scheitert der Abruf, bleiben die Kopien bis zum nächsten erfolgreichen Lauf. Eine Warnung bei längerem Rückstau im Postfach gibt es nicht.	Die Kopien enthalten echte Besucheranfragen.
Keine Sicherung an einem zweiten Standort, keine Verschlüsselung der Datenbank im Ruhezustand	Abschnitt 8.1. Eine verschlüsselte Kopie der Sicherung an einem zweiten Standort ist geplant.	Ein einzelnes Ereignis am Standort erfasst Daten und Sicherung zugleich; ein entwendeter Datenträger wäre lesbar.
Unerledigte Auffälligkeiten ohne Frist	Auffälligkeiten mit vollständiger IP-Adresse als Schlüssel werden erst 90 Tage nach ihrer Erledigung gelöscht; wer nie erledigt wird, bleibt.	Bezug zum Grundsatz der Speicherbegrenzung (Art. 5 Abs. 1 lit. e); die Löschung hängt an einer manuellen Erledigung. Eine feste Frist ist geplant (Maßnahmen der Datenschutz-Folgenabschätzung).
Fehlerarten mit Beispielmeldung ohne Frist	Die Beispielmeldung wird unverändert bis 2.000 Zeichen gespeichert; das bereinigte Muster entfernt Adressen und Zahlen, das Beispiel nicht.	Fehlermeldungen können E-Mail-Adressen, Hostnamen oder IP-Adressen enthalten.
Skript-Inventar ohne eigene Frist	Skript-Inventar und Skript-Änderungen werden mit der Domain gelöscht (FE_DOMAIN_TABELLEN), auch beim Löschen von Arbeitsbereich oder Konto und im nächtlichen Lauf für Waisen; eine eigene Frist haben sie nicht. Sie enthalten Skript-Adressen, Seitenadressen und bei Freigaben die freigebende Person und eine Begründung im Freitext.	Bezug zum Grundsatz der Speicherbegrenzung (Art. 5 Abs. 1 lit. e); das Änderungsprotokoll mit den Freigaben wächst, solange die Domain besteht.
Abonnenten widerrufener Portale	Ein widerrufenes Portal wird gesperrt, nicht gelöscht; seine Abonnenten bleiben bis zur Löschung des Arbeitsbereichs.	Der Zweck (Versand des Berichts) ist mit dem Widerruf entfallen.
Studienlisten ohne Frist	Nach der Veröffentlichung bleiben Hosts und Segmente stehen; nie veröffentlichte Studien behalten auch ihre Rohdaten.	Die Zusage „Rohdaten werden gelöscht“ gilt nur für veröffentlichte Studien.
Interne Prüfungen ohne Löschweg	Prüfungen mit der Vertrauensstufe „intern“, die weder eine Domain noch einen Bericht haben (Studien und vom Betreiber von der Kommandozeile angelegte Prüfungen), erfasst keiner der Löschwege; mit ihnen bleiben Formulare, Befunde und Bildschirmfotos fremder Websites.	Bezug zum Grundsatz der Speicherbegrenzung (Art. 5 Abs. 1 lit. e); betrifft Personen, die von der Prüfung nichts wissen. Bewertet als hohes Risiko in der Datenschutz-Folgenabschätzung.
Eigentumsnachweis wird nicht erneuert	Der Nachweis der Verfügungsbefugnis wird einmal geprüft; einen Weg, auf dem eine Domain ihn wieder verliert, gibt es im Code nicht.	Aktive Test-Einsendungen, Dateisuche und Scan hinter dem Login laufen nach einem Inhaber- oder Mandatswechsel weiter.
Scan hinter dem Login: Transport zur Kundenseite	Als Anmeldeadresse ist neben https auch http zugelassen, und Zertifikatsfehler der Kundenseite halten die Anmeldung nicht auf.	Zugangsdaten des Testkontos könnten auf dem Weg zur Kundenseite mitgelesen werden.
Löschung hängt an einem Zeitfenster	Der tägliche Block läuft nur, wenn ein Statuslauf zwischen 03:00 und 03:04 Uhr startet. Fällt dieser eine Lauf aus (Datenbank nicht erreichbar, Server neu gestartet), entfallen Löschung und Sicherung dieses Tages; nachgeholt wird nicht. Was gelöscht wurde, wird nicht dauerhaft protokolliert.	Die Fristen verlängern sich dann still um einen Tag. Ein ausgelassenes Fenster löst keinen Alarm aus; gemeldet wird nur eine Sicherung, die läuft und scheitert. Die Einrichtungsliste im Verwaltungsbereich zeigt das Datum der letzten erfolgreichen Sicherung.
Einige Löschungen hängen an der Überwachung	Das Leeren des Kontrollpostfachs der Zustellungsprüfung, das Löschen von Vorfällen, versandten Sammelmeldungen, Schwarm-Signalen und Interessenten-Prüfungen und das Leeren übrig gebliebener Testkonto-Kopien in Aufträgen laufen im Planer-Teil des Statuslaufs, der nur arbeitet, solange die Überwachung im Verwaltungsbereich eingeschaltet ist; die Zuordnungen der Zustellungsprüfung werden nur gelöscht, solange ein Kontrollpostfach eingerichtet ist.	Wird die Überwachung zentral abgeschaltet oder das Postfach entfernt, stehen diese Fristen still, ohne dass es auffällt.
Meldestelle und Postfächer ohne Frist	Meldungen zu Sicherheitslücken und andere eingehende E-Mails werden außerhalb der Anwendung gehalten; eine Frist ist nicht festgelegt.	Meldungen können Belegdaten Dritter enthalten.
Werte verborgener Felder werden während der Prüfung gelesen	Der Scanner liest den Wert verborgener Formularfelder bis 24 Zeichen und Datenattribute bis 60 Zeichen, um Zeitstempel und Token zu erkennen. In die Feldkarte und die Befunde gelangen nur Feldname, Typ, Beschriftung und das Erkennungsergebnis, nicht der Wert.	Keine Speicherlücke; der Wert liegt nur während der Prüfung im Arbeitsspeicher des Prüf-Containers. Ein vorbelegter Wert (etwa eine Kundennummer) wird dabei gelesen, aber nicht abgelegt.
Abgeleitete Absender-Domain im Echtheitsergebnis	A.1.	Bei persönlichen Domains von Besuchern ein personenbezogenes Datum, das aus einer echten Nachricht stammt.
Härtung der Serververwaltung nicht abgeschlossen; interne Verbindungen nicht durchgehend verschlüsselt	Abschnitt 8.1. Die Härtung wird fortgesetzt; Einzelheiten nennen wir nicht öffentlich.	Ein Sicherheitsvorfall auf Serverebene beträfe Anwendung, Datenbank und Sicherungen zugleich.
Messung auf dem Entwicklungssystem	Schema, Code und Einstellungen wurden auf dem Entwicklungssystem gemessen.	Code und Schema entsprechen dem Produktivsystem; Einstellungen können abweichen und sind dort vor dem Start erneut zu prüfen.

11. Pflege dieses Verzeichnisses

Art. 30 verlangt, das Verzeichnis schriftlich zu führen und der Aufsichtsbehörde auf Anfrage zur Verfügung zu stellen. Dafür braucht es jemanden, der es verantwortet, und einen Abstand, in dem es gegen das System geprüft wird statt gegen seine Vorfassung.

• Verantwortung: Lukas Wójcik, Inhaber. Geprüft wird jährlich und bei jeder Änderung einer Verarbeitung.
• Ereignisse, die eine Fortschreibung erzwingen: ein neuer oder gewechselter Unterauftragsverarbeiter, insbesondere die Festlegung des Mail-Dienstleisters; eine neue Tabelle oder ein neues Feld mit personenbezogenen Daten; eine Änderung der Fristen oder der Löschketten in cfg/fristen_lib.php oder srv/cron_status.php; ein neuer Alarmkanal oder ein neuer Abruf bei einem Dritten; das Einschalten einer ab Werk ausgeschalteten Funktion (Schwarmschutz mit IP-Netzen, Sonde, eigene Domains, Partnerprogramm, Zahlung auf Rechnung, Spamhaus oder Google Web Risk); der Umzug auf andere Server.
• Vorgehen: Jede Aussage hier stammt aus Code, Schema oder Messung. Eine Überprüfung, die nur den Text liest, hat nichts überprüft: Schema und Löschketten werden neu gemessen, Platzhalter bleiben Platzhalter, offene Punkte werden geschlossen oder mit Begründung fortgeschrieben.
• Verhältnis zu anderen Dokumenten: Dieses Verzeichnis ersetzt weder die Datenschutzerklärung noch den Auftragsverarbeitungsvertrag, die Technischen und organisatorischen Maßnahmen oder die Liste der Unterauftragsverarbeiter. Wo sie und dieses Verzeichnis voneinander abweichen, ist die Abweichung ein Befund.
• Änderungen an diesem Dokument stehen auf der Seite Änderungen der Vertragsunterlagen.