Themenseite · Art. 32 DSGVO

Technisch-organisatorische Maßnahmen (TOMs)

TOMs gehören zu den am häufigsten gestellten und am unsaubersten beantworteten Fragen im Datenschutz: Was muss konkret in eine TOM-Anlage zum Auftragsverarbeitungsvertrag? Welche Maßnahmen sind „angemessen"? Wie prüft man die TOMs eines Anbieters? Diese Seite gibt dazu eine strukturierte Antwort – auf Basis des Standard-Datenschutzmodells (SDM) v3.1a der DSK, des BSI-IT-Grundschutzes und der ISO/IEC 27001:2022.

Keine Rechtsberatung, kein Ersatz für Einzelfallprüfung: Diese Seite dient der fachlichen Orientierung und kann eine rechtsverbindliche Einzelfallbewertung nicht ersetzen. Sie stellt keine individuelle Rechtsberatung im Sinne des Rechtsdienstleistungsgesetzes (RDG) dar. Für konkrete Fragen wenden Sie sich bitte an die Landesbeauftragte für den Datenschutz Sachsen-Anhalt oder an eine auf Datenschutzrecht spezialisierte Rechtsanwaltskanzlei.

Persönliche fachliche Auffassung: Ich bin hauptberuflich als Datenschutzmanager an einer öffentlichen Hochschule in Sachsen-Anhalt tätig. Die hier veröffentlichten Inhalte geben ausschließlich meine persönliche fachliche Auffassung wieder und stellen keine offizielle Position meines Arbeitgebers dar.

Praxisbeispiele als didaktische Fallgruppen: Die auf dieser Seite enthaltenen Praxisbeispiele sind didaktische Fallgruppen zur Veranschaulichung typischer Konstellationen. Sie ersetzen keine Bewertung des konkreten Einzelfalls; abweichende Sachverhaltsmerkmale können zu einer anderen rechtlichen Würdigung führen.

Was sind TOMs?

Technisch-organisatorische Maßnahmen sind alle konkreten Vorkehrungen, die ein Verantwortlicher oder Auftragsverarbeiter trifft, um ein dem Risiko angemessenes Schutzniveau bei der Verarbeitung personenbezogener Daten zu gewährleisten. Pflichtgrundlage für die Auswahl und Umsetzung dieser Maßnahmen ist Art. 32 DSGVO. Erfasst sind sowohl technische Vorkehrungen (Verschlüsselung, Zugriffskontrollen, Backups, Protokollierung) als auch organisatorische Vorkehrungen (Verpflichtung auf Vertraulichkeit, Schulungen, Berechtigungskonzepte, Notfallpläne).

Wichtig: TOMs ersetzen keine Rechtsgrundlage. Eine Verarbeitung ist auch dann unzulässig, wenn sie technisch perfekt abgesichert ist, sofern keine wirksame Rechtsgrundlage nach Art. 6 DSGVO vorliegt. Art. 32 DSGVO ist seinerseits keine Rechtsgrundlage für eine Verarbeitung – die Norm regelt ausschließlich die Pflicht des Verantwortlichen, geeignete Sicherungsmaßnahmen zu treffen. Bei öffentlichen Hochschulen ergibt sich die Rechtsgrundlage der Verarbeitung regelmäßig aus Art. 6 Abs. 1 lit. e DSGVO in Verbindung mit einer landesrechtlichen Aufgabennorm. In Sachsen-Anhalt ist bei hochschulspezifischen Fachverfahren (Lehre, Studium, Prüfungen, Forschung, Mitgliederverwaltung) nach dem Grundsatz lex specialis derogat legi generali vorrangig zu prüfen, ob § 119 HSG LSA als speziellere Verarbeitungsnorm einschlägig ist, bevor auf § 4 DSAG LSA als Generalklausel zurückgegriffen wird. Für klassische Personalverwaltungsprozesse trägt § 119 HSG LSA dagegen nicht; hier gelten vorrangig die beamten-, tarif- und landesdatenschutzrechtlichen Spezialregelungen (siehe Themenseite Beschäftigtendatenschutz).

Annex-Theorie: Rechtsgrundlage für TOM-bedingte Verarbeitungen

TOM-bedingte Verarbeitungen wie etwa die Speicherung von Log-Dateien zur Sicherstellung der Revisibilität benötigen ihrerseits eine Rechtsgrundlage – Art. 32 DSGVO genügt dafür nicht. Nach der Aufsichtspraxis des Landesbeauftragten für den Datenschutz Sachsen-Anhalt (Stellungnahme gegenüber den Datenschutzbeauftragten der Hochschulen, Erfahrungsaustausch 2024) trägt die Rechtsgrundlage der Hauptverarbeitung im Regelfall auch die zu deren Sicherung erforderlichen Annex-Verarbeitungen.

Wörtlich: „Wenn die Hochschule im Rahmen der Aufgabenerfüllung nach dieser Vorschrift personenbezogene Daten verarbeitet, dürfte dies m. E. auch für die Daten gelten, die notwendig aufgrund der Vorgaben von Art. 32 DS-GVO zu Sicherungsmaßnahmen für die Verarbeitungen anfallen, wie z. B. Log-Dateien für das Sicherheitsziel der Revisibilität."

Praxiskonsequenz: Verarbeitet eine Hochschule personenbezogene Daten auf Grundlage von § 119 Abs. 1 HSG LSA – etwa für Zulassung, Immatrikulation, Rückmeldung oder Teilnahme an Lehrveranstaltungen und Prüfungen – deckt diese Norm im Regelfall auch die Log-Dateien ab, die zur Wahrung der Sicherheitsziele aus Art. 32 DSGVO erforderlich sind. Bestehen im Einzelfall Zweifel an der Tragfähigkeit, ist auf § 4 DSAG LSA als landesrechtliche Generalklausel zurückzugreifen.

Maßstab: Was ist „angemessen"?

Art. 32 Abs. 1 DSGVO verlangt Maßnahmen, die unter Berücksichtigung folgender vier Faktoren ein dem Risiko angemessenes Schutzniveau gewährleisten:

Faktor	Bedeutung in der Praxis
Stand der Technik	Technisch erprobte und am Markt verfügbare Maßnahmen, nicht zwingend das Neueste – aber auch nicht das Veraltete. Maßstab z. B. BSI TR-02102 für kryptografische Verfahren.
Implementierungskosten	Verhältnismäßigkeit von Aufwand und Schutzwirkung. Hohe Kosten entbinden nicht von Mindeststandards, rechtfertigen aber abgestufte Lösungen.
Art, Umfang, Umstände, Zweck	Großmenge sensibler Forschungsdaten erfordert mehr als ein Adressverzeichnis. Kontextspezifisch zu bewerten.
Risiko für die Rechte der Betroffenen	Eintrittswahrscheinlichkeit und Schwere möglicher Schäden. Maßstab insbesondere Erwägungsgründe 75, 76, 83 DSGVO.

Die Auswahl der TOMs ist also risikoorientiert, nicht schematisch. Eine standardisierte „TOM-Anlage von der Stange" ist datenschutzrechtlich angreifbar – ebenso wie eine maximalistische, wirtschaftlich unverhältnismäßige Lösung.

SDM v3.1a als Strukturrahmen: Die sieben Schutzziele

Das Standard-Datenschutzmodell (SDM) v3.1a der Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder (DSK) ist der in Deutschland von den Aufsichtsbehörden anerkannte methodische Rahmen für die Auswahl und Dokumentation von TOMs. Es strukturiert Maßnahmen nach sieben Schutzzielen, die deutlich über die klassische CIA-Triade hinausgehen:

Schutzziel	Was es bedeutet
Datenminimierung	Verarbeitung nur im erforderlichen Umfang; Pseudonymisierung, Anonymisierung, Löschkonzepte.
Verfügbarkeit	Zugriff auf Daten und Systeme bei Bedarf; Backups, Wiederherstellbarkeit, Redundanz, BCM.
Integrität	Unversehrtheit und Richtigkeit der Daten; Hashverfahren, Logging, Versionsverwaltung.
Vertraulichkeit	Schutz vor unbefugter Kenntnisnahme; Verschlüsselung, Zugriffskontrolle, MFA.
Transparenz	Nachvollziehbarkeit für Betroffene und Aufsicht; VVT, Datenschutzhinweise, Protokollierung.
Intervenierbarkeit	Durchsetzung der Betroffenenrechte; technische Umsetzung von Auskunft, Löschung, Berichtigung.
Nichtverkettung	Keine unzulässige Zweckzusammenführung; Mandantentrennung, kontextbezogene Identifikatoren.

Die meisten AVV-Anlagen am Markt strukturieren TOMs noch nach dem klassischen 8-Punkte-Schema (Zutritts-, Zugangs-, Zugriffs-, Weitergabe-, Eingabe-, Auftrags-, Verfügbarkeits- und Trennungskontrolle) aus der alten BDSG-Anlage. Diese Struktur ist nicht falsch, aber unvollständig – die Schutzziele Transparenz, Intervenierbarkeit und Datenminimierung fehlen vollständig. Eine moderne TOM-Anlage sollte entweder das SDM-Schema verwenden oder das alte 8-Punkte-Schema um diese Aspekte ergänzen.

Interaktiv: TOM-Explorer

★ Interaktiv – TOM-Explorer

Der TOM-Explorer steht jetzt als eigene Seite im Werkzeugkasten zur Verfügung. Eingaben bleiben lokal im Browser; am Ende erzeugt der Wizard ein druckfertiges Workpaper für die Akte.

★ TOM-Explorer öffnen

SDM v3.1a – die sieben Schutzziele Eigene Darstellung nach Standard-Datenschutzmodell SDM v3.1a (DSK-Beschluss) und Art. 32 DSGVO. Die drei Klassiker bilden die CIA-Triade der IT-Sicherheit; Art. 32 Abs. 1 lit. b DSGVO nennt zusätzlich die Belastbarkeit (Resilienz), die im SDM der Verfügbarkeit zugeordnet wird. Die vier weiteren Schutzziele konkretisieren datenschutzspezifische Anforderungen.

Pflichten in der Praxis: Auswahl, Dokumentation, Wirksamkeit

Aus Art. 32 DSGVO und der Rechenschaftspflicht des Art. 5 Abs. 2 DSGVO ergeben sich drei Pflichten, die zusammen einen kontinuierlichen Prozess bilden. Vorgelagert ist eine Asset-Inventur: Wer nicht weiß, welche Systeme, Daten und Verarbeitungstätigkeiten im eigenen Verantwortungsbereich existieren, kann weder Risiken bewerten noch angemessene Maßnahmen auswählen. Ein gepflegtes Asset-Register – mindestens bestehend aus Anwendungen, Speicherorten, Schnittstellen, eingebundenen Auftragsverarbeitern und KI-Komponenten – bildet damit das gemeinsame Fundament für Verarbeitungsverzeichnis (Art. 30 DSGVO), ISMS (ISO/IEC 27001 Anhang A.5.9 – Inventar von Informationen und anderen damit verbundenen Werten; BSI IT-Grundschutz ISMS.1) und KI-Inventar nach der KI-VO. Auf dieser Basis bauen die drei Pflichten auf:

Risikobewertung Vor jeder Verarbeitung ist das Risiko für die Rechte der Betroffenen strukturiert zu bewerten – methodisch z. B. nach SDM v3.1a oder BSI-Standard 200-3 (Risikoanalyse). Bei voraussichtlich hohem Risiko folgt eine Datenschutz-Folgenabschätzung nach Art. 35 DSGVO. Art. 32 Abs. 1 i. V. m. Art. 35 DSGVO
Auswahl und Umsetzung der Maßnahmen Auf Basis der Risikobewertung sind konkrete TOMs zu wählen und technisch sowie organisatorisch umzusetzen. Maßstab: Stand der Technik, Risikoadäquanz, Verhältnismäßigkeit. Art. 32 Abs. 1 lit. a–c DSGVO
Wirksamkeitskontrolle Die Maßnahmen sind regelmäßig auf Wirksamkeit zu überprüfen, zu bewerten und zu dokumentieren – durch Audits, Penetrationstests, interne Reviews oder externe Prüfungen. Eine einmalige Befüllung der TOM-Anlage genügt nicht. Art. 32 Abs. 1 lit. d DSGVO

An der Schnittstelle zur Informationssicherheit gilt: TOMs nach Art. 32 DSGVO und Maßnahmen aus einem ISMS (BSI-Grundschutz oder ISO/IEC 27001) überschneiden sich erheblich. Es ist effizient und sachgerecht, beide Systeme zu integrieren – die Aufsichtsbehörden erwarten dies bei reifen Organisationen ohnehin.

DSB-Schnellcheck beim System-Onboarding (10 Fragen)

Datenschutzbeauftragte müssen IT-Systeme nicht administrieren, aber datenschutzrechtlich einordnen. Die folgenden zehn Leitfragen strukturieren den Erstkontakt mit einer neuen Verarbeitung oder einem neuen System und decken die häufigsten Risikofelder ab. Sie sind komplementär zur Anbieter-Prüfung (siehe Sektion 7) und zum Schutzbedarfs-Wizard:

Wo entstehen die Daten? Erhebungsweg (Webformular, Schnittstelle, Massenimport, Sensorik), Erhebungskontext (freiwillig, Beschäftigungsverhältnis, Antragsverfahren).
Wo werden sie gespeichert? Physischer Speicherort, Cloud-Region, Backup- und Archivsysteme, Spiegelungen.
Wer hat Zugriff – fachlich und administrativ? Anzahl der Administratoren, gemeinsame Accounts, Rollen- und Berechtigungskonzept, Rezertifizierung.
Gibt es externe Dienstleister? Auftragsverarbeitungsvertrag, Unterauftragnehmer, Drittlandtransfer, Fernzugriff für Support.
Wie sind Berechtigungen geregelt? Least Privilege, Need-to-know, Funktionstrennung (Separation of Duties), Offboarding bei Stellenwechsel.
Gibt es Protokollierung? Umfang (Logins, Admin-Aktionen, Datenexporte, Zugriffe auf besondere Datenkategorien), Aufbewahrung, Manipulationsschutz, Zweckbindung der Logs.
Gibt es ein Löschkonzept? Aufbewahrungsfristen je Datenart, Startzeitpunkte, technische Umsetzung, Behandlung von Backups und Archivkopien (vgl. Themenseite Datenvernichtung).
Gibt es Backups? 3-2-1-Regel, Wiederherstellungstests, Ransomware-resistente Sicherungen, Verschlüsselung der Backup-Medien.
Wie erfolgt die Datenübertragung? Schnittstellen, automatische Weiterleitungen, Verschlüsselung in Transit, Empfängerverzeichnis, Drittlandtransfer.
Wer trägt technisch Verantwortung? Systemverantwortlicher, Fachverantwortlicher, IT-Sicherheitsbeauftragter, Auftragsverarbeiter; klare RACI-Zuordnung im Verfahrensverzeichnis.

Die zehn Fragen sind keine erschöpfende Prüfung, sondern ein Anker für das Erstgespräch zwischen Datenschutzbeauftragten, IT-Administration und Fachverantwortlichen. Sie sind so gewählt, dass auch Personen ohne tiefes IT-Wissen die richtigen Anschlussfragen stellen können – „Verständnis schlägt Detailwissen" (B. Fuhlert, privacyXperts, 16. April 2026). Art. 5 Abs. 2, Art. 25, Art. 32 DSGVO; methodisch angelehnt an: B. Fuhlert (privacyXperts), Webinar „Technik verstehen, Datenschutz bewerten", 16.04.2026

TOM-Prüfraster nach den sieben Schutzzielen

Das folgende Prüfraster führt strukturiert durch die sieben Schutzziele des SDM v3.1a. Es kann zur Selbstbewertung der eigenen Verarbeitung, zur Prüfung externer Auftragsverarbeiter und als Grundlage für die Dokumentation nach Art. 5 Abs. 2 DSGVO genutzt werden. Je nach Schutzbedarf sind zusätzliche Maßnahmen aus dem IT-Grundschutz-Kompendium oder Anhang A der ISO/IEC 27001:2022 zu ergänzen.

1 · Datenminimierung

Nur die für den Verarbeitungszweck erforderlichen Daten werden erhoben und verarbeitet (Art. 5 Abs. 1 lit. c DSGVO).
Pseudonymisierung wird eingesetzt, wo der Zweck es erlaubt (Art. 32 Abs. 1 lit. a DSGVO).
Anonymisierung erfolgt, sobald der Personenbezug nicht mehr erforderlich ist.
Löschfristen sind definiert, dokumentiert und technisch umgesetzt (Art. 17 DSGVO).
Zugriffsrechte sind nach dem Prinzip der minimalen Rechte (least privilege) zugewiesen.
Datenerhebung erfolgt grundsätzlich bei der betroffenen Person (Art. 13, 14 DSGVO).

2 · Verfügbarkeit

Dokumentiertes Backup-Konzept nach der 3-2-1-Regel: drei Datenspeicherungen, zwei verschiedene Backup-Medien, davon eines an einem externen Standort.
Wiederherstellungsverfahren werden regelmäßig getestet; RTO und RPO sind dokumentiert.
Mindestens ein Backup-System ist durch Schadcode nicht verschlüsselbar (Pull-Verfahren, Air-Gap-Trennung oder Immutable Backup) – Schutz vor Ransomware.
Redundante Hardware- und Netzinfrastruktur (Strom, Klima, Netz); USV gegen kurzfristige Stromausfälle.
Notfall- und Wiederanlaufplan (BCM nach BSI-Standard 200-4) etabliert und bekannt; Notfallplan inklusive Umgang mit Verschlüsselungstrojanern liegt auch in Papierform vor.
Schutz vor Schadsoftware, DDoS und physischen Risiken wie Feuer, Wasser, Diebstahl.
Wartungsfenster und Patch-Management definiert und dokumentiert.

3 · Integrität

Schreib- und Änderungsprozesse sind protokolliert (Audit-Trails).
Hash- oder Signaturverfahren sichern kritische Datenbestände ab.
Plausibilitätsprüfungen fangen Tipp- und Manipulationsfehler ab.
Versionsverwaltung schützt vor unbeabsichtigtem Überschreiben.
Übertragene Daten werden auf Vollständigkeit und Unversehrtheit geprüft.
Change-Management ist dokumentiert.

4 · Vertraulichkeit

Verschlüsselung at-rest (z. B. AES-256 mit GCM oder CBC) auf Speichersystemen.
Verschlüsselung in-transit (TLS 1.3, aktuelle Cipher-Suites nach BSI TR-02102).
Verschlüsselung in-use (Data in Use): Schutz personenbezogener Daten während der aktiven Verarbeitung im Arbeitsspeicher durch Confidential-Computing-Technologien (Intel SGX, Intel TDX, AMD SEV-SNP, ARM CCA) bzw. anbieterseitige Trusted Execution Environments (Azure Confidential Computing, AWS Nitro Enclaves, Google Confidential VMs). Praxisrelevant insbesondere bei der Auslagerung sensibler Verarbeitungen in die Cloud (Forschungsdaten nach Art. 9 DSGVO, KI-Inferenz auf Personalakten, Drittlandtransfers mit Anbieter-Zugriff). Confidential Computing kann je nach Architektur als ergänzende technische Schutzmaßnahme zur Risikominderung in Cloud- und Drittlandkonstellationen in Betracht kommen, insbesondere gegen privilegierte Insider-Zugriffe beim Cloud-Anbieter; ob dies im Einzelfall ein hinreichendes zusätzliches Schutzniveau vermittelt, ist gesondert zu prüfen. Die Prüfung der Rechtsgrundlage und der Drittlandsabsicherung wird durch Confidential Computing nicht ersetzt.
Asymmetrische Verschlüsselung nach Stand der Technik (z. B. RSA-2048 Bit oder höher, EC-256 Bit oder höher).
Passwortspeicherung niemals im Klartext; Verwendung etablierter, für Passwortspeicherung geeigneter Verfahren mit Salt (z. B. bcrypt, scrypt, PBKDF2 oder Argon2id). Allgemeine kryptographische Primitive (SHA-256, HMAC-SHA-256) sind für die Passwortspeicherung nicht ohne Weiteres geeignet, weil sie nicht auf die hohe Berechnungskosten ausgelegt sind, die ein Brute-Force-Angriff auf gehashte Passwörter erfordert.
Passwortrichtlinie mit klaren Mindestanforderungen (z. B. mind. 10 Zeichen komplex oder mind. 16 Zeichen einfacher); automatische Sperrung nach mehreren Fehlversuchen; keine Speicherung im Browser ohne Master-Passwort.
Rollen- und Rechtekonzept (RBAC/ABAC) mit regelmäßiger Rezertifizierung; least privilege auch bei Administrationsrollen.
Mehr-Faktor-Authentifizierung für privilegierte Zugänge; getrennte Administrations- und Nutzerkennungen für IT-Personal (Details s. Sonderkapitel 4b).
Verpflichtung auf Vertraulichkeit aller verarbeitenden Personen (Art. 28 Abs. 3 lit. b DSGVO).
Physische Zutrittskontrolle zu Serverräumen (Protokollierung, Besucherregelung); klare Sicherheitszonen.
Sichere Löschung von Datenträgern nach BSI-Vorgabe (vgl. Themenseite Datenvernichtung).
Clean-Desk- und Screen-Lock-Regelungen etabliert.

4b · Authentifizierung und Identitätsmanagement (Sonderkapitel zur Vertraulichkeit)

Die schlichte Aussage „MFA ist aktiv" sagt nichts über das tatsächliche Sicherheitsniveau aus. Zwischen einem SMS-Einmalcode und einem FIDO2-Sicherheitsschlüssel liegen erhebliche Unterschiede in der Robustheit gegen reale Angriffe (Adversary-in-the-Middle, SIM-Swapping, MFA-Fatigue, Session-Token-Diebstahl). Art. 32 Abs. 1 DSGVO fordert den Stand der Technik – dieser ist bei der Authentifizierung dynamisch zu interpretieren.

Phishing-resistente Verfahren bevorzugen: FIDO2/WebAuthn-Sicherheitsschlüssel und Passkeys binden die kryptografische Signatur an die Domain und schützen damit auch gegen Echtzeit-Phishing über Reverse-Proxys (z. B. Evilginx, Modlishka).
Schwächere Verfahren risikoadäquat einsetzen: SMS-OTP, E-Mail-OTP und „Passwort + Sicherheitsfrage" sind für privilegierte Zugänge risikobehaftet und bedürfen einer besonders sorgfältigen Begründung, wenn sie weiterhin eingesetzt werden; SMS-OTP ist durch SIM-Swapping kompromittierbar, E-Mail-Codes verlagern die Authentifizierung nur auf das E-Mail-Postfach. „Passwort + Sicherheitsfrage" ist im technischen Sinne keine Zwei-Faktor-Authentifizierung, weil beide Komponenten dem Faktor Wissen zuzuordnen sind.
Push-Bestätigungen mit Number-Matching oder kontextabhängige Prompts einsetzen, um MFA-Fatigue (Prompt-Bombing) zu verhindern.
Bedingter / adaptiver Zugriff (Conditional Access): Risikosignale wie unbekanntes Gerät, ungewöhnlicher Standort oder „unmögliche Reise" auslösen zusätzliche Authentifizierung oder Blockade.
Sitzung und Token absichern: kurze Session-Lifetimes, Re-Authentifizierung bei sensitiven Aktionen, Token-Binding bzw. DPoP (Demonstrating Proof-of-Possession) koppelt Tokens an Gerät und TLS-Schlüssel; Continuous Access Evaluation (CAE) invalidiert Sitzungen bei Risikoänderungen sofort.
Schutz vor Infostealern auf Endgeräten: Endpoint Detection & Response (EDR), gehärtete Browser, hardware-gebundene Schlüssel; gestohlene Cookies bzw. OAuth-Refresh-Tokens umgehen jede MFA.
Wiederherstellung absichern: Recovery-Prozesse („Passwort vergessen", Geräteverlust) müssen so stark sein wie der primäre Faktor; mindestens zwei registrierte starke Faktoren je Nutzerkonto (z. B. zwei FIDO2-Keys); Backup-Codes physisch oder im Passwortmanager mit eigenem zweiten Faktor; kein Self-Service-Reset privilegierter Konten allein per SMS oder E-Mail.
Notfall-Administratorkonten („Break-Glass"): dokumentiert, offline aufbewahrt, mit Vier-Augen-Prinzip versehen und auditiert; nicht in das reguläre SSO eingebunden.
OAuth-Consent-Management: App-Consent-Policies für Microsoft Entra / Google Workspace, administrative Freigabe für sensible Berechtigungen; regelmäßiges Review erteilter Drittanwendungs-Zugriffe.
Regulatorische Verankerung: Art. 32 Abs. 1 DSGVO (Stand der Technik), Art. 21 NIS-2-RL (angemessene Risikomanagementmaßnahmen, im Anwendungsbereich regelmäßig einschließlich MFA), BSI IT-Grundschutz-Bausteine ORP.4 (Identitäts- und Berechtigungsmanagement) und APP.1.4 (Mobile Anwendungen); der Stand der Technik und aktuelle Angriffsmuster sprechen für privilegierte Zugänge regelmäßig für phishing-resistente Verfahren wie FIDO2 oder gerätegebundene Passkeys. Eine pauschale Verrechtlichung („einziger zulässiger Mindeststandard") ist damit nicht verbunden; die Auswahl bleibt risikoadäquat zu begründen.

4a · Mobile Datenspeicher (Sonderkapitel zur Vertraulichkeit)

Starke Verschlüsselung mobiler Endgeräte (Festplattenverschlüsselung, Container-Lösungen).
Mobile-Device-Management (MDM) zur Verwaltung von Smartphones und Tablets, einschließlich Remote-Wipe.
USB-Sticks und externe Datenträger nur nach Whitelisting; Auto-Start externer Medien deaktiviert.
Klare Regelungen zur Privatnutzung dienstlicher Geräte (Empfehlung: keine Privatnutzung).
Verlustmeldeprozess bei mobilen Endgeräten ist kommuniziert und übungserprobt.
Keine unverschlüsselte Übertragung personenbezogener Daten per E-Mail oder Cloud-Plattform; bei hohem Risiko zusätzlich Inhaltsverschlüsselung.

5 · Transparenz

Vollständiges Verarbeitungsverzeichnis (Art. 30 DSGVO) wird geführt.
Datenschutzhinweise nach Art. 13, 14 DSGVO sind aktuell und verfügbar.
Protokollierungskonzept (Was, wie lange, durch wen zugänglich?) ist dokumentiert.
Konfigurationsdokumentation der eingesetzten Systeme ist aktuell.
Änderungen an Verarbeitungsprozessen werden dokumentiert und kommuniziert.
Ansprechpartner für Betroffenenrechte sind klar benannt.

6 · Intervenierbarkeit

Technische Umsetzung des Auskunftsrechts (Art. 15 DSGVO).
Löschung (Art. 17 DSGVO) kontextabhängig auslösbar.
Berichtigung (Art. 16 DSGVO) möglich, inklusive historisierter Korrektur.
Einschränkung der Verarbeitung (Art. 18 DSGVO) technisch umsetzbar.
Einwilligungen protokollierbar und jederzeit widerrufbar (Art. 7 Abs. 3 DSGVO).
Eskalationswege und Krisenprozesse bei Datenpannen sind definiert (Art. 33, 34 DSGVO).

7 · Nichtverkettung

Daten aus unterschiedlichen Verarbeitungszwecken werden technisch getrennt.
Mandantentrennung in gemeinsam genutzten Systemen ist umgesetzt.
Keine Zusammenführung mit Daten anderer Verantwortlicher ohne Rechtsgrundlage.
Verknüpfungs-Identifikatoren sind kontextspezifisch (keine Universal-IDs).
Forschungsdaten werden strukturell getrennt verarbeitet.
Verschiedene Identitäten (z. B. beruflich/privat) werden nicht vermischt.

Methodische Originalquellen

Standard-Datenschutzmodell (SDM) – methodischer Primärrahmen. Version 3.1 wurde von der DSK am 14.05.2024 (107. Sitzung) beschlossen; die aktuell verfügbare Fassung v3.1a ist eine redaktionelle Aktualisierung durch die LfDI Mecklenburg-Vorpommern als Geschäftsstelle des SDM.
BSI IT-Grundschutz – BSI-Standards 200-1 bis 200-4 und IT-Grundschutz-Kompendium.
ISO/IEC 27001:2022 – internationaler ISMS-Standard mit Anhang A (93 Controls).

Praxis-Checklisten und ergänzende Quellen

Das in den vorigen Abschnitten skizzierte SDM-Schema bildet den methodischen Rahmen. Für die operative Umsetzung sind zusätzlich Prüfraster auf konkreter Maßnahmenebene hilfreich, weil sie die SDM-Schutzziele in alltagstaugliche Einzelfragen herunterbrechen. Aus der Beratungspraxis empfehle ich folgende drei Quellen besonders:

Empfehlung: BayLDA-Checkliste „Good Practice bei TOMs"

Das Bayerische Landesamt für Datenschutzaufsicht hat eine achtseitige Checkliste mit rund 200 Einzelmaßnahmen veröffentlicht, gegliedert in 18 Praxisbereiche (Management und Organisation, physische Sicherheit, Awareness, Authentifizierung, Rollen-/Rechtekonzept, Endgeräte, mobile Datenspeicher, Serversysteme, Webanwendungen, Netzwerk, Archivierung, Wartung durch Dienstleister, Protokollierung, Business Continuity, Kryptografie, Datentransfer, Software-Entwicklung, Auftragsverarbeiter). Die Liste richtet sich primär an KMU, lässt sich aber für öffentliche Hochschulen sehr gut adaptieren – sie ergänzt das SDM um konkrete Detailmaßnahmen mit klaren Algorithmen-Empfehlungen (AES-256-GCM, RSA-2048, bcrypt etc.) und Backup-Verfahren (3-2-1-Regel).

Direktlink: BayLDA – Good Practice bei technischen und organisatorischen Maßnahmen (PDF) · Übersicht aller BayLDA-Checklisten: lda.bayern.de/de/checklisten.html

Hinweis zur Anwendbarkeit: Die Checkliste ist eine Empfehlung gelebter Good Practice, kein abschließender Pflichtenkatalog. Die Auswahl der Maßnahmen ist risikoorientiert und im konkreten Verarbeitungskontext zu treffen (siehe Abschnitt „Maßstab: Was ist ‚angemessen'?"). Stand der Veröffentlichung: 13. Oktober 2020 – die Inhalte sind weitgehend zeitlos, BSI- und ISO-Verweise sollten gegen die jeweils aktuelle Fassung geprüft werden.

Weitere relevante Praxisquellen

BSI IT-Grundschutz-Kompendium – Edition 2023 mit über 100 Bausteinen; für die TOM-Beschreibung insbesondere relevant: CON.1 „Kryptokonzept", CON.3 „Datensicherungskonzept", CON.6 „Löschen und Vernichten", ORP.4 „Identitäts- und Berechtigungsmanagement", INF.7 „Büroarbeitsplatz", OPS.1.1.5 „Protokollierung". Abrufbar unter bsi.bund.de.
ISO/IEC 27002:2022 – internationaler Begleitstandard zu ISO/IEC 27001 mit 93 Controls (organisatorisch, personell, physisch, technisch). Inhalt ist im Anhang A der ISO/IEC 27001:2022 referenziert.
ENISA Handbook on Security of Personal Data Processing – europäische Behördenperspektive auf risikoadäquate TOMs; hilfreich für die DSFA-Vorbereitung. enisa.europa.eu.
CNIL Practice Guide for the Security of Personal Data – 2024 Edition – Leitfaden der französischen Datenschutzaufsichtsbehörde mit 25 Fact-Sheets, einschließlich neuer Themen wie Cloud Computing, Mobile Applications, KI und APIs. Wird in der Praxis häufig komplementär zur BayLDA-Checkliste eingesetzt. cnil.fr/en/practice-guide-security-personal-data-2024-edition.

BayLDA – Good Practice bei TOMs (Stand 13.10.2020); BSI IT-Grundschutz-Kompendium Edition 2023; ISO/IEC 27002:2022; ENISA Handbook on Security of Personal Data Processing; CNIL Security of Personal Data

Anbieter-Prüfung: Die zentralen Fragen

Die folgende Übersicht fasst die fünfzehn wichtigsten Fragen für die Bewertung externer Auftragsverarbeiter zusammen. Sie sind in der Download-Checkliste in detaillierter Form mit Antwort- und Nachweisspalten enthalten.

Kernfragen an Auftragsverarbeiter

Welche Datenkategorien werden verarbeitet, in welcher Menge, über welchen Zeitraum?
Wo (Land, Rechenzentrum, Cloud-Region) werden die Daten gespeichert?
Welche Unterauftragsverarbeiter sind eingebunden?
Welche Verschlüsselung kommt at-rest und in-transit zum Einsatz?
Wie ist die Zugriffskontrolle umgesetzt (RBAC, MFA, Protokollierung)?
Welche Ereignisse werden wie lange protokolliert?
Wie sind Backup und Wiederherstellung geregelt (RTO/RPO, Tests)?
Gibt es ein dokumentiertes Datenpannen-Meldemanagement?
Welche Zertifizierungen liegen vor (ISO 27001, BSI C5, SOC 2, TISAX)?
Wie wird der Verantwortliche bei Betroffenenrechten unterstützt?
Welche Löschroutinen gelten bei Vertragsende?
Wie ist die Trennung von Eigen- und Kundendaten geregelt?
Welche Awareness-Maßnahmen und Schulungen existieren?
Welche faktischen Zugriffsmöglichkeiten ausländischer Behörden bestehen (TIA)?
Wann und mit welchem Ergebnis wurde die letzte externe Sicherheitsprüfung durchgeführt?

Typische Fallbeispiele aus dem Hochschulkontext

Hochschulweite Lernplattform

Cloud-basierte LMS-Plattform mit Studierendendaten

Eine zentral betriebene Lernplattform speichert Stamm-, Anmelde-, Teilnahme- und Leistungsdaten zehntausender Studierender. Verarbeitung erfolgt teilweise im Drittland. Hoher Schutzbedarf bei Vertraulichkeit und Verfügbarkeit, mittlerer Bedarf bei Integrität.

Empfohlene Schwerpunkte: Verschlüsselung at-rest und in-transit (BSI TR-02102), Mandantentrennung, Single Sign-On mit MFA, dokumentiertes Backup mit Wiederherstellungstests, vollständige Sub-AV-Liste, TIA für Drittlandverarbeitung.

Forschungsdatenbank

Forschungsdatenbank mit besonderen Kategorien (Art. 9 DSGVO)

Verarbeitung von Gesundheits- oder genetischen Daten im Rahmen eines Forschungsvorhabens nach § 27 DSAG LSA. Sehr hoher Schutzbedarf bei Vertraulichkeit; Risikobewertung über die DSFA-Schwelle.

Empfohlene Schwerpunkte: Pseudonymisierung mit getrennter Schlüsselverwaltung, restriktives Berechtigungskonzept (need-to-know), Logging aller Zugriffe, sichere Datenträgervernichtung, Notfallplanung für Datenpannen, vorherige Konsultation der Aufsichtsbehörde nach Art. 36 DSGVO prüfen.

Videokonferenz

SaaS-Videokonferenzsystem für Lehre und Prüfungen

Externer Anbieter stellt das Videokonferenzsystem bereit. Aufzeichnung optional. Mittlerer Schutzbedarf bei Vertraulichkeit; bei Online-Prüfungen kann der Schutzbedarf hoch sein.

Empfohlene Schwerpunkte: Ende-zu-Ende- oder zumindest Transportverschlüsselung, abgestufte Aufzeichnungsregeln, Zugriffsprotokollierung, klare Hinweise an Teilnehmer (Art. 13 DSGVO), Lösch- und Aufbewahrungsfristen für Aufzeichnungen, Sub-AV-Prüfung des Anbieters.

Backup-Strategie

Zentrales Backup für Verwaltungsdaten

Die Universitätsverwaltung sichert Personal-, Bewerbungs- und Finanzdaten in einem zentralen Backup-System mit Geo-Redundanz. Hoher Schutzbedarf bei Verfügbarkeit, sehr hoher Bedarf bei Vertraulichkeit (Beschäftigtendaten; Personalakten unterliegen in Sachsen-Anhalt zusätzlich den Sondervorschriften des § 26 DSAG LSA i. V. m. § 50 BeamtStG / §§ 84 ff. LBG LSA).

Empfohlene Schwerpunkte: Backup-Verschlüsselung mit kontrollierter Schlüsselverwaltung, klar definierte RTO/RPO, regelmäßige Wiederherstellungstests, separater Schutz der Backup-Infrastruktur (eigenes Berechtigungskonzept), Schutz vor Ransomware (Air-Gap, Immutable Backup).

Wiederkehrende Schwachpunkte bei TOM-Prüfungen

Sechs Muster, die TOM-Anlagen in der Praxis schwächen – meist an der Schnittstelle zwischen Anbieter-Marketing und tatsächlicher Sicherheitswirkung:

Marketing-Begriffe statt konkreter Maßnahmen: Formulierungen wie „Military Grade Encryption", „AI-driven Security" oder „Zero Trust by Default" stellen häufig keine TOM-Beschreibungen im Sinne des Art. 32 DSGVO dar. Es wird empfohlen, konkrete Angaben zu Algorithmus, Schlüssellänge, Schlüsselverwaltung und Implementierung anzufordern.
Pauschale Übernahme der Anbieter-Anlage: Eine ungeprüfte Übernahme der TOM-Anlage des Auftragsverarbeiters reicht in der Regel nicht aus. Empfohlen wird eine eigenständige inhaltliche Bewertung und Freigabe durch den Verantwortlichen.
Keine Wirksamkeitskontrolle: Eine einmalig abgeschlossene und anschließend nicht wieder überprüfte TOM-Anlage dürfte den Anforderungen des Art. 32 Abs. 1 lit. d DSGVO nicht gerecht werden. Es wird eine regelmäßige Überprüfung, Bewertung und Dokumentation empfohlen.
Fehlende Schnittstelle zum ISMS: Eine isolierte Führung der TOMs ohne Anbindung an das Informationssicherheits-Managementsystem führt in der Praxis zu Doppelarbeit und Inkonsistenzen. Empfehlung: Integration beider Systeme.
Risikoblindheit: Standardisierte TOM-Anlagen „von der Stange" ohne Bezug zum konkreten Verarbeitungsrisiko dürften der individuellen Risikolage selten gerecht werden. Ein Adressverzeichnis und eine Forschungsdatenbank mit Genomdaten erfordern in der Praxis unterschiedliche Maßnahmen.
Vernachlässigung organisatorischer Maßnahmen: Schulungen, Verpflichtungen, Berechtigungskonzepte und Prozessbeschreibungen werden gegenüber technischen Maßnahmen häufig unterbewertet. Erfahrungsgemäß haben viele Datenpannen organisatorische Ursachen.

Vertiefende Quellen

Rechtsquellen

Verordnung (EU) 2016/679 (DSGVO) – insb. Art. 5 Abs. 1 lit. f (Integrität und Vertraulichkeit); Art. 25 (Datenschutz durch Technikgestaltung und durch Voreinstellungen); Art. 32 (Sicherheit der Verarbeitung); Art. 35 (Datenschutz-Folgenabschätzung).
Hochschulgesetz Sachsen-Anhalt (HSG LSA) – § 119 Abs. 1 (Datenverarbeitung im Hochschulkontext) als Aufgabennorm i. S. d. Art. 6 Abs. 1 lit. e DSGVO.
Datenschutz-Grundverordnungs-Ausfüllungsgesetz Sachsen-Anhalt (DSAG LSA) – § 4 (allgemeine Rechtsgrundlage für öffentliche Stellen, subsidiär).

Rechtsprechung

EuGH, Urteil v. 14.12.2023 – C-340/21 (Natsionalna agentsia za prihodite) – Maßstab und Beweislast bei der Bemessung geeigneter TOMs nach Art. 32 DSGVO.

Aufsichtspraxis und Mustervorlagen

DSK, Standard-Datenschutzmodell (SDM) v3.1a – methodische Operationalisierung der Schutzziele in TOM-Bausteine.
BSI, IT-Grundschutz-Kompendium – Bausteine, Anforderungen und Umsetzungshinweise als Referenzmaßstab für TOMs.
ISO/IEC 27001:2022 – internationaler Standard für Informationssicherheits-Managementsysteme; einschlägig für die Wirksamkeitskontrolle.
LfD Sachsen-Anhalt, Orientierungshilfen und Hinweisdokumente – aufsichtsbehördliche Praxis im Land Sachsen-Anhalt.

Querverweise auf eigene Themenseiten

Hochschuldatenschutz – Normenrahmen für die Rechtsgrundlagen, auf die TOMs aufsetzen.
Auftragsverarbeitung (Art. 28 DSGVO) – TOMs als Anlage zum AVV.
Datenschutz-Folgenabschätzung – TOMs als Risikominderungsmaßnahmen.
Datenpannen und Meldepflicht – TOM-Wirksamkeit als Indiz im Schadensfall.
Microsoft 365 an öffentlichen Hochschulen – TOM-Anforderungen in einer der praxisrelevantesten Konstellationen.

Stand: Q2/2026 · letzte inhaltliche Pflege; anbieter- und produktbezogene Aussagen sind dynamisch und vor produktiver Nutzung an aktuellen Primärquellen zu prüfen.

★

Interaktiv: Schutzbedarfs-Wizard

★ Interaktiv – Schutzbedarfs-Wizard

Der Schutzbedarfs-Wizard steht jetzt als eigene Seite im Werkzeugkasten zur Verfügung. Eingaben bleiben lokal im Browser; am Ende erzeugt der Wizard ein druckfertiges Workpaper für die Akte.

★ Schutzbedarfs-Wizard öffnen

Weitere Themenseiten zu Datenschutz, KI-Verordnung und Informationssicherheit.

Zur Themenübersicht

Fragen zu dieser Seite?

Hinweise, Fehlerkorrekturen oder Anregungen zur Erweiterung dieser Seite – insbesondere zur TOM-Checkliste – nehme ich gerne entgegen.

kontakt@dennisawinkler.de