7 Anzeichen, dass Ihr Online-Formular-Builder nicht sicher für sensible Daten ist

Die meisten Formular-Builder sehen von außen ähnlich aus. Ein Drag-and-Drop-Editor, eine Veröffentlichungsschaltfläche, E-Mail-Benachrichtigungen bei Einreichung. Nichts in dieser Benutzeroberfläche zeigt Ihnen, ob die Daten verschlüsselt sind, wer darauf zugreifen kann oder wohin sie nach der Erfassung gehen.

Sicherheitsfehler in Formular-Buildern sind selten sichtbar, bevor sie zu einem Problem werden. Sie erscheinen in Verletzungsbenachrichtigungen, Compliance-Prüfungen oder Anfragen von Nutzern, die wissen möchten, was mit ihren Daten passiert ist.

Die Warnzeichen sind jedoch meist im Voraus sichtbar. In der Dokumentation, in den Funktionssets und in den Antworten auf spezifische Fragen. Dieser Artikel behandelt sieben davon.

Dieser Artikel dient nur zu Informationszwecken und stellt keine Rechtsberatung dar. Konsultieren Sie einen qualifizierten Datenschutzexperten für spezifische Anleitungen für Ihre Organisation.

Zeichen 1: Kein Datenverarbeitungsvertrag verfügbar

Ein Datenverarbeitungsvertrag (DPA) ist ein rechtsverbindlicher Vertrag zwischen der Organisation, die Daten sammelt (der Verantwortliche), und der Plattform, die sie verarbeitet (der Auftragsverarbeiter). Wo die DSGVO gilt und ein Verantwortlicher einen Drittanbieter-Auftragsverarbeiter einsetzt, verlangt Artikel 28 einen konformen Datenverarbeitungsvertrag, bevor der Auftragsverarbeiter personenbezogene Daten im Auftrag des Verantwortlichen verarbeitet.

Der Vertrag muss mindestens definieren: den Gegenstand und die Dauer der Verarbeitung, die Art der Daten und die Kategorien der betroffenen Personen, die Anweisungen des Verantwortlichen an den Auftragsverarbeiter, Sicherheitsverpflichtungen, Offenlegung von Unterauftragsverarbeitern, Verfahren zur Bearbeitung von Anfragen zu Betroffenenrechten, Zeitpläne für Verletzungsbenachrichtigungen und Datenlöschung oder -rückgabe bei Vertragsbeendigung.

Dies ist kein Kontrollkästchen. Artikel 28(3) spezifiziert jedes dieser Elemente ausdrücklich. Eine Datenschutzerklärung ist kein DPA. Nutzungsbedingungen sind kein DPA. Ein DPA ist ein separates, bilaterales Instrument, das von beiden Parteien unterzeichnet wird.

Das Zeichen: Die Website des Formular-Builders hat kein herunterladbares DPA. Die Suche nach „DPA“ oder „Datenverarbeitungsvertrag“ liefert nichts oder leitet zu einer allgemeinen Datenschutzerklärung weiter.

Was das in der Praxis bedeutet: Ohne ein unterzeichnetes DPA führt die Nutzung der Plattform zur Erfassung personenbezogener Daten von Einzelpersonen in der EU zu rechtlichen Risiken für Ihre Organisation, nicht für die Plattform. Unter der DSGVO trägt der Verantwortliche (Sie) die primäre Verantwortung dafür, dass ein Artikel 28-konformer Vertrag vorliegt. Das Fehlen eines Artikel 28-konformen Verarbeitungsvertrags ist an sich ein Compliance-Problem, unabhängig davon, ob eine Verletzung personenbezogener Daten auftritt.

Ähnliche Verantwortlichkeitsprinzipien existieren unter anderen Datenschutzrahmen. CCPA/CPRA, Brasiliens LGPD und Kanadas PIPEDA erwarten alle, dass Organisationen geeignete vertragliche Schutzmaßnahmen beim Einsatz von Drittanbietern ergreifen, obwohl die rechtlichen Mechanismen sich von Artikel 28 der DSGVO unterscheiden.

Worauf zu achten ist: Ein öffentlich zugängliches, herunterladbares DPA, das ohne Unternehmensverhandlungen unterzeichnet werden kann. Für Organisationen unter der DSGVO sollte das DPA auch Unterauftragsverarbeiter ansprechen, also die Drittanbieter, auf die der Formular-Builder selbst für Infrastruktur, Speicherung oder Verarbeitung angewiesen ist. Ein Trust Center des Anbieters ist normalerweise der richtige Ort, um diese Dokumentation zu finden. Für eine vollständige DSGVO-Implementierungsliste siehe DSGVO-Compliance für Online-Formulare: Eine praktische Checkliste.

Zeichen 2: Drittanbieter-Skripte laufen auf Formularseiten ohne Offenlegung

Wenn ein Nutzer Ihr Formular öffnet, teilt er möglicherweise seine Daten mit mehr als nur Ihnen.

Die meisten Webanwendungen, einschließlich Formular-Builder, laden Drittanbieter-JavaScript für Analysen, Werbung, Sitzungsaufzeichnung, Fehlerüberwachung und A/B-Tests. Einige dieser Skripte haben Zugriff auf Formularfeldwerte, während Nutzer tippen. Das bedeutet, dass ein Name, eine E-Mail-Adresse oder eine Telefonnummer das Gerät des Nutzers verlassen kann, bevor er auf „Absenden“ geklickt hat.

Dies ist ein dokumentiertes Verhalten. Eine Studie von 2022 von Forschern der Radboud University, KU Leuven und der Universität Lausanne mit dem Titel „Leaky Forms: A Study of Email and Password Exfiltration Before Form Submission“ fand heraus, dass 1.844 Websites in einer Stichprobe von 100.000 Benutzer-E-Mail-Adressen vor der Formulareinreichung über Drittanbieter-Tracking-Skripte sammelten, ohne Zustimmung der Nutzer. Die Daten wurden stillschweigend exfiltriert, bevor ein Einreichungsereignis stattfand.

Der Mechanismus ist einfach: Analyse- und Marketing-Skripte hängen Ereignislistener an Eingabefelder an und übertragen den Inhalt an entfernte Sammlungspunkte. Der Formular-Builder selbst beabsichtigt möglicherweise nicht dieses Verhalten, aber wenn Drittanbieter-Skripte auf derselben Seite geladen werden, fließen die Daten trotzdem zu ihnen.

Das Zeichen: Der Formular-Builder dokumentiert nicht, welche Drittanbieter-Skripte auf veröffentlichten Formularseiten laufen. Ihre Datenschutzerklärung beschreibt ihre eigene Datenerfassung, nicht das Erfassungsverhalten der Skripte, die auf Ihren Formularen laufen.

Was das in der Praxis bedeutet: Wenn Ihr Formular ein Drittanbieter-Analyse-Pixel oder ein Sitzungsaufzeichnungstool lädt, können die Daten, die Ihre Nutzer eingeben, ohne Zustimmung an diesen Drittanbieter übertragen werden. Dies beeinflusst die Genauigkeit Ihrer Datenschutzerklärung, Ihre DSGVO-Compliance (rechtmäßige Grundlage für die Verarbeitung) und in Gesundheitskontexten möglicherweise Ihre HIPAA-Verpflichtungen.

Worauf zu achten ist: Explizite Dokumentation der Skripte, die auf veröffentlichten Formularseiten geladen werden. Eine Plattform, die mit sensiblen Daten umgeht, sollte genau angeben können, welche Dienste Daten aus Formulareinreichungen erhalten und in welcher Form. Formulare, die auf isolierten, erstparteiigen Domains ohne Werbe- oder Analyse-Skripte bereitgestellt werden, sind die stärkste Lösung.

Zeichen 3: Verschlüsselungsansprüche sind vage oder fehlen

„Ihre Daten sind sicher“ ist eine Marketingaussage. Sie beschreibt keine technische Kontrolle. Zwei spezifische Ansprüche sind für Formulardaten wichtig:

Verschlüsselung während der Übertragung bedeutet, dass Daten verschlüsselt sind, während sie zwischen dem Browser des Nutzers und dem Server übertragen werden. Der aktuelle Standard ist TLS 1.2 oder höher. Dies ist weitgehend Standard im Web, sollte aber explizit mit der Protokollversion angegeben werden.

Verschlüsselung im Ruhezustand bedeutet, dass gespeicherte Daten — Formulareinreichungen, die in einer Datenbank liegen — verschlüsselt sind. Der aktuelle Standard für sensible Daten ist AES-256. Hier unterscheiden sich Plattformen. Einige verschlüsseln Einreichungsdaten im Ruhezustand, viele nicht. Eine Plattform kann eine hervorragende Verschlüsselung während der Übertragung haben, während Ihre Daten im Klartext gespeichert werden.

Der Unterschied ist wichtig, da die Bedrohungsmodelle unterschiedlich sind. Verschlüsselung während der Übertragung schützt vor Abfangen während der Übertragung. Verschlüsselung im Ruhezustand schützt vor unbefugtem Zugriff auf gespeicherte Daten, was die relevante Bedrohung in den meisten Verletzungsszenarien ist. Laut IBMs 2025 Cost of a Data Breach Report dauert es im Durchschnitt 158 Tage, um eine Verletzung zu identifizieren und 83 Tage, um sie einzudämmen — ein gesamter Lebenszyklus von 241 Tagen, der niedrigste in neun Jahren, laut IBM Security. Während dieses Zeitraums sind gespeicherte Daten die primäre Exposition.

OWASPs Top 10 (2025) listet „Kryptografische Fehler“ als A04 — eines der kritischsten Sicherheitsrisiken für Webanwendungen — speziell einschließlich „Daten, die im Klartext gespeichert sind“ als primären Fehler.

Das Zeichen: Die Sicherheitsdokumentation der Plattform verwendet Phrasen wie „wir verwenden branchenübliche Sicherheit“, ohne den Verschlüsselungsalgorithmus, die Protokollversion oder den Abdeckungsbereich zu spezifizieren. Keine Erwähnung von AES-256 oder TLS 1.2+.

Was das in der Praxis bedeutet: Vage Verschlüsselungsansprüche bieten keine überprüfbare Sicherheit. Für regulierte Daten — Gesundheitswesen, Finanzen, Recht — ist Verschlüsselung im Ruhezustand häufig eine Compliance-Anforderung, keine Präferenz. HIPAA’s Sicherheitsregel (45 CFR § 164.312) behandelt Verschlüsselung ausdrücklich als „adressierbare“ Schutzmaßnahme, was bedeutet, dass betroffene Einrichtungen sie entweder implementieren oder dokumentieren müssen, warum eine gleichwertige Alternative denselben Schutz bietet.

Worauf zu achten ist: Eine klare, technische Aussage: „Einreichungsdaten werden im Ruhezustand mit AES-256 und während der Übertragung mit TLS 1.2+ verschlüsselt.“ Wenn dies nicht in öffentlichen Dokumentationen gefunden werden kann — typischerweise in einem Trust Center oder auf der Sicherheitsseite eines Anbieters — fragen Sie direkt nach. Eine Plattform, die mit sensiblen Daten umgeht, sollte ohne Zweideutigkeit antworten können. Für eine vollständige Aufschlüsselung, wie der Sicherheitsstack aussehen sollte, siehe Datensicherheit für Online-Formulare: Was jedes Unternehmen wissen sollte.

Zeichen 4: Keine konfigurierbare Datenaufbewahrung

Wie lange speichert die Plattform Ihre Einreichungsdaten? Wenn die Antwort „unbegrenzt, es sei denn, Sie löschen sie manuell“ lautet, ist das ein Problem.

Das Speicherbegrenzungsprinzip der DSGVO (Artikel 5(1)(e)) verlangt, dass personenbezogene Daten „in einer Form aufbewahrt werden, die die Identifizierung der betroffenen Personen nicht länger ermöglicht, als es für die Zwecke, für die die personenbezogenen Daten verarbeitet werden, erforderlich ist.“ Das Speichern von Formulareinreichungen für immer — auch von vor Jahren — ist fast nie konform mit dieser Anforderung.

Es gibt auch ein praktisches Risiko: Je größer der Datensatz, den eine Plattform hält, desto wertvoller wird er als Ziel für einen Datenverstoß. Formulareinreichungen von vor drei Jahren, die noch auf einem Server liegen, sind weiterhin gefährdet. Automatisierte Löschung reduziert diese Exposition.

Verschiedene Workflows haben unterschiedliche legitime Aufbewahrungsbedürfnisse:

Das Zeichen: Die Plattform speichert Einreichungen standardmäßig unbegrenzt. Es gibt keine Einstellungen, um einen automatischen Löschplan zu konfigurieren. Die einzige Option ist die manuelle Löschung.

Was das in der Praxis bedeutet: Die Einhaltung von Datenaufbewahrungsanforderungen hängt von menschlichem Handeln ab. Automatisierte Richtlinien nicht. Eine Organisation, die sich auf Mitarbeiter verlässt, um alte Formulareinreichungen manuell zu löschen, wird irgendwann einen Löschzyklus verpassen — insbesondere während Personalwechsel oder in Hochphasen.

Worauf zu achten ist: Konfigurierbare Aufbewahrungsfristen auf Konto- oder Formularebene. Der Bereich sollte sowohl kurze Aufbewahrung (für hochgradig vertrauliche Workflows) als auch verlängerte Aufbewahrung (für compliance-erforderliche Aufbewahrung) ermöglichen. Optionen wie „sofort nach dem Export in die Cloud-Speicherung löschen“ stellen Best Practices für datenschutzkritische Workflows dar.

Zeichen 5: Kein Audit-Log für den Zugriff auf Einreichungen

Wenn eine Einreichung geöffnet wird, wer hat sie geöffnet? Wann? Hat jemand sie exportiert? Wurde sie über einen Link geteilt? Wurde sie gelöscht, und von wem?

In Abwesenheit eines Audit-Logs können keine dieser Fragen beantwortet werden. Dies schafft eine erhebliche Verantwortlichkeitslücke — eine, die in regulatorischen Audits, Anfragen zu Betroffenenrechten oder internen Untersuchungen sichtbar wird.

Die Sicherheitsregel von HIPAA behandelt dies ausdrücklich. Der Standard für Audit-Kontrollen (45 CFR § 164.312(b)) verlangt, dass betroffene Einrichtungen „Hardware-, Software- und/oder Verfahrensmechanismen implementieren, die Aktivitäten in Informationssystemen aufzeichnen und untersuchen, die elektronische geschützte Gesundheitsinformationen enthalten oder verwenden.“ Das Protokollieren, wer eine Einreichung angesehen hat und wann, ist eine direkte Umsetzung dieser Anforderung.

Über das Gesundheitswesen hinaus: Artikel 5(2) der DSGVO etabliert das Verantwortlichkeitsprinzip — Verantwortliche müssen in der Lage sein, die Einhaltung der Datenschutzgrundsätze nachzuweisen. Ein Audit-Log ist eine grundlegende Komponente dieses Nachweises. Ohne es ist „wir haben auf diese Daten nicht zugegriffen“ eine Behauptung, die Sie nicht verifizieren können.

OWASPs Top 10 (2025) umfasst „Fehler bei der Sicherheitsprotokollierung und -alarmierung“ (A09) als kritisches Risiko für Webanwendungen — speziell: „Auditable Ereignisse, wie Logins, fehlgeschlagene Logins und hochrangige Transaktionen, werden nicht protokolliert.“

Das Zeichen: Die Plattform hat kein Aktivitätsprotokoll. Administratoren können Einreichungen ansehen, aber nicht die Zugriffshistorie, Exporthistorie oder Freigabeaktivität.

Was das in der Praxis bedeutet: Sie können keine Fragen darüber beantworten, wer auf bestimmte Einreichungen zugegriffen hat. Wenn ein Betroffener sein Zugriffsrecht gemäß Artikel 15 der DSGVO ausübt, kann er Informationen über die Empfänger oder Kategorien von Empfängern anfordern, mit denen seine personenbezogenen Daten geteilt wurden — eine Frage, die ein Audit-Log hilft zu beantworten. Während Artikel 15 nicht verlangt, dass Verantwortliche Audit-Logs führen, können solche Logs erheblich dabei helfen, die Einhaltung nachzuweisen und genau auf Zugriffsanfragen zu reagieren.

Worauf zu achten ist: Ein teamweites Audit-Log, das für Administratoren zugänglich ist und mindestens aufzeichnet: Einreichungszugriffsereignisse, Exportereignisse, Erstellung von Freigabelinks und Löschereignisse. Logs sollten für einen Zeitraum aufbewahrt werden, der mit Ihren Compliance-Anforderungen übereinstimmt.

Zeichen 6: Kein BAA für den Einsatz im Gesundheitswesen verfügbar

In den Vereinigten Staaten ist jede Organisation, die geschützte Gesundheitsinformationen (PHI) im Auftrag einer betroffenen Einrichtung verarbeitet — einschließlich eines Formular-Builders, der Patientenaufnahmeformulare verarbeitet — rechtlich ein Business Associate gemäß HIPAA (45 CFR § 160.103).

Bevor PHI durch ein Drittanbieter-Tool fließt, muss ein unterzeichnetes Business Associate Agreement (BAA) vorliegen. Das BAA ist nicht nur eine Formalität: Es legt die Verpflichtungen des Business Associate in Bezug auf den Schutz von PHI, Zeitpläne für Verletzungsbenachrichtigungen und zulässige Datennutzungen fest. Ohne es trägt die betroffene Einrichtung die Haftung für HIPAA-Verstöße, die sich aus der Verarbeitung von PHI durch den Business Associate ergeben — unabhängig von den tatsächlichen Sicherheitskontrollen der Plattform.

Das OCR hat diese Anforderung konsequent durchgesetzt. Es wurden Vergleiche gegen Gesundheitsorganisationen erzielt, die nicht autorisierte Drittanbieter-Tools zur Verarbeitung von PHI verwendet haben, selbst in Abwesenheit eines Verstoßes. Die Verletzung ist das fehlende Abkommen, nicht der Verstoß.

Für die spezifischen technischen Schutzmaßnahmen, die HIPAA erfordert — die ein Formular-Builder implementieren muss, um ein BAA gültig zu unterzeichnen — siehe was HIPAA tatsächlich von Online-Formular-Tools verlangt.

Das Zeichen: Die Plattform bietet kein BAA an oder nur zu Unternehmenspreisklassen, die für die meisten Gesundheitsorganisationen unzugänglich sind. Kleine Kliniken, unabhängige Therapeuten und Gesundheits-Startups sammeln PHI ohne eine konforme Verarbeitungsbeziehung.

Was das in der Praxis bedeutet: Die Verwendung eines Formular-Builders ohne BAA zur Erfassung von Patientendaten — Aufnahmeformulare, Einwilligungsformulare, Terminanforderungen, Versicherungsdetails, die mit Gesundheitsinformationen verknüpft sind — ist ein HIPAA-Verstoß. Es ist kein Graubereich.

Worauf zu achten ist: Ein BAA, das auf einem mittleren Marktplan verfügbar ist, automatisch unterzeichnet (oder mit minimalem Aufwand), wenn der HIPAA-Modus aktiviert ist. Das unterzeichnete BAA sollte dem Kontoadministrator als Dokument übermittelt werden, das er aufbewahren und bei einer Prüfung vorlegen kann.

Zeichen 7: Einzelne Einreichungen können auf Anfrage nicht gelöscht werden

Artikel 17 der DSGVO etabliert das Recht auf Löschung. Wenn ein Betroffener die Löschung seiner personenbezogenen Daten verlangt, muss der Verantwortliche ohne unangemessene Verzögerung und in jedem Fall innerhalb eines Monats nachkommen — vorbehaltlich begrenzter Ausnahmen (rechtliche Verpflichtung, öffentliches Interesse usw.). Die Anfrage bezieht sich auf die Daten der spezifischen Person, nicht auf Massenarchive.

Dies schafft eine technische Anforderung: Sie müssen in der Lage sein, die Einreichung einer bestimmten Person zu identifizieren und sie sauber zu löschen. Viele Plattformen machen dies schwierig. Massenlöschung ist oft verfügbar; gezielte Suche und Löschung nach Teilnehmer ist es nicht.

Dasselbe Problem betrifft proaktive Compliance. Wenn Ihre Aufbewahrungsrichtlinie die Löschung nach 90 Tagen vorschreibt, müssen Sie die Plattform dazu bringen, dies auf der Datensatzebene durchzusetzen — nicht nur eine „Alles löschen“-Schaltfläche bereitzustellen, die alles löscht.

Das Zeichen: Die Einreichungsschnittstelle hat keine Suche nach Teilnehmerkennung (E-Mail, Name). Löschung ist nur in Massen möglich. Es gibt keine Möglichkeit, alle Einreichungen einer bestimmten Person über mehrere Formulare hinweg zu identifizieren.

Was das in der Praxis bedeutet: Wenn ein Nutzer eine Löschanfrage stellt — was ihm die DSGVO das Recht gibt zu tun — wird die Erfüllung zu einem manuellen, fehleranfälligen Prozess. Wenn Einreichungen mehrere Formulare oder Zeiträume umfassen, wird das Finden und Löschen aller relevanten Datensätze operativ schwierig.

Worauf zu achten ist: Einreichungssuche nach Feldwert, einschließlich E-Mail-Adresse, Name oder eines identifizierenden Feldes. Individuelle Datensatzlöschung aus der Einreichungsschnittstelle. Für Organisationen unter der DSGVO ist die Fähigkeit, eine formularübergreifende Abfrage nach Teilnehmer durchzuführen, wertvoll.

Eine Checkliste

Bevor Sie ein Formular veröffentlichen, das sensible Daten sammelt:

• Ein herunterladbares, unterzeichnungsfähiges DPA ist von der Plattform verfügbar
• Die Plattform dokumentiert, welche Drittanbieter-Skripte auf veröffentlichten Formularseiten laufen
• Verschlüsselung im Ruhezustand (AES-256) und während der Übertragung (TLS 1.2+) sind ausdrücklich angegeben
• Datenaufbewahrung ist konfigurierbar, mit automatischen Löschoptionen
• Ein Audit-Log zeichnet Einreichungszugriffs- und Exportereignisse auf
• Wenn PHI gesammelt wird, ist ein unterzeichnetes BAA vorhanden, bevor Daten gesammelt werden
• Einzelne Einreichungen können nach Teilnehmer gefunden und gelöscht werden

Referenzen

• Europäisches Parlament und Rat, DSGVO Artikel 28. Pflichten des Auftragsverarbeiters und Anforderungen an die DPA, gdpr-info.eu/art-28-gdpr/
• Europäisches Parlament und Rat, DSGVO Artikel 15. Auskunftsrecht der betroffenen Person, gdpr-info.eu/art-15-gdpr/
• Europäisches Parlament und Rat, DSGVO Artikel 17. Recht auf Löschung, gdpr-info.eu/art-17-gdpr/
• HHS Office for Civil Rights, 45 CFR § 160.103. Definitionen (Geschäftspartner), ecfr.gov
• HHS Office for Civil Rights, 45 CFR § 164.312. Technische Schutzmaßnahmen, ecfr.gov
• HHS Office for Civil Rights, Geschäftspartnerverträge, hhs.gov
• Acar, G. et al., Leaky Forms: Eine Studie über E-Mail- und Passwort-Exfiltration vor der Formularübermittlung, Radboud University / KU Leuven / Universität Lausanne, präsentiert auf der USENIX Security 2023
• OWASP, OWASP Top 10 2025, owasp.org/Top10, A04 Kryptografische Fehler; A09 Fehler bei der Sicherheitsprotokollierung und Alarmierung
• IBM Security, Kosten eines Datenverstoßberichts 2025, ibm.com/reports/data-breach, durchschnittlicher Lebenszyklus eines Verstoßes 241 Tage (158 zur Identifizierung, 83 zur Eindämmung)

Verwandte Lektüre: DSGVO-Compliance für Online-Formulare: Eine praktische Checkliste · HIPAA-konforme Online-Formulare: Ein Leitfaden für 2026 · Datensicherheit für Online-Formulare: Was jedes Unternehmen wissen sollte