DSGVO Stand der Technik: Was Artikel 32 verlangt

"Stand der Technik" ist einer der meistzitierten und am wenigsten verstandenen Begriffe der DSGVO. Er steht in Artikel 32 und verpflichtet Unternehmen, personenbezogene Daten technisch angemessen zu schützen. Was das konkret bedeutet, lässt der Text offen.

Dieser Artikel füllt diese Lücke. Mit den Mindeststandards, die Aufsichtsbehörden in der Praxis erwarten, und mit Hinweisen, woran ein Audit nach einem Vorfall scheitert.

Was Artikel 32 sagt

Artikel 32 DSGVO verlangt "unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung [...] geeignete technische und organisatorische Maßnahmen".

Dieser Satz wirkt unscharf. Tatsächlich ist er das gewollt. Der Gesetzgeber wollte nicht alle paar Jahre einen Katalog konkreter Technologien aktualisieren müssen.

In der Praxis hat sich aber ein klarer Erwartungshorizont gebildet. Aufsichtsbehörden, Gerichte und Branchenverbände orientieren sich an etablierten Standards wie BSI-Grundschutz, ISO 27001 oder den Richtlinien der ENISA. Wer diese Standards deutlich unterschreitet, hat ein Problem.

Mehr Kontext zum Begriff unter DSGVO-Compliance.

Aktuelle Software-Versionen

Der wichtigste Punkt zuerst. Eine Anwendung auf einer Sprachversion zu betreiben, für die es keine Sicherheits-Updates mehr gibt, gilt nicht als Stand der Technik. Punkt.

Konkret heißt das im Mai 2026:

• PHP: Mindestens 8.2, besser 8.3 oder höher. PHP 7 und früher sind End of Life.
• Node.js: Mindestens eine aktuelle LTS-Version. Ältere Linien erhalten keine Patches mehr.
• Python: 3.10 oder neuer. Python 2 ist seit Jahren tot.
• Java: LTS-Versionen wie 17 oder 21 werden noch unterstützt.
• Frameworks: Symfony, Laravel, Spring Boot, Django und vergleichbare müssen in unterstützten Versionen laufen.
• CMS: WordPress, Typo3, Joomla in aktuell gepflegten Hauptversionen.

Eine Aufsichtsbehörde, die nach einem Vorfall prüft, schaut sich genau diese Versionen an. Eine Antwort wie "Wir wollten upgraden, sind aber nicht dazugekommen" wirkt selten überzeugend.

Verschlüsselung in Transit und Ruhe

Daten müssen sowohl auf der Übertragung als auch in der Speicherung geschützt sein.

In Transit: HTTPS ist Pflicht, mit aktuellem TLS. Mindestens TLS 1.2, besser TLS 1.3. Veraltete Verfahren wie TLS 1.0 oder SSL gehören abgeschaltet. Zertifikate müssen gültig und automatisch erneuerbar sein.

At Rest: Datenbanken mit personenbezogenen Daten sollten verschlüsselt gespeichert sein. Backups gleichermaßen. Festplattenverschlüsselung auf Servern ist heute Standard.

Passwörter: Niemals im Klartext speichern. Auch nicht mit veralteten Verfahren wie MD5 oder SHA1. Aktuelle Standards sind bcrypt, Argon2 oder vergleichbare Verfahren mit ausreichend hohen Kostenfaktoren.

Wer Passwörter im Klartext findet oder schwache Hashes nutzt, hat im Auditfall keinen Verteidigungsspielraum.

Backups und Wiederherstellbarkeit

Backups gehören technisch zur Datenintegrität, die Artikel 32 ausdrücklich verlangt.

Drei Bedingungen müssen erfüllt sein.

Regelmäßigkeit. Tägliche Sicherungen sind bei den meisten Systemen Standard. Bei kritischen Systemen häufiger.

Trennung. Backups dürfen nicht auf demselben System liegen, das gesichert wird. Sonst zerstört ein Ransomware-Angriff beides. Eine Kopie an einem getrennten Ort, idealerweise offline oder mit Schreibschutz, ist Pflicht.

Wiederherstellung getestet. Ein nie geprüftes Backup ist kein Backup. Mindestens einmal pro Jahr sollte eine vollständige Wiederherstellung getestet werden.

Wer im Ernstfall feststellt, dass die Backups seit Monaten kaputt sind, hat einen kapitalen Fehler gemacht. Das passiert häufiger, als man denkt.

Zugriffskontrolle und Rechtevergabe

Personenbezogene Daten dürfen nur Personen erreichen, die sie für ihre Arbeit benötigen. Das nennt sich Need-to-know-Prinzip.

Mindeststandards sind:

• Personalisierte Zugänge statt geteilter Sammelkonten.
• Klare Rollen mit definierten Rechten.
• Regelmäßige Überprüfung, wer noch Zugriff braucht.
• Sperren von Konten beim Ausscheiden von Mitarbeitern, am besten am gleichen Tag.
• Zwei-Faktor-Authentifizierung für Administratoren und privilegierte Konten.

Ein gemeinsamer "admin"-Zugang mit Passwort, das alle kennen, ist heute nicht mehr verteidigbar. Wer das nutzt, kann im Vorfall nicht einmal nachweisen, wer was gemacht hat.

Audit-Logs: Wer hat wann was getan?

Logs sind die Geschichte einer Anwendung. Sie zeigen, wer wann auf welche Daten zugegriffen hat. Im Vorfall sind sie das wichtigste Beweismittel.

Sinnvoll protokolliert werden sollten:

• Anmeldungen und Anmeldefehler.
• Zugriffe auf besonders sensible Daten.
• Änderungen an Rechten und Konfigurationen.
• Datenexporte und Massenoperationen.

Wichtig: Logs müssen ausreichend lange aufbewahrt werden, oft mindestens sechs Monate. Und sie müssen vor Manipulation geschützt sein. Ein Angreifer, der seine Spuren löschen kann, hinterlässt ein Loch in der Beweiskette.

Gleichzeitig dürfen Logs nicht ihrerseits unnötig viele personenbezogene Daten enthalten. Eine Anmelde-ID ja, das volle Passwort nein.

Was eine Aufsichtsbehörde nach einem Vorfall prüft

Wir haben mit Mandanten verschiedener Branchen erlebt, was nach einem Datenleck konkret abgefragt wird. Die Liste ist ähnlich.

Welche Software-Versionen waren im Einsatz? Konkret, mit Versionsnummern und Patch-Stand.

Wann wurde das letzte Sicherheitsupdate eingespielt? Mit Datum und Beleg.

Gab es ein systematisches Monitoring von Sicherheitslücken? Welches Werkzeug, welcher Prozess?

Wie sind die Zugänge geregelt? Listen aller berechtigten Konten, Rollenmodell, letzte Überprüfung.

Gibt es Audit-Logs des Vorfalls? Aus welcher Quelle? Wie weit zurück?

Wie wurde der Vorfall entdeckt? Aktiv durch Monitoring oder passiv durch externe Meldung?

Welche Wiederherstellungspläne gab es? Wurden sie getestet?

Wer hier keine Antworten hat, hat über die Sorgfaltspflicht hinaus auch ein Dokumentationsproblem. Das beeinflusst die Höhe möglicher Bußgelder erheblich.

Praktische Mindeststandards

Aus all dem lassen sich konkrete Mindeststandards ableiten. Diese Liste ist nicht abschließend, deckt aber ab, was in den meisten Fällen erwartet wird.

• Software auf aktuell unterstützten Hauptversionen.
• Sicherheitsupdates innerhalb von wenigen Tagen bis Wochen eingespielt.
• HTTPS überall, mit aktuellem TLS.
• Passwörter mit modernen Hash-Verfahren gespeichert.
• Personalisierte Zugänge, Zwei-Faktor für Admins.
• Tägliche Backups, getrennt gelagert, getestet wiederhergestellt.
• Audit-Logs für kritische Aktionen, manipulationsgeschützt.
• Dokumentierter Notfallplan mit Verantwortlichkeiten.
• Jährliches Sicherheits-Audit für sensitive Systeme.

Mehr zur Umsetzung unter Sicherheits-Audit und Sicherheit & Härtung.

Fazit

"Stand der Technik" ist kein abstrakter Begriff, sondern eine konkrete Erwartungshaltung. Wer die etablierten Mindeststandards einhält, ist im Bedarfsfall verteidigungsfähig. Wer sie unterschreitet, läuft sehenden Auges in eine schwer entschuldbare Lage.

Die gute Nachricht: Die meisten dieser Standards sind technisch unspektakulär. Sie kosten kein Vermögen. Sie kosten Aufmerksamkeit und Routine. Genau das, was viele Systeme nicht bekommen, weil sie als "läuft doch" abgehakt sind.

Wenn Sie wissen wollen, wo Ihre Systeme im Vergleich zu diesen Standards stehen, machen wir einen Check. Jetzt Kontakt aufnehmen.