Stand: 28.5.2026 · Thema: Dokumentation · DSGVO Art. 32

TOM-Beschreibung nach Art. 32 DSGVO

Die TOM-Beschreibung ist die operative Übersetzung Ihrer Sicherheitsmaßnahmen in einen prüffähigen Text. Sie dient zwei Zwecken: dem internen Steuern (was haben wir, was fehlt?) und dem externen Nachweis (gegenüber Auftraggebern, Aufsicht, Versicherung).

Aufbau

Teil 1 — Stammteil

Geltungsbereich (welche Standorte, welche Anwendungen).
Verantwortlichkeiten (Datenschutz, IT-Sicherheit, IT-Operations).
Stand und Revision (Versionsdatum, nächste planmäßige Überprüfung).

Teil 2 — Schutzziele

Strukturiert entlang der vier Schutzziele aus Art. 32 Abs. 1 lit. b:

Vertraulichkeit (Zutritt, Zugang, Zugriff, Trennung, Verschlüsselung, Pseudonymisierung)
Integrität (Weitergabe, Eingabe, Manipulationserkennung)
Verfügbarkeit und Belastbarkeit (Backup, Restore, Redundanz, USV)
Verfahren zur regelmäßigen Überprüfung (Audits, Penetrationstests, Notfallübungen)

Je Schutzziel: konkrete Maßnahmen + Verantwortlichkeit + Nachweis.

Teil 3 — Ergänzende Verfahren

Incident-Response-Plan (wer wird wann informiert).
Datenschutz-Folgenabschätzung für riskante Verarbeitungen.
Schulungs- und Awareness-Konzept.

Konkretheitsanforderung

Die Aufsicht akzeptiert keine pauschalen Aussagen. Jede Maßnahme braucht:

Was wird gemacht (konkret).
Wie wird es technisch/organisatorisch umgesetzt.
Wer ist verantwortlich.
Wann/Wie oft (Frequenz oder Trigger).
Wo ist der Nachweis (Pfad zum Wiki-Artikel, Ticket-Nummer, Audit-Report).

Beispiel:

Maßnahme: Quartalsweise Berechtigungsreview aller Admin-Accounts. Umsetzung: SQL-Script generiert die Liste aller Accounts mit Rolle admin oder höher; CTO und Geschäftsführung prüfen, dokumentieren Freigabe im Wiki. Verantwortlich: CTO. Frequenz: quartalsweise (Q1: Januar, Q2: April, …). Nachweis: Confluence-Seite „Berechtigungsreview Admin-Accounts”.

Die fünf häufigsten Audit-Lücken

Restore-Tests sind nie dokumentiert. Backup wird täglich gemacht, aber niemand hat in den letzten 12 Monaten geprüft, ob Restore tatsächlich funktioniert.
Berechtigungen werden nie reviewed. Personen, die längst nicht mehr im Unternehmen sind, haben aktive Accounts.
Datenträgervernichtung ist nicht geregelt. Alte Laptops, USB-Sticks, defekte Festplatten — wer entsorgt wie?
Logging deckt Datenschutz-relevante Ereignisse nicht ab — oder Logs werden so kurz aufbewahrt, dass eine Forensik nicht möglich ist.
Mobile-Device-Management fehlt. Mitarbeiter haben Firmen-Mails und -Kalender auf privaten Smartphones ohne MDM.

Aktualisierungsturnus

Mindestens jährlich komplette Revision.
Anlassbezogen bei: neuem System, größerer Organisationsänderung, nach Datenpanne, nach Audit-Befund.
Versionsstand im Dokument.

Häufige Fehler

TOM = ISMS-Handbuch — die TOM ist die Kurzfassung mit Verweisen, nicht die Komplettdoku.
TOM und VVT widersprechen sich — z.B. VVT nennt eine Speicherdauer von 10 Jahren, TOM nennt das gelöschte System.
Keine Pflege nach Personalwechseln — alte Verantwortliche stehen noch drin.

Wenn wir DSB sind

Wir liefern eine TOM-Vorlage in zwei Größen (KMU-light und Mittelstand-voll), führen das jährliche Review als Workshop durch und dokumentieren die Anpassungen im Ticket-System.

Quelle: FS/CS GmbH