Beispieldokument: Nicht freigegebene Mustermethodik für die fiktive „Muster GmbH“. Sie enthält keine realen Vorfälle, Schwellenwerte oder Behördenentscheidungen.
Perspektive: Bewertet werden mögliche Folgen für Rechte und Freiheiten natürlicher Personen – nicht nur Schaden, Reputation oder Betriebsunterbrechung des Unternehmens.
Entscheidungsregel:
kein Risiko,Risikoundhohes Risikowerden begründet unterschieden. Fehlende Informationen gelten als Unsicherheit, nicht automatisch als Entwarnung.
| Feld | Wert |
|---|---|
| Dokumenten-ID | DSGVO-VF-06-02 |
| Dokumentenart | Mustermethodik zur Verletzungs- und Risikobewertung |
| Wiki.js-Pfad | /DSGVO/06-Datenschutzverletzungen/Bewertung-von-Datenschutzverletzungen |
| Verantwortlich | festzulegende Incident-Verantwortung mit Datenschutzkoordination |
| Fachlich geprüft durch | Datenschutzbeauftragte/r, Informationssicherheit, IT, Recht und betroffene Fachrollen |
| Freigabe durch | Geschäftsführung beziehungsweise dokumentierte befugte Leitung |
| Status | Entwurf – Skalen, Befugnisse und Akzeptanzkriterien nicht organisationsbezogen freigegeben |
| Version | 1.0 |
| Stand | 09.08.2026 |
| Gültig ab | Nach Anpassung, Falltests und formaler Freigabe |
| Nächste Prüfung | Mindestens jährlich sowie nach Vorfällen, Übungen, Rechtsprechung oder Methodikänderung |
| Schutzklasse | Vertraulich; Vorfalldaten, Betroffene, Schwachstellen und Bewertungen geschützt |
| DSGVO-Bezug | Erwägungsgründe 75, 85 bis 88 sowie Artikel 4 Nummer 12, 33 und 34 DSGVO |
| Schnittstellen | Meldeweg, Register, Aufsicht, Betroffenenbenachrichtigung, TOM, ISMS Incident Response |
Die Bewertung verbindet bestätigte Fakten, mögliche Folgen für Menschen, Unsicherheiten und die getrennten Schwellen der Artikel 33 und 34. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
| Art | Leitfrage | Beispiele |
|---|---|---|
| Vertraulichkeit | Wurden Daten unbefugt offengelegt oder zugänglich? | Fehlversand, Kontoübernahme, offene Cloudfreigabe |
| Integrität | Wurden Daten unbefugt oder versehentlich verändert? | manipulierte Stammdaten, falsche Zuordnung, beschädigte Historie |
| Verfügbarkeit | Wurden Daten vernichtet, verloren oder nicht rechtzeitig verfügbar? | Ransomware, versehentliche Löschung ohne Restore, Systemausfall |
Ein Vorfall kann mehrere Arten gleichzeitig betreffen.
| Feld | Mindestinhalt |
|---|---|
| Incident-ID | eindeutige Referenz und Versionsstand |
| Kenntnis | Zeitpunkt und Grundlage hinreichender Gewissheit |
| Art / Ursache | Vertraulichkeit, Integrität, Verfügbarkeit und Auslöser |
| Daten | Kategorien, Sensibilität, Umfang, Identifizierbarkeit und Schutz |
| Personen | Gruppen, Anzahl, Schutzbedürftigkeit und Abhängigkeit |
| Empfänger / Angreifer | Zahl, Vertrauensstellung, Fähigkeiten, Motive und Rückruf |
| Dauer / Reichweite | Zeitraum, Systeme, Länder, Kopien und öffentliche Zugänglichkeit |
| Folgen | konkrete Szenarien für Rechte und Freiheiten |
| Maßnahmen | vorbestehend, nachträglich, umgesetzt, geprüft und wirksam |
| Unsicherheit | fehlende Fakten, Bandbreiten und nächste Klärung |
| Ergebnis | Risikostufe, Begründung, Meldungen und Entscheider |
Erhöhend wirken insbesondere Sensibilität, leichte Identifizierbarkeit, große Menge, viele Betroffene, Kinder oder Schutzbedürftige, öffentliche Verfügbarkeit, böswillige Empfänger, lange Dauer, fehlender Rückruf und irreversible Folgen.
Mindernd dürfen nur tatsächlich wirksame Faktoren berücksichtigt werden, etwa starke Verschlüsselung mit nicht kompromittiertem Schlüssel, nachgewiesener ungelesener Rückruf bei vertrauenswürdigem Empfänger oder schnelle vollständige Wiederherstellung. Eine bloß geplante Maßnahme mindert das Risiko nicht.
| Ergebnis | Artikel-33-Behördenmeldung | Artikel-34-Benachrichtigung | Dokumentation |
|---|---|---|---|
| Verletzung, Risiko unwahrscheinlich | grundsätzlich keine Meldung | keine Benachrichtigung | vollständig erforderlich |
| Verletzung, Risiko wahrscheinlich | Meldung ohne unangemessene Verzögerung, möglichst binnen 72 Stunden | gesonderte Hochrisikoprüfung | vollständig erforderlich |
| Verletzung, hohes Risiko wahrscheinlich | Behördenmeldung | Benachrichtigung ohne unangemessene Verzögerung, sofern keine Ausnahme | vollständig erforderlich |
| Sachlage noch offen | unverzüglich weiter untersuchen; Frist und mögliche stufenweise Meldung steuern | Schutzbedarf und Vorabkommunikation prüfen | Unsicherheit und Maßnahmen dokumentieren |
Aufgrund von
[Zugriff, Verlust oder Veränderung]können[Personen/Angreifer]die Daten[missbrauchen oder nicht nutzen]. Für[Personengruppe]kann daraus[konkrete Folge]entstehen. Die Wahrscheinlichkeit ist[Stufe], weil[Fakten/Unsicherheiten]; die Schwere ist[Stufe], weil[Reichweite/Dauer/Reversibilität].
Eine bloße Ampelfarbe oder Zahl ohne Szenario ist keine belastbare Entscheidung.
Bewertungen werden bei neuen Logs, Empfängerrückmeldungen, forensischen Erkenntnissen, veröffentlichten Daten, missbräuchlicher Nutzung oder geänderten Maßnahmen aktualisiert. Jede Version erhält Zeitpunkt, Änderungen und Entscheider.
Die Triage unterstützt die erste Strukturierung. Sie speichert keine Angaben, übernimmt keine Rechtsentscheidung und darf nicht mit realen Vorfalldaten in einem öffentlich lesbaren Wiki verwendet werden. Maßgeblich bleiben geschützte Vorfallakte, Faktenprüfung und befugte Entscheidung.
Entwurfshinweis: Der rechnerische Termin ist nur ein Steuerungshinweis. Kenntniszeitpunkt, Risiko und Meldepflicht werden fachlich bestätigt.
Eine Datei mit Kontaktdaten wird an eine falsche, aber bekannte Geschäftspartnerin gesendet. Die Organisation klärt Inhalt, Öffnung, Weiterleitung, Vertrauensstellung, Rückruf und bestätigte Löschung. Eine glaubhafte ungelesene Löschung kann das Risiko mindern, ersetzt aber weder Verletzungsfeststellung noch Dokumentation. Enthält die Datei Gesundheits- oder Konfliktdaten, steigt die mögliche Schwere deutlich.
Ein Notebook geht verloren. Bewertet werden nicht nur Geräteverlust, sondern Verschlüsselungsstärke, Schlüsselverwaltung, Sperrstatus, Benutzerkonto, lokale Daten, Fernzugriff, Backup und Hinweise auf Missbrauch. Wirksame Verschlüsselung mit nicht kompromittiertem Schlüssel kann das Risiko für Personen stark reduzieren. Eine bloße Herstellerangabe ohne geprüfte Konfiguration genügt nicht.
Systeme sind nicht verfügbar und Logs lassen zunächst offen, ob Daten exfiltriert wurden. Verfügbarkeitsverletzung und mögliche Vertraulichkeitsverletzung werden getrennt bewertet. Fehlende Beweise für Abfluss sind nicht automatisch Beweis, dass keiner stattfand. Die Organisation dokumentiert Unsicherheit, forensische Schritte, betroffene Prozesse, Folgen der Nichtverfügbarkeit, Meldefrist und mögliche stufenweise Meldung.
Die fachliche Bewertung wird von einer zweiten befugten Rolle geprüft. Sie kontrolliert Faktenbasis, Personengruppen, Szenarien, Schwere, Wahrscheinlichkeit, Minderungsmaßnahmen, Unsicherheit und Konsistenz mit Meldungsentwurf. Abweichende Auffassungen werden nicht gelöscht, sondern mit Entscheidung und Begründung dokumentiert.
Die Akte enthält mindestens Version, Kenntnisstand, Bewertende, verwendete Quellen, Annahmen, offene Ermittlungen, Artikel-33- und Artikel-34-Ergebnis, Freigabe, nächste Neubewertung und Verknüpfung zu Maßnahmen. Bei neuer Erkenntnis entsteht eine neue Version; die frühere Bewertung bleibt nachvollziehbar.

Erstgespräch unter info@smct-management.de vereinbaren
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe |
|---|---|---|---|---|
| 1.0 | 09.08.2026 | Ersttriage, Fallbeispiele, Vier-Augen-Prüfung und versionierte Entscheidungsakte ergänzt | Datenschutzkoordination / Musterrolle | Ausstehend |
| 0.1 | 08.08.2026 | Mustermethodik mit Verletzungsarten, Betroffenenfolgen, Risikofaktoren, Entscheidungsstufen, Unsicherheit und dynamischer Neubewertung erstellt | Datenschutzkoordination / Musterrolle | Ausstehend |