Technische und organisatorische Maßnahmen

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

Fassung 1.1 · Stand: 22. Oktober 2026

Maßnahmen nach Art. 32 DSGVO, mit denen LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polen, den Dienst formexposed schützt. Diese Seite ist als Anlage 2 Bestandteil des Auftragsverarbeitungsvertrags.

1. Geltungsbereich und Grundsatz

Die Maßnahmen gelten für alle Daten, die der Dienst verarbeitet: für die Daten, die wir im Auftrag unserer Kunden verarbeiten (beschrieben im Auftragsverarbeitungsvertrag), und für die Daten, für die wir selbst verantwortlich sind, etwa Kundenkonten und Protokolle. Getrennte Schutzstufen für beide gibt es nicht; was das Konto schützt, schützt auch die Auftragsdaten.

Gliederung nach Art. 32 Abs. 1 DSGVO. Pseudonymisierung und Verschlüsselung (Buchst. a) stehen in Abschnitt 4; die Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme auf Dauer (Buchst. b) in den Abschnitten 3, 5, 6 und 7; die rasche Wiederherstellung nach einem Zwischenfall (Buchst. c) in Abschnitt 7.1; das Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit (Buchst. d) in Abschnitt 9. Ausgewählt haben wir die Maßnahmen nach den Risiken, die unsere Datenschutz-Folgenabschätzung beschreibt, unter Berücksichtigung des Stands der Technik und der Implementierungskosten.

Grundsatz: gemessen statt beabsichtigt. Hier steht nur, was im Code oder im Betrieb tatsächlich umgesetzt ist. Was geplant, aber noch nicht umgesetzt ist, steht in Abschnitt 10 ausdrücklich als „geplant“. Eine Maßnahme, die hier fehlt, ist nicht stillschweigend vorhanden.

Bewusst nicht genannt sind Namen von Rechnern, interne Adressen, Ports, Benutzernamen und Softwareversionen. Sie helfen niemandem, die Maßnahmen zu beurteilen, wohl aber jemandem, der sie umgehen will. Wer sie für eine Kontrolle nach dem Auftragsverarbeitungsvertrag braucht, erhält sie im Rahmen dieser Kontrolle unter Vertraulichkeit, soweit sie für die Kontrolle erforderlich sind.

2. Aufbau des Dienstes

Der Dienst läuft auf zwei eigenen Servern des Anbieters in Polen, die im selben internen Netz stehen:

Webserver mit Datenbank. Er liefert die Anwendung aus, hält die Datenbank, versendet Meldungen und sichert die Daten. Nur er ist dafür eingerichtet, Anfragen aus dem Internet anzunehmen.
Scan-Server. Er führt die Prüfungen fremder und eigener Websites in einem Browser aus und betreibt das Sprachmodell, das einzelne Formulare einordnet und bei „Fix it for me“ Code ergänzt. Er ist nicht dafür eingerichtet, Anfragen aus dem Internet anzunehmen, sondern holt seine Aufträge selbst beim Webserver ab und liefert die Ergebnisse dorthin zurück.

Ein Hosting-, Rechenzentrums- oder Cloud-Anbieter ist am Betrieb nicht beteiligt, und an einen externen KI-Dienst geht nichts. Welche Dritten Daten erhalten, steht auf der Seite Unterauftragsverarbeiter.

3. Vertraulichkeit

3.1 Zutrittskontrolle

Die Server stehen in nicht öffentlich zugänglichen Räumen des Anbieters in Polen. Zutritt hat nur der Inhaber (Angabe des Betreibers). Die genaue Anschrift des Standorts ist hier bewusst nicht genannt.

3.2 Zugangskontrolle: Anmeldung am Dienst

Passwörter werden nur als Hash mit dem Standardverfahren von PHP (bcrypt) gespeichert. Ändert sich das Standardverfahren, wird der Hash bei der nächsten Anmeldung erneuert. Bei einer Anmeldung mit unbekannter Adresse rechnet der Server trotzdem einen Hash, damit die Antwortzeit nicht verrät, ob es ein Konto gibt. Ebenso verrät die Antwort auf eine Anfrage zum Zurücksetzen des Passworts weder durch ihren Wortlaut noch durch ihre Dauer, ob es das Konto gibt; Mails zum Zurücksetzen gehen an dieselbe Adresse höchstens dreimal in der Stunde. Neue Passwörter müssen mindestens zehn Zeichen lang sein und dürfen höchstens 72 Byte (UTF-8) umfassen, weil bcrypt nicht mehr Byte berücksichtigt. Ein Passwortwechsel meldet alle anderen Geräte ab; das Zurücksetzen über den Link meldet alle Geräte ab, und der Link gilt nur einmal.
Sperre bei Fehlversuchen. Fehlgeschlagene Anmeldungen werden je IP-Adresse gezählt; nach zu vielen in kurzer Zeit (derzeit acht in 15 Minuten) ist die Anmeldung von dieser Adresse vorübergehend gesperrt. Eine erfolgreiche Anmeldung setzt diesen Zähler zurück. Die Versuche werden nach sieben Tagen gelöscht. Zusätzlich wird vor jeder Passwortprüfung ein Versuch je Konto (bei unbekannter Adresse je eingegebener Adresse) und je IP-Adresse gezählt, erfolgreiche eingeschlossen: derzeit höchstens acht je Konto von derselben IP-Adresse und 80 je IP-Adresse in 15 Minuten; je Konto über alle Adressen zusammen gilt eine deutlich höhere Grenze gegen verteiltes Raten. Fehlversuche von einer fremden Adresse sperren den Inhaber eines Kontos deshalb nicht mehr aus. Diese Zähler enthalten nur einen HMAC-Schlüssel, keine E-Mail- oder IP-Adresse im Klartext, und verfallen mit ihrem Zeitfenster. Ist der Zählerspeicher nicht verfügbar, wird die Anmeldung abgewiesen, nicht durchgelassen. Auf dieselbe Weise begrenzt sind die Bestätigung des Passworts vor Passwort- und Adresswechsel, dem Ein- und Ausschalten des zweiten Faktors, der Übergabe eines Arbeitsbereichs, dem Datenexport und der Kontolöschung (fünf Versuche je Konto in 15 Minuten), Registrierungen (zehn je IP-Adresse in der Stunde) und Passwörter von Kundenportalen (zehn Versuche je Portal und IP-Adresse, 50 je Portal in 15 Minuten).
Zweiter Faktor. Jedes Konto kann eine Anmeldung mit Einmalcode nach RFC 6238 (TOTP) einschalten. Das Geheimnis dazu liegt verschlüsselt in der Datenbank; der Schlüssel liegt nicht in der Datenbank, sodass ein Datenbankauszug allein nicht genügt. Ein angenommener Code gilt kein zweites Mal. Zehn Wiederherstellungscodes werden nur als Hash gespeichert. Einmal- und Wiederherstellungscodes sind auf zehn Versuche je Konto in 15 Minuten begrenzt, auch bei der Einrichtung.
Verwaltungsbereich nur mit zweitem Faktor. Der Verwaltungsbereich des Betreibers öffnet sich nur Konten mit eingeschaltetem zweiten Faktor. Die Einrichtungsliste meldet jedes Verwalterkonto ohne zweiten Faktor.
Sitzungen. Das Sitzungscookie ist für Skripte nicht lesbar (HttpOnly), wird nur über HTTPS gesendet (Secure) und nicht bei Anfragen von fremden Seiten mitgeschickt, die etwas verändern könnten (SameSite=Lax). Bei der Anmeldung entsteht eine neue Sitzungskennung, damit eine vorher untergeschobene Kennung nicht weiter gilt; eine Sitzungskennung, die er nicht selbst ausgegeben hat, nimmt der Server nicht an. Jedes Konto sieht seine angemeldeten Geräte und kann sie einzeln abmelden.
„Angemeldet bleiben“ ist freiwillig und gilt 30 Tage, nicht für Konten mit Verwaltungsrechten; sie melden sich immer mit Passwort und zweitem Faktor an. Das Merkmal besteht aus zwei Teilen; der prüfende Teil liegt nur als Hash in der Datenbank. Jede Nutzung ersetzt es durch ein neues, und auch bei gleichzeitigen Anfragen gilt jedes Merkmal nur einmal, sodass ein gestohlenes Merkmal spätestens beim nächsten echten Besuch auffällt.
Links in Mails. Links zur Bestätigung der Adresse und zum Zurücksetzen des Passworts stehen nur als Hash in der Datenbank. Der Link zum Zurücksetzen gilt eine Stunde, der zur Bestätigung der Registrierung 72 Stunden, der zur Bestätigung einer geänderten Adresse 24 Stunden. Wird die E-Mail-Adresse geändert, verliert ein offener Link zum Zurücksetzen seine Gültigkeit.
Schnittstellen. API-Schlüssel, Verbindungscodes der Erweiterungen und Rollout-Codes werden nur als Hash gespeichert. API-Schlüssel sind je Minute begrenzt nutzbar; Verbindungscodes der Erweiterungen gelten 15 Minuten und nur einmal.
Bot-Abwehr auf den öffentlichen Formularen (Registrierung, Anmeldung, Passwort, Check, Header-Werkzeug, Opt-out, Support und Kontakt): Google reCAPTCHA, das erst beim Absenden geladen wird. Angenommen wird nur eine gültige Antwort von Google mit ausreichender Punktzahl für genau die Aktion des Formulars; antwortet Google nicht innerhalb von drei Sekunden, wird das Absenden abgelehnt. Einzelheiten stehen in der Datenschutzerklärung.

3.3 Zugangskontrolle: Verwaltung der Server

Der aus dem Internet erreichbare Server lässt über einen Paketfilter nur die Dienste zu, die er anbietet, und sperrt Adressen nach wiederholt fehlgeschlagenen Anmeldungen an der Serververwaltung automatisch.
Automatische Abläufe zwischen den Servern nutzen eigene Schlüssel mit eng begrenzten Rechten. Der Schlüssel, mit dem der Webserver neue Fassungen des Scanners ausliefert, darf auf dem Scan-Server nur eine feste Liste von Befehlen ausführen und nur schreibend in das Verzeichnis des Scanners kopieren; eine interaktive Anmeldung ist mit ihm nicht möglich, und jeder abgewiesene Befehl wird protokolliert. Ebenso darf der Scan-Server Bildschirmfotos nur in ein bestimmtes Verzeichnis des Webservers schreiben.
Der Prozess, der die Website ausliefert, hat weder Schreibrechte auf die Produktivinstallation noch einen Schlüssel für den Scan-Server. Eine Auslieferung, die im Verwaltungsbereich angestoßen wird, legt nur einen Auftrag ab, den ein gesonderter Lauf ausführt.
Geheimnisse wie Datenbankzugänge und Schlüssel liegen in Konfigurationsdateien außerhalb des ausgelieferten Verzeichnisses und werden bei der Auslieferung nicht mitkopiert. Die Konfiguration des Webservers wird nicht über die Weboberfläche verteilt.

3.4 Zugriffskontrolle: Rechte im Dienst

Rollen. In jedem Arbeitsbereich gibt es die Rollen Inhaber, Administrator und Leser. Ändern, Löschen, Einladen und das Hinterlegen von Zugangsdaten sind Inhabern und Administratoren vorbehalten; Rollen ändern und Mitglieder entfernen darf nur der Inhaber. Eine Einladung gilt nur, solange die einladende Person noch Inhaber oder Administrator ist. Leser sehen die Adressen von Webhooks und Chat-Kanälen nur gekürzt auf den Host, weil schon die Adresse das Senden in den Kanal erlaubt. Die Prüfung findet auf dem Server statt, nicht nur in der Oberfläche.
Bindung an den Arbeitsbereich. Domains und Einstellungen sind nur für Mitglieder des Arbeitsbereichs erreichbar. Zu jeder Prüfung legt der Dienst einen Bericht unter einem zufälligen, nicht erratbaren Link an; Ergebnisse und Bildschirmfotos einer Prüfung sind über diesen Link ohne Anmeldung abrufbar, Bildschirmfotos nur zusammen mit dem Link ihres Berichts. Der Link steht im Konto und in Alarmen; wer ihn weitergibt, gibt den Bericht weiter.
Zustandsändernde Anfragen verlangen ein Sicherheitsmerkmal je Sitzung (CSRF-Schutz), das zeitkonstant verglichen wird.
„Ansicht als Kunde“. Für den Support kann der Betreiber die Anwendung so sehen, wie ein Kunde sie sieht. Die Ansicht endet nach einer Stunde, sperrt Änderungen an Passwort, Adresse, zweitem Faktor, Geräten, Abo, Export und Löschung, schließt währenddessen den Verwaltungsbereich und wird protokolliert. Ihr Ende meldet den Betreiber vollständig ab; zurück in den Verwaltungsbereich kommt er nur mit einer neuen Anmeldung mit Passwort und zweitem Faktor. Der Kunde sieht sie in seinem Datenexport.
Verwaltung. Nur wenige ausdrücklich berechtigte Konten haben Verwaltungsrechte; jede Rücksetzung eines zweiten Faktors durch die Verwaltung wird protokolliert.

3.5 Trennungskontrolle

Die Daten der Kunden sind nach Arbeitsbereichen logisch getrennt. Jeder Lese- und Schreibweg im angemeldeten Bereich führt diese Bindung mit; Berichte sind zusätzlich über ihren Link erreichbar (Abschnitt 3.4).
Entwicklung und Betrieb laufen in getrennten Installationen mit getrennten Datenbanken und getrennten Datenbankbenutzern. Der Benutzer der Entwicklung hat keinen Zugriff auf die Datenbank des Betriebs. Echte Kundendaten werden nicht in die Entwicklung kopiert; dort arbeiten wir mit erzeugten Beispieldaten.
Der Scanner hat je Umgebung eigene Zugangsdaten mit Rechten nur auf die Daten, die er für seine Aufträge braucht. Konten, Abrechnung und Protokolle kann er nicht lesen.
Auf dem Webserver laufen auch andere Dienste desselben Anbieters. Sie haben eigene Datenbanken und eigene Datenbankbenutzer ohne Zugriff auf die Daten dieses Dienstes.

4. Verschlüsselung, Pseudonymisierung und Datensparsamkeit

4.1 Zugangsdaten für den Scan hinter dem Login

Für diese Funktion hinterlegt der Kunde Benutzername und Passwort eines Testkontos. Sie sind die empfindlichsten Daten im Dienst und deshalb anders geschützt als alles andere:

Der Webserver verschlüsselt sie beim Speichern mit dem öffentlichen Schlüssel des Scan-Servers (ECIES: X25519 mit einem Einmalschlüssel je Datensatz, HKDF-SHA256, AES-256-GCM). Den privaten Schlüssel gibt es nur auf dem Scan-Server. Webserver, Datenbank und Sicherungen enthalten nur Chiffretext; auch wir können ihn dort nicht lesen.
Jeder Datensatz ist kryptografisch an seine Domain gebunden. Umgehängt auf eine andere Domain, scheitert die Entschlüsselung.
Für einen Scan wird der Chiffretext an den Auftrag gehängt. Der Scan-Server entschlüsselt ihn und übergibt die Zugangsdaten dem Prüf-Container nur über die Standardeingabe, nie als Aufrufparameter, der in Prozesslisten sichtbar wäre. Sobald der Scan-Server ihn gelesen hat, wird der Chiffretext am Auftrag gelöscht; Reste räumt ein Lauf nach spätestens einer Stunde ab.
Die Zugangsdaten werden nie angezeigt, nie protokolliert, nie über die Schnittstelle ausgegeben und nicht exportiert. Die Oberfläche zeigt nur das erste Zeichen und die Länge des Benutzernamens. Das Entfernen überschreibt den Chiffretext.
Hinter dem Login liest der Scanner nur: kein Absenden, kein aktiver Test, keine Bildschirmfotos, keine Seiten zum Abmelden, Löschen oder Kündigen.

4.2 Weitere Verschlüsselung und Hashes

Passwörter, Wiederherstellungscodes, Passwörter von Kundenportalen, API-Schlüssel, Verbindungs- und Rollout-Codes, Merkmale für „Angemeldet bleiben“, Sitzungskennungen in der Geräteliste sowie Links zur Bestätigung und zum Zurücksetzen werden nur als Hash gespeichert.
Geheimnisse für den zweiten Faktor werden verschlüsselt gespeichert (Abschnitt 3.2).
Eine Verschlüsselung der gesamten Datenbank im Ruhezustand behaupten wir nicht. Geschützt sind die empfindlichen Werte einzeln, wie oben beschrieben.

4.3 Datensparsamkeit nach Bauart

Zustellungsprüfung: Gelesen werden nur die Kopfzeilen und höchstens die ersten 8 KB des Textes. In der Datenbank landen nur Zeitpunkt, Zuordnung, gegebenenfalls die Kennung der Test-Einsendung und das Ergebnis der Echtheitsprüfung (SPF, DKIM, DMARC), nie der Inhalt oder eine vollständige Absenderadresse. Das Echtheitsergebnis der jeweils letzten Mail steht an der Domain und wird von der nächsten überschrieben; es enthält die IP-Adresse des einliefernden Mailservers und die E-Mail-Domain des Absenders. Die Mail wird nach erfolgreicher Verarbeitung aus dem Postfach gelöscht; scheitert der Abruf oder die Löschung, geschieht das mit dem nächsten erfolgreichen Lauf.
Prüfungen: Gespeichert wird der Aufbau der Formulare mit Feldnamen, -typen und Beschriftungen, Pflicht- und Sichtbarkeitsmerkmal, keine Werte; die Anfänge vorbelegter versteckter Felder (bis 24 Zeichen) und von data-Attributen (bis 60 Zeichen) liest der Scanner nur während der Prüfung und speichert sie nicht. Die Bildschirmfotos der vollen Prüfung werden nicht geschwärzt; nur die Browserprüfungen decken Eingabefelder ab. Empfängeradressen von Formularen werden nur als Domain gespeichert. Aktive Test-Einsendungen enthalten nur gekennzeichnete Testtexte ohne Personendaten.
Erweiterungen für WordPress und TYPO3 übermitteln nur Tageszahlen und Merkmale wie das Plugin-Inventar, beim verbundenen WordPress-Plugin für den Schwarmschutz (ab Werk an) außerdem die Domains von Links aus abgewehrten Nachrichten; keine weiteren Inhalte, keine Namen, Adressen oder IP-Adressen von Besuchern. Optionale Formular- und Feldfehlerzahlen sind ab Werk ausgeschaltet.
„Fix it for me“: Der eingefügte Code wird nur für die Dauer der Anfrage verarbeitet und nicht gespeichert.
Siegel: Das Siegelbild auf Kundenseiten setzt kein Cookie und startet keine Sitzung.
Betriebsmeldungen an das Telefon des Betreibers sind feste Texte ohne Variable, also ohne Namen, Adressen oder Inhalte. Fehlermeldungen per Mail an den Betreiber enthalten den Rohtext der Fehlermeldung, nicht bereinigt und gekürzt auf 400 Zeichen; er kann im Einzelfall Adressen oder Links enthalten.
Schwarmschutz: Zwischen den Erweiterungen der Kunden werden nur Domains von Links aus abgewehrtem Spam geteilt; der Austausch von IP-Netzen ist ausgeschaltet.
Standort: Das Land einer IP-Adresse wird aus einer lokalen Datenbankdatei bestimmt; an einen Geodienst geht keine Adresse.

5. Schutz vor Missbrauch des Scanners

Der Scanner lädt fremde Seiten mit einem echten Browser. Ohne Schutz wäre er ein Werkzeug, mit dem jemand von außen unser internes Netz oder andere nicht öffentliche Ziele ansprechen könnte (Server-Side Request Forgery). Deshalb gibt es zwei unabhängige Schichten und eine Abschottung jedes einzelnen Laufs.

5.1 Abgeschotteter Lauf

Jede Prüfung läuft in einem eigenen Container, der danach entfernt wird. Er läuft ohne Administratorrechte, ohne zusätzliche Fähigkeiten des Betriebssystems und ohne die Möglichkeit, Rechte zu erweitern. Sein Dateisystem ist schreibgeschützt bis auf kleine flüchtige Bereiche.
Speicher, Zahl der Prozesse und Laufzeit sind begrenzt; ein Lauf, der die Zeit überschreitet, wird beendet.

5.2 Netz: zwei Schichten

Erste Schicht, im Scanner: Vor dem Scan und dann für jede einzelne Anfrage des Browsers, auch für Umleitungen und eingebettete Inhalte, wird geprüft, wohin die Adresse aufgelöst wird. Private, lokale, reservierte und Dokumentationsnetze (IPv4 und IPv6) werden abgewiesen, ebenso andere Ports als die für Web üblichen. Service Worker lässt der Browser nicht zu, und WebSocket-Verbindungen werden geschlossen, weil beide an dieser Prüfung vorbeiführen könnten.
Zweite Schicht, im Netz: Die Container laufen in einem eigenen Netz. Firewall-Regeln erlauben von dort ins Internet nur Verbindungen zu Web-Ports; Verbindungen in private Netze, also auch in unser internes Netz mit Webserver und Datenbank, sind gesperrt. Ausnahmen, die der Prüflauf selbst braucht, sind auf das Nötige beschränkt und in unseren internen Unterlagen beschrieben. Diese Schicht greift auch, wenn ein Name erst nach der ersten Prüfung anders aufgelöst wird.

5.3 Abrufe durch den Webserver

Wo der Webserver selbst fremde Adressen abruft, beim Nachweis der Domain, beim Header-Werkzeug, bei der Suche nach offen liegenden Dateien, bei Puls-Abrufen, bei RDAP-Abfragen und bei der Prüfung von Zertifikaten, bei Webhooks und Chat-Alarmen und bei der optionalen zweiten Prüfstelle, gelten dieselben Regeln: nur Web-Protokolle auf den üblichen Web-Ports (Webhooks und Chat-Alarme nur über HTTPS auf dem Standard-Port), nur öffentliche Adressen, Verbindung nur zu genau der zuvor geprüften Adresse, damit ein Name nicht nachträglich auf ein internes Ziel umgelenkt werden kann, Weiterleitungen entweder gar nicht oder nur von Hand verfolgt und jeweils neu geprüft, kurze Zeitlimits; beim Nachweis der Domain, bei Puls-Abrufen und bei der zweiten Prüfstelle für Browserprüfungen auch eine begrenzte Antwortgröße.

5.4 Was der Scanner auf fremden Seiten nicht tut

Aktive Test-Einsendungen (höchstens fünf je Prüfung) gibt es für Kunden nur für Domains, deren Verfügungsbefugnis nachgewiesen ist (DNS, Meta-Tag, Datei oder Erweiterung); ausgenommen sind nur interne Prüfungen unserer eigenen Test- und Demodomains. Der Hostname einer nachgewiesenen Domain lässt sich nicht ändern, damit der Nachweis nicht auf einen anderen Host übergeht. Alles andere ist passiv: Seiten lesen wie ein Besucher.
Browserprüfungen gehen bis vor das Absenden und lösen keine Bestellung, Zahlung oder Einsendung aus.
Domains auf der Opt-out-Liste werden nicht geprüft; eine laufende Überwachung endet mit der nächsten fälligen Prüfung.

6. Integrität: Weitergabe und Eingabe

6.1 Transport

Die Anwendung ist aus dem Internet nur über HTTPS erreichbar; der Browser wird angewiesen, für ein Jahr nur HTTPS zu verwenden (HSTS). Zertifikate werden automatisch erneuert.
Weitere Kopfzeilen beschränken das Einbetten der Anwendung in fremde Seiten, das Erraten von Dateitypen und das Absenden von Formularen an fremde Ziele. Eine Content-Security-Policy lässt in der Anwendung nur Skripte laufen, die der Server mit der jeweiligen Antwort freigibt; eingeschleuste Skripte und Ereignis-Handler im HTML führen aktuelle Browser nicht aus.
Das Postfach der Zustellungsprüfung wird über eine verschlüsselte Verbindung mit Prüfung des Zertifikats abgerufen.
Webhooks können mit einem Geheimnis des Kunden signiert werden (HMAC-SHA256 mit Zeitstempel), damit der Empfänger Herkunft und Unverfälschtheit prüfen kann. Anfragen an die optionale zweite Prüfstelle sind signiert, bei Browserprüfungen auch deren Antworten.
Offen benannt: Verbindungen innerhalb unseres internen Netzes sind nicht durchgehend verschlüsselt. Die Zugangsdaten für den Scan hinter dem Login bleiben dabei durchgehend verschlüsselt (Abschnitt 4.1).

6.2 Eingabekontrolle und Protokolle

Wichtige Handlungen in Konten und Arbeitsbereichen (etwa Anmeldung, Änderungen an Domains, Alarmzielen und Rechten, Löschungen, Support-Zugriffe) werden mit Konto, Zeitpunkt, IP-Adresse und Land im Aktivitätsprotokoll festgehalten und nach 365 Tagen gelöscht.
Seitenaufrufe werden zur Sicherheit und Missbrauchsabwehr nach 60 Tagen gelöscht, Fehlerprotokolle nach 90 Tagen, Inhalte versendeter Mails nach 30 Tagen. Zugangskennungen in aufgerufenen Adressen und Herkunftsseiten, etwa von Report- oder Portal-Links, stehen im Protokoll der Seitenaufrufe nur unkenntlich gemacht.
Die Annahme der Vertragsunterlagen wird mit der angezeigten Fassung, ihrem Prüfwert, Zeitpunkt, IP-Adresse und Browserkennung gespeichert.
Nachweis-Protokolle können mit einem Zeitstempel einer externen Zeitstempelstelle versehen werden; an sie geht nur ein Prüfwert des Inhalts, nicht der Inhalt selbst.

7. Verfügbarkeit und Belastbarkeit

7.1 Sicherung

Die Datenbank wird jede Nacht gesichert. Eine Sicherung erhält ihren endgültigen Namen erst, nachdem ihr Inhalt geprüft ist: erfolgreicher Abschluss des Sicherungsprogramms, mindestens ein Datensatz, so viele Tabellen wie die Datenbank hat, und die Schlusszeile eines vollständigen Laufs. Ältere Sicherungen werden erst nach einer gelungenen neuen entfernt.
Jede Sicherung wird nach 14 Tagen gelöscht. Der Ablageort liegt außerhalb jedes ausgelieferten Verzeichnisses; ein Ort innerhalb des Projekts wird abgewiesen.
Wiederherstellungsprobe: Einmal in der Woche wird die neueste Sicherung in eine Wegwerf-Datenbank eingespielt, Tabelle für Tabelle mit dem Betrieb verglichen und wieder gelöscht. Das Ergebnis wird gespeichert.
Scheitert eine Sicherung oder eine Probe, geht eine Meldung per Mail und auf das Telefon des Betreibers.
Wiederherstellung nach einem Zwischenfall: Fällt die Datenbank aus oder sind Daten beschädigt, spielen wir die neueste geprüfte Sicherung ein. Änderungen seit dieser Sicherung, in der Regel höchstens die eines Tages, können dabei verloren gehen; ist eine Sicherung gescheitert, entsprechend mehr. Danach führen wir bekannte spätere Löschaufträge erneut aus (Abschnitt 8). Eine bestimmte Wiederherstellungszeit sagen wir nicht zu.
Grenze, offen benannt: Die Sicherungen liegen derzeit am selben Standort wie die Datenbank und sind nicht gesondert verschlüsselt. Sie schützen vor Fehlbedienung, fehlerhaften Änderungen und beschädigten Daten, nicht vor dem Verlust des Servers selbst. Eine verschlüsselte Kopie an einem zweiten Ort ist geplant (Abschnitt 10).
Die Zugangsdaten für den Scan hinter dem Login sind in den Sicherungen nur als Chiffretext enthalten; das Geheimnis des zweiten Faktors nur verschlüsselt, mit einem Schlüssel außerhalb der Datenbank.

7.2 Überwachung

Ein Statuslauf prüft alle fünf Minuten die Komponenten des Dienstes, darunter Datenbank, Warteschlange und das Lebenszeichen des Scanners, das dieser auch im Leerlauf regelmäßig schreibt. Fällt eine Komponente aus, geht eine Meldung hinaus; erholt sie sich, eine Entwarnung.
Gegenwache: Ein Statuslauf kann den Ausfall des Rechners, auf dem er läuft, nicht melden. Deshalb prüft der Scan-Server jede Minute, ob die Anwendung antwortet, und meldet sich nach mehreren Fehlschlägen in Folge mit einem festen Text auf dem Telefon des Betreibers. Umgekehrt überwacht der Webserver das Lebenszeichen des Scanners; ob die Gegenwache läuft, zeigt die Einrichtungsliste an.
Fehleralarm: Eine Fehlerart, die es noch nie gab, meldet sich einmal sofort; bei einer Häufung von Fehlern geht nur ein einzelnes Signal auf das Telefon des Betreibers; einmal am Tag kommt eine Übersicht. Damit erfahren wir einen Fehler nicht erst vom Kunden.
Grenze, offen benannt: Beide Server stehen am selben Ort. Ein Ausfall des ganzen Standorts, etwa von Strom oder Internetanbindung, wird von keinem Melder gemeldet, sondern von einem Menschen bemerkt.

7.3 Änderungen und Auslieferung

Neue Fassungen werden zuerst in der getrennten Entwicklungsumgebung gebaut und erprobt. Die Auslieferung prüft alle Voraussetzungen, bevor die erste Datei geschrieben wird, führt die Änderungen am Datenbankschema aus und lässt laufende Prüfungen geordnet zu Ende laufen, bevor der Scanner neu startet.
Für den Weg eines neuen Kunden gibt es einen Rauchtest über echtes HTTP, der nach Umstellungen ausgeführt wird. Eine automatische Testreihe vor jeder einzelnen Auslieferung behaupten wir nicht.

8. Löschung und Fristen

Ein Löschlauf jede Nacht hält die Fristen ein, die die Datenschutzerklärung und der Auftragsverarbeitungsvertrag nennen. Er liest dieselben Einstellungen, aus denen die Zahlen in den Texten stammen; für diese Fristen laufen Text und Verhalten deshalb nicht auseinander.
Prüfergebnisse samt Bildschirmfotos werden nach 13 Monaten gelöscht (die letzte je Domain bleibt), Zahlen der Erweiterungen nach 13 Monaten, Versandprotokolle der Alarme nach 90 Tagen, Supportanfragen nach 24 Monaten.
Das Entfernen einer Domain löscht die Daten der Domain, darunter Prüfungen, Formulare, Befunde, Bildschirmfotos, Berichte, Aufträge, Alarmziele und -protokolle, Vorfälle, Zustellungsdaten, Zugangsdaten für den Scan hinter dem Login und Nachweise.
Die Löschung eines Kontos geschieht sofort; Arbeitsbereiche ohne weitere Mitglieder werden mit ihren Daten gelöscht, Arbeitsbereiche mit weiteren Mitgliedern gehen auf ein anderes Mitglied über, zuerst auf Administratoren, unter ihnen auf das dienstälteste. Bis zum Ablauf ihrer eigenen Frist bleiben die Protokolle, deren Einträge die alte Kontonummer behalten, die auf kein bestehendes Konto mehr verweist, darunter der Eintrag der Löschung, außerdem versandte E-Mails, der Nachweis des Vertragsschlusses, Supportanfragen, Reports von Interessenten-Prüfungen (bis zu 90 Tage) und Rechnungsdaten bei Stripe; Einzelheiten stehen in der Datenschutzerklärung.
In Sicherungen bleiben gelöschte Daten bis zu deren Ablauf nach 14 Tagen. Eine gezielte Löschung in einer Sicherung findet nicht statt; wird eine Sicherung zurückgespielt, werden bekannte spätere Löschaufträge von Hand erneut ausgeführt.

9. Organisation und Überprüfung

Personen: Den Dienst betreibt derzeit der Inhaber selbst. Weitere Personen erhalten Zugang nur nach Verpflichtung zur Vertraulichkeit und nur im nötigen Umfang, und sie verarbeiten Daten nur auf unsere Anweisung (Art. 29 und Art. 32 Abs. 4 DSGVO).
Unterauftragsverarbeiter: Wir setzen sie nur nach Prüfung ihrer Garantien und mit einem Vertrag nach Art. 28 Abs. 4 DSGVO ein und führen sie auf der Seite Unterauftragsverarbeiter; Einzelheiten regelt der Auftragsverarbeitungsvertrag.
Datenpannen: Betrifft eine Verletzung des Schutzes personenbezogener Daten Auftragsdaten, melden wir sie dem Kunden unverzüglich, möglichst innerhalb von 48 Stunden; Einzelheiten regelt der Auftragsverarbeitungsvertrag.
Meldestelle für Sicherheitslücken: Hinweise nehmen wir unter Sicherheit und über die Datei /.well-known/security.txt entgegen.
Einrichtungs- und Launch-Liste: Im Verwaltungsbereich misst eine Liste den Stand sicherheitsrelevanter Einstellungen, etwa Sicherung, Verwalter ohne zweiten Faktor, Mail-Einrichtung und Lebenszeichen, und zeigt Abweichungen an.
Überprüfung dieser Maßnahmen (Art. 32 Abs. 1 Buchst. d DSGVO): bei jeder wesentlichen Änderung des Dienstes, nach jedem Sicherheitsvorfall und im Übrigen mindestens einmal im Jahr. Wir bewerten dabei, ob die Maßnahmen wirken und den Risiken noch entsprechen, und halten das Ergebnis mit einer neuen Fassung dieser Seite oder, wenn sich nichts ändert, mit dem Datum der Überprüfung in Abschnitt 11 fest. Laufend misst die Einrichtungs- und Launch-Liste den Stand der dort erfassten Einstellungen.
Externe Prüfungen: Externe Penetrationstests sind derzeit nicht beauftragt, und es bestehen keine Sicherheitszertifizierungen. Das steht hier, damit niemand sie voraussetzt.

10. Geplant, noch nicht umgesetzt

Diese Punkte sind keine zugesagten Maßnahmen, bis sie hier in einer neuen Fassung als umgesetzt stehen:

Sicherung an einem zweiten Ort: eine verschlüsselte Kopie der nächtlichen Sicherung außerhalb des Servers, damit auch ein Totalverlust des Servers nicht zum Datenverlust führt.
Zweite Prüfstelle: Die unabhängige Bestätigung von Browserprüfungen von einem zweiten Standort ist im Dienst vorbereitet, aber nicht eingerichtet. Ohne sie gibt es keine Bestätigung von einem zweiten Ort.
Härtung der Serververwaltung: Sie wird fortgesetzt. Einzelheiten nennen wir aus den in Abschnitt 1 genannten Gründen nicht öffentlich.

11. Stand und Fassung

Fassung 1.1 · Stand: 22. Oktober 2026 · bei Abweichungen zwischen den Sprachfassungen ist statt der deutschen die polnische Fassung maßgeblich; sonst keine Änderung.
Fassung 1.0 · Stand: 11. Oktober 2026 · erste Fassung als eigene Seite; bisher Anlage 2 im Auftragsverarbeitungsvertrag. Gegenüber der bisherigen Anlage berichtigt: Die Wiederherstellungsprobe läuft wöchentlich, die Sicherungen liegen auf demselben Server, eine automatische Testreihe vor jeder Auslieferung findet nicht statt, Verbindungen im internen Netz sind nicht durchgehend verschlüsselt. Neu beschrieben: Verschlüsselung der Zugangsdaten für den Scan hinter dem Login, Abschottung des Scanners, Gegenwache und Fehleralarm.
Änderungen werden mit neuer Fassungsnummer hier und in der Übersicht Änderungen der Vertragsunterlagen veröffentlicht; für Abschwächungen gilt die Ankündigungsfrist des Auftragsverarbeitungsvertrags.
Bei Abweichungen zwischen den Sprachfassungen ist die polnische Fassung maßgeblich.

Wie können wir helfen?