Datenschutz-Folgenabschätzung (Art. 35 DSGVO)

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

Fassung 1.0 · Stand: 16. Oktober 2026

1. Worum es geht und was diese Seite ist

Diese Seite ist die Datenschutz-Folgenabschätzung von formexposed nach Art. 35 DSGVO. Sie beantwortet zuerst die Vorfrage, ob eine Folgenabschätzung überhaupt erforderlich ist – und zwar für jede Verarbeitung einzeln, nicht für den Dienst im Ganzen. Wo die Antwort ja lautet, führt sie die Abschätzung nach Art. 35 Abs. 7 lit. a bis d durch: systematische Beschreibung, Notwendigkeit und Verhältnismäßigkeit, Risiken für die betroffenen Personen und die Maßnahmen dagegen. Danach folgen das verbleibende Risiko, die Frage der vorherigen Konsultation nach Art. 36 und die Regeln für die Überprüfung.

Art. 35 verlangt nicht, eine Folgenabschätzung zu veröffentlichen. Wir tun es aus zwei Gründen. Erstens brauchen Kunden, die die Zustellungsprüfung oder den Scan hinter dem Login einsetzen, für ihre eigene Abschätzung Tatsachen, die nur wir kennen; diese Tatsachen schulden wir ihnen als Auftragsverarbeiter ohnehin (Art. 28 Abs. 3 lit. f DSGVO). Zweitens prüft unser Crawler Websites, deren Betreiber uns nicht kennen. Sie sollen nachlesen können, welche Risiken wir für sie und für die Personen auf ihren Seiten sehen und was wir dagegen tun.

Rechtsnatur. Diese Folgenabschätzung ist eine Dokumentation des Verantwortlichen nach Art. 35 DSGVO, die wir freiwillig veröffentlichen. Sie ist nicht Bestandteil eines Vertrags und begründet keine Zusicherung, Garantie oder Beschaffenheitsvereinbarung gegenüber Kunden oder Dritten. Welche Leistungen und Schutzmaßnahmen wir Kunden schulden, regeln die Allgemeinen Geschäftsbedingungen, der Auftragsverarbeitungsvertrag und dessen Anlagen; für diese Pflichten gehen sie dieser Seite vor. Die Seite beschreibt den Stand zum Datum dieser Fassung. Einstufungen von Risiken und Bewertungen sind unsere eigene Einschätzung und nehmen keine rechtliche Würdigung durch eine Aufsichtsbehörde oder ein Gericht vorweg; als „geplant“ bezeichnete Maßnahmen sind Vorhaben ohne zugesagten Termin. Für Kunden ist die Seite eine Grundlage ihrer eigenen Abschätzung, keine Rechtsberatung.

Dies ist die erste Fassung der Schwellwertprüfung. Sie prüft Verarbeitung für Verarbeitung, ob eine Folgenabschätzung erforderlich ist, und hält das Ergebnis in Abschnitt 3.5 fest.

Für jede Tatsachenaussage gilt derselbe Grundsatz wie in unseren übrigen Rechtsunterlagen: gemessen statt beabsichtigt. Was im Code oder in der Datenbank belegt ist, steht hier mit Fundstelle. Was nicht belegt werden konnte, ist als „nicht geprüft“ gekennzeichnet. Was nur geplant ist, heißt „geplant“. Offene Punkte nennen wir offen, zusammen mit der geplanten Maßnahme; eine Folgenabschätzung, die nur Stärken aufzählt, hilft den Personen nicht, um die es geht.

Begriffe: Ein Betreiber ist, wer eine geprüfte Website betreibt. Ein Kunde hat ein Konto bei formexposed. Ein Besucher ist, wer die Website eines Kunden nutzt, etwa ihr Kontaktformular. Mit Fundstelle ist eine Datei, Funktion oder Einstellung des Quelltexts gemeint, gemessen am Stand des Entwicklungssystems vom 11. Oktober 2026.

Eine Grenze der Offenheit ziehen wir bewusst: Offene Punkte bei der Absicherung unserer eigenen Server beschreiben wir nur allgemein (R13). Das Risiko und seine Stufe benennen wir, den Weg zu einer konkreten Schwachstelle nicht; einer Aufsichtsbehörde legen wir die Einzelheiten auf Anfrage vor.

2. Rollen: wen die Pflicht trifft, und wofür

Art. 35 verpflichtet den Verantwortlichen. formexposed ist für einige Verarbeitungen Verantwortlicher, für andere Auftragsverarbeiter seiner Kunden, und für die Daten, die unser WordPress-Plugin und unsere TYPO3-Erweiterung auf der Website eines Kunden speichern, weder das eine noch das andere. Die Antwort auf fast jede Frage in diesem Dokument hängt davon ab, nach welcher Rolle gefragt wird. Die Zuordnung folgt der Datenschutzerklärung und dem Auftragsverarbeitungsvertrag.

Verarbeitung	Rolle von formexposed	Wen die Pflicht aus Art. 35 trifft
Prüfung fremder Websites ohne Auftrag ihres Betreibers: kostenloser Check, Interessenten-Prüfung für Agenturen, Studie	Verantwortlicher	formexposed
Prüfung von Domains im Kundenkonto: Überwachung, aktive Test-Einsendungen, Browserwege, offen liegende Dateien, Formular-Puls	Verantwortlicher für Konto- und Prüfdaten des Kunden; Auftragsverarbeiter für personenbezogene Daten Dritter, die auf der nachgewiesenen Website des Kunden sichtbar sind; solange eine Domain nicht nachgewiesen ist, Verantwortlicher wie beim kostenlosen Check	formexposed für den eigenen Teil; der Kunde für die Daten Dritter auf seiner Website
Scan hinter dem Login mit einem Testkonto	Auftragsverarbeiter: Zugangsdaten und Inhalte hinter der Anmeldung gehören zur Website des Kunden	Der Kunde; formexposed unterstützt
Zustellungsprüfung mit Kontrollkopie	Auftragsverarbeiter	Der Kunde; formexposed unterstützt
Schwarmschutz: gemeinsame Liste von Link-Domains aus abgewehrtem Spam	Verantwortlicher: wir führen die Meldungen vieler Websites zusammen, bilden die Liste und verteilen sie	formexposed
Kundenkonten, Anmeldung, Protokolle, Support, E-Mail-Versand, Zahlungen, Nachweise	Verantwortlicher	formexposed
Kundenportal und Monatsbericht an Abonnenten einer Agentur	Auftragsverarbeiter	Die Agentur
Daten, die Plugin und Erweiterung auf der Kundenwebsite speichern (Quarantäne, Rettungsnetz, gespeicherte Anfragen)	Weder noch: die Daten verlassen die Website nicht	Der Betreiber der Website

Daraus folgt eine Unterscheidung, die wir ausdrücklich festhalten, weil sie in beide Richtungen oft falsch gemacht wird. Wo formexposed Verantwortlicher ist, führen wir die Abschätzung selbst und tragen ihr Ergebnis. Wo wir Auftragsverarbeiter sind, können wir die Abschätzung des Kunden nicht an seiner Stelle durchführen, die Erforderlichkeitsfrage nicht für ihn entscheiden und die Aufsichtsbehörde nicht nach Art. 36 an seiner Stelle konsultieren. Was wir dort können und müssen, ist, ihm alles zu liefern, was er dafür braucht: die Beschreibung nach lit. a, die gemessenen Tatsachen zu den Risiken nach lit. c und eine ehrliche Statusliste der Maßnahmen nach lit. d. Für die Zustellungsprüfung und den Scan hinter dem Login ist diese Seite genau das.

Ein Kunde, der die Abschnitte zur Zustellungsprüfung unverändert als eigene Folgenabschätzung übernimmt, hat keine durchgeführt. Ob die Kontrollkopie für seine Formulare gerechtfertigt ist, ob dort besondere Kategorien personenbezogener Daten zu erwarten sind und wie er seine Besucher informiert, kann nur er entscheiden. Abschnitt 11 fasst zusammen, was dafür zu klären ist.

3. Schwellwertprüfung: ist eine Folgenabschätzung erforderlich?

3.1 Art. 35 Abs. 1 und Abs. 3

Art. 35 Abs. 1 verlangt eine Folgenabschätzung, wenn eine Form der Verarbeitung, insbesondere bei Verwendung neuer Technologien, aufgrund ihrer Art, ihres Umfangs, ihrer Umstände und ihrer Zwecke voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge hat. Art. 35 Abs. 3 nennt drei Fälle, in denen das insbesondere so ist. Keiner der drei passt auf formexposed, und das sollte begründet statt behauptet werden:

Lit. a – systematische und umfassende Bewertung persönlicher Aspekte natürlicher Personen auf Grundlage automatisierter Verarbeitung, die Grundlage für Entscheidungen mit Rechtswirkung oder ähnlich erheblicher Beeinträchtigung ist. Wir bewerten Formulare und Websites, nicht persönliche Aspekte von Menschen. Eine Entscheidung mit Rechtswirkung gegenüber einer Person trifft der Dienst nicht. Am nächsten kommt dem der Schwarmschutz: Nachrichten mit einem Link auf eine gelistete Domain landen auf den angeschlossenen Websites in der Quarantäne. Das ist eine automatisierte Folge für die Nachricht, keine umfassende Bewertung einer Person; wir behandeln es unter dem Kriterium „Bewerten oder Einstufen“ in Abschnitt 3.3.
Lit. b – umfangreiche Verarbeitung besonderer Kategorien nach Art. 9 oder von Daten über Straftaten nach Art. 10. Nicht beabsichtigt und nicht gebaut. Auf einem Weg können solche Daten trotzdem bei uns ankommen: in der Kontrollkopie echter Besuchernachrichten bei der Zustellungsprüfung. Das ist einzelfallabhängig und nicht umfangreich im Sinne dieser Vorschrift; es geht aber in die Risikobewertung ein (R1).
Lit. c – systematische umfangreiche Überwachung öffentlich zugänglicher Bereiche. Gemeint ist die körperliche Beobachtung von Orten, nicht der Abruf öffentlicher Webseiten. Diese Vorschrift als Aufhänger für einen Website-Crawler anzuführen wäre unzutreffend.

Der richtige Weg ist deshalb Art. 35 Abs. 1 selbst, angewendet über die neun Kriterien der Leitlinien der Artikel-29-Datenschutzgruppe zur Datenschutz-Folgenabschätzung (WP248 rev.01, vom Europäischen Datenschutzausschuss bestätigt), und die Liste der polnischen Aufsichtsbehörde nach Art. 35 Abs. 4 (Abschnitt 3.4).

3.2 Die neun Kriterien der Leitlinien WP248

Die Leitlinien nennen neun Merkmale, die auf ein voraussichtlich hohes Risiko hinweisen. Als Faustregel gilt: Erfüllt eine Verarbeitung zwei davon, ist in den meisten Fällen eine Folgenabschätzung durchzuführen. Ein Verantwortlicher kann im Einzelfall zu einem anderen Ergebnis kommen, muss das dann aber begründen und dokumentieren. Umgekehrt kann schon ein Kriterium genügen. Wir verwenden in dieser Seite die folgenden Kurzbezeichnungen:

K1 – Bewerten oder Einstufen, einschließlich Profiling und Prognose, etwa der Arbeitsleistung, wirtschaftlichen Lage, Zuverlässigkeit oder des Verhaltens.
K2 – Automatisierte Entscheidung mit Rechtswirkung oder ähnlich erheblicher Wirkung.
K3 – Systematische Überwachung, also Beobachtung, Überwachung oder Kontrolle betroffener Personen, auch über Netze. Die Leitlinien begründen das Kriterium ausdrücklich damit, dass Betroffene oft nicht wissen, wer ihre Daten erhebt und wofür.
K4 – Vertrauliche oder höchstpersönliche Daten: besondere Kategorien nach Art. 9 und 10, aber auch Daten, deren Bekanntwerden das tägliche Leben erheblich berührt, darunter elektronische Kommunikation, deren Vertraulichkeit zu schützen ist.
K5 – Umfangreiche Verarbeitung, gemessen an der Zahl der Betroffenen, der Menge und Bandbreite der Daten, der Dauer und der geografischen Reichweite.
K6 – Abgleichen oder Zusammenführen von Datensätzen aus verschiedenen Verarbeitungen oder von verschiedenen Verantwortlichen, auf eine Weise, die Betroffene nicht erwarten.
K7 – Daten schutzbedürftiger Personen, etwa von Beschäftigten, Kindern, Patienten oder anderen Personen in einem Machtgefälle.
K8 – Innovative Nutzung oder Anwendung neuer technologischer oder organisatorischer Lösungen; in der Aufsichtspraxis wird der Einsatz künstlicher Intelligenz regelmäßig hierunter gefasst.
K9 – Hinderung an der Ausübung eines Rechts oder an der Nutzung einer Dienstleistung oder eines Vertrags.

Wir bewerten jedes Kriterium mit „erfüllt“, „Grenzfall“ oder „nicht erfüllt“ und begründen die Einordnung aus dem Code. Ein Grenzfall zählt in der Summe nicht als erfüllt, wird aber im Ergebnis genannt; wo mehrere Grenzfälle in dieselbe Richtung weisen, führen wir die Verarbeitung in der Abschätzung mit.

3.3 Prüfung je Verarbeitung

V1 – Kostenloser Check ohne Konto (Prüfung beliebiger fremder Websites auf Zuruf)

Jeder kann auf der Startseite eine Domain eingeben. Der Crawler ruft dann höchstens acht öffentliche Seiten dieser Website ab, liest die Formulare aus, macht Bildschirmfotos und erstellt einen Report, den jeder sieht, der seinen zufälligen Link kennt. Der Betreiber der Website erfährt davon nichts, sofern er nicht die Kennung des Crawlers in seinen Protokollen bemerkt.

K1 – Grenzfall. Der Report bewertet den Schutz eines Formulars mit einer Stufe („ungeschützt“, „teilweise geschützt“, „geschützt“) und einer Punktzahl. Bei einer GmbH betrifft das keine natürliche Person. Bei Einzelunternehmern und Freiberuflern ist die Domain dem Menschen zuzuordnen, und die Stufe sagt dann etwas über die Sorgfalt in seiner beruflichen Tätigkeit. Bewertet wird aber eine technische Einrichtung, nicht Verhalten oder Eigenschaften einer Person. Wir werten das als Grenzfall.
K2 – nicht erfüllt. Gegenüber dem Betreiber wird nichts entschieden. Gegenüber der Person, die den Check anfordert, greifen Grenzen je IP-Adresse und Sitzung (cfg/check_lib.php); eine abgewiesene Prüfung hat keine erhebliche Wirkung.
K3 – nicht erfüllt. Es ist ein einzelner Abruf auf Zuruf, höchstens einmal je Domain und Woche (cfg/check_lib.php, Einstellung fc_domain_days = 7). Personen werden nicht beobachtet. Der Umstand, den die Leitlinien zur Begründung von K3 anführen – die Betroffenen wissen nichts von der Verarbeitung –, liegt allerdings vor. Er fließt in die Risikobewertung ein (R5).
K4 – nicht erfüllt. Gespeichert werden Formularaufbau und Befunde, keine eingetragenen Werte (scanner/src/crawl.js speichert bei sichtbaren Feldern nur die Länge eines Werts). Die Anfänge vorbelegter versteckter Felder (bis 24 Zeichen) und data-Attribute (bis 60 Zeichen) liest der Scanner nur während der Prüfung, um Token und Zeitstempel zu erkennen; gespeichert werden sie nicht. Bildschirmfotos können beiläufig Personen und Namen zeigen; die Website einer Arztpraxis zeigt im Bild die Fachrichtung. Das sind öffentliche Berufsangaben, keine Gesundheitsdaten einer bestimmten Person.
K5 – Grenzfall. Die Tagesobergrenze liegt bei 200 angenommenen Prüfungen (fc_daily_cap), rechnerisch also bis zu rund 73.000 Websites im Jahr. Je Website fallen nur wenige personenbezogene Angaben an, die Dauer ist kurz (30 Tage). Gemessen am Entwicklungssystem stehen 2 anonyme Prüfungen im Bestand. Heute nicht erfüllt; nach der angelegten Größe ein Grenzfall.
K6 – nicht erfüllt. Neben dem Abruf der Seiten fragt der Dienst das Alter der Domain über den RDAP-Dienst rdap.org ab (übermittelt wird nur der Domainname; gespeichert nur das Registrierungsdatum, zwischengespeichert) und löst DNS auf. Das sind technische Angaben zur Domain, keine Zusammenführung von Datensätzen über Personen.
K7 – nicht erfüllt.
K8 – erfüllt, in schwacher Form. Ein automatisierter Browser prüft die Seiten, und ein Sprachmodell auf unserem eigenen Server ordnet Formulare ein, die die Regeln nicht erkennen (scanner/src/classify.js). Das Modell sieht Seitentitel, Adresse, Feldbeschriftungen und bis zu 400 Zeichen Formulartext. Es kann ein Formular nie „absendbar“ machen.
K9 – nicht erfüllt.

Zwischenergebnis V1: ein Kriterium in schwacher Form (K8), zwei Grenzfälle (K1, K5). Nach der Faustregel keine Pflicht. Weil beide Grenzfälle in dieselbe Richtung weisen und die Betroffenen von der Verarbeitung nichts wissen, führen wir V1 in der Abschätzung mit.

V2 – Interessenten-Prüfung für Agenturen

Eine Agentur im Business-Tarif mit hinterlegter eigener Marke kann die Website eines Interessenten passiv prüfen lassen. Sie erhält einen Kurzbefund unter ihrer Marke und einen ausführlichen Report und gibt den Link selbst weiter (cfg/akquise_lib.php). Wir schreiben niemanden an.

K1 – Grenzfall, stärker als bei V1. Der Kurzbefund ist ausdrücklich als „Türöffner fürs erste Gespräch“ gedacht. Die Bewertung der Website wird also Grundlage dafür, einen Menschen geschäftlich anzusprechen.
K5 – nicht erfüllt. Höchstens 30 Prüfungen je Agentur und Monat (prospect_monthly), gelöscht nach 90 Tagen.
K8 – erfüllt, in schwacher Form (dieselbe Technik wie V1).
Übrige Kriterien – nicht erfüllt. Der Befund wird mit der Marke der Agentur dargestellt, aber nicht mit anderen Daten über den Betreiber verbunden.

Zwischenergebnis V2: keine Pflicht nach der Faustregel; mitgeführt aus denselben Gründen wie V1 und weil der Zweck – Akquise – ein eigenes Risiko trägt (R6).

V3 – Studie „Formular-Sicherheitsindex“

Für eine Studie wird eine Liste von Websites passiv geprüft, gedrosselt auf höchstens fünf offene Aufträge je Lauf des Statusprozesses, der alle fünf Minuten läuft (cfg/studie_lib.php). Veröffentlicht werden nur Summen, Segmente erst ab 20 Websites mit Formular (study_min_segment, cfg/studie_lib.php). Die Rohdaten werden mit der Veröffentlichung gelöscht (cfg/studie_lib.php).

K5 – Grenzfall, bei großen Listen erfüllt. Die Listengröße ist im Code nicht begrenzt; die Drosselung erlaubt rechnerisch über tausend Prüfungen am Tag. Eine Studie über einen Ländermarkt umfasst Tausende Websites, darunter viele von Einzelunternehmern. Ab einer solchen Größe sehen wir das Kriterium als erfüllt an.
K8 – erfüllt, in schwacher Form.
K1 – nicht erfüllt. Die einzelne Website wird zwar eingestuft, veröffentlicht wird aber nur die Summe; die Einstufung dient nicht einer Aussage über den einzelnen Betreiber.
Übrige Kriterien – nicht erfüllt.

Zwischenergebnis V3: bei Studien in der angelegten Größe zwei Kriterien (K5, K8). Die Studie erreicht damit die Schwelle; formexposed führt die Abschätzung als Verantwortlicher. Gemessen am Entwicklungssystem ist bisher keine Studie angelegt.

V4 – Prüfung von Domains im Kundenkonto

Für Domains in seinem Konto lässt der Kunde regelmäßig prüfen. Hat er nachgewiesen, dass er über die Domain verfügen darf, kommen aktive Test-Einsendungen (höchstens fünf je Prüfung), die Suche nach offen liegenden Dateien und konfigurierte Browserwege hinzu.

K3 – nicht erfüllt. Die Prüfung ist planmäßig und wiederkehrend, gilt aber der eigenen Website des Kunden und auf seinen Wunsch, nicht der Beobachtung von Personen.
K4 – Grenzfall, nein. Die Suche nach offen liegenden Dateien liest von Pfaden wie /backup.sql oder einem Debug-Protokoll höchstens die ersten 8 KB, um am Inhalt zu erkennen, ob die Datei wirklich offen liegt (cfg/dateien_lib.php). Ein solcher Auszug kann Formulareingaben von Besuchern enthalten. Er wird nur im Arbeitsspeicher geprüft und nie gespeichert; gespeichert werden Pfad, Art und Schwere.
K8 – erfüllt, in schwacher Form.
Übrige Kriterien – nicht erfüllt.

Zwischenergebnis V4: keine Pflicht. Mitgeführt, weil die aktiven Test-Einsendungen und die Dateiprüfung an einem Nachweis hängen, der nie erneuert wird (R7).

V5 – Scan hinter dem Login

Der Kunde kann für eine nachgewiesene Domain ein Testkonto seiner Website hinterlegen. Der Scanner meldet sich damit an und liest die Formulare auf bis zu fünf angegebenen Seiten des Kundenbereichs (cfg/login_lib.php, scanner/src/login.js).

K4 – Grenzfall. Zugangsdaten sind keine höchstpersönlichen Daten im Sinne der Leitlinien, aber ihr Missbrauch öffnet den Kundenbereich. Hinter einer Anmeldung kann je nach Website Vertrauliches stehen, etwa in einem Mitglieder- oder Patientenportal. Das hängt vom Kunden ab, nicht von uns.
K8 – nicht erfüllt. Automatisierte Anmeldungen sind in Überwachungsdiensten üblich.
Übrige Kriterien – nicht erfüllt.

Zwischenergebnis V5: keine Pflicht nach der Faustregel. Für Kunden, deren Kundenbereich vertrauliche Inhalte zeigt, kann sich das ändern; die Entscheidung liegt dann bei ihnen. Mitgeführt wegen der Sicherheitsrisiken (R8).

V6 – Zustellungsprüfung mit Kontrollkopie

Der Kunde trägt eine Kontrolladresse von formexposed als Blindkopie in die Mail-Einstellungen seines Formulars ein. Damit geht jede Formularmail auch an unser Kontrollpostfach – unsere Testnachricht ebenso wie jede echte Nachricht eines Besuchers. Ein automatischer Abruf liest Kopfzeilen und die ersten 8 KB, ordnet die Mail zu, wertet SPF, DKIM und DMARC aus und löscht sie (cfg/zustellung_lib.php).

K4 – erfüllt. Was Besucher in ein Kontaktformular schreiben, ist elektronische Kommunikation an ein Unternehmen mit beliebigem Inhalt. Auf der Website einer Arztpraxis, einer Kanzlei, einer Beratungsstelle oder einer Schule sind Angaben nach Art. 9 oder über Kinder zu erwarten. Die Leitlinien nennen vertrauliche elektronische Kommunikation ausdrücklich unter diesem Kriterium.
K3 – Grenzfall, eher erfüllt. Jede Nachricht wird planmäßig und fortlaufend kopiert und automatisch ausgewertet, ohne dass der Absender es bemerkt. Zweck ist die Kontrolle des Mailwegs, nicht die Beobachtung von Personen. Der Umstand, mit dem die Leitlinien das Kriterium begründen – Betroffene wissen nicht, wer ihre Daten erhält –, liegt aber vollständig vor, solange der Kunde seine Besucher nicht informiert.
K7 – je nach Kunde. Patienten, Mandanten, Bewerber, Eltern und Schüler stehen gegenüber dem Empfänger ihrer Nachricht häufig in einem Abhängigkeitsverhältnis.
K5 – Grenzfall, nein. Für den einzelnen Kunden nicht umfangreich. Bei formexposed laufen die Kopien vieler Kunden in einem Postfach zusammen; das erhöht das Gewicht einer Panne, nicht die Zahl je Verantwortlichem.
Übrige Kriterien – nicht erfüllt. Die Zuordnung zu Domain und Test ist kein Abgleich von Datensätzen über Personen; die Technik ist nicht neu.

Zwischenergebnis V6: K4 erfüllt, K3 als Grenzfall eher erfüllt, K7 bei vielen typischen Kunden erfüllt. In der typischen Konstellation sind damit zwei oder mehr Kriterien erfüllt. Die Folgenabschätzung ist erforderlich – als Pflicht des Kunden, der Verantwortlicher ist. Die Abschnitte 6 bis 11 liefern ihm dafür die Tatsachen.

V7 – Schwarmschutz

Verbundene WordPress-Websites melden einmal am Tag die Domains von Links aus Nachrichten, die ihre Schutzschicht gestoppt hat. Eine Domain, die bei mindestens drei verschiedenen Websites mit mindestens fünf Treffern binnen sieben Tagen auftaucht, kommt auf eine gemeinsame Liste; die Liste geht an alle verbundenen Websites zurück, die Nachrichten mit Links dorthin dann in die Quarantäne legen (cfg/swarm_lib.php).

K6 – erfüllt. Meldungen von vielen voneinander unabhängigen Websites, also von verschiedenen Verantwortlichen, werden zusammengeführt und als gemeinsame Liste an alle zurückgegeben.
K1 – erfüllt, soweit eine Domain einer natürlichen Person zuzuordnen ist. Die Liste ist eine Einstufung als Spam-Quelle. Die Leitlinien nennen den Abgleich mit einer gemeinsamen Betrugsdatenbank als Beispiel dieses Kriteriums. Die meisten Domains auf einer solchen Liste gehören Unternehmen oder sind Wegwerf-Domains; die Domain einer Einzelperson kann aber darauf geraten, zu Recht oder durch absichtlich gestreute Fehlmeldungen.
K9 – Grenzfall. Eine Nachricht mit einem gelisteten Link erreicht den Empfänger nicht sofort, sondern liegt in seiner Quarantäne, bis er sie freigibt. Sie geht nicht verloren.
K2 – nicht erfüllt. Die Quarantäne ist eine automatisierte Folge für eine Nachricht, ohne Rechtswirkung und mit menschlicher Freigabe beim Empfänger.
Übrige Kriterien – nicht erfüllt. IP-Netze sind ausgeschaltet (swarm_ip_enabled = 0, cfg/swarm_lib.php).

Zwischenergebnis V7: zwei Kriterien (K6, K1) und ein Grenzfall (K9). Die Schwelle ist erreicht; formexposed führt die Abschätzung als Verantwortlicher. Mit eingeschalteten IP-Netzen wären K1 und K6 ohne Einschränkung erfüllt; das Einschalten setzt eine neue Fassung dieser Abschätzung voraus (Abschnitt 12). Gemessen am Entwicklungssystem sind weder Meldungen noch Listeneinträge vorhanden.

V8 – Kundenkonten, Anmeldung, Protokolle, Support, E-Mail, Zahlungen

K1 und K9 – nicht erfüllt. Auffälliges Verhalten beim kostenlosen Check führt zu einem Vermerk mit der IP-Adresse (cfg/check_lib.php) und gegebenenfalls zur Abweisung weiterer Prüfungen. Das ist Missbrauchsabwehr mit geringer Wirkung, keine Bewertung persönlicher Aspekte.
Übrige Kriterien – nicht erfüllt. Es sind die üblichen Daten eines Dienstes für Unternehmen.

Zwischenergebnis V8: keine Folgenabschätzung erforderlich. Die Verarbeitungen sind im Verzeichnis von Verarbeitungstätigkeiten beschrieben.

V9 – Plugin-Zahlen, Feldfehler, Recorder, Siegel, Kundenportal, „Fix it for me“

Plugin und Erweiterung übermitteln Tageszahlen, das Plugin-Inventar und Fehlerkategorien, das WordPress-Plugin außerdem für den Schwarmschutz (ab Werk an) Link-Domains (V7), keine Inhalte, Adressen, Namen oder Besucher-IPs; der Recorder hält Selektoren höchstens 15 Minuten im Browser des Administrators. Keine Kriterien erfüllt.
Das Siegel überträgt beim Laden die üblichen Verbindungsdaten in das Protokoll des Webservers, ohne Cookie. Keine Kriterien erfüllt.
Das Kundenportal verarbeitet E-Mail-Adressen von Abonnenten mit Double-Opt-in im Auftrag der Agentur. Keine Kriterien erfüllt.
„Fix it for me“ lässt eingefügten Formular-Code von einem Sprachmodell auf unserem eigenen Server umbauen; der Code wird nicht gespeichert. K8 in schwacher Form, sonst nichts.

Zwischenergebnis V9: keine Folgenabschätzung erforderlich.

3.4 Die Liste der polnischen Aufsichtsbehörde nach Art. 35 Abs. 4

Zuständig ist der Präsident des Amtes für den Schutz personenbezogener Daten (Prezes Urzędu Ochrony Danych Osobowych, UODO). Er hat die Liste der Arten von Verarbeitungsvorgängen, für die eine Folgenabschätzung erforderlich ist, mit der Mitteilung vom 17. Juni 2019 veröffentlicht (Komunikat Prezesa Urzędu Ochrony Danych Osobowych z dnia 17 czerwca 2019 r. w sprawie wykazu rodzajów operacji przetwarzania danych osobowych wymagających oceny skutków przetwarzania dla ich ochrony, Monitor Polski 2019, Pos. 666). Die Liste ordnet ihre Einträge den Kriterien der Leitlinien WP248 zu, nennt Beispiele und ist ausdrücklich nicht abschließend; sie ersetzt die Prüfung nach Art. 35 Abs. 1 nicht.

Nach unserer Lesart entsprechen dem Inhalt nach folgende Arten der Liste Verarbeitungen von formexposed:

Art der Verarbeitung nach der Liste (sinngemäß)	Zugeordnetes Kriterium	Verarbeitung bei formexposed	Einordnung
Vergleich, Bewertung oder Schlussfolgerung auf Grundlage der Analyse von Daten aus verschiedenen Quellen	K6	V7 Schwarmschutz	trifft zu
Bewertung oder Einstufung, einschließlich Profiling	K1	V7 Schwarmschutz; V1 und V2 als Grenzfall	trifft für V7 zu
Verarbeitung besonderer Kategorien personenbezogener Daten	K4	V6 Zustellungsprüfung	trifft je nach Kunde zu
Innovative Nutzung oder Anwendung technologischer Lösungen	K8	V1 bis V4 (Sprachmodell zur Einordnung)	trifft in schwacher Form zu
Umfangreiche Verarbeitung	K5	V3 Studie	trifft bei großen Listen zu
Systematische Überwachung öffentlich zugänglicher Orte, auch mit Erkennung von Merkmalen	K3	–	trifft nicht zu: gemeint sind Orte, nicht Websites

Diese Zuordnung ist eine Lesart, kein Zitat; der Wortlaut der Einträge ist in der anwaltlichen Prüfung gegenzulesen. Sie bestätigt das Ergebnis aus Abschnitt 3.3, ändert es aber nicht. Eine Liste nach Art. 35 Abs. 5 – Verarbeitungen, für die keine Folgenabschätzung erforderlich ist – hat der UODO nach unserer Kenntnis nicht veröffentlicht.

3.5 Ergebnis der Schwellwertprüfung

Verarbeitung	Erfüllt	Grenzfall	Ergebnis
V1 Kostenloser Check	K8 (schwach)	K1, K5	nicht verpflichtend; mitgeführt
V2 Interessenten-Prüfung	K8 (schwach)	K1	nicht verpflichtend; mitgeführt
V3 Studie	K8 (schwach), K5 bei großen Listen	–	erforderlich (Pflicht von formexposed)
V4 Prüfung von Kundendomains	K8 (schwach)	K4 (Dateiprüfung)	nicht verpflichtend; mitgeführt
V5 Scan hinter dem Login	–	K4	nicht verpflichtend; mitgeführt; beim Kunden je nach Inhalt
V6 Zustellungsprüfung	K4; K7 je nach Kunde	K3 (eher erfüllt), K5	erforderlich (Pflicht des Kunden; diese Seite unterstützt nach Art. 28 Abs. 3 lit. f)
V7 Schwarmschutz	K6, K1	K9	erforderlich (Pflicht von formexposed)
V8 Konten, Protokolle, Support, Zahlungen	–	–	nicht erforderlich
V9 Plugin-Zahlen, Siegel, Portal, „Fix it for me“	K8 (schwach, nur „Fix it for me“)	–	nicht erforderlich

Ergebnis zu Art. 35 Abs. 1: Eine Folgenabschätzung ist für einzelne Verarbeitungen von formexposed erforderlich. Für den Schwarmschutz und für Studien in der angelegten Größe ist sie erforderlich, und formexposed führt sie als Verantwortlicher. Für die Zustellungsprüfung ist sie in der typischen Konstellation erforderlich, aber als Pflicht des Kunden; formexposed liefert die Grundlage. Für die übrigen Prüfungen fremder und eigener Websites ist sie nicht verpflichtend. Wir führen sie trotzdem mit, weil sie dieselbe Technik nutzen, weil mehrere Grenzfälle in dieselbe Richtung weisen und weil die Betroffenen – Betreiber ohne Konto und Personen auf geprüften Seiten – von der Verarbeitung nichts wissen. Für Konten, Protokolle, Support und Zahlungen ist keine Abschätzung erforderlich.

Die Abschnitte 6 bis 10 gelten deshalb für V1 bis V7. Wo eine Aussage nur für eine dieser Verarbeitungen gilt, ist sie so gekennzeichnet.

4. Datenschutzbeauftragter: die Prüfung nach Art. 37

Ein Datenschutzbeauftragter ist nicht benannt. Art. 37 Abs. 1 bindet den Verantwortlichen und den Auftragsverarbeiter gleichermaßen; die Frage ist also unsere eigene. Die drei gesetzlichen Fälle:

Art. 37 Abs. 1	Voraussetzung	Ergebnis
lit. a	Behörde oder öffentliche Stelle	Nicht einschlägig; LW IT Solutions Company Lukas Wójcik ist ein privates Einzelunternehmen.
lit. b	Die Kerntätigkeit besteht in Verarbeitungen, die eine umfangreiche regelmäßige und systematische Überwachung von betroffenen Personen erfordern	Die Kerntätigkeit ist die Prüfung und Überwachung von Websites und Formularen, regelmäßig und systematisch. Überwacht werden aber keine Personen: Der Crawler beobachtet kein Verhalten, und die Zustellungsprüfung wertet Mails nur auf Zustellung und Echtheit aus. Nicht erfüllt.
lit. c	Die Kerntätigkeit besteht in der umfangreichen Verarbeitung von Daten nach Art. 9 oder 10	Nicht der Bauart nach. Besondere Kategorien können über die Kontrollkopie der Zustellungsprüfung bei uns ankommen; das ist beiläufig, nicht Kerntätigkeit. Nicht erfüllt.

Es besteht daher nach unserer Bewertung keine Pflicht zur Benennung. Ob das polnische Recht nach Art. 37 Abs. 4 darüber hinaus eine Benennung verlangt, ist eine offene Frage an die anwaltliche Prüfung. Da kein Datenschutzbeauftragter benannt ist, entfällt der Rat nach Art. 35 Abs. 2. Ergibt die anwaltliche Prüfung eine Pflicht zur Benennung, wird der Rat des dann benannten Datenschutzbeauftragten vor der Freigabe dieser Abschätzung eingeholt (Abschnitt 12). Ansprechpartner für Fragen zu dieser Abschätzung ist der Inhaber unter contact@lukaswojcik.com.

5. Vorgehen, Quellen und Grenzen dieser Fassung

Die Tatsachen in diesem Dokument stammen aus dem Quelltext der Anwendung und des Scanners, aus dem Datenbankschema, aus Zeilenzahlen und Einstellungen des Entwicklungssystems, gemessen am 11. Oktober 2026. Auf Datenbank und Server wurde ausschließlich lesend zugegriffen. Wo eine Messung einer Absicht widerspricht – auch einer Aussage in unseren eigenen Rechtstexten –, berichten wir die Messung. Genehmigte Verhaltensregeln nach Art. 40, deren Einhaltung nach Art. 35 Abs. 8 zu berücksichtigen wäre, wenden wir nicht an.

Gemessen wurde das Entwicklungssystem. Der Dienst ist noch nicht gestartet. Die Zahlen sind deshalb klein und teils Artefakte von Tests: 112 Prüfungen, davon 110 ohne Kundendomain; 432 Bildschirmfotos; 2 Domains, davon 1 nachgewiesen; keine Zustellungsprüfung eingeschaltet; kein Testkonto für den Scan hinter dem Login hinterlegt; keine Studie; keine Meldungen im Schwarmschutz. Vor dem Start und danach in regelmäßigen Abständen ist neu zu messen.
In dieser Fassung nicht gemessen und vor der Freigabe zu ergänzen sind: die Konfiguration des Produktivsystems, darunter ob und wie das Kontrollpostfach eingerichtet ist und ob das Schlüsselpaar für den Scan hinter dem Login dort eingerichtet ist; ob die Software des Sprachmodells Anfragen protokolliert; der Stand der Serververwaltung (R13); der Vertrag mit dem E-Mail-Dienstleister.
Nicht gemessen werden konnte, wie viele echte Besuchernachrichten über die Kontrollkopie laufen werden und aus welchen Branchen die Kunden kommen. Beides bestimmt das Gewicht von R1 und R2 und ist nach dem Start zu erheben.
Die Fundstellen verweisen auf Dateien und Funktionen im Quelltext des Entwicklungssystems. Maßgeblich ist die beschriebene Funktion, nicht ihre Lage in der Datei.

Dieses Dokument ist ein Entwurf. Es ist vom Verantwortlichen noch nicht freigegeben (Abschnitt 12), und zwei seiner Schlüsse – die Umfangsbewertung für V1 und V3 und das Gewicht der Zustellungsprüfung – hängen an Zahlen, die es erst nach dem Start gibt.

6. (a) Systematische Beschreibung der Verarbeitungsvorgänge und Zwecke

6.1 Wie das Prüfsystem aufgebaut ist

formexposed läuft auf eigenen Servern in Polen, ohne externen Hosting-Anbieter: ein Webserver mit der Anwendung und der Datenbank und ein Scan-Server mit dem Prüfdienst und einem lokalen Sprachmodell, beide im selben internen Netz. Eine Prüfung läuft so ab:

Die Anwendung legt einen Auftrag in der Datenbank an – nach den Grenzen und Sperren aus Abschnitt 6.3.
Der Prüfdienst auf dem Scan-Server holt den Auftrag, prüft Sperrliste, Hostnamen und, bei anonymen Prüfungen, das Alter der Domain ein zweites Mal und startet für genau diesen Auftrag einen abgeschotteten Container: eigenes Netz mit eigenen Filterregeln, keine Sonderrechte, schreibgeschütztes Dateisystem, Speicher- und Prozessgrenzen, Zeitlimit (scanner/src/worker.js).
Im Container ruft ein automatisierter Browser höchstens acht öffentliche Seiten ab, zuerst die Startseite, dann bevorzugt Kontakt-, Impressums- und Support-Seiten. Vorher liest er die robots.txt; ein Ausschluss für FormExposedBot oder für alle Crawler, der die Startseite erfasst, beendet die Prüfung, ebenso eine nicht erreichbare robots.txt oder ein Serverfehler beim Abruf (scanner/src/net.js). 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. Neben den acht Seiten kommen bis zu drei Seiten mit Klick auf „Ablehnen“ im Cookie-Banner, bis zu drei Seiten in Telefonansicht, bei nachgewiesenen Domains aktive Proben und bis zu fünf Seiten hinter einem Login hinzu; die Seiten werden nacheinander geladen, nicht parallel. Jede Anfrage des Browsers – auch Umleitungen und eingebettete Inhalte – läuft durch einen Filter, der private Netze und fremde Ports abweist.
Der Container schreibt ein Ergebnis und die Bildschirmfotos in ein temporäres Verzeichnis. Der Prüfdienst übergibt Ergebnis und Bilder über das interne Netz an die Anwendung und löscht das temporäre Verzeichnis, auch nach einem Fehler (scanner/src/worker.js).
Die Anwendung bereitet das Ergebnis auf, vergleicht es bei Kundendomains mit der vorigen Prüfung und meldet Veränderungen an die Ziele, die der Kunde eingerichtet hat.

6.2 Was der Crawler speichert – und was nicht

Angabe	Was gespeichert wird	Was nicht gespeichert wird	Fundstelle
Seiten	Adresse, HTTP-Status, Kopfzeilen, Content-Security-Policy, angefragte fremde Hosts (höchstens 120)	Seiteninhalt als Text oder HTML	`scanner/src/crawl.js`
Formularfelder	Typ, Name, Beschriftung, Platzhalter, Pflichtfeld, Sichtbarkeit, Länge eines vorhandenen Werts	Feldwerte; bei versteckten Feldern werden die ersten 24 Zeichen des Werts nur während der Prüfung gelesen (für die Erkennung von Token)	`scanner/src/crawl.js`
Empfängeradressen im Formular	nur die Domain	die Adresse	`scanner/src/crawl.js`
Skripte	Inventar mit Prüfsumme; Adressen und Textanfänge ohne Kontokennungen von Werbe- und Analysediensten	Konto- und Pixelkennungen	`scanner/src/crawl.js`
Mitleser	welche Werbe-Pixel und Aufzeichnungswerkzeuge vor und nach dem Ablehnen im Cookie-Banner laden, ob sie Eingaben maskieren	Kennungen der Konten bei diesen Diensten	`scanner/src/mitleser.js`, `scanner/src/einwilligung.js`
Formulartext	bis zu 400 Zeichen gehen an das lokale Sprachmodell, wenn die Regeln den Typ nicht erkennen	Weitergabe an Dritte; Speicherung des Textes	`scanner/src/classify.js`
Bildschirmfotos (Crawler)	sichtbarer Bereich der ersten Seite; je sichtbarem Formular ein Bild des Formular-Elements	–	`scanner/src/crawl.js`
Bildschirmfotos (aktive Prüfung)	Bild der Antwortseite auf die Test-Einsendung; dazu Status, Zieladresse, Titel und die ersten 300 Zeichen ihres Textes	–	`scanner/src/active.js`
Bildschirmfotos (Browserwege)	Bild des Formulars mit geschwärzten Eingabefeldern, komprimiert, höchstens 32 KB	Eingaben	`scanner/src/browser.js`
Hinter dem Login	wie Formularfelder oben	Bildschirmfotos, Cookies, Links	`scanner/src/login.js`

Personenbezogene Daten stehen in diesen Angaben nicht der Bauart nach, aber beiläufig: der Name einer Ansprechperson neben dem Formular, ein Teamfoto auf der Startseite, eine Telefonnummer in einer Beschriftung, die E-Mail-Domain einer Einzelperson, ein Name in einem Platzhalter. Hinter dem Login kommen Angaben zum Testkonto und, je nach Website, zu anderen Nutzern hinzu.

6.3 Wer eine Prüfung auslöst, und was dann gilt

Auslöser	Vertrauensstufe im Auftrag	Test-Einsendungen	Ergebnis erreichbar über	Löschung
Jemand gibt auf der Startseite eine Domain ein (kostenloser Check)	anonym	nein	Report unter zufälligem Link	30 Tage, samt Bildern (`cfg/check_lib.php`)
Plugin oder Erweiterung ohne Konto	Plugin	nein	Report unter zufälligem Link	30 Tage
Agentur für einen Interessenten	registriert	nein	Kurzbefund und Report unter zufälligem Link	90 Tage (`cfg/akquise_lib.php`)
Kunde, Domain ohne Nachweis	registriert	nein	Konto; Report unter zufälligem Link	13 Monate, die letzte Prüfung bleibt
Kunde, Domain mit Nachweis	nachgewiesen	ja, höchstens fünf je Prüfung	Konto; Report unter zufälligem Link	13 Monate, die letzte Prüfung bleibt (`cfg/fristen_lib.php`)
Studie	intern	nein	nur Summen nach Veröffentlichung	mit der Veröffentlichung; ohne Veröffentlichung keine Frist (R4)
Interne Prüfung von der Kommandozeile durch den Betreiber	intern; für eigene Test- und Demodomains auch „verifiziert“	nein; mit der Stufe „verifiziert“ ja (nur eigene Test- und Demodomains)	nur intern	keine Frist (R4)

Vor dem kostenlosen Check stehen mehrere Schichten (cfg/check_lib.php): ein Notaus; reCAPTCHA; dieselbe Domain höchstens einmal in sieben Tagen (danach wird der vorhandene Report gezeigt); Grenzen je IP-Adresse, je Sitzung (als Hashwert, nie die Sitzungskennung selbst) und für den ganzen Dienst je Tag; die Sperrliste aus Opt-out und robots.txt; die Prüfung, dass die Domain auf öffentliche Adressen zeigt; und eine Sperre für sehr junge oder unbekannte Domains. Auffälligkeiten – viele verschiedene Domains von einer IP-Adresse, viele Anfragen in kurzer Zeit – werden mit der IP-Adresse vermerkt und lösen ein Signal ohne Inhalt aus (cfg/check_lib.php).

6.4 Prüfung von Domains im Kundenkonto

Der Kunde weist nach, dass er über eine Domain verfügen darf: per DNS-Eintrag, Meta-Tag, Datei oder über unser Plugin (cfg/verify_lib.php). Erst danach gilt die Domain als nachgewiesen. Der Überwachungsplaner plant regelmäßige Prüfungen nur für aktive, überwachte und nachgewiesene Domains (cfg/monitor_lib.php).

Aktive Test-Einsendungen sind an zwei Tore gebunden: Die Anwendung setzt den aktiven Modus für Kunden nur bei nachgewiesenen Domains (für eigene Test- und Demodomains kann der Betreiber über ein internes Kommandozeilen-Werkzeug eine Prüfung mit der Stufe „verifiziert“ anlegen), und der Prüfdienst prüft erneut Vertrauensstufe und Notaus fc_active_enabled (scanner/src/worker.js). Absendbar ist nur ein Formular, das die Regeln mit hoher Sicherheit als allgemeines Kontaktformular erkennen, das keine Pflichtfelder für echte Personendaten hat und dessen Domain nicht nach Behörde, Bildungseinrichtung, Klinik, Praxis, Polizei oder Gericht aussieht (scanner/src/classify.js). Das Sprachmodell kann kein Formular absendbar machen (scanner/src/classify.js). Je Prüfung gehen höchstens fünf Einsendungen hinaus (fc_active_max_posts), klar gekennzeichnet, mit dem Absender dummy@formexposed.com, einer Adresse unter .invalid für die Prüfung der E-Mail-Validierung und einer harmlosen Zusatz-Kopfzeile für die Erkennung von Header-Injection (scanner/src/active.js).
Browserwege prüfen konfigurierte Formularwege in einem Browser bis vor das Absenden. Nur GET- und HEAD-Anfragen sind zugelassen; alles andere wird abgebrochen, ebenso Adressen mit Abmelde-, Lösch-, Kauf- oder Zahlungswörtern (scanner/src/browser.js). Pflichtfelder werden zur Prüfung mit erfundenen Werten gefüllt, die den Browser nie verlassen.
Offen liegende Dateien werden wöchentlich gesucht, nur bei nachgewiesenen Domains, höchstens ein Abruf je Pfad, höchstens 8 KB, Inhalt nie gespeichert (cfg/dateien_lib.php).
Eine unabhängige zweite Sonde ist vorbereitet und ab Werk aus (browser_probe_enabled = 0). Eingeschaltet erhielte sie nur Domain, Adresse, Selektor, Schritte und Browserwahl, nie Zugangsdaten, Bildschirmfotos oder Besucherdaten (cfg/formular_probe_lib.php).

6.5 Scan hinter dem Login

Voraussetzungen: Die Funktion ist eingerichtet, die Domain ist nachgewiesen, der Kunde hat einen bezahlten Tarif und ist Inhaber oder Administrator des Arbeitsbereichs (cfg/login_lib.php); er bestätigt, dass es sich um ein Testkonto mit möglichst wenigen Rechten handelt (cfg/login_lib.php).

Benutzername und Passwort werden auf dem Webserver sofort mit dem öffentlichen Schlüssel des Scan-Servers verschlüsselt: Einmal-Schlüssel je Datensatz (X25519), Schlüsselableitung (HKDF-SHA256), AES-256-GCM, an die Domain gebunden (cfg/login_lib.php). Den privaten Schlüssel hat nur der Prüfdienst auf dem Scan-Server (scanner/src/geheim.js). Wer Webserver, Datenbank oder Sicherung hat, hat nur Chiffretext.
Die Oberfläche zeigt vom Benutzernamen nur das erste Zeichen und die Länge (cfg/login_lib.php). Zugangsdaten werden nie angezeigt, nie protokolliert und nie über die Programmierschnittstelle ausgegeben.
Für eine Prüfung hängt die Anwendung den Chiffretext an den Auftrag. Der Prüfdienst entschlüsselt ihn, leert das Feld im Auftrag sofort und gibt die Zugangsdaten nur über die Standardeingabe an den Container, nie als Aufrufparameter (scanner/src/worker.js). Reste in abgebrochenen Aufträgen räumt der Statusprozess nach einer Stunde (cfg/login_lib.php).
Im Container meldet sich der Browser an. Er bricht ab, wenn die Anmeldeseite auf einen fremden Host umleitet, wenn das Anmeldeformular ein CAPTCHA trägt (wir umgehen keine CAPTCHAs) oder wenn nach dem Absenden noch ein Passwortfeld sichtbar ist (scanner/src/login.js). Danach leert er das Passwortfeld im Speicher der Seite und vergisst die Zugangsdaten (scanner/src/login.js).
Er liest höchstens fünf vom Kunden angegebene Seiten derselben Domain. Adressen mit Wörtern für Abmelden, Löschen, Entfernen oder Kündigen sind gesperrt (scanner/src/login.js). Hinter dem Login wird nichts abgesendet, es entstehen keine Bildschirmfotos, Cookies und Links landen nicht im Ergebnis (scanner/src/login.js).
Löschen ist endgültig: Der Chiffretext wird mit Zufall gleicher Länge überschrieben, die Zeile gelöscht, wartende Aufträge geleert (cfg/login_lib.php). Mit der Domain verschwindet die Zeile über einen Fremdschlüssel automatisch.

6.6 Zustellungsprüfung

Die Zustellungsprüfung beantwortet die Frage, ob eine Mail aus dem Kontaktformular wirklich ankommt, und wertet ihre Echtheitsmerkmale aus. Sie ist optional, ab Werk aus und setzt ein eingerichtetes Kontrollpostfach voraus (cfg/zustellung_lib.php).

Schaltet der Kunde sie ein, erhält die Domain ein zufälliges Kennzeichen. Der Kunde trägt die Kontrolladresse mit diesem Kennzeichen als Blindkopie in sein Formular ein.
Ab dann geht jede Formularmail auch an das Kontrollpostfach: unsere gekennzeichneten Test-Einsendungen und alle echten Nachrichten von Besuchern. Die Mails gehen direkt an das Postfach bei Namecheap, Inc. (Private Email), Phoenix, Arizona, USA – sie kommen nur an, wenn die MX-Einträge unserer Domain dorthin zeigen; über eine Weiterleitung, etwa beim Domain-Registrar Namecheap, Inc., erreichen sie das Postfach nicht – und liegen dort, bis sie abgerufen werden.
Der Statusprozess ruft das Postfach alle fünf Minuten ab (srv/cron_status.php). Er liest je Mail die Kopfzeilen und höchstens die ersten 8 KB des Textes, ohne sie als gelesen zu markieren (cfg/zustellung_lib.php).
Aus den Kopfzeilen ermittelt er das Kennzeichen und damit die Domain, aus dem Text gegebenenfalls die Kennung unseres Tests (cfg/zustellung_lib.php). Gespeichert werden Zeitpunkt, Domain und gegebenenfalls Testkennung (cfg/zustellung_lib.php), für 180 Tage (cfg/zustellung_lib.php).
Aus den Kopfzeilen bewertet er SPF, DKIM und DMARC und speichert das Ergebnis an der Domain: die Prüfergebnisse, die Domain der Absenderadresse, die Domains der Signaturen und die Adresse des versendenden Mailservers (cfg/zustellung_lib.php). Wird das Ergebnis schlecht, geht einmal ein Alarm an den Kunden, der die Absender-Domain nennen kann (cfg/zustellung_lib.php).
Danach markiert er jede abgerufene Mail zur Löschung, auch eine, die keiner Domain zugeordnet werden konnte, und entfernt sie am Ende des Laufs aus dem Postfach (cfg/zustellung_lib.php). Bricht der Lauf vorher ab, bleiben die Mails bis zum nächsten erfolgreichen Lauf liegen.
Als Nachweis der Zustellung zählt nur die Kopie genau des Tests, um den es geht (cfg/zustellung_lib.php). Kommt sie binnen drei Stunden nicht an (delivery_wait_h), meldet der Dienst „Zustellung fehlt“.

Der Text echter Nachrichten wird nie in die Datenbank geschrieben, die Adresse des Besuchers ebenfalls nicht. Gelesen werden beide trotzdem: Der Abruf holt die ersten 8 KB jeder Mail in den Arbeitsspeicher, um nach der Testkennung zu suchen.

6.7 Schwarmschutz

Die Schutzschicht des WordPress-Plugins stoppt eine Nachricht als Spam und zählt die Domains der Links darin. Einmal am Tag meldet das Plugin diese Domains mit ihrer Trefferzahl an uns, höchstens 60 je Tag; keine Adressen, kein Text, keine IP-Adressen (cfg/swarm_lib.php).
Einmal am Tag bilden wir daraus die Liste: Eine Domain kommt darauf, wenn sie binnen sieben Tagen bei mindestens drei verschiedenen Websites und mit mindestens fünf Treffern gemeldet wurde (swarm_min_sites, swarm_window_days, cfg/swarm_lib.php). Nie auf die Liste kommen große Dienste aus einer festen Ausnahmeliste und die Domains unserer Kunden, jeweils samt Subdomains (cfg/swarm_lib.php).
Die Liste geht mit der Antwort auf die Tagesmeldung an alle verbundenen Websites. Deren Schutzschicht legt Nachrichten mit Links auf gelistete Domains in die Quarantäne, nicht in den Papierkorb.
Was in der neuen Liste nicht mehr vorkommt, fällt heraus; Meldungen werden nach 30 Tagen gelöscht (cfg/swarm_lib.php).
IP-Netze (/24 bzw. /48) sind vorbereitet, aber ausgeschaltet, bis die rechtliche Prüfung abgeschlossen ist (cfg/swarm_lib.php).

6.8 Einsatz von künstlicher Intelligenz

Ein Sprachmodell läuft auf unserem eigenen Scan-Server, nicht bei einem KI-Anbieter. Es wird an zwei Stellen eingesetzt: Im Prüfdienst ordnet es Formulare ein, deren Typ die Regeln nicht erkennen; es sieht dabei Seitentitel, Seitenadresse, Beschriftungen der Absende-Knöpfe, Feldtypen, Namen, Beschriftungen und Platzhalter sowie bis zu 400 Zeichen Formulartext (scanner/src/classify.js). Es wird nur gefragt, wenn die Regeln „unbekannt“ liefern; so eingeordnete Formulare werden nie abgesendet und zählen nicht für Punktzahl und Urteil. Punktzahl, Urteil, Missbrauchsabwehr, Schwarmschutz und Spamregeln sind feste Regeln, keine KI. Bei „Fix it for me“ baut es eingefügten Formular-Code um; der Code wird nicht gespeichert. Entscheidungen über Personen trifft das Modell nicht. Mehr dazu auf der Seite EU-KI-Verordnung: wie formexposed KI einsetzt.

6.9 Rechtsgrundlagen

Verarbeitung	Rechtsgrundlage
V1 Kostenloser Check: Prüfung der angefragten Domain; Grenzen und Missbrauchsabwehr	gegenüber der anfragenden Person Art. 6 Abs. 1 lit. b; gegenüber Betreiber und abgebildeten Personen Art. 6 Abs. 1 lit. f; Missbrauchsabwehr Art. 6 Abs. 1 lit. f
V2 Interessenten-Prüfung	Art. 6 Abs. 1 lit. f (berechtigtes Interesse der Agentur und von formexposed)
V3 Studie	Art. 6 Abs. 1 lit. f
V4 Prüfung von Kundendomains	Art. 6 Abs. 1 lit. b gegenüber dem Kunden; für Daten Dritter auf seiner Website Weisung des Kunden nach Art. 28
V5 Scan hinter dem Login	Weisung des Kunden nach Art. 28; Rechtsgrundlage des Kunden
V6 Zustellungsprüfung	Weisung des Kunden nach Art. 28; Rechtsgrundlage des Kunden (in unserem Textvorschlag für Kunden Art. 6 Abs. 1 lit. f)
V7 Schwarmschutz	Art. 6 Abs. 1 lit. f (gemeinsame Abwehr von Spam über viele Websites)

Unser berechtigtes Interesse bei V1 bis V3 liegt darin, Betreibern und ihren Dienstleistern Schwachstellen ihrer Formulare zu zeigen, bevor sie für Spam oder Missbrauch genutzt werden, und darin, den Dienst zu erbringen. Die Daten stammen aus öffentlich zugänglichen Quellen. Die Abwägung steht in Abschnitt 7; ob Art. 6 Abs. 1 lit. f die Prüfung fremder Websites auf Zuruf trägt, ist eine offene Frage an die anwaltliche Prüfung.

6.10 Empfänger und Übermittlungen in Drittländer

Empfänger	Was	Verarbeitung	Stand
Niemand außerhalb von formexposed	Prüfergebnisse, Bildschirmfotos, Einordnung durch das Sprachmodell	V1–V5	Prüfdienst und Sprachmodell laufen auf eigenen Servern; im Prüfweg des Crawlers wurde kein Aufruf an einen Dritten gefunden außer an die geprüfte Website selbst, an die Dienste, deren Inhalte sie einbindet (wie bei jedem Besucher), und an den RDAP-Dienst rdap.org für das Domainalter (nur der Domainname); die Wächter der Überwachung stehen in der nächsten Zeile
Jeder, der den Link kennt	Report mit Befunden und Bildschirmfotos	V1, V2, V4	zufälliger Link mit 128 Bit (`cfg/check_lib.php`), Seiten mit `noindex` (`www/report.php`)
Dienste, die die Überwachung einer Kundendomain abfragt	DNS-Blocklisten (SpamCop, PSBL, Mailspike, SURBL): Domains und IP-Adressen von Servern, keine Daten von Besuchern; Google Web Risk nur, wenn eingerichtet: die Adresse der Startseite; Zeitstempel-Stellen Certum und DigiCert: nur ein Hashwert des Nachweis-Protokolls; RDAP über das Verzeichnis der IANA: nur der Domainname; Statusseiten von Anbietern: es wird nichts übermittelt; wpvulnerability.net: Kennung eines Plugins (ohne Version) oder Themes und die WordPress-Version	V4	in Nutzung; Einzelheiten im Verzeichnis von Verarbeitungstätigkeiten und auf der Seite Unterauftragsverarbeiter
Namecheap, Inc. (Private Email), Phoenix, Arizona, USA	Kontrollkopien einschließlich echter Besuchernachrichten	V6	Vertrag noch nicht abgeschlossen; Verarbeitungsort und Übermittlungsgrundlage noch zu prüfen
Namecheap, Inc. (USA)	Registrar und DNS; bis zur Einrichtung des Postfachs Weiterleitung allgemeiner Mails an Adressen unserer Domain, nicht der Kontrollkopien (diese erreichen das Postfach nur über direkt darauf zeigende MX-Einträge)	– (keine Kontrollkopien)	Übermittlungsgrundlage zu prüfen
Vom Kunden gewählte Alarmkanäle (E-Mail, Webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram)	Ereignis, Domain, Link; bei der Echtheitsprüfung die Absender-Domain, wenn sie nicht zur Website gehört	V4, V6	vom Kunden gewähltes Ziel; teils außerhalb der EU. Telegram-Nachrichten verschicken wir über unseren Bot; die Übermittlungsgrundlage dafür ist eine offene Frage der anwaltlichen Prüfung
Alle verbundenen Websites	Liste der Link-Domains	V7	über die Antwort an das Plugin
Zweite Sonde	Domain, Formularadresse, Selektor, Schritte	V4	ausgeschaltet

6.11 Aufbewahrung, gemessen statt beabsichtigt

Gelöscht wird überwiegend nachts um 03:00 im Statusprozess (srv/cron_status.php, cfg/fristen_lib.php); Meldungen im Schwarmschutz und Interessenten-Zeilen täglich ab 04:00, Zuordnungen der Zustellungsprüfung bei jedem Abruf; anonyme und Interessenten-Reports über ihr Ablaufdatum (cfg/check_lib.php). Bildschirmfotos werden jeweils mit ihrem Scan von der Platte gelöscht (cfg/fristen_lib.php).

Daten	Frist laut Code	Fundstelle	Befund
Kostenloser Check samt Bildern	30 Tage	`cfg/check_lib.php`	wirksam
Interessenten-Prüfung samt Bildern	90 Tage	`cfg/akquise_lib.php`; `srv/cron_status.php` (Interessenten-Zeilen)	wirksam
Prüfungen einer Kundendomain	13 Monate, die letzte bleibt, solange die Domain besteht	`cfg/fristen_lib.php`	wirksam
Ergebnisse der Browserwege samt geschwärzter Bilder	13 Monate	`cfg/fristen_lib.php`	wirksam
Daten einer gelöschten Domain	sofort; Waisen nachts	`cfg/fristen_lib.php` (`fe_domain_loeschen()`, `fe_fristen_lauf()`)	wirksam, einschließlich Skript-Inventar und Skript-Änderungen, die darüber hinaus keine eigene Frist haben (siehe Verzeichnis von Verarbeitungstätigkeiten)
Studie: Rohdaten samt Bildern	bei Veröffentlichung	`cfg/studie_lib.php`	ohne Veröffentlichung keine Frist; die Liste der geprüften Hosts bleibt auch nach der Veröffentlichung ohne Frist
Interne Prüfungen ohne Domain und ohne Report	keine	–	keine Löschung; gemessen 85 Prüfungen mit 369 Bildern seit 22.09.2026 (R4)
Zuordnungen der Zustellungsprüfung	180 Tage	`cfg/zustellung_lib.php`	wirksam
Ergebnis der Echtheitsprüfung an der Domain	bis zum nächsten Ergebnis oder zur Löschung der Domain	`cfg/zustellung_lib.php`	überschrieben, nicht befristet
Kontrollkopien im Postfach	bis zum nächsten erfolgreichen Abruf (Takt fünf Minuten)	`cfg/zustellung_lib.php`	Kopien und Sicherungen beim Postfach-Anbieter nicht geprüft
Zugangsdaten für den Scan hinter dem Login	bis zur Löschung durch den Kunden oder der Domain; im Auftrag höchstens bis zum Ende des Laufs, Reste nach einer Stunde	`cfg/login_lib.php`	wirksam; in den Sicherungen nur als Chiffretext bis zu 14 Tage
Meldungen im Schwarmschutz	30 Tage	`cfg/swarm_lib.php`	wirksam
Grenzen des kostenlosen Checks (IP, Land, Sitzungs-Hash)	7 Tage	`srv/cron_status.php`	wirksam
Vermerke über auffälliges Verhalten mit IP-Adresse	90 Tage nach Klärung	`srv/cron_status.php`	ungeklärte Vermerke ohne Frist; gemessen: 3 Vermerke, alle geklärt
IP-Adresse, Land, Browser zu einem Opt-out	12 Monate; der Ausschluss bleibt	`cfg/fristen_lib.php`	wirksam
Sicherungen der Datenbank	14 Tage	`cfg/backup_lib.php`	wirksam; 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 (R13)

7. (b) Bewertung der Notwendigkeit und der Verhältnismäßigkeit

Gemessen wird an den erklärten Zwecken: Betreibern zu zeigen, ob ihre Formulare gegen Spam und Missbrauch geschützt sind (V1 bis V5), zu prüfen, ob Formularmails ankommen und echt wirken (V6), und Spam über viele Websites gemeinsam abzuwehren (V7). Diese Zwecke sind legitim. Die Frage nach Art. 35 Abs. 7 lit. b ist enger: Ist diese Verarbeitung in dieser Tiefe für den Zweck notwendig, und steht der Eingriff im Verhältnis zum Nutzen?

Bestandteil	Für den Zweck notwendig?	In der gebauten Form verhältnismäßig?
Abruf weniger öffentlicher Seiten, Aufbau der Formulare, erkannte Schutzmaßnahmen	Ja. Ohne sie gibt es keinen Befund.	Ja. Höchstens acht Seiten (zuzüglich der Ansichten aus Abschnitt 6.1), ein Verbot der Startseite in der robots.txt wird beachtet, keine Werte sichtbarer Felder, Empfängeradressen nur als Domain.
Bildschirmfoto je Formular	Ja, als Beleg im Report: Der Betreiber erkennt, welches Formular gemeint ist.	Weitgehend. Die Felder sind leer, weil der Crawler nichts eintippt. Das Bild zeigt aber das Umfeld des Formular-Elements ungeschwärzt (R3).
Bildschirmfoto der Startseite	Für den Befund selbst nicht erforderlich. Es dient der Wiedererkennung der geprüften Website im Report.	Nur eingeschränkt; weitere Minimierung geplant. Startseiten zeigen häufig Menschen: Teamfotos, Ansprechpersonen, Kundenstimmen mit Namen. Siehe R3 und Abschnitt 9.3.
Lesen der Werte versteckter Felder (erste 24 Zeichen, nur während der Prüfung)	Ja: daran werden Token und Zeitstempel erkannt.	Ja. Gespeichert wird nur das Erkennungsergebnis, nicht der Wert, auch hinter dem Login (R8).
Antwortseite der Test-Einsendung (Bild und 300 Zeichen Text)	Ja, als Beleg, wie das Formular reagiert hat.	Ja. Die Antwort bezieht sich auf unsere gekennzeichnete Testnachricht ohne Personendaten.
Einordnung durch das Sprachmodell	Nützlich, nicht notwendig: Ohne sie bleiben mehr Formulare „unbekannt“.	Ja. Lokal, ohne Weitergabe, ohne Recht zum Absenden.
Aktive Test-Einsendungen	Ja. Ob ein Schutz wirkt, zeigt sich nur, wenn man ihn prüft.	Ja, mit Deckel und Kennzeichnung. Die Voraussetzung – der Nachweis der Verfügungsbefugnis – wird aber nie erneuert (R7).
Suche nach offen liegenden Dateien	Ja für den Kunden, dessen Formulardaten dort offenliegen können.	Ja. Nur nachgewiesene Domains, höchstens 8 KB, Inhalt nie gespeichert.
Scan hinter dem Login	Ja für Formulare im Kundenbereich, die sonst ungeprüft blieben.	Weitgehend. Verschlüsselung und Löschung sind sorgfältig gebaut; die Anmeldung akzeptiert aber unverschlüsselte Verbindungen und fehlerhafte Zertifikate (R8).
Kontrollkopie echter Besuchernachrichten	Für den Zustellungsnachweis nein. Er stützt sich nur auf die Kopie unseres Tests (`cfg/zustellung_lib.php`). Echte Nachrichten kommen mit, weil eine Blindkopie im Formular nicht zwischen Test und echter Nachricht unterscheidet. Für die Echtheitsprüfung (SPF, DKIM, DMARC) sind sie nützlich, weil sie den wirklichen Versandweg zeigen.	Teilweise. Inhalte werden nicht gespeichert, aber gelesen, und sie liegen bis zum Abruf beim Postfach-Anbieter, dessen Vertrag noch offen ist (R1, R2). Eine mildere Gestaltung ist technisch möglich: Mit unserem Plugin ließe sich die Blindkopie auf gekennzeichnete Testnachrichten beschränken (Abschnitt 9.3).
Speicherung der Absender-Domain echter Nachrichten	Teilweise: Sie zeigt, ob das Formular mit der Adresse des Besuchers als Absender verschickt (eine häufige Ursache für Spam-Einstufung).	Bedingt. Für eine Einzelperson mit eigener Domain ist die Domain ein personenbezogenes Datum, und sie geht im Alarm an den Kunden und seine Kanäle (R1).
Gemeinsame Liste von Link-Domains	Ja. Ein Spam-Link, der bei vielen Websites gleichzeitig auftaucht, ist ein starkes Signal, das eine einzelne Website nicht hat.	Ja, mit Mindestzahlen, Ausnahmen und Quarantäne statt Löschung. IP-Netze wären ohne neue Prüfung nicht verhältnismäßig.
Rohdaten der Studie	Bis zur Auswertung ja.	Ohne Höchstfrist nein (R4).
Report unter zufälligem Link	Ja. Den Report weiterzugeben – etwa an den Dienstleister, der die Website betreut – ist Zweck des kostenlosen Checks.	Ja. Zufallslink mit 128 Bit, `noindex`, kostenloser Report nur als Auszug (`cfg/check_lib.php`, `FE_FREE_DETEKTOREN`), Löschung nach 30 Tagen.

Rechtmäßigkeit. Für V1 bis V3 und V7 stützen wir uns auf Art. 6 Abs. 1 lit. f. Für die Abwägung spricht: Die Daten sind öffentlich und werden so abgerufen, wie es jeder Besucher tut; es wird nichts abgesendet; personenbezogene Daten sind beiläufig und gering; die Fristen sind kurz; der Betreiber kann weitere Prüfungen durch den Crawler über ein Verbot der Startseite in der robots.txt und jede weitere Prüfung über unsere Opt-out-Seite sofort und ohne Nachweis ausschließen; der Nutzen – ein geschütztes Formular – kommt auch dem Betreiber und seinen Besuchern zugute. Gegen sie spricht: Der Betreiber erfährt von der Prüfung nichts, der Report ist für Dritte bestimmt, und bei Einzelunternehmern bewertet er einen Menschen. Wir halten die Abwägung für vertretbar, solange die Maßnahmen aus Abschnitt 9.1 bestehen; die anwaltliche Bestätigung steht aus.

Information der Betroffenen (Art. 13 und 14). Betreiber und Personen auf geprüften Seiten informieren wir über die Seite zum Crawler, die in der Kennung jedes Abrufs steht, über die Datenschutzerklärung und über die Opt-out-Seite. Personen, die beiläufig auf einem Bildschirmfoto erscheinen, einzeln zu informieren, wäre nur möglich, wenn wir sie identifizieren – das wäre ein weiterer, stärkerer Eingriff. Wir berufen uns insoweit auf Art. 14 Abs. 5 lit. b. Besucher, deren Nachrichten über die Kontrollkopie laufen, informiert der Kunde; der Auftragsverarbeitungsvertrag verlangt das, und wir stellen dafür einen Textbaustein bereit.

Datenminimierung (Art. 5 Abs. 1 lit. c). Sie ist an vielen Stellen sichtbar und im Code begründet: keine Feldwerte, Empfängeradressen nur als Domain, Kontokennungen in Skriptadressen ausgeblendet, kein Inhalt aus der Kontrollkopie in der Datenbank, keine Bildschirmfotos hinter dem Login, im Schwarmschutz nur Domains. An zwei Stellen ist eine weitere Minimierung möglich und geplant (Abschnitt 9.3): beim ungeschwärzten Bildschirmfoto der Startseite und bei der Absender-Domain echter Nachrichten.

Speicherbegrenzung (Art. 5 Abs. 1 lit. e). Seit dem 27. September 2026 hält der nächtliche Lauf die Fristen der Datenschutzerklärung für Kundendaten ein und räumt Daten ab, die aus der Zeit davor ohne zugehörige Domain verblieben sind (cfg/fristen_lib.php). Offen sind zwei Wege ohne Frist: interne Prüfungen und unveröffentlichte Studien (R4).

Richtigkeit (Art. 5 Abs. 1 lit. d). Ein Befund kann falsch sein: Ein Formular wirkt ungeschützt, weil der Schutz erst nach einer Interaktion lädt, oder der Crawler wurde von einer Firewall anders behandelt als ein Besucher. Für einen Betreiber, dessen Website öffentlich als „ungeschützt“ weitergereicht wird, ist das eine Frage des Rufs. Der Report nennt deshalb die Methode, zeigt Belege und weist auf die Grenzen einer Prüfung von außen hin.

Ergebnis zur Verhältnismäßigkeit: Die Prüfung fremder und eigener Websites ist in ihrer gebauten Form im Wesentlichen verhältnismäßig. An drei Stellen besteht Verbesserungsbedarf, der sich mit gewöhnlichen Mitteln beheben lässt und für den Maßnahmen geplant sind (Abschnitt 9.3): den Bildschirmfotos der Startseite, den fristlosen internen Prüfungen und der unverschlüsselten Anmeldung beim Scan hinter dem Login. Die Zustellungsprüfung ist verhältnismäßig für die Testkopie und für die Echtheitsprüfung; für echte Besuchernachrichten trägt sie nur, solange deren Inhalt nicht gespeichert wird, der Weg über den Postfach-Anbieter vertraglich gesichert ist und der Kunde seine Besucher informiert. Heute fehlt der zweite dieser drei Punkte.

8. (c) Bewertung der Risiken für die Rechte und Freiheiten der betroffenen Personen

Bewertet wird das Risiko für die betroffenen Personen, nicht für formexposed. Die Eintrittswahrscheinlichkeit ist mit fern, möglich, wahrscheinlich oder eingetreten bewertet; „eingetreten“ heißt, dass das Ereignis keine Prognose ist, sondern ein gemessener Zustand. Die Schwere ist mit begrenzt, erheblich, schwer oder sehr schwer bewertet, je nachdem, was die Person verlieren kann: die Vertraulichkeit ihrer Nachricht, die Kontrolle über ein Konto, ihren geschäftlichen Ruf, die Möglichkeit, ein Recht auszuüben. Die Stufe ergibt sich aus beiden und beschreibt den heutigen Stand mit den Maßnahmen aus Abschnitt 9.1.

Nr.	Risiko	Verarbeitung	Wahrscheinlichkeit	Schwere	Stufe
R1	Echte Besuchernachrichten in der Kontrollkopie, einschließlich möglicher besonderer Kategorien	V6	Eingetreten, sobald eingeschaltet	Schwer	Hoch
R2	Weg der Kontrollkopie über den Postfach-Anbieter ohne abgeschlossenen Vertrag und mit möglichem Drittlandbezug	V6	Wahrscheinlich, solange der Vertrag fehlt	Schwer	Hoch
R3	Ungeschwärzte Bildschirmfotos fremder Websites	V1–V4	Wahrscheinlich	Begrenzt	Mittel
R4	Prüfdaten und Bildschirmfotos ohne Löschweg	V3, interne Prüfungen	Eingetreten	Erheblich	Hoch
R5	Prüfung und öffentliche Bewertung fremder Websites ohne Wissen des Betreibers; Missbrauch als Spähwerkzeug	V1	Möglich	Erheblich	Mittel
R6	Interessenten-Prüfung als Grundlage unerbetener Ansprache	V2	Wahrscheinlich	Begrenzt	Mittel
R7	Nachweis der Verfügungsbefugnis wird nie erneuert	V4, V5	Möglich	Erheblich	Mittel
R8	Zugangsdaten und Inhalte beim Scan hinter dem Login	V5	Möglich	Schwer	Mittel; hoch bei echten Konten
R9	Aktive Test-Einsendungen und Dateiprüfung auf der Kundenwebsite	V4	Fern	Erheblich	Gering
R10	Einordnung durch ein Sprachmodell	V1–V4	Fern	Begrenzt	Gering
R11	Gemeinsame Sperrliste aus Meldungen vieler Websites	V7	Möglich	Begrenzt	Gering bis mittel; hoch mit IP-Netzen
R12	Reports und Bildschirmfotos unter öffentlichem Link	V1, V2, V4	Möglich	Begrenzt	Gering
R13	Schwächen der Infrastruktur: Sicherungen, Serverzugang, Scan-Server	alle	Möglich	Schwer	Hoch
R14	Betroffenenrechte für Personen, die uns nicht kennen	V1–V6	Wahrscheinlich	Begrenzt	Gering

R1 – Echte Besuchernachrichten in der Kontrollkopie

Das ist das schwerste Risiko des Dienstes, und es entsteht nicht durch einen Fehler, sondern durch die Bauart. Eine Blindkopie im Formular unterscheidet nicht zwischen unserer Testnachricht und der Nachricht eines Besuchers. Schaltet ein Kunde die Zustellungsprüfung ein, kommt jede Nachricht, die über dieses Formular geschickt wird, in unser Kontrollpostfach (cfg/zustellung_lib.php). Der Abruf liest Kopfzeilen und die ersten 8 KB des Textes in den Arbeitsspeicher, um nach unserer Testkennung zu suchen (cfg/zustellung_lib.php). Bei einem gewöhnlichen Kontaktformular sind das Name, E-Mail-Adresse, Telefonnummer und die vollständige Nachricht.

Was der Besucher schreibt, bestimmt er selbst, und das Feld lädt zu Persönlichem ein: eine Terminanfrage mit Beschwerden an eine Praxis, die Schilderung eines Rechtsstreits an eine Kanzlei, eine Bewerbung, eine Anfrage zu einem Kind an eine Schule. Unsere Rechtstexte sagen, Kopien „sollen keine besonderen Kategorien personenbezogener Daten enthalten“. Das ist eine Bitte an den Kunden, keine Schutzmaßnahme: Weder er noch wir wissen vorher, was ein Besucher schreibt.

Zwei Nebenwege gehören dazu. Erstens speichert die Echtheitsprüfung an der Domain die Domain der Absenderadresse (cfg/zustellung_lib.php). Verschickt das Formular mit der Adresse des Besuchers als Absender, ist das die Domain des Besuchers – bei einem großen Mail-Anbieter nichtssagend, bei einer Einzelperson mit eigener Domain ein personenbezogenes Datum. Diese Domain steht auch im Alarm, der an den Kunden und an die Kanäle geht, die er gewählt hat (cfg/zustellung_lib.php). Zweitens speichert sie die Adresse des versendenden Mailservers (cfg/zustellung_lib.php); das ist in aller Regel der Server der Website, nicht der des Besuchers.

Wahrscheinlichkeit – eingetreten, sobald eingeschaltet. Es ist keine Frage, ob echte Nachrichten ankommen, sondern wie viele. Gemessen am Entwicklungssystem ist die Funktion bei keiner Domain eingeschaltet. Schwere – schwer. Die Vertraulichkeit einer Nachricht an ein Unternehmen ist für viele Menschen wichtig, und Angaben nach Art. 9 sind bei einem Teil der typischen Kunden zu erwarten. Gemildert wird die Schwere dadurch, dass der Inhalt nicht in der Datenbank landet, nur kurz im Postfach liegt und von keinem Menschen bei formexposed gelesen wird. Stufe – hoch.

R2 – Weg der Kontrollkopie über den Postfach-Anbieter ohne abgeschlossenen Vertrag

Bevor unser Abruf eine Kontrollkopie sieht, liegt sie im Postfach bei Namecheap, Inc. (Private Email), Phoenix, Arizona, USA. Sie kommt dort nur an, wenn die MX-Einträge unserer Domain direkt auf dieses Postfach zeigen; eine Weiterleitung beim Domain-Registrar Namecheap, Inc. ist keine Station der Kontrollkopien (über eine Weiterleitung erreichen sie das Postfach nicht). Für die Station, die bleibt, ist die vertragliche Regelung noch offen: Der Vertrag mit dem Postfach-Anbieter ist nicht abgeschlossen, seine Speicherorte, Unterauftragsverarbeiter und Sicherungsfristen sind nicht festgestellt, und ob für seinen Verarbeitungsort ein Angemessenheitsbeschluss oder Standardvertragsklauseln nötig sind und greifen, ist offen. Für unsere eigenen Transaktionsmails ist das ein Punkt der Vertragsgestaltung. Für die Kontrollkopien ist es ernster: Dort sind es Daten, die wir als Auftragsverarbeiter erhalten, und jeder Dienstleister im Weg ist ein Unterauftragsverarbeiter, für den wir nach Art. 28 Abs. 4 einstehen.

Hinzu kommt, dass „nach dem Abruf gelöscht“ nur für unsere Sicht auf das Postfach gilt. Ob der Anbieter gelöschte Mails in eigenen Sicherungen oder einem Papierkorb hält, und wie lange, ist nicht geprüft. Bricht ein Abruf ab, bleiben die Mails bis zum nächsten erfolgreichen Lauf liegen (cfg/zustellung_lib.php); fällt der Statusprozess aus, bleiben sie unbegrenzt liegen. Schließlich gehört die Absicherung des Abrufs selbst zu den Punkten, die vor dem Start auf dem Produktivsystem zu prüfen sind (Abschnitt 9.3).

Wahrscheinlichkeit – wahrscheinlich, solange der Vertrag fehlt: Jede Kontrollkopie läuft diesen Weg. Schwere – schwer, aus denselben Gründen wie R1. Stufe – hoch. Die Einrichtungsliste der Anwendung meldet das fehlende Postfach als Warnung; einen Riegel, der die Zustellungsprüfung ohne dokumentierten Vertrag sperrt, gibt es nicht.

R3 – Ungeschwärzte Bildschirmfotos fremder Websites

Der Crawler macht von der ersten Seite ein Bildschirmfoto des sichtbaren Bereichs und von jedem sichtbaren Formular ein Bild des Formular-Elements (scanner/src/crawl.js). Geschwärzt wird dabei nichts. Bei den Browserwegen ist das anders: Dort werden Eingabefelder vor dem Foto maskiert (scanner/src/browser.js). „Bereinigt“ sind also nur die Bilder der Browserwege, nicht die des Crawlers und nicht das Bild der Antwortseite einer aktiven Prüfung.

Weil der Crawler nichts eintippt, sind die Formularfelder leer. Die Startseite einer kleinen Firma zeigt aber oft den Inhaber, das Team, Kundenstimmen mit Namen und Foto oder ein Chatfenster mit dem Bild einer Mitarbeiterin. Das alles ist öffentlich; das Bildschirmfoto macht daraus eine Kopie, die bei uns liegt, im Report erscheint und mit dem Link weitergegeben werden kann.

Wahrscheinlichkeit – wahrscheinlich. Gemessen sind 432 Bildschirmfotos im Bestand des Entwicklungssystems. Schwere – begrenzt: Die Inhalte sind bereits öffentlich, die Fristen sind bei Prüfungen ohne Konto kurz. Stufe – mittel, wegen der Unkenntnis der Abgebildeten und weil das Startbild für den Befund nicht gebraucht wird.

R4 – Prüfdaten und Bildschirmfotos ohne Löschweg

Der nächtliche Lauf löscht Prüfungen auf zwei Wegen: über das Ablaufdatum eines Reports (cfg/check_lib.php) und über die Frist für Prüfungen einer Kundendomain (cfg/fristen_lib.php, nur für Prüfungen mit Domain). Eine Prüfung, die weder einen Report noch eine Domain hat, fällt durch beide Raster. Das sind die Prüfungen mit der Vertrauensstufe „intern“: Studien und Prüfungen, die der Betreiber von der Kommandozeile anlegt.

Studien löschen ihre Rohdaten mit der Veröffentlichung (cfg/studie_lib.php). Wird eine Studie nie veröffentlicht – weil sie zu wenige Websites mit Formular hat (cfg/studie_lib.php verweigert dann die Veröffentlichung) oder weil sie liegen bleibt –, bleiben Prüfungen, Formulare, Befunde und Bildschirmfotos ohne Frist.
Interne Prüfungen von der Kommandozeile haben überhaupt keinen Löschweg. Gemessen am 11. Oktober 2026: 85 solcher Prüfungen fremder Websites mit 978 Formularen und 369 Bildschirmfotos, die älteste vom 22. September 2026, keine mit Report oder Domain.
Vermerke über auffälliges Verhalten beim kostenlosen Check enthalten die IP-Adresse und werden 90 Tage nach ihrer Klärung gelöscht (srv/cron_status.php). Ein Vermerk, der nie geklärt wird, bleibt. Gemessen: drei Vermerke, alle geklärt.

Wahrscheinlichkeit – eingetreten. Die 85 Prüfungen sind kein Szenario, sondern Bestand. Auf dem Entwicklungssystem sind es Prüfungen aus einem Feldtest; auf dem Produktivsystem gilt derselbe Code. Schwere – erheblich: Für diese Daten fehlt eine Löschfrist. Im Hinblick auf den Grundsatz der Speicherbegrenzung (Art. 5 Abs. 1 lit. e) ist das ein offener Punkt mit geplanter Maßnahme (Abschnitt 9.3, Vorrang „zuerst“), und er betrifft gerade Personen, die von der Prüfung nichts wissen. Beschrieben sind interne Prüfungen im Verzeichnis von Verarbeitungstätigkeiten; die Datenschutzerklärung nennt sie noch nicht gesondert (Abschnitt 9.4). Stufe – hoch.

R5 – Prüfung und öffentliche Bewertung fremder Websites ohne Wissen des Betreibers

Jeder kann jede öffentlich erreichbare Website prüfen lassen, ohne Konto und ohne Bezug zu ihr. Der Betreiber wird nicht benachrichtigt. Das Ergebnis ist ein Report, der die Website als „ungeschützt“, „teilweise geschützt“ oder „geschützt“ einstuft und den jeder sieht, der den Link hat. Zwei Folgen sind für Betroffene denkbar. Ein Einzelunternehmer wird öffentlich – wenn auch nur für die Empfänger des Links – mit einer Bewertung versehen, die ein Fehlbefund sein kann. Und der Report zeigt einem Spammer, welches Formular sich ohne Hindernis beschicken lässt.

Dagegen steht eine Reihe von Sperren (cfg/check_lib.php): je Domain höchstens eine Prüfung in sieben Tagen, danach derselbe Report; Grenzen je IP-Adresse und Sitzung; eine Tagesobergrenze für den ganzen Dienst; keine Prüfung sehr junger Domains, die typisch für Missbrauch sind; Vermerk und Signal bei auffälligem Verhalten; robots.txt und Opt-out, zweimal geprüft (cfg/check_lib.php und im Prüfdienst). Der kostenlose Report ist ein Auszug: Er zeigt nur die Grundbefunde, nicht die Belege aller Detektoren. Und er sagt nichts, was ein Bot nicht in Sekunden selbst herausfände – ein ungeschütztes Formular ist von außen sichtbar.

Wahrscheinlichkeit – möglich. Schwere – erheblich für einen Einzelunternehmer, dessen Formular nach einem Report gezielt beschickt wird oder dessen Bewertung falsch ist. Stufe – mittel.

R6 – Interessenten-Prüfung als Grundlage unerbetener Ansprache

Die Interessenten-Prüfung ist in der Oberfläche als „Türöffner fürs erste Gespräch“ beschrieben. Wie die Agentur den Kurzbefund verwendet, bestimmt sie; technisch kann sie ihn auch einem Betreiber schicken, der nicht darum gebeten hat. Wir schreiben niemanden an (cfg/akquise_lib.php), und die Allgemeinen Geschäftsbedingungen verpflichten die Agentur, die Regeln über Werbung und Ansprache einzuhalten. Eine unerbetene E-Mail mit dem Befund ist aber auch unter Unternehmen Direktwerbung, die in Polen (Art. 398 des Gesetzes über elektronische Kommunikation) und in Deutschland (§ 7 Abs. 2 UWG) eine vorherige Einwilligung braucht. Die Oberfläche weist darauf nicht hin; die Texte der Interessenten-Prüfung sprechen nur von „passiv“ und „Opt-out-Liste“.

Wahrscheinlichkeit – wahrscheinlich, weil die Funktion der Akquise dient und wir nicht prüfen können, ob eine Einwilligung des Empfängers vorliegt. Schwere – begrenzt: Für den Betreiber ist es eine lästige Werbemail mit einer Bewertung seiner Website. Stufe – mittel. Das Risiko liegt im Verhalten der Agentur; weil die Funktion von uns stammt, ist ein Hinweis in der Oberfläche geplant (Abschnitt 9.3).

R7 – Nachweis der Verfügungsbefugnis wird nie erneuert

Aktive Test-Einsendungen, die Suche nach offen liegenden Dateien und der Scan hinter dem Login setzen voraus, dass der Kunde nachgewiesen hat, über die Domain verfügen zu dürfen. Dieser Nachweis wird einmal geprüft (cfg/verify_lib.php) und danach nie wieder. Im Code gibt es keinen Weg, auf dem eine Domain ihren Nachweis verliert. Wechselt die Domain den Inhaber, kündigt eine Agentur das Mandat oder entfernt der Betreiber den DNS-Eintrag, laufen die Prüfungen weiter – bis zu täglich, mit bis zu fünf Test-Einsendungen und, wo hinterlegt, mit der Anmeldung eines Testkontos, das der neue Betreiber vielleicht nicht kennt. Nicht möglich ist dagegen, den Nachweis durch Umbenennen auf einen anderen Host zu übertragen: Der Hostname einer nachgewiesenen Domain lässt sich nicht ändern.

Wahrscheinlichkeit – möglich: Domainwechsel und Mandatswechsel sind bei Agenturen Alltag. Schwere – erheblich für den neuen Betreiber und seine Mitarbeiter, die gekennzeichnete Testnachrichten erhalten, deren Website nach offen liegenden Dateien abgesucht wird, ohne dass sie zugestimmt haben. Stufe – mittel. Die Testnachrichten erklären sich selbst und verweisen auf die Seite zum Crawler und das Opt-out; das Opt-out wirkt auch gegen Prüfungen durch Kunden.

R8 – Zugangsdaten und Inhalte beim Scan hinter dem Login

Die Verschlüsselung der Zugangsdaten ist sorgfältig gebaut: Der Webserver kann sie nach dem Speichern nicht mehr lesen, in Datenbank und Sicherung steht nur Chiffretext, der Datensatz ist an seine Domain gebunden, die Zugangsdaten gehen nur über die Standardeingabe in den Container und werden danach im Speicher geleert (Abschnitt 6.5). Zwei Lücken bleiben; ein dritter Punkt betrifft nur das Lesen, nicht das Speichern.

Unverschlüsselte Anmeldung ist zugelassen. Die Prüfung der Adressen lässt http neben https zu (cfg/login_lib.php, scanner/src/login.js). Trägt der Kunde eine Anmeldeseite mit http ein, gehen Benutzername und Passwort bei jeder Prüfung im Klartext über das Internet.
Zertifikatsfehler halten die Anmeldung nicht auf. Die Anmeldung bricht bei einem ungültigen Zertifikat der Kundenseite derzeit nicht ab (scanner/src/login.js). Das Zertifikat schützt die Zugangsdaten auf dem Weg zur Kundenseite deshalb nicht in vollem Umfang. Geplant ist der Abbruch bei Zertifikatsfehlern (Abschnitt 9.3, Vorrang „zuerst“).
Werte versteckter Felder hinter dem Login werden gelesen, nicht gespeichert. Der Crawler liest von versteckten Feldern die ersten 24 Zeichen des Werts (scanner/src/crawl.js), und dieselbe Auslesefunktion läuft hinter dem Login (scanner/src/login.js). Dort tragen versteckte Felder häufig eine Kontonummer, eine Nutzerkennung oder die E-Mail-Adresse des angemeldeten Kontos; in Feldkarte und Befunde gelangen aber nur Feldname, Typ, Beschriftung und das Erkennungsergebnis.

Dazu kommt, was der Code nicht verhindern kann: Der Kunde bestätigt, dass er ein Testkonto mit möglichst wenigen Rechten verwendet (cfg/login_lib.php), aber er kann ein echtes Administrator-Konto eintragen. Die Seiten, die der Scanner dann liest, bestimmt der Kunde; Adressen mit Wörtern für Abmelden und Löschen sind gesperrt, andere Aktionen, die eine Website über einen einfachen Aufruf auslöst, nicht.

Wahrscheinlichkeit – möglich. Schwere – schwer, wenn ein Konto mit weiten Rechten betroffen ist; dann steht der Kundenbereich mit den Daten aller Nutzer offen. Stufe – mittel bei einem Testkonto mit wenigen Rechten, hoch bei einem echten Konto. Gemessen am Entwicklungssystem ist kein Testkonto hinterlegt.

R9 – Aktive Test-Einsendungen und Dateiprüfung auf der Kundenwebsite

Eine Test-Einsendung geht an die Menschen, die die Formularmails des Kunden lesen – seine Mitarbeiter oder einen Dienstleister. Personenbezogene Daten enthält sie nicht: Absender ist dummy@formexposed.com, Text und Betreff sind gekennzeichnet und nennen die Prüfkennung (scanner/src/active.js). Das Risiko liegt in einer Fehleinordnung: Hielte der Scanner ein Bewerbungs-, Buchungs- oder Beratungsformular für ein Kontaktformular, landete die Testnachricht in einem Ablauf, der Folgen hat. Dagegen stehen die strengen Regeln für „absendbar“ (scanner/src/classify.js), die Sperre für Domains von Behörden, Bildungseinrichtungen, Kliniken, Praxen, Polizei und Gerichten (scanner/src/classify.js) und der Ausschluss des Sprachmodells von dieser Entscheidung (scanner/src/classify.js). Gespeichert werden von der Antwort Status, Zieladresse, Titel, 300 Zeichen Text und ein Bild; sie beziehen sich auf unsere Testnachricht.

Die Dateiprüfung liest von typischen Pfaden höchstens 8 KB. Liegt dort wirklich ein Datenbankauszug offen, enthalten diese 8 KB womöglich Formulareingaben von Besuchern. Sie werden nur auf eine Signatur geprüft und verworfen (cfg/dateien_lib.php); gespeichert werden Pfad, Art und Schwere.

Wahrscheinlichkeit – fern. Schwere – erheblich. Stufe – gering. Gemessen am Entwicklungssystem ist eine aktive Prüfung im Bestand, ohne angenommene Einsendung.

R10 – Einordnung durch ein Sprachmodell

Das Sprachmodell erhält für Formulare, die die Regeln nicht erkennen, Seitentitel, Adresse, Knopftexte, Feldbeschreibungen und bis zu 400 Zeichen Formulartext (scanner/src/classify.js). Darin kann ein Name stehen, etwa „Ihr Ansprechpartner: …“. Es läuft auf unserem eigenen Server; im Code geht nichts an einen Dritten. Ob die Software des Modells Anfragen protokolliert, wurde nicht geprüft. Sein Ergebnis bestimmt nur den angezeigten Formulartyp und kann kein Formular absendbar machen; eine falsche Einordnung führt zu einem schlechteren Befund, nicht zu einer Handlung.

Wahrscheinlichkeit – fern. Schwere – begrenzt. Stufe – gering.

R11 – Gemeinsame Sperrliste aus Meldungen vieler Websites

Eine Domain auf der Liste bewirkt, dass Nachrichten mit Links dorthin auf allen verbundenen Websites in der Quarantäne landen. Gehört die Domain einer Einzelperson – einem Handwerker, einer Fotografin, einem Blog –, erreichen deren Nachrichten mit einem Link auf die eigene Website die Empfänger verspätet. Auf die Liste geraten kann eine solche Domain, weil Spammer sie missbrauchen, oder weil jemand absichtlich bei mehreren Websites scheiternde Nachrichten mit ihr schickt.

Dagegen steht (cfg/swarm_lib.php): Mindestzahl von drei verschiedenen Websites und fünf Treffern binnen sieben Tagen; feste Ausnahmen für große Dienste; nie Domains unserer Kunden; Streichen von Hand über ein Werkzeug auf dem Server; Quarantäne statt Löschung; die Liste wird täglich neu gebildet, und was nicht mehr gemeldet wird, fällt heraus. Wer betroffen ist, sieht die Liste nicht und hat keinen eigenen Weg, eine Streichung zu verlangen, außer über uns.

Wahrscheinlichkeit – möglich. Schwere – begrenzt, weil nichts verloren geht und der Empfänger freigeben kann. Stufe – gering bis mittel. Mit eingeschalteten IP-Netzen wären Netze ganzer Anbieter betroffen, IP-Adressen sind personenbezogen, und die Schwere stiege auf erheblich: hoch.

R12 – Reports und Bildschirmfotos unter öffentlichem Link

Reports des kostenlosen Checks, der Interessenten-Prüfung und der Prüfungen von Kundendomains sind ohne Anmeldung unter einem zufälligen Link erreichbar. Der Link enthält 128 Bit Zufall und wird nicht erraten (cfg/check_lib.php). Die Seiten tragen noindex, die Anwendung sendet eine Referrer-Policy, die nur die Herkunft weitergibt (www/.htaccess), und Bildschirmfotos werden nur zusammen mit dem Report ausgeliefert, zu dem sie gehören; eine fremde Bildnummer liefert „nicht gefunden“ (www/shot.php). Das Risiko ist nicht kryptografisch, sondern menschlich: Ein Link wird weitergereicht, in ein Ticket kopiert, in einem Chat geteilt. Wer ihn öffnet, wird nur wie jeder Seitenaufruf im Seitenaufrufprotokoll erfasst (60 Tage), in dem der Link selbst nur unkenntlich gemacht steht; eine Liste der Leser je Report gibt es nicht.

Wahrscheinlichkeit – möglich. Schwere – begrenzt, weil der Report nur Öffentliches zeigt und nach 30 beziehungsweise 90 Tagen erlischt; Reports zu Kundendomains bleiben erreichbar, solange die Prüfung besteht (13 Monate, die letzte länger). Stufe – gering.

R13 – Schwächen der Infrastruktur

Die folgenden Punkte stehen in unserem internen Prüfpaket als offen und werden hier nicht geschönt. Wir beschreiben sie so genau, wie es Kunden für ihre eigene Bewertung brauchen, aber nicht so genau, dass die Beschreibung einem Angreifer den Weg zeigt; die Einzelheiten legen wir einer Aufsichtsbehörde auf Anfrage vor.

Sicherungen der Datenbank liegen derzeit am selben Standort wie die Datenbank und sind nicht gesondert verschlüsselt; eine verschlüsselte Kopie an einem zweiten Standort ist geplant (cfg/backup_lib.php). Bis dahin schützen sie nicht gegen den Verlust des Standorts, und wer die Datenbank erlangt, erlangt auch die Sicherungen. Die Zugangsdaten des Scans hinter dem Login sind darin nur als Chiffretext enthalten.
Keine Verschlüsselung der Datenbank im Ruhezustand. Ausgenommen sind die Felder, die einzeln verschlüsselt werden (Zugangsdaten der Testkonten, Zwei-Faktor-Geheimnis).
Verbindungen innerhalb unseres internen Netzes sind nicht durchgehend verschlüsselt.
Serververwaltung. Die Absicherung der Verwaltungszugänge unserer Server entspricht noch nicht dem Stand, den wir für den Betrieb vorsehen; die Härtung der Serververwaltung wird fortgesetzt.
Prüfumgebung. Der Scan-Server öffnet fremde Websites in einem Browser. Die Prüf-Container sind abgeschottet – eigenes Netz, keine Sonderrechte, schreibgeschützt, begrenzt (scanner/src/worker.js). Die Trennung zwischen der Prüfumgebung und den übrigen Teilen des Dienstes wird weiter verstärkt (Abschnitt 9.3).

Wahrscheinlichkeit – möglich. Schwere – schwer, weil im Ernstfall alles auf einmal betroffen wäre. Stufe – hoch. Die einzelnen Punkte sind mit gewöhnlichen Mitteln behebbar (Abschnitt 9.3).

R14 – Betroffenenrechte für Personen, die uns nicht kennen

Wer beiläufig auf einem Bildschirmfoto erscheint oder dessen Nachricht über eine Kontrollkopie lief, weiß in der Regel nicht, dass es uns gibt. Selbst wenn er es weiß, hat er keinen Schlüssel zu „seinen“ Daten: Wir speichern sie nicht nach Personen, sondern nach Domain und Prüfung. Ein Auskunftsersuchen nach Art. 15 können wir nur beantworten, wenn die Person die Domain nennt; dann können wir die vorhandenen Prüfungen und Bilder durchsehen. Für echte Besuchernachrichten gibt es nichts zu beauskunften, weil wir sie nicht speichern – außer der Absender-Domain aus R1. Das Opt-out wirkt nur für Betreiber einer Domain, nicht für abgebildete Personen; für sie bleibt der Weg über contact@lukaswojcik.com.

Wahrscheinlichkeit – wahrscheinlich als strukturelle Lage. Schwere – begrenzt, weil die Daten kurzlebig und nicht nach Personen geordnet sind. Stufe – gering.

9. (d) Abhilfemaßnahmen

Jede Maßnahme trägt einen Status, und die Statusangaben sind nicht schmückend. Heute umgesetzt – geprüft heißt: im Code des Entwicklungssystems gelesen und, wo es ging, an der Datenbank nachgemessen. Teilweise heißt: Der Mechanismus besteht, erreicht seinen Zweck aber noch nicht vollständig. Geplant heißt: von dieser Abschätzung vorgeschlagen und nicht gebaut; ob und wann, entscheidet der Inhaber. Noch festzulegen sind Verfahren und Entscheidungen, die kein Code ersetzt. Eine Folgenabschätzung, die geplante Maßnahmen als umgesetzte darstellt, verliert ihren Wert genau in der Lage, in der sie gebraucht wird.

9.1 Heute umgesetzt – geprüft

Maßnahme	Wirkt gegen	Fundstelle
robots.txt wird vor jeder Prüfung durch den Crawler gelesen; ein Ausschluss, der die Startseite erfasst, eine nicht erreichbare robots.txt oder ein Serverfehler beenden die Prüfung (Unterpfade werden nicht einzeln beachtet; Puls, Nachweisabruf, Header-Werkzeug und Dateisuche lesen sie nicht)	R5, Rechtmäßigkeit	`scanner/src/net.js`
Opt-out ohne Nachweis, sofort wirksam, für die Domain und ihre www-Variante, für anonyme Prüfungen, Interessenten, Studien und Kundenprüfungen (laufende Überwachung endet mit der nächsten fälligen Prüfung); zweimal geprüft (Anwendung und Prüfdienst); aufgehoben nur durch uns auf Anfrage mit Nachweis	R5, R7, Art. 21	`cfg/check_lib.php`; `cfg/akquise_lib.php`; `cfg/studie_lib.php`; `scanner/src/worker.js`
Kostenloser Check: Notaus, reCAPTCHA, eine Prüfung je Domain und Woche, Grenzen je IP-Adresse und Sitzung, Tagesobergrenze, keine jungen Domains, nur öffentliche Adressen, Vermerk und Signal ohne Inhalt bei Auffälligkeiten	R5	`cfg/check_lib.php`
Sitzung wird für Grenzen nur als Hashwert gespeichert, nie die Sitzungskennung	Minimierung	`cfg/check_lib.php`
Keine Feldwerte (Anfänge versteckter Felder und data-Attribute werden nur während der Prüfung gelesen, Abschnitt 6.2); Empfängeradressen nur als Domain; Kontokennungen in Skriptadressen ausgeblendet	Minimierung	`scanner/src/crawl.js`
Kostenloser Report ist ein Auszug: nur Grundbefunde, keine Belege aller Detektoren	R5	`cfg/check_lib.php`, `FE_FREE_DETEKTOREN`
Reports unter 128-Bit-Zufallslink, `noindex`, Bilder nur zum eigenen Report, außerhalb des öffentlichen Webverzeichnisses; der Link steht im Seitenaufrufprotokoll nur unkenntlich gemacht	R12	`cfg/check_lib.php`; `www/report.php`; `www/shot.php`
Löschung: anonyme Reports nach 30 Tagen, Interessenten nach 90 Tagen, Kundenprüfungen nach 13 Monaten (die letzte je Domain bleibt, solange die Domain besteht), die Daten einer gelöschten Domain sofort (Ausnahmen siehe Abschnitt 6.11), Bilder jeweils mit	Speicherbegrenzung	`cfg/check_lib.php`; `cfg/fristen_lib.php`
Studie: Veröffentlichung nur als Summe, Segmente erst ab 20 Websites mit Formular, Rohdaten mit der Veröffentlichung gelöscht	R4 teilweise, V3	`cfg/studie_lib.php`
Prüf-Container: eigenes abgeschottetes Netz, keine Sonderrechte, schreibgeschützt, Speicher- und Prozessgrenzen, Zeitlimit; Filter gegen private Ziele für jede Anfrage, Service Worker gesperrt und WebSocket-Verbindungen geschlossen, damit nichts am Filter vorbeiläuft; Abrufe des Webservers nur auf Web-Ports und nur zu genau der zuvor geprüften öffentlichen Adresse	R13	`scanner/src/worker.js`; `scanner/src/net.js`
Aktive Prüfung für Kunden nur bei nachgewiesener Domain (intern zusätzlich für eigene Test- und Demodomains) und eingeschaltetem Notaus, zweimal geprüft; höchstens fünf Einsendungen; nur klar erkannte Kontaktformulare ohne Pflicht-Personendaten; keine Behörden-, Bildungs-, Klinik-, Praxis-, Polizei- oder Gerichtsdomains; Sprachmodell darf nichts freigeben; Testnachricht ohne Personendaten, gekennzeichnet, mit Verweis auf Crawler-Seite und Opt-out	R9	`scanner/src/worker.js`; `scanner/src/classify.js`; `scanner/src/active.js`
Browserwege: nur GET und HEAD, gefährliche Adressen gesperrt, erfundene Werte verlassen den Browser nicht, Bilder mit geschwärzten Eingabefeldern	R3 (für diese Bilder), R9	`scanner/src/browser.js`
Dateiprüfung: nur nachgewiesene Domains, ein Abruf je Pfad, höchstens 8 KB, Inhalt nie gespeichert	R9	`cfg/dateien_lib.php`
Zweite Sonde: ab Werk aus; erhielte nur eine feste Liste unbedenklicher Angaben, signiert	Empfänger	`cfg/formular_probe_lib.php`
Scan hinter dem Login: nur nachgewiesene Domain, bezahlter Tarif, Inhaber oder Administrator, Bestätigung „Testkonto“; Verschlüsselung mit dem öffentlichen Schlüssel des Scan-Servers, an die Domain gebunden; Zugangsdaten nie angezeigt, protokolliert oder per Schnittstelle ausgegeben; Übergabe nur über die Standardeingabe; Feld im Auftrag sofort geleert, Reste nach einer Stunde; keine Bildschirmfotos, keine Einsendungen, keine Abmelde- und Löschadressen, Abbruch bei CAPTCHA; endgültiges Löschen mit Überschreiben	R8	`cfg/login_lib.php`; `scanner/src/login.js`; `scanner/src/geheim.js`; `scanner/src/worker.js`
Zustellungsprüfung: ab Werk aus; Abruf liest nur Kopfzeilen und 8 KB, ohne Lesemarkierung; Inhalt und Besucheradresse nie in der Datenbank; jede abgerufene Mail wird gelöscht, auch unzuordenbare; Zuordnungen nach 180 Tagen gelöscht; Nachweis nur über die Kopie genau dieses Tests	R1, R2	`cfg/zustellung_lib.php`
Schwarmschutz: nur Domains, IP-Netze aus; Mindestzahlen; Ausnahmen für große Dienste und Kundendomains; Quarantäne statt Löschung; Liste täglich neu; Meldungen nach 30 Tagen gelöscht	R11	`cfg/swarm_lib.php`
Sprachmodell auf eigenem Server, ohne Absenderecht	R10	`scanner/src/classify.js`
Signale über Telegram enthalten nur einen festen Satz ohne Variable	Empfänger	`cfg/check_lib.php`
Wiederherstellungsprobe der Sicherung wöchentlich, mit Alarm bei Fehlschlag	Verfügbarkeit	`cfg/backup_lib.php`; `srv/cron_status.php`

9.2 Teilweise – vorhanden, erreicht seinen Zweck aber noch nicht

Maßnahme	Warum sie noch nicht vollständig wirkt
„Bereinigte“ Bildschirmfotos	Nur die Bilder der Browserwege sind geschwärzt. Die Bilder des Crawlers – Startseite und Formular-Elemente – und das Bild der Antwortseite einer aktiven Prüfung sind es nicht (R3).
Fristen für Prüfdaten	Wirksam für anonyme, Interessenten- und Kundenprüfungen; nicht für interne Prüfungen und unveröffentlichte Studien; ungeklärte Auffälligkeitsvermerke ohne Frist (R4).
Löschung der Kontrollkopien	Wirkt in unserer Sicht auf das Postfach. Bei Abbruch des Laufs bleiben Mails liegen; was der Postfach-Anbieter in eigenen Sicherungen hält, ist nicht geprüft (R2).
Schutz der Zugangsdaten beim Scan hinter dem Login	Ruhend und im Prüfdienst stark; auf dem Weg zur Website nicht: `http` ist zugelassen, Zertifikatsfehler werden übergangen (R8).
Nachweis der Verfügungsbefugnis	Wird einmal geprüft und gilt dann für immer; der Hostname einer nachgewiesenen Domain lässt sich aber nicht ändern, sodass der Nachweis nicht auf einen anderen Host übergeht (R7).
Information der Betroffenen	Für Betreiber über Crawler-Seite, Kennung, Datenschutzerklärung und Opt-out vorhanden; für Besucher bei der Zustellungsprüfung abhängig davon, dass der Kunde den Textbaustein übernimmt; die Anwendung prüft das nicht.
Bitte an Kunden, keine besonderen Kategorien in die Kontrollkopie zu geben	Steht in den Rechtstexten, wird aber technisch nicht unterstützt: Die Anwendung fragt bei der Einrichtung nicht nach der Art der Website und warnt nicht bei Domains, die nach Gesundheit, Recht oder Bildung aussehen (R1).

9.3 Geplant – nicht umgesetzt

Maßnahme	Wirkt gegen	Vorrang
Löschweg für interne Prüfungen: Prüfungen ohne Domain und ohne Report nach einer festen Frist löschen (Vorschlag: 30 Tage); Rohdaten einer Studie spätestens eine feste Frist nach ihrem Abschluss löschen, auch ohne Veröffentlichung (Vorschlag: 90 Tage); den Bestand von 85 Prüfungen mit 369 Bildern einmalig löschen	R4	Zuerst
Zustellungsprüfung erst freischalten, wenn der Vertrag mit dem Postfach-Anbieter abgeschlossen, Speicherorte, Unterauftragsverarbeiter und Sicherungsfristen dokumentiert und die Übermittlungsgrundlage für den Postfach-Anbieter geklärt sind und die MX-Einträge unserer Domain direkt auf das Postfach zeigen; bis dahin die Funktion im Produktivsystem gesperrt lassen	R2	Zuerst
Absicherung des Postfachabrufs auf dem Produktivsystem prüfen und dokumentieren, bevor die Zustellungsprüfung freigeschaltet wird	R2	Zuerst
Scan hinter dem Login nur über `https` und mit gültigem Zertifikat; `http`-Adressen ablehnen; Zertifikatsfehler bei der Anmeldung als Abbruchgrund	R8	Zuerst
Werte versteckter Felder hinter dem Login nicht speichern (nur Name, Typ und Länge) – bereits so umgesetzt, kein weiterer Schritt	R8	erledigt
Kontrollkopie auf Testnachrichten beschränken, wo das Plugin oder die Erweiterung im Einsatz ist: Blindkopie nur für Einsendungen mit unserer Testkennung	R1	Hoch
Absender-Domain echter Nachrichten nicht speichern und nicht in Alarme schreiben, wenn sie weder die Domain der Website noch die eines bekannten Versanddienstes ist; im Alarm stattdessen „fremde Absender-Domain“	R1	Hoch
Warnung bei der Einrichtung der Zustellungsprüfung für Domains, die nach Gesundheit, Recht, Sozialem oder Bildung aussehen, mit dem Hinweis auf die eigene Folgenabschätzung des Kunden	R1	Hoch
Nachweis der Verfügungsbefugnis regelmäßig erneuern (Vorschlag: vor jeder aktiven Prüfung prüfen, ob DNS-Eintrag, Meta-Tag, Datei oder Plugin-Verbindung noch bestehen; sonst passiv weiter und Hinweis an den Kunden)	R7	Hoch
Startseite nicht mehr fotografieren, oder nur mit geschwärzten Bildern und Gesichtern; Formular-Bilder auf das Formular-Element beschränken (wie heute) und Eingabefelder wie bei den Browserwegen maskieren	R3	Hoch
Hinweis in der Oberfläche der Interessenten-Prüfung: Den Kurzbefund ungefragt per E-Mail oder Telefon zu schicken, ist auch unter Unternehmen Direktwerbung und braucht eine vorherige Einwilligung (Art. 398 des polnischen Gesetzes über elektronische Kommunikation; in Deutschland § 7 Abs. 2 UWG, wobei für Anrufe bei Unternehmen eine mutmaßliche Einwilligung genügt)	R6	Hoch
Infrastruktur: Härtung der Serververwaltung abschließen; verschlüsselte Kopie der Sicherung an einem zweiten Standort; Verbindungen im internen Netz durchgehend verschlüsseln; Trennung zwischen Scan-Server und Anwendung weiter verstärken	R13	Hoch
Frist für ungeklärte Auffälligkeitsvermerke (Vorschlag: Klärung binnen 30 Tagen, sonst Löschung der IP-Adresse)	R4	Mittel
Eine Seite oder ein Formular, über das jemand die Streichung einer Domain aus dem Schwarmschutz verlangen kann	R11, R14	Mittel
Vor dem Einschalten von IP-Netzen im Schwarmschutz: neue Fassung dieser Abschätzung	R11	Bedingung
Protokoll, ob die Software des Sprachmodells Anfragen speichert, und gegebenenfalls Abschalten dieser Protokolle	R10	Gering

9.4 Verfahren und Entscheidungen, die noch festzulegen sind

Art. 35 Abs. 7 lit. d verlangt neben technischen Vorkehrungen auch Verfahren. Diese stehen noch aus:

Datenpanne. Erkennen: Inhaber, Fehleralarm der Anwendung, Hinweise über die Meldestelle für Sicherheitslücken oder contact@lukaswojcik.com. Entscheidung über die Meldung an den UODO binnen 72 Stunden (Art. 33 Abs. 1): der Inhaber. Unterrichtung betroffener Kunden als Verantwortliche: unverzüglich, möglichst binnen 48 Stunden, wie im Auftragsverarbeitungsvertrag zugesagt. Festzulegen: eine schriftliche Ablaufbeschreibung und eine erste Übung; für die Zustellungsprüfung zusätzlich, wie ermittelt wird, welche Kunden von einer Panne beim Postfach-Anbieter betroffen sind.
Branchen. Festzulegen: ob die Zustellungsprüfung für Websites aus Gesundheit, Recht, Sozialem und Bildung angeboten, mit Warnung angeboten oder ausgeschlossen wird.
Interne Prüfungen. Festzulegen: wofür der Betreiber interne Prüfungen von der Kommandozeile verwendet, wer sie anlegen darf und wie lange ihre Ergebnisse bleiben; und ob sie über das Verzeichnis von Verarbeitungstätigkeiten hinaus in der Datenschutzerklärung zu nennen sind.
Studien. Festzulegen: wer Listen zusammenstellt, nach welchen Quellen, mit welcher Höchstgröße, und eine Prüfung vor jeder Studie, ob sie die Annahmen dieser Abschätzung einhält.
Standpunkt der Betroffenen (Art. 35 Abs. 9). Er ist für diese Fassung nicht eingeholt worden. Art. 35 Abs. 9 verlangt die Einholung nur, wo sie angebracht ist („gegebenenfalls“); das ist hier nach unserer Bewertung derzeit nicht der Fall. Betreiber geprüfter Websites und Besucher von Kundenwebsites haben zu uns keinen eigenen Kanal; sie gezielt anzusprechen, wäre selbst eine neue Verarbeitung ihrer Daten, und der Dienst ist noch nicht gestartet, sodass es noch keinen Kreis tatsächlich Betroffener gibt. Ihre Interessen sind mittelbar berücksichtigt: durch robots.txt und Opt-out, durch die kurzen Fristen und dadurch, dass Inhalte der Kontrollkopien nicht gespeichert werden. Bei jeder Überprüfung nach Abschnitt 12 prüfen wir erneut, ob eine Einholung angebracht ist, etwa über Rückmeldungen auf der Crawler-Seite oder bei Kunden der Zustellungsprüfung.

10. Verbleibendes Risiko und vorherige Konsultation nach Art. 36

Art. 36 Abs. 1 verlangt die vorherige Konsultation der Aufsichtsbehörde, wenn aus der Folgenabschätzung hervorgeht, dass die Verarbeitung ein hohes Risiko zur Folge hätte, sofern der Verantwortliche keine Maßnahmen zu seiner Eindämmung trifft. Gefragt ist also nicht, ob hohe Risiken festgestellt wurden – vier wurden es –, sondern ob ein hohes Risiko bleibt, wenn die Maßnahmen stehen.

Für die Verarbeitungen, für die formexposed Verantwortlicher ist (V1 bis V4, V7), sind die hohen Risiken R4 und R13 mit gewöhnlichen Mitteln behebbar: einem Löschweg und einer Bereinigung des Bestands, einer verschlüsselten Sicherung außer Haus und der Härtung zweier Server. Mit den Maßnahmen aus 9.3 fallen sie auf gering bis mittel. R3, R5, R6 und R7 stehen auf mittel und fallen mit den vorgeschlagenen Maßnahmen auf gering. Der Schwarmschutz bleibt ohne IP-Netze gering bis mittel. Eine vorherige Konsultation ist für diesen Teil nicht angezeigt, wenn die als „zuerst“ und „hoch“ gekennzeichneten Maßnahmen vor dem Start umgesetzt werden. Ist eine dieser Maßnahmen vor dem Start nicht umgesetzt, bleibt für die betroffene Verarbeitung ein hohes Risiko. Dann wird diese Verarbeitung erst aufgenommen, wenn die Maßnahme umgesetzt ist, oder vorher der UODO nach Art. 36 Abs. 1 konsultiert.

Für die Zustellungsprüfung (V6) ist die Lage anders, und zwar aus einem Grund, den keine Maßnahme ganz beseitigt: Was ein Besucher schreibt, bestimmt er. Mit einem abgeschlossenen Vertrag, einem abgesicherten Abruf, der Beschränkung auf Testnachrichten wo möglich und dem Verzicht auf die Absender-Domain fällt R2 auf gering und R1 auf mittel. Bei Kunden, deren Besucher typischerweise Angaben nach Art. 9 machen, kann R1 trotzdem hoch bleiben. Die Konsultationspflicht trifft dann den Kunden als Verantwortlichen, nicht formexposed. Unsere Empfehlung an solche Kunden ist, die Kontrollkopie nicht für das allgemeine Kontaktformular einzurichten, sondern nur für Formulare ohne sensible Inhalte, oder auf die Zustellungsprüfung zu verzichten.

Verbleibendes Risiko, ehrlich benannt. Heute, mit den Maßnahmen aus 9.1, stehen vier Risiken auf hoch: R1 und R2 (Zustellungsprüfung), R4 (Prüfdaten ohne Löschweg) und R13 (Infrastruktur). Mit den Maßnahmen aus 9.3 fallen R2, R4 und R13 auf gering bis mittel. R1 bleibt bei mittel und ist dauerhaft abhängig von Entscheidungen, die die Kunden treffen. Keines der übrigen Risiken liegt nach den Maßnahmen über mittel.

Art. 36 ist keine Strafe, und zu konsultieren ist kein Eingeständnis. Es ist der Weg, den die Verordnung für die Lage vorsieht, in der ein nützliches Verfahren ein Risiko trägt, das der Verantwortliche nicht vollständig beherrscht. Wer als Kunde die Zustellungsprüfung für Nachrichten mit Gesundheitsangaben nutzen will, findet hier die Tatsachen für diese Entscheidung.

11. Was Kunden für ihre eigene Folgenabschätzung brauchen (Art. 28 Abs. 3 lit. f)

Für die Zustellungsprüfung und den Scan hinter dem Login ist der Kunde Verantwortlicher. Diese Seite liefert ihm die Beschreibung (Abschnitte 6.5 und 6.6), die Risiken aus unserer Sicht (R1, R2, R8) und den Stand der Maßnahmen (Abschnitt 9). Die folgenden Fragen kann nur er beantworten:

Was schreiben meine Besucher? Ist zu erwarten, dass über das Formular Angaben zu Gesundheit, Religion, Herkunft, Gewerkschaftszugehörigkeit, sexueller Orientierung, Straftaten oder über Kinder kommen? Dann ist die Folgenabschätzung für die Kontrollkopie in aller Regel erforderlich, und die Kontrollkopie für dieses Formular ist zu überdenken.
Brauche ich die Kontrollkopie für alle Nachrichten? Für den Nachweis, dass unsere Testnachricht ankommt, genügt sie für diese. Wo das Formular es zulässt, die Blindkopie nur für Testnachrichten setzen.
Wie informiere ich meine Besucher? Der Auftragsverarbeitungsvertrag verlangt es; der Textbaustein für Ihre Datenschutzerklärung beschreibt den Weg der Kopie und unsere Rolle.
Welche Rechtsgrundlage habe ich? Unser Textvorschlag nennt Art. 6 Abs. 1 lit. f (zuverlässiger Empfang von Anfragen). Für Angaben nach Art. 9 trägt diese Grundlage allein nicht.
Welche Alarmkanäle wähle ich? Alarme der Echtheitsprüfung können die Absender-Domain nennen. Wer Alarme an Chatdienste außerhalb der EU schickt, übermittelt sie dorthin.
Für den Scan hinter dem Login: Ist das Testkonto wirklich ein Testkonto mit den geringsten nötigen Rechten? Ist die Anmeldeseite nur über https erreichbar? Sieht das Testkonto Daten anderer Nutzer? Wenn ja: Auf welchen der angegebenen Seiten?
Wann lösche ich? Zustellungsprüfung und Testkonto lassen sich jederzeit abschalten und löschen; das Testkonto wird dabei endgültig überschrieben.

Weitere Unterlagen für die Abschätzung des Kunden: der Auftragsverarbeitungsvertrag, die technischen und organisatorischen Maßnahmen, die Liste der Unterauftragsverarbeiter und das Verzeichnis von Verarbeitungstätigkeiten. Fragen zu einzelnen Tatsachen beantworten wir unter contact@lukaswojcik.com.

12. Überprüfung, Fassung und Freigabe

Art. 35 Abs. 11 verlangt zu überprüfen, ob die Verarbeitung gemäß der Folgenabschätzung durchgeführt wird, zumindest wenn sich das Risiko ändert. Wir überprüfen diese Abschätzung mindestens jährlich und außerdem vor jedem der folgenden Ereignisse; jedes löst eine neue Messung aus, nicht nur eine Lektüre:

Start des Produktivbetriebs, mit Zahlen des Produktivsystems statt des Entwicklungssystems;
erstes Einschalten der Zustellungsprüfung auf dem Produktivsystem und Abschluss des Vertrags mit dem Postfach-Anbieter;
Einschalten der IP-Netze im Schwarmschutz;
erste Studie, und jede Studie mit einer größeren Liste als die vorige;
Einschalten der zweiten Sonde oder eines neuen Empfängers im Prüfweg;
neuer Einsatz des Sprachmodells, der über die Einordnung von Formularen und „Fix it for me“ hinausgeht;
jede Änderung an den Bildschirmfotos, an den Fristen oder an den Voraussetzungen für aktive Prüfungen.

Punkt	Eintrag
Verantwortlicher	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polen · NIP 7252266190 · contact@lukaswojcik.com
Zuständige Aufsichtsbehörde	Prezes Urzędu Ochrony Danych Osobowych (UODO), ul. Moniuszki 1A, 00-014 Warszawa, Polen
Datenschutzbeauftragter	Nicht benannt; Prüfung nach Art. 37 in Abschnitt 4
Grundlage der Tatsachen	Quelltext von Anwendung und Prüfdienst, Datenbankschema, Zeilenzahlen und Einstellungen des Entwicklungssystems, gemessen am 11. Oktober 2026, ausschließlich lesend
Verwandte Dokumente	Datenschutzerklärung, Auftragsverarbeitungsvertrag, Technische und organisatorische Maßnahmen, Unterauftragsverarbeiter, Verzeichnis von Verarbeitungstätigkeiten, EU-KI-Verordnung, Zulässige Nutzung und Missbrauch, FormExposedBot, Opt-out
Fassung	1.0 vom 11. Oktober 2026, erste Fassung
Überprüfungen nach Art. 35 Abs. 11	Noch keine (erste Fassung). Jede Überprüfung wird hier mit Datum, Anlass und Ergebnis eingetragen.
Freigabe	Noch nicht freigegeben. Freigabe durch den Inhaber nach anwaltlicher Prüfung und nach Entscheidung über die Maßnahmen aus Abschnitt 9.3 und die Fragen aus Abschnitt 9.4. Externer Datenschutzrat wurde bisher nicht eingeholt.

Eine abschließende Beobachtung gehört in das Dokument und nicht in ein Begleitschreiben. Die Teile von formexposed, die am stärksten in fremde Bereiche hineinreichen – die Test-Einsendungen und die Anmeldung mit fremden Zugangsdaten –, sind mit der meisten Vorsicht gebaut: zwei Tore, harte Deckel, Verschlüsselung, die selbst uns aussperrt. Die Risiken dieser Abschätzung liegen überwiegend an anderer Stelle: bei dem, was nebenbei mitkommt – echte Nachrichten in einer Blindkopie, Menschen auf einem Bildschirmfoto, Prüfungen, die niemand mehr löscht. Das ist eine günstige Ausgangslage, denn das Nebenbei lässt sich abstellen, ohne den Dienst zu ändern.

Wie können wir helfen?