¶ Technische und organisatorische Maßnahmen
Beispieldokument: Diese Seite ist ein nicht freigegebener Musterrahmen für die fiktive „Muster GmbH“. Sie enthält keine realen Systeme, Konfigurationen, Schutzmaßnahmen, Tests oder Wirksamkeitsnachweise.
Kontextregel: TOM werden für eine konkrete Verarbeitung und ihre Risiken ausgewählt. Ein allgemeiner Katalog ohne Zweck-, System-, Personen-, Daten- und Risikobezug belegt kein angemessenes Schutzniveau.
Wirksamkeitsregel: „Geplant“, „umgesetzt“, „geprüft“ und „wirksam“ sind unterschiedliche Zustände. Nur belastbar geprüfte Maßnahmen dürfen bei der Restrisikobewertung als wirksam berücksichtigt werden.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | DSGVO-MA-05-03 |
| Dokumentenart | Verfahren und Registerrahmen für technische und organisatorische Maßnahmen |
| Wiki.js-Pfad | /DSGVO/05-Risiken-DSFA-und-TOM/Technische-und-organisatorische-Massnahmen |
| Verantwortlich | festzulegender Verantwortlicher / Prozesseigner mit Datenschutzkoordination und Informationssicherheit |
| Fachlich geprüft durch | Datenschutzbeauftragte/r, sofern benannt, Rechtsfunktion, Informationssicherheit, IT, Prozesseigner und betroffene Fachrollen |
| Freigabe durch | Geschäftsführung beziehungsweise dokumentierte befugte Leitung |
| Status | Entwurf – Maßnahmensystematik, Rollen, Mindestniveaus, Prüfmethoden und Fristen nicht organisationsbezogen freigegeben |
| Version | 1.0 |
| Stand | 10.08.2026 |
| Gültig ab | Nach fachlicher Prüfung, Abgleich mit realen Verarbeitungen, Praxistest und formaler Freigabe |
| Nächste Prüfung | Mindestens jährlich sowie bei Risiko-, Verarbeitungs-, Technik-, Lieferanten-, Rechts- oder Wirksamkeitsänderungen |
| Schutzklasse | Intern; konkrete Architektur, Konfigurationen, Schwachstellen und Nachweise vertraulich bis streng vertraulich |
| DSGVO-Bezug | Artikel 5 Absatz 2, 24, 25, 28, 32 und 35 DSGVO; Erwägungsgründe 75, 76, 78, 83 und 84 |
| Schnittstellen | VVT, Datenschutz-Risikomethodik, Risikoregister, DSFA, Projekte, ISMS, Lieferanten, Transfers, Löschung, Vorfälle und Nachweise |
TOM werden aus Verarbeitung, rechtlichen Anforderungen und Risiken abgeleitet, kontrolliert umgesetzt und regelmäßig auf Wirksamkeit geprüft. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Zweck
Das Verfahren steuert Auswahl, Umsetzung, Prüfung und Verbesserung technischer und organisatorischer Maßnahmen. Es verbindet datenschutzrechtliche Anforderungen und Risiken für natürliche Personen mit konkreten Kontrollen, Verantwortlichen, Nachweisen und Restrisikoentscheidungen.
Das TOM-Verzeichnis ist eine Steuerungs- und Referenzquelle. Es ersetzt weder die technische Umsetzung noch deren Prüfung.
¶ 2. Maßstab der Angemessenheit
Bei der Festlegung des angemessenen Schutzniveaus werden nach Artikel 32 DSGVO insbesondere berücksichtigt:
- Stand der Technik,
- Implementierungskosten,
- Art, Umfang, Umstände und Zwecke der Verarbeitung,
- unterschiedliche Eintrittswahrscheinlichkeit und Schwere der Risiken für Rechte und Freiheiten natürlicher Personen.
Kosten sind ein Abwägungsfaktor, keine pauschale Ausnahme. Gesetzlich, vertraglich oder aus der konkreten Verarbeitung zwingend erforderliche Schutzanforderungen können nicht durch eine bloße Risikoakzeptanz entfallen.
¶ 3. Anforderungen aus Artikel 32
Je nach Angemessenheit werden insbesondere betrachtet:
- Pseudonymisierung und Verschlüsselung personenbezogener Daten,
- dauerhafte Sicherstellung von Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme und Dienste,
- Fähigkeit, Verfügbarkeit personenbezogener Daten und Zugang zu ihnen nach einem physischen oder technischen Zwischenfall rasch wiederherzustellen,
- Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der Maßnahmen.
Bei der Risikobeurteilung werden besonders unbeabsichtigte oder unrechtmäßige Vernichtung, Verlust, Veränderung, unbefugte Offenlegung und unbefugter Zugang berücksichtigt.
¶ 4. Datenschutzmaßnahmen sind mehr als IT-Sicherheit
TOM unterstützen neben Artikel 32 auch Datenschutzgrundsätze, Betroffenenrechte und Datenschutz durch Technikgestaltung. Deshalb werden zusätzlich betrachtet:
- Datenminimierung und Zweckbegrenzung,
- Transparenz und Nachvollziehbarkeit,
- Nichtverkettung unterschiedlicher Zwecke,
- Intervenierbarkeit, Berichtigung, Einschränkung und Löschung,
- datenschutzfreundliche Voreinstellungen,
- geregelte Verantwortlichkeit, Freigabe und Kontrolle.
Informationssicherheit ist eine wesentliche Schnittstelle, deckt aber die Betroffenenperspektive und alle datenschutzrechtlichen Anforderungen nicht automatisch vollständig ab.
¶ 5. Standard-Datenschutzmodell als Strukturhilfe
Das Standard-Datenschutzmodell 3.1 der Datenschutzkonferenz strukturiert Anforderungen über sieben Gewährleistungsziele:
| Gewährleistungsziel | TOM-Fragen |
|---|---|
| Datenminimierung | Sind Daten, Felder, Kopien, Zugriffe, Dauer und Auswertungen auf das Erforderliche begrenzt? |
| Verfügbarkeit | Sind Daten und Funktionen im erforderlichen Umfang verfügbar und wiederherstellbar? |
| Integrität | Werden unbefugte oder unbeabsichtigte Änderungen verhindert, erkannt und korrigiert? |
| Vertraulichkeit | Können nur befugte Personen und Systeme auf Daten zugreifen? |
| Nichtverkettung | Werden Datenbestände und Verarbeitungsschritte verschiedener Zwecke wirksam getrennt? |
| Transparenz | Sind Verarbeitung, Zustände, Zugriffe, Entscheidungen und Verantwortlichkeiten nachvollziehbar? |
| Intervenierbarkeit | Können Rechte, Korrekturen, Sperren, Löschungen, Widersprüche und menschliche Eingriffe praktisch umgesetzt werden? |
Das SDM ist eine methodische Strukturhilfe. Entscheidend bleibt die konkrete rechtliche, technische und organisatorische Bewertung der jeweiligen Verarbeitung.
¶ 6. Eingangsinformationen
Vor der Maßnahmenselektion liegen mindestens vor:
- VVT-ID und eindeutige Verarbeitungsbeschreibung,
- Zwecke, Rechtsgrundlagen und besondere Anforderungen,
- Daten- und Personengruppen einschließlich Schutzbedürftigkeit,
- Datenfluss, Systeme, Dienste, Standorte und Schnittstellen,
- Verantwortliche, Auftragsverarbeiter, Empfänger und Unterauftragnehmer,
- Speicher-, Lösch-, Support- und Drittlandkontext,
- Risiken, DSFA-Status und verknüpfte Risiko-IDs,
- vorhandene ISMS-Kontrollen und deren nachgewiesener Geltungsbereich,
- bekannte Schwachstellen, Vorfälle und offene Abweichungen.
Unvollständige Informationen führen zu offenen Klärungen und nicht zu einer pauschalen Bestätigung der Angemessenheit.
¶ 7. TOM-Kennung und Registerfelder
| Feld | Mindestinhalt |
|---|---|
| TOM-ID | eindeutige Kennung, zum Beispiel TOM-YYYY-NNN |
| Titel und Kategorie | verständliche Bezeichnung und Maßnahmenart |
| VVT-/Risiko-/DSFA-Bezug | konkrete Verarbeitungen und Risikoszenarien |
| Anforderung | Rechtsnorm, Vertrag, Richtlinie, Standard oder interne Entscheidung |
| Zielwirkung | betroffenes Gewährleistungsziel, Ursache, Wahrscheinlichkeit oder Auswirkung |
| Geltungsbereich | Systeme, Dienste, Standorte, Rollen, Daten und Prozessphasen |
| Sollbeschreibung | überprüfbare Anforderung und gewünschter Zustand |
| Ist-Zustand | tatsächliche technische und organisatorische Umsetzung |
| Owner / Betreiber | fachliche Verantwortung und operative Durchführung |
| Status | geplant, in Umsetzung, umgesetzt, geprüft, wirksam, unwirksam oder außer Betrieb |
| Prüfmethode | Test, Stichprobe, Messung, Review, Audit oder Wiederanlaufübung |
| Wirksamkeitskriterium | vorab bestimmter Sollwert beziehungsweise Akzeptanzkriterium |
| Nachweisreferenz | geschützter Ablageort, Version, Datum und Schutzklasse |
| Restrisiko | neue Bewertung und verknüpfte Entscheidung |
| Abweichung / Maßnahme | Feststellung, Ursache, Korrektur, Owner und Frist |
| Review | letzter Test, nächste Prüfung und Änderungsauslöser |
¶ 8. Statusmodell
| Status | Bedeutung | Darf risikomindernd berücksichtigt werden? |
|---|---|---|
| geplant | Maßnahme ist ausgewählt, aber nicht umgesetzt | nein |
| in Umsetzung | Umsetzung läuft; Wirkung nicht bestätigt | nein |
| umgesetzt | Sollzustand wurde eingerichtet; Prüfung steht aus | nur mit begründeter vorläufiger Bewertung |
| geprüft | Durchführung wurde mit festgelegter Methode kontrolliert | abhängig vom Prüfergebnis |
| wirksam | Sollkriterium wurde im relevanten Geltungsbereich erreicht | ja, bis Review oder Änderung |
| unwirksam | Zielwirkung wurde nicht oder nicht ausreichend erreicht | nein; Abweichung behandeln |
| außer Betrieb | Maßnahme wurde beendet oder ersetzt | nein; Nachfolger und Übergang prüfen |
Dokumentenfreigabe, Umsetzungsstatus und Wirksamkeitsstatus werden getrennt geführt.
¶ 9. Maßnahmen auswählen
Die Auswahl folgt einem nachvollziehbaren Soll-Ist-Vergleich:
- Verarbeitung und rechtliche Anforderungen abgrenzen.
- Risiken für Rechte und Freiheiten bestimmen.
- vorhandene Kontrollen und ihren tatsächlichen Geltungsbereich erfassen.
- Schutzlücken und erforderliches Schutzniveau ableiten.
- geeignete technische, organisatorische, rechtliche und verfahrensbezogene Maßnahmen wählen.
- erwartete Wirkung und mögliche Nebenwirkungen bewerten.
- Verantwortliche, Ressourcen, Fristen und Wirksamkeitskriterien festlegen.
Eine Maßnahme darf nicht mehrfach als Risikominderung gezählt werden, ohne ihre Wirkung je Risikoszenario zu begründen.
¶ 10. Technische Maßnahmenfelder
- sichere Architektur, Segmentierung und Mandantentrennung,
- Identitäts-, Authentifizierungs- und Berechtigungsmanagement,
- Verschlüsselung bei Übertragung und Speicherung sowie Schlüsselmanagement,
- Pseudonymisierung, Tokenisierung und Trennung von Zuordnungswissen,
- Protokollierung, Erkennung, Alarmierung und manipulationsgeschützte Auswertung,
- sichere Konfiguration, Härtung, Schwachstellen- und Patchmanagement,
- Datensicherung, Wiederherstellung, Redundanz und Belastbarkeit,
- Datenminimierung, Feldbegrenzung und datenschutzfreundliche Voreinstellungen,
- technische Löschung, Sperrung, Berichtigung und Exportfähigkeit,
- sichere Übertragung, Schnittstellen, Entwicklung, Testdaten und Änderungen,
- Schutz von Endgeräten, mobilen Geräten, Cloud-Diensten und Fernzugriffen,
- physische Schutzmaßnahmen für Räume, Geräte und Datenträger.
Die Auswahl wird nicht aus dieser Liste allein, sondern aus der konkreten Verarbeitung und Risikobewertung abgeleitet.
¶ 11. Organisatorische Maßnahmenfelder
- Rollen, Verantwortlichkeiten, Vertretungen und Funktionstrennung,
- Berechtigungsbeantragung, Freigabe, Review und Entzug,
- Richtlinien, Arbeitsanweisungen und datenschutzgerechte Standardprozesse,
- Verpflichtung, Schulung, Awareness und Kompetenzprüfung,
- Lieferantenprüfung, Verträge, Weisungen, Unterauftragnehmer und Exit,
- Änderungs-, Projekt-, Beschaffungs- und Freigabeprozesse,
- Lösch-, Aufbewahrungs-, Archiv- und Datenträgerverfahren,
- Datenschutzverletzungs-, Notfall- und Wiederanlaufverfahren,
- Betroffenenrechte, Beschwerden, Korrektur und menschliche Intervention,
- Kontrollen, Audits, Stichproben, Kennzahlen und Managementbewertung,
- physische Zutritts-, Besucher-, Schlüssel- und Schutzbereichsregelungen.
¶ 11.1 Modularer TOM-Musterkatalog: Governance und Organisation
Der folgende Katalog deckt typische TOM-Felder vollständig als Musterstruktur ab. Die Auswahl, Tiefe und konkrete Ausgestaltung werden je Verarbeitung, Risiko, Technik, Verantwortungsmodell und Vertrag festgelegt. Nicht anwendbare Bausteine werden nicht stillschweigend gelöscht, sondern mit Begründung bewertet.
| ID | TOM-Baustein | Typische Mustermaßnahmen | Prüfung und geschützter Nachweis |
|---|---|---|---|
| TOM-01 | Datenschutz- und Sicherheitsgovernance | Rollen, Verantwortlichkeiten, Vertretung, Richtlinien, Freigaben, Ressourcen, Trennung von Beratung und Entscheidung | Organigramm, Rollenbeschreibung, Freigabeprotokoll, Managementreview |
| TOM-02 | Personal, Vertraulichkeit und Kompetenz | Auswahl geeigneter Beschäftigter, Verpflichtung, On-/Offboarding, Schulungen, rollenbezogene Kompetenz, Umgang mit Verstößen | Verpflichtungsnachweis, Schulungsstand, Stichprobe On-/Offboarding, Kompetenzprüfung |
| TOM-03 | Projekt-, Beschaffungs- und Änderungssteuerung | Datenschutzprüfung vor Beschaffung oder Änderung, Privacy by Design, Freigabegates, sichere Entwicklung, Test- und Rückfallregeln | Projektgate, Datenschutzprüfung, Change-Ticket, Abnahme- und Rückfalltest |
| TOM-04 | Lieferanten, Auftragsverarbeiter und Cloud | Eignungsprüfung, Vertrag und Weisungen, TOM-Prüfung, Unterauftragnehmer, Standorte, Support, Vorfälle, Audit- und Exitregelungen | AVV, Lieferantenbewertung, Scope-Prüfung, Vertrags-/Konfigurationsabgleich, Exit-Test |
| TOM-05 | Vorfall-, Datenschutzverletzungs- und Notfallorganisation | Meldewege, Triage, Rollen, Erreichbarkeit, Beweissicherung, Risikobewertung, Meldeentscheidung, Wiederanlauf und Lessons Learned | Übungsprotokoll, Alarmtest, Fallakte, Zeitlinie, Maßnahmen- und Wirksamkeitsnachweis |
¶ 11.2 Modularer TOM-Musterkatalog: physische und technische Sicherheit
| ID | TOM-Baustein | Typische Mustermaßnahmen | Prüfung und geschützter Nachweis |
|---|---|---|---|
| TOM-06 | Zutritt und physische Schutzbereiche | Zonen, Ausweise/Schlüssel, Besucher, Begleitung, Schließung, Video-/Alarmtechnik, Datenträger- und Umweltschutz | Zutrittsreview, Besucherstichprobe, Schlüsselbestand, Alarm- und Funktionstest |
| TOM-07 | Identitäten und Authentifizierung | eindeutige Konten, sichere Registrierung, MFA, Passwort-/Passkey-Regeln, technische Konten, privilegierte Identitäten, Sperrung | Kontenstichprobe, MFA-Nachweis, Joiner-Mover-Leaver-Test, Prüfung technischer Konten |
| TOM-08 | Berechtigungen und Funktionstrennung | Least Privilege, Rollenmodelle, Genehmigung, regelmäßiger Review, privilegierte Zugriffe, Notfallkonten, Entzug | Rollen-/Rechteexport, Genehmigungsnachweis, Rezertifizierung, Entzugs- und Notfallkontentest |
| TOM-09 | Verschlüsselung und Schlüsselmanagement | Transport- und Speicherverschlüsselung, Schlüsseltrennung, Lebenszyklus, Rotation, Backup, Entzug, Zertifikate, Geheimnisse | Konfigurationsprüfung, Zertifikats-/Schlüsselregister, Rotations- und Wiederherstellungstest |
| TOM-10 | Pseudonymisierung und Trennungsgebot | Tokenisierung, getrenntes Zuordnungswissen, getrennte Zwecke/Mandanten/Umgebungen, kontrollierte Reidentifizierung | Datenflussprüfung, Trennungstest, Berechtigungsstichprobe, Reidentifizierungs- und Rückführungsregeln |
| TOM-11 | Sichere Übertragung und Schnittstellen | freigegebene Kanäle, Empfängerprüfung, Ende-zu-Ende-Schutz soweit erforderlich, API-Authentisierung, Integrität, Fehlversandschutz | Übertragungstest, API-/Schnittstellenprüfung, Fehlversandsimulation, Protokollauswertung |
| TOM-12 | Härtung, Schwachstellen, Patch und sichere Änderung | sichere Baselines, Inventar, Schwachstellenbewertung, risikobasierte Fristen, Patchen, Ausnahmen, sichere Entwicklung und Deployment | Baselinevergleich, Scan-/Patchnachweis, Ausnahmeregister, Stichprobe Änderung und Rollback |
| TOM-13 | Protokollierung, Überwachung und Alarmierung | erforderliche Ereignisse, Zeitabgleich, Manipulationsschutz, Zugriffsbegrenzung, Aufbewahrung, Alarme, Auswertung und Reaktion | Testereignis, Alarm- und Reaktionszeit, Log-Vollständigkeit, Berechtigungs- und Löschprüfung |
| TOM-14 | Verfügbarkeit, Belastbarkeit, Backup und Wiederherstellung | Sicherungsumfang, getrennte/geschützte Kopien, Redundanz, Kapazität, RTO/RPO, Wiederanlauf, Notbetrieb, Abhängigkeiten | Restore- und Wiederanlauftest, RTO-/RPO-Messung, Integritätsprüfung, dokumentierte Abweichungen |
| TOM-15 | Endgeräte, mobile Arbeit und Fernzugriff | Gerätemanagement, Verschlüsselung, Bildschirmsperre, Updates, Schutz vor Schadsoftware, sichere Netze, Remotezugriff, Verlustprozess | Gerätestichprobe, Konformitätsbericht, Fernzugriffs- und Sperrtest, Verlustübung |
¶ 11.3 Modularer TOM-Musterkatalog: Datenschutzprinzipien und Lebenszyklus
| ID | TOM-Baustein | Typische Mustermaßnahmen | Prüfung und geschützter Nachweis |
|---|---|---|---|
| TOM-16 | Datenminimierung und datenschutzfreundliche Voreinstellungen | erforderliche Felder, begrenzte Sichtbarkeit, sparsame Standardwerte, deaktivierte Zusatzfunktionen, Kopien- und Exportbegrenzung | Feld-/Maskenreview, Konfigurationsvergleich, Rollenstichprobe, Negativtest optionaler Funktionen |
| TOM-17 | Aufbewahrung, Löschung und Einschränkung | Fristauslöser, Regeln je Datenklasse/System, Sperre, Legal Hold, Löschläufe, Backups, Datenträger und Dienstleister | Löschstichprobe, Negativsuche, Protokoll, Restore-/Backup-Regel, Dienstleisterbestätigung |
| TOM-18 | Transparenz und Nachvollziehbarkeit | aktuelle Informationen, Versionen, Datenquellen, Zwecke, Empfänger, Entscheidungen, Protokolle und verantwortliche Rollen | Abgleich VVT–Hinweis–System, Versionsprüfung, Prozessstichprobe und Auskunftstest |
| TOM-19 | Intervenierbarkeit und Betroffenenrechte | Identitätsprüfung, Suche, Export, Berichtigung, Einschränkung, Löschung, Widerspruch, menschliche Überprüfung und sichere Antwort | Ende-zu-Ende-Test eines Musterfalls, Frist- und Vollständigkeitsnachweis, technische Negativprüfung |
| TOM-20 | Regelmäßige Prüfung und kontinuierliche Verbesserung | Prüfplan, Kriterien, Stichproben, technische Tests, Audits, Kennzahlen, Abweichungen, Ursachen, Korrektur und erneuter Test | Prüfbericht, Feststellung, Maßnahme, Owner, Termin, Retest und Managemententscheidung |
¶ 11.4 Auswahlregeln für die Bausteine
- Jeder verwendete Baustein erhält konkrete VVT-, Risiko-, System-, Standort- und Rollenbezüge.
- Ein Baustein kann mehrere Einzelmaßnahmen enthalten; jede kritische Einzelmaßnahme bleibt prüfbar.
- Derselbe technische Dienst kann mehrere Bausteine unterstützen, ersetzt aber keine getrennte Ziel- und Wirksamkeitsbewertung.
- „Nicht anwendbar“ benötigt Geltungsbereich, Begründung, prüfende Rolle und Reviewauslöser.
- Lieferantenmaßnahmen und eigene Konfigurationen des Verantwortlichen werden getrennt betrachtet.
- Details, die Angriffe erleichtern oder Schwachstellen offenlegen könnten, werden im öffentlichen Wiki nicht veröffentlicht.
¶ 12. Umsetzung steuern
Für jede Maßnahme werden festgelegt:
- konkrete Arbeitspakete und technische Zielkonfiguration,
- verantwortliche und ausführende Rollen,
- Ressourcen, Abhängigkeiten und Fristen,
- Test- und Abnahmekriterien,
- Übergangsmaßnahmen bis zur vollständigen Umsetzung,
- Rückfall-, Notfall- und Wiederherstellungsregeln,
- Dokumentations- und Nachweisanforderungen.
Abweichungen werden mit Risiko, Ursache, Entscheidung, befristeter Kompensation und Eskalation behandelt. Eine offene Abweichung gilt nicht stillschweigend als akzeptiert.
¶ 12.1 Vollständig ausgearbeiteter Beispielbaustein
Fiktives Beispiel: Der folgende Baustein beschreibt keine reale Konfiguration und keinen Wirksamkeitsnachweis. Er zeigt die erforderliche Dokumentationstiefe am Beispiel „Identitäten und Authentifizierung“.
| Feld | Musterinhalt |
|---|---|
| TOM-ID / Titel | TOM-07-001 – Identitäten und Authentifizierung für eine fiktive Cloud-Fachanwendung |
| Verarbeitung / Risiko | VVT-001; Risiko R-001: unbefugter Zugriff auf Kunden- und Ansprechpartnerdaten durch kompromittierte oder verwaiste Konten |
| Zielwirkung | Vertraulichkeit und Nachvollziehbarkeit erhöhen; Eintrittswahrscheinlichkeit unbefugter Zugriffe reduzieren |
| Geltungsbereich | Produktivmandant, Administrationsoberfläche, Identitätsprovider, Supportzugänge und technische Schnittstellen; konkrete Systeme geschützt dokumentieren |
| Sollzustand | ausschließlich eindeutige Konten; MFA für interaktive Zugriffe; privilegierte Rollen separat genehmigt; technische Konten mit Owner, Zweck, Ablauf und kontrolliertem Geheimnis |
| Organisatorische Umsetzung | Rollenmodell, Genehmigungsprozess, Vertretung, Joiner-Mover-Leaver-Ablauf, regelmäßige Rezertifizierung und dokumentierte Notfallzugriffe |
| Technische Umsetzung | zentrale Authentisierung, MFA-Richtlinie, gesperrte Altprotokolle, Sitzungsregeln, Alarmierung verdächtiger Anmeldungen und zeitnaher Kontenentzug |
| Owner / Betrieb | Prozesseigner und Informationssicherheit als Owner; IT-/Servicebetrieb als ausführende Rolle; Zuständigkeiten organisationsbezogen festzulegen |
| Status | Entwurf / nicht real umgesetzt; Beispielstatus darf nicht als Risikominderung angerechnet werden |
| Prüfmethode | Stichprobe normaler, privilegierter, technischer und ausgeschiedener Konten; Test von MFA, Entzug, Notfallzugriff und Alarmierung |
| Akzeptanzkriterien | alle Stichprobenkonten besitzen Owner und gültige Freigabe; MFA aktiv; ausgeschiedene Konten fristgerecht entzogen; Testalarm erkannt und bearbeitet; keine kritische Abweichung |
| Geschützte Nachweise | Richtlinienexport, Rollen-/Kontenliste, Freigaben, Testprotokoll, Alarm-/Reaktionsnachweis, Abweichungen und Retest – nur referenziert |
| Restrisiko / Entscheidung | nach bestandenem Test neu bewerten; offene technische Konten, Ausnahmen oder fehlende Alarmierung verhindern Status „wirksam“ |
| Reviewauslöser | Rollenänderung, neue Schnittstelle, Anbieter-/IdP-Wechsel, Vorfall, Prüfabweichung oder spätestens zum festgelegten Reviewtermin |
¶ 12.2 Interaktiver TOM-Baustein
Der Baustein-Assistent zeigt anhand frei erfundener Beispiele, welche Informationen und Nachweise für unterschiedliche TOM-Felder erwartet werden. Er speichert keine Eingaben und erzeugt weder eine fertige TOM-Dokumentation noch eine Freigabe.
¶
Aussagegrenze:
Entwurfshinweis: Die Auswahl bleibt eine Orientierung. Nur die geschützte, organisationsbezogene TOM-Akte enthält reale Systeme, Konfigurationen, Tests und Entscheidungen.
Ohne JavaScript bleiben der vollständige Musterkatalog und der statische Beispielbaustein lesbar.
¶ 13. Wirksamkeit prüfen
Artikel 32 Absatz 1 Buchstabe d verlangt ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit. Geeignete Prüfungen können sein:
| Prüfart | Beispiel für einen belastbaren Nachweis |
|---|---|
| Konfigurationsprüfung | dokumentierter Soll-Ist-Abgleich mit Version und Stichtag |
| technischer Test | Testprotokoll mit Umfang, Ergebnis, Abweichungen und Wiederholung |
| Berechtigungsreview | vollständige oder risikobasierte Stichprobe mit Entzugsnachweisen |
| Wiederherstellungstest | nachgewiesene Wiederanlaufzeit, Datenstand und festgestellte Lücken |
| Prozessstichprobe | reale Vorgänge zu Löschung, Rechten, Freigaben oder Änderungen |
| Protokoll- und Alarmtest | erzeugtes Testereignis, Erkennung, Eskalation und Reaktion |
| Lieferantenkontrolle | dienstbezogene Prüfung von Umsetzung, Geltungsbereich und Abweichungen |
| unabhängige Prüfung | Bericht mit passendem Scope, Zeitraum, Methodik und Feststellungen |
Ein Zertifikat, Prüfbericht oder Fragebogen ist nur insoweit verwertbar, wie Geltungsbereich, Aktualität und Aussage zur konkreten Maßnahme passen.
¶ 14. Wirksamkeitskriterien
Prüfkriterien werden möglichst vor der Umsetzung festgelegt und können umfassen:
- Zielkonfiguration vollständig und unverändert aktiv,
- nur befugte Zugriffe in geprüfter Stichprobe,
- definierte Wiederherstellungszeit und zulässiger Datenverlust erreicht,
- Lösch- oder Sperrregel im realen Prozess technisch wirksam,
- Alarm innerhalb vorgegebener Zeit erkannt und bearbeitet,
- keine kritische Abweichung im festgelegten Scope,
- Betroffenenrecht vollständig und fristgerecht technisch unterstützt,
- Maßnahme mindert das zugeordnete Risikoszenario wie erwartet.
Ein erfolgreiches Einzelereignis kann je nach Maßnahme noch keinen dauerhaften Wirksamkeitsnachweis darstellen.
¶ 15. Restrisiko und Entscheidung
Nach bestätigter Wirksamkeit werden betroffene Risiken vollständig neu bewertet. Dokumentiert werden:
- tatsächlich wirksame Maßnahmen,
- verbleibende Schwachstellen und Unsicherheiten,
- Wahrscheinlichkeit und Schwere nach Maßnahmen,
- Restrisikoklasse und Begründung,
- entscheidungsbefugte Rolle und Bedingungen,
- zusätzlicher Maßnahmenbedarf und Reviewtermin,
- DSFA- oder Konsultationsbezug bei hohem Risiko.
Eine Maßnahme mit unklarer oder veralteter Wirksamkeit wird nicht dauerhaft als voll wirksam fortgeschrieben.
¶ 16. Schnittstelle zum ISMS
ISMS-Kontrollen können als TOM referenziert werden, wenn:
- die konkrete Verarbeitung vom Geltungsbereich erfasst ist,
- betroffene Systeme, Dienste, Standorte und Rollen übereinstimmen,
- die Maßnahme das datenschutzbezogene Risikoszenario tatsächlich beeinflusst,
- Umsetzung und Wirksamkeit aktuell nachgewiesen sind,
- zusätzliche Anforderungen an Transparenz, Nichtverkettung, Intervenierbarkeit und Rechte berücksichtigt sind.
Das führende ISMS-Dokument oder der technische Nachweis wird referenziert statt unnötig dupliziert. Die datenschutzrechtliche Zuordnung und Entscheidung verbleibt im Datenschutzmanagement.
¶ 17. Auftragsverarbeiter und Lieferanten
Verantwortlicher und Auftragsverarbeiter setzen nach Artikel 32 angemessene Maßnahmen um. Für einen Dienst werden mindestens geprüft:
- dienstbezogene TOM statt allgemeiner Unternehmensdarstellung,
- Rollen, Verantwortungsgrenzen und Weisungsfähigkeit,
- Unterauftragnehmer, Standorte und internationale Zugriffe,
- technische Konfiguration und vom Kunden zu aktivierende Schutzfunktionen,
- Nachweise, Prüfberichte, Zertifikate und bekannte Abweichungen,
- Änderungsinformation, Vorfälle, Unterstützung und Exit,
- verbleibende eigene Maßnahmen des Verantwortlichen.
Eine Lieferantenselbstauskunft bestätigt nicht automatisch ausreichende Garantien oder Wirksamkeit.
¶ 18. Änderung und Außerbetriebnahme
Eine erneute Prüfung wird ausgelöst durch:
- neue oder geänderte Verarbeitung, Systeme, Daten oder Zwecke,
- neue Bedrohung, Schwachstelle oder Sicherheitsvorfall,
- Änderung von Stand der Technik oder Schutzanforderung,
- Änderung von Anbieter, Unterauftragnehmer, Land oder Betriebsmodell,
- unwirksame Prüfung, Auditfeststellung oder Beschwerde,
- geänderte Rechtslage, Aufsichtspraxis oder vertragliche Anforderung,
- Ablösung, Abschaltung oder Migration einer Maßnahme.
Bei Außerbetriebnahme werden Ersatz, Übergang, Daten- und Schlüsselbehandlung, Zugriffsrechte, Protokolle und Nachweise kontrolliert.
¶ 19. Geschützte Nachweise
- vollständiges TOM-Verzeichnis mit Ist-Zuständen,
- Architektur-, Datenfluss- und Konfigurationsunterlagen,
- Risiko-, VVT-, DSFA- und Projektreferenzen,
- technische Tests, Stichproben, Messungen und Protokolle,
- Berechtigungs-, Backup-, Restore-, Lösch- und Notfallnachweise,
- Lieferantenbewertungen, Verträge, Berichte und Abweichungen,
- Umsetzungs-, Freigabe- und Wirksamkeitsentscheidungen,
- Restrisikobewertungen, Korrekturmaßnahmen und Reviews,
- Änderungs- und Außerbetriebnahmenachweise.
Das öffentliche Wiki enthält nur Methodik, leere Struktur und kontrollierte Verweise. Sicherheitsrelevante Details bleiben geschützt.
¶ 20. Leeres TOM-Verzeichnis
| TOM-ID | VVT / Risiko / DSFA | Maßnahme und Geltungsbereich | Owner | Soll / Ist | Status | Prüfmethode und Kriterium | letzter Nachweis | Restrisiko / Abweichung | nächster Review |
|---|---|---|---|---|---|---|---|---|---|
| – | – | – | – | – | – | – | – | Kein realer Eintrag im Muster-Wiki | – |
¶ 21. Qualitätskontrolle
- Ist die Maßnahme konkreten Verarbeitungen und Risiken zugeordnet?
- Sind rechtliche Anforderung und erwartete Zielwirkung nachvollziehbar?
- Stimmen dokumentierter und technischer Geltungsbereich überein?
- Sind Soll, Ist, Owner, Frist und Status eindeutig?
- Werden geplante, umgesetzte, geprüfte und wirksame Zustände getrennt?
- Ist die Prüfmethode für die konkrete Maßnahme geeignet?
- Wurde das Wirksamkeitskriterium nachvollziehbar erreicht?
- Sind Zertifikate und Lieferantennachweise auf Scope und Aktualität geprüft?
- Wurde das Restrisiko nach bestätigter Wirkung neu bewertet?
- Sind Abweichungen, Kompensationen und Reviews wirksam gesteuert?
- Stimmen TOM-Verzeichnis, VVT, DSFA, ISMS und technische Praxis überein?
¶ 22. Verknüpfte Seiten
| Seite | Funktion |
|---|---|
| Verzeichnis von Verarbeitungstätigkeiten | Zweck, Verarbeitung, Systeme, Empfänger und TOM-Referenz |
| Datenschutz-Risikomethodik | Bewertung, Maßnahmenwirkung und Restrisiko |
| Datenschutz-Risikoregister | Risikoszenarien, Maßnahmen-IDs und Entscheidungen |
| DSFA-Prüfregister | Screening und DSFA-Entscheidung |
| Datenschutz-Folgenabschätzung | Maßnahmen für voraussichtlich hohe Risiken |
| Auftragsverarbeitung | TOM, Vertrag, Weisungen und Dienstleisterbetrieb |
| Auftragsverarbeiterregister | dienstbezogene Garantien, Nachweise und Reviews |
| ISMS IT-Betrieb und Änderungen / Zugriff und Berechtigungen | führende Sicherheitsregelungen und technische Kontrollen |
| Privacy by Design und by Default | frühe Projekt- und Technikgestaltung, Voreinstellungen und Freigaben |
| Lösch- und Aufbewahrungskonzept | Fristen, Sperren, Löschung, Backups und Nachweise |
| Testdaten, Anonymisierung und Pseudonymisierung | kontrollierte Datenwahl, Transformation, Testumgebung und Löschung |
| TOM-Prüfliste | öffentliches Prüfraster für Kontext, Status, Wirksamkeit und geschützte Nachweise |
¶ 23. Offizielle Grundlagen
- DSGVO, insbesondere Artikel 24, 25, 28, 32 und 35 – EUR-Lex
- Datenschutzkonferenz: Standard-Datenschutzmodell Version 3.1
- EDSA-Leitlinien 4/2019 zu Datenschutz durch Technikgestaltung und datenschutzfreundlichen Voreinstellungen – finale Fassung
- BSI: IT-Grundschutz
Normen, Standards und Zertifikate können die Auswahl und Prüfung unterstützen. Sie ersetzen nicht die konkrete datenschutzrechtliche Angemessenheits- und Wirksamkeitsbewertung.
¶ 24. Weiterführende Informationen von SMCT MANAGEMENT
Unterstützung bei TOM-Verzeichnis, Risikozuordnung, ISMS-Schnittstellen und Wirksamkeitsnachweisen
- Technische und organisatorische Maßnahmen nach Artikel 32 DSGVO
- Datenschutzmanagement
- Datenschutz-Leistungen
Erstgespräch unter info@smct-management.de vereinbaren
¶ 25. Änderungshistorie
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe |
|---|---|---|---|---|
| 1.0 | 10.08.2026 | Vollständigen modularen TOM-Musterkatalog mit 20 Bausteinen, Auswahlregeln, ausgearbeitetem Identitätsbeispiel, interaktivem TOM-Baustein, Qualitätsampel, SEO-Metadaten und Seitenkennzeichnung ergänzt | Datenschutzkoordination / Musterrolle | Ausstehend |
| 0.2 | 08.08.2026 | Privacy by Design, Lösch- und Aufbewahrungskonzept sowie Testdatenverfahren als vertiefende TOM-Schnittstellen verknüpft | Datenschutzkoordination / Musterrolle | Ausstehend |
| 0.1 | 08.08.2026 | Musterverfahren und leeres TOM-Verzeichnis mit Artikel-32-Kriterien, SDM-Gewährleistungszielen, Statusmodell, ISMS-Schnittstelle, Wirksamkeitsprüfung, Restrisiko und geschützten Nachweisen erstellt | Datenschutzkoordination / Musterrolle | Ausstehend |
Seite 1 von 1 · DSGVO-MA-05-03 · Version 1.0