Category: IT-SICHERHEIT

Kaum ein IT-Prozess wird so oft unterschätzt wie das Schwachstellenmanagement. Firewalls, Verschlüsselung und Zugriffskonzepte greifen erst dann verlässlich, wenn die Systeme dahinter frei von bekannten, ausnutzbaren Lücken sind. Angreifer scannen das Internet automatisiert nach genau diesen Lücken, und die Zahl neu gemeldeter Schwachstellen wächst seit Jahren rasant. Ohne einen systematischen Prozess bleibt die Frage offen, welche der hunderten offenen Punkte zuerst geschlossen werden müssen.

Gerade im Mittelstand, wo die IT-Sicherheit im Mittelstand häufig auf wenigen Schultern ruht, entscheidet ein strukturiertes Vorgehen darüber, ob knappe Ressourcen auf die wirklich kritischen Risiken gelenkt werden. Dieser Leitfaden erklärt, was Schwachstellenmanagement ist, wie es sich von verwandten Begriffen abgrenzt, wie der Prozess Schritt für Schritt abläuft und wie er sich in ein ISMS nach ISO 27001 einfügt.

Was ist Schwachstellenmanagement?

Schwachstellenmanagement ist der kontinuierliche, systematische Prozess, mit dem eine Organisation Sicherheitslücken in ihrer IT-Infrastruktur aufdeckt, hinsichtlich ihres Risikos bewertet, behebt und die Wirksamkeit der Maßnahmen überprüft. Gemeint sind damit technische Schwachstellen in Betriebssystemen, Anwendungen, Netzwerkkomponenten, Cloud-Diensten und Firmware, aber auch Fehlkonfigurationen wie offene Ports oder Standardpasswörter.

Der entscheidende Punkt: Es handelt sich nicht um eine einmalige Aktion, sondern um einen Kreislauf. Neue Schwachstellen werden täglich veröffentlicht, Systeme ändern sich, und was gestern sicher konfiguriert war, kann heute angreifbar sein. Ein reifer Prozess läuft daher dauerhaft und begleitet jedes System vom Einsatz bis zur Außerbetriebnahme.

Zur Einordnung hilft die Abgrenzung dreier Begriffe: Eine Schwachstelle (Vulnerability) ist eine ausnutzbare Schwäche in einem System. Eine Bedrohung (Threat) ist ein potenzielles Ereignis, das diese Schwäche ausnutzt. Ein Risiko ist die Kombination aus Eintrittswahrscheinlichkeit und Schadenshöhe. Schwachstellenmanagement setzt bei der ersten Größe an, denn Schwachstellen sind die einzige der drei, die eine Organisation direkt und selbst beseitigen kann.

Vulnerability Management, Schwachstellenanalyse und Pentest: die Abgrenzung

Die Begriffe werden im Alltag oft synonym verwendet, meinen aber Unterschiedliches. Wer sie sauber trennt, plant seine Sicherheitsmaßnahmen zielgerichteter.

Vereinfacht gilt: „Vulnerability Management” ist der englische Oberbegriff für das gesamte Schwachstellenmanagement. Die Schwachstellenanalyse ist ein Bestandteil davon, der Scan liefert die Rohdaten, und der Pentest ergänzt die automatisierte Suche um die manuelle Perspektive eines Angreifers, die auch logische Fehler und Verkettungen mehrerer kleiner Schwächen findet, die kein Scanner erkennt.

Der Schwachstellenmanagement-Prozess in fünf Schritten

In der Praxis hat sich ein Kreislauf aus fünf Phasen bewährt. Er lässt sich unabhängig von Branche und Unternehmensgröße anwenden und beginnt nach dem letzten Schritt wieder von vorn.

1. Identifikation: Asset-Inventar, Scans und CVE-Feeds

Am Anfang steht die einfache Wahrheit, dass sich nur schützen lässt, was bekannt ist. Grundlage ist deshalb ein aktuelles Asset-Inventar aller Server, Clients, Netzwerkgeräte, Anwendungen und Cloud-Dienste. Auf dieser Basis suchen automatisierte Schwachstellenscanner nach bekannten Lücken, indem sie die installierten Versionen und Konfigurationen mit öffentlichen Schwachstellendatenbanken abgleichen.

Die zentrale Referenz dafür sind CVE-Einträge (Common Vulnerabilities and Exposures), eindeutige Kennungen für öffentlich bekannte Schwachstellen. Angereichert werden sie unter anderem über die National Vulnerability Database (NVD) des NIST. Ergänzend liefern Hersteller-Advisories und CVE-Feeds laufend Meldungen zu neuen Lücken. Die Menge ist erheblich: Die Zahl der jährlich gemeldeten CVEs ist zwischen 2020 und 2025 um mehrere Hundert Prozent gestiegen, weshalb NIST seine NVD-Prozesse 2026 neu priorisiert hat.

2. Bewertung und Priorisierung: CVSS im Geschäftskontext

Ein Scan liefert schnell hunderte Treffer. Ohne Priorisierung ist diese Liste wertlos, denn niemand kann alles gleichzeitig beheben. Der etablierte Standard zur Einordnung der Schwere ist das Common Vulnerability Scoring System (CVSS), das jeder Schwachstelle einen Basiswert von 0 bis 10 zuweist.

Die aktuelle Version CVSS v4.0 (veröffentlicht Ende 2023) ergänzt den Basiswert um Threat- und Environmental-Metriken, mit denen sich die tatsächliche Bedrohungslage und die eigene Umgebung abbilden lassen. Wichtig ist das Verständnis, dass der Basiswert allein nicht über die Priorität entscheidet. Eine „kritische” Lücke auf einem isolierten Testsystem ohne Datenbezug ist weniger dringlich als eine „mittlere” Lücke auf einem öffentlich erreichbaren Produktivserver.

Zwei Faktoren gehören deshalb zwingend in die Bewertung: der Geschäftskontext des betroffenen Assets und die Frage, ob eine Schwachstelle aktiv ausgenutzt wird. Ein starkes Signal dafür ist die Aufnahme in den Known-Exploited-Vulnerabilities-Katalog (KEV) der US-Behörde CISA, der Schwachstellen listet, für die eine Ausnutzung in freier Wildbahn belegt ist. Genau diese Verbindung von technischer Schwere und geschäftlicher Auswirkung ist der Kern jeder belastbaren Risikobewertung nach ISO 27001.

3. Behebung: Patch-Management, Kompensation oder Risikoakzeptanz

Für jede priorisierte Schwachstelle gibt es grundsätzlich drei Wege. Der Regelfall ist die Behebung durch Patch-Management, also das Einspielen von Sicherheitsupdates der Hersteller in geordneten, getesteten Abläufen. Ein sauberer Patch-Prozess umfasst das Testen vor dem Ausrollen, ein definiertes Wartungsfenster und einen Rückfallplan.

Ist ein Patch noch nicht verfügbar oder aus Kompatibilitätsgründen nicht sofort einspielbar, greifen kompensierende Maßnahmen: Segmentierung des Netzwerks, Deaktivieren betroffener Dienste, zusätzliche Zugriffsbeschränkungen oder Virtual Patching über eine Web Application Firewall. Der dritte Weg ist die bewusste, dokumentierte Risikoakzeptanz für Fälle, in denen Aufwand und Nutzen einer Behebung in keinem Verhältnis stehen. Entscheidend ist, dass diese Akzeptanz eine begründete Entscheidung der richtigen Ebene ist und nicht ein stilles Liegenlassen.

4. Verifikation: Rescan und Retest

Eine Maßnahme gilt erst dann als erledigt, wenn ihre Wirksamkeit belegt ist. Nach der Behebung prüft ein erneuter Scan oder ein gezielter Retest, ob die Schwachstelle tatsächlich geschlossen wurde und dabei keine neuen Probleme entstanden sind. Dieser Schritt wird häufig übersprungen, ist aber der eigentliche Nachweis, dass der Prozess funktioniert, und in einem Audit unverzichtbar.

5. Reporting und kontinuierliche Verbesserung

Den Abschluss bildet die Auswertung: Kennzahlen wie die durchschnittliche Zeit bis zur Behebung, die Zahl offener kritischer Schwachstellen und die Einhaltung der eigenen Fristen machen den Sicherheitsstand messbar und für die Geschäftsführung greifbar. Aus diesen Erkenntnissen werden Verbesserungen abgeleitet, womit der Kreislauf von neuem beginnt.

Schwachstellenmanagement in der ISO 27001 (A.8.8)

In einem Informationssicherheits-Managementsystem nach ISO 27001 ist Schwachstellenmanagement kein optionaler Zusatz, sondern eine explizite Anforderung. Die Norm in der Fassung von 2022 adressiert das Thema in Control A.8.8 „Handhabung technischer Schwachstellen”. Verlangt wird ein dokumentiertes Verfahren, das technische Schwachstellen rechtzeitig identifiziert, die eigene Betroffenheit bewertet und geeignete Maßnahmen einleitet, samt Nachweis aller Aktivitäten.

Die Neufassung 2022 hat den Fokus bewusst verschoben: weg von einer rein reaktiven „Patcherei” hin zu einem proaktiven Risikomanagement. Die konkrete Umsetzungsanleitung liefert die begleitende Norm ISO/IEC 27002:2022 im gleichnamigen Abschnitt 8.8. A.8.8 ist dabei eine von 93 Maßnahmen des Anhangs A, die sich auf die vier Themenbereiche organisatorisch, personenbezogen, physisch und technologisch verteilen.

Für die Praxis bedeutet das: Der oben beschriebene Fünf-Schritte-Prozess ist genau der Nachweis, den ein Auditor sehen will. Klare Verantwortlichkeiten, definierte Fristen, dokumentierte Risikoentscheidungen und belegte Rescans machen die Control erfüllbar. Wie sich A.8.8 in den größeren Rahmen aus Scoping, Risikoanalyse und Maßnahmenauswahl einfügt, zeigt der Leitfaden zum Aufbau eines ISMS nach ISO 27001 im Detail.

Werkzeuge und Methoden im Überblick

Kein einzelnes Werkzeug deckt alle Schwachstellen ab. In der Praxis kombinieren Organisationen mehrere Kategorien, abgestimmt auf ihre Systemlandschaft:

• Netzwerk- und Infrastruktur-Scanner: prüfen Server, Clients und Netzwerkkomponenten auf bekannte CVEs und Fehlkonfigurationen. Es existieren etablierte kommerzielle wie quelloffene Lösungen.
• Authentifizierte Scans: melden sich mit Zugangsdaten am System an und liefern ein deutlich vollständigeres Bild als reine Netzwerk-Scans von außen.
• Web-Application-Scanner: untersuchen Webanwendungen gezielt auf typische Schwächen wie fehlerhafte Eingabevalidierung.
• Software Composition Analysis (SCA): deckt verwundbare Open-Source-Bibliotheken und Abhängigkeiten in eigenentwickelter Software auf.
• Penetrationstests: ergänzen die Automatisierung um die manuelle Angreiferperspektive und finden logische Fehler und Angriffsketten, die Scanner nicht erkennen.

Die Werkzeugwahl ist dabei sekundär gegenüber dem Prozess. Ein Scanner, dessen Ergebnisse niemand priorisiert und nachverfolgt, erzeugt nur eine lange Liste ohne Wirkung. Umgekehrt macht ein klarer Prozess auch mit überschaubaren Mitteln einen messbaren Unterschied.

Häufige Fehler im Schwachstellenmanagement

Auch mit guten Werkzeugen scheitern Programme immer wieder an denselben Punkten. Diese Stolperfallen sollten Sie kennen:

1. Scannen ohne Priorisierung:
Wer alle Treffer als gleich dringlich behandelt, überlastet das Team und schließt am Ende oft die falschen Lücken zuerst. Ohne Kontext- und Ausnutzbarkeitsbewertung bleibt der Scan Selbstzweck.

2. Unvollständiges Asset-Inventar:
Vergessene Testserver, veraltete Systeme oder Schatten-IT tauchen im Scan nicht auf und bleiben damit ungeschützt. Blinde Flecken im Inventar sind blinde Flecken in der Sicherheit.

3. Fehlende Verifikation:
Eine als „behoben” markierte Schwachstelle ohne Rescan ist eine Annahme, kein Nachweis. Ohne diesen Schritt bleibt offen, ob der Patch tatsächlich gegriffen hat.

4. Reaktion statt Prozess:
Wer erst bei einem akuten Vorfall handelt, ist strukturell zu spät. Schwachstellenmanagement entfaltet seinen Wert nur als dauerhafter Kreislauf mit festen Zuständigkeiten und Fristen.

Fazit: Ein Kreislauf, kein Projekt

Schwachstellenmanagement ist die stille Grundlage jeder wirksamen IT-Sicherheit. Es sorgt dafür, dass bekannte Lücken systematisch gefunden, nach ihrem tatsächlichen Risiko priorisiert und nachweisbar geschlossen werden, bevor Angreifer sie ausnutzen. Der Schlüssel liegt weniger im teuersten Scanner als im gelebten Prozess: Identifikation, Bewertung, Behebung, Verifikation und Reporting im ständigen Kreislauf.

Wer diesen Prozess in ein ISMS nach ISO 27001 einbettet, erfüllt nicht nur die Control A.8.8, sondern gewinnt vor allem einen klaren, planbaren Umgang mit einem Risiko, das ohne Struktur schnell unübersichtlich wird. Mit definierten Fristen, sauberer Nachweisführung und der richtigen Werkzeugunterstützung wird aus einer Pflichtübung ein belastbarer Baustein Ihrer Sicherheitsstrategie.

Häufige Fragen (FAQ)

Was ist der Unterschied zwischen Schwachstellenmanagement und einem Schwachstellenscan?

Ein Schwachstellenscan ist ein einzelner technischer Schritt, der automatisiert nach bekannten Lücken sucht. Schwachstellenmanagement ist der übergeordnete, fortlaufende Prozess, der den Scan einbettet und um Bewertung, Priorisierung, Behebung, Verifikation und Reporting ergänzt. Der Scan liefert Rohdaten, das Management macht daraus gesteuertes Handeln.

Wie oft sollte man Schwachstellenscans durchführen?

Ein fester Turnus allein greift zu kurz. Bewährt hat sich eine Kombination aus regelmäßigen Scans (etwa wöchentlich oder monatlich, je nach Kritikalität der Systeme) und anlassbezogenen Scans nach wesentlichen Änderungen oder bei Bekanntwerden schwerwiegender neuer Schwachstellen. Kritische, öffentlich erreichbare Systeme werden häufiger geprüft als interne, gut abgeschottete.

Ist Schwachstellenmanagement für die ISO 27001 verpflichtend?

Ja. Die ISO 27001:2022 verlangt in Control A.8.8 ein dokumentiertes Verfahren zur Handhabung technischer Schwachstellen. Wer eine Zertifizierung anstrebt, muss einen nachvollziehbaren Prozess mit klaren Verantwortlichkeiten, Fristen und Nachweisen vorweisen können.

Was bedeutet der CVSS-Score und reicht er zur Priorisierung aus?

Der CVSS-Score (0 bis 10) bewertet die technische Schwere einer Schwachstelle und teilt sie in die Stufen niedrig, mittel, hoch und kritisch ein. Als alleiniger Maßstab reicht er nicht: Erst der Geschäftskontext des betroffenen Assets und die Frage, ob die Lücke aktiv ausgenutzt wird, ergeben die tatsächliche Priorität.

Ersetzt ein Penetrationstest das Schwachstellenmanagement?

Nein. Ein Pentest ist eine periodische Tiefenprüfung, die die manuelle Angreiferperspektive einbringt. Er ergänzt das Schwachstellenmanagement, ersetzt aber nicht dessen kontinuierlichen Kreislauf aus laufenden Scans, Priorisierung und nachgewiesener Behebung.

Eine E-Mail mit Kundendaten ging an den falschen Verteiler, ein Laptop wurde gestohlen, ein Verschlüsselungstrojaner hat zugeschlagen: In dem Moment, in dem so etwas passiert, tickt eine Uhr. Die DSGVO gibt Ihnen nur 72 Stunden, um eine meldepflichtige Datenpanne bei der Aufsichtsbehörde anzuzeigen. Dieser Guide zeigt Schritt für Schritt, wann Sie melden müssen, wie der Ablauf aussieht und welche Angaben in die Meldung gehören – inklusive ausfüllbarer Vorlage.

Was ist eine Datenpanne im Sinne der DSGVO?

Der umgangssprachliche Begriff „Datenpanne” heißt in der DSGVO Verletzung des Schutzes personenbezogener Daten. Nach Art. 4 Nr. 12 DSGVO ist das jede Verletzung der Sicherheit, die zur Vernichtung, zum Verlust, zur Veränderung oder zur unbefugten Offenlegung von bzw. zum unbefugten Zugang zu personenbezogenen Daten führt. Fachlich unterscheidet man drei Ausprägungen:

• Verletzung der Vertraulichkeit – Unbefugte erhalten Zugang zu Daten (z. B. Fehlversand, Hackerangriff, gestohlener Datenträger).
• Verletzung der Integrität – Daten werden unbefugt oder versehentlich verändert.
• Verletzung der Verfügbarkeit – Daten gehen verloren oder sind nicht mehr zugänglich (z. B. Ransomware, gelöschtes Backup).

Typische Beispiele aus der Praxis sind der Versand einer E-Mail mit offenem Empfängerverteiler (CC statt BCC), ein verlorener USB-Stick mit Personaldaten, ein Ransomware-Angriff oder ein an die falsche Adresse verschickter Bescheid. Ob es sich zugleich um eine Verletzung der Informationssicherheit handelt, ist eine verwandte, aber eigene Frage – die Abgrenzung zwischen Datenschutz und Informationssicherheit hilft, beide Perspektiven auseinanderzuhalten.

Die 72-Stunden-Frist: Was Art. 33 DSGVO verlangt

Der Verantwortliche meldet die Verletzung der zuständigen Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden. Zwei Punkte sind dabei entscheidend:

• Ausnahme „kein Risiko”: Eine Meldung ist entbehrlich, wenn die Verletzung voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt. Diese Einschätzung müssen Sie begründen und dokumentieren.
• Verspätete Meldung: Schaffen Sie die 72 Stunden nicht, ist die Meldung trotzdem nachzuholen – dann aber mit einer Begründung für die Verzögerung.

Wenn Sie als Auftragsverarbeiter eine Panne feststellen, melden Sie diese nicht selbst an die Behörde, sondern unverzüglich an den Verantwortlichen, für den Sie die Daten verarbeiten. Dieser entscheidet über die Meldung.

Der Melde-Ablauf in sechs Schritten

Ein klarer Ablauf verhindert, dass in der Hektik des Vorfalls Zeit verloren geht. Die folgende Reihenfolge hat sich bewährt:

Wer die Meldung übernimmt und die Bewertung verantwortet, hängt von Ihrer Organisation ab. In vielen Unternehmen ist das der Datenschutzbeauftragte – wann dieser überhaupt Pflicht ist, klärt unser Beitrag zur DSB-Pflicht. Fehlt intern die Kapazität, übernimmt oft ein externer Datenschutzbeauftragter für KMU die Fristenkontrolle und die Kommunikation mit der Behörde.

Ob sich ein externer gegenüber einem internen Datenschutzbeauftragten rechnet, hängt von Unternehmensgröße und Fallzahl ab – ein Kosten-Nutzen-Vergleich beider Modelle schafft hier Klarheit.

Muss ich auch die betroffenen Personen informieren?

Nicht immer – aber immer dann, wenn die Datenpanne voraussichtlich ein hohes Risiko für die Rechte und Freiheiten der betroffenen Personen zur Folge hat. In diesem Fall verlangt Art. 34 DSGVO, dass Sie die Betroffenen unverzüglich und in klarer, einfacher Sprache benachrichtigen, damit sie sich schützen können (etwa Passwörter ändern oder Konten überwachen).

Die Benachrichtigung der Betroffenen kann entfallen, wenn eine der folgenden Bedingungen erfüllt ist:

• Die betroffenen Daten waren durch geeignete Maßnahmen wie eine starke Verschlüsselung für Unbefugte unbrauchbar.
• Sie haben durch nachträgliche Maßnahmen dafür gesorgt, dass das hohe Risiko aller Wahrscheinlichkeit nach nicht mehr eintritt.
• Die individuelle Benachrichtigung wäre mit unverhältnismäßigem Aufwand verbunden – dann ist eine öffentliche Bekanntmachung zulässig.

Melde-Vorlage: diese Angaben braucht die Aufsichtsbehörde

Die Meldung nach Art. 33 Abs. 3 DSGVO muss einen Mindestinhalt haben. Nutzen Sie die folgende Vorlage, um im Ernstfall keine Angabe zu vergessen – die meisten Aufsichtsbehörden fragen genau diese Felder in ihrem Online-Formular ab:

Liegen noch nicht alle Informationen vor, dürfen Sie die Angaben schrittweise nachreichen. Wichtig ist, die 72-Stunden-Meldung nicht zu verzögern, nur weil einzelne Details noch offen sind.

An welche Behörde wird gemeldet?

Zuständig ist die Datenschutz-Aufsichtsbehörde des Bundeslandes, in dem Ihr Unternehmen seinen Sitz hat. Die Landesbehörden stellen dafür in der Regel ein Online-Meldeformular bereit, das Sie direkt ausfüllen können. Für Unternehmen mit Niederlassungen in mehreren EU-Staaten gilt das Prinzip der federführenden Behörde am Ort der Hauptniederlassung.

Die DSGVO ist nicht das einzige Regelwerk mit engen Meldefristen: Für Betreiber wichtiger oder besonders wichtiger Einrichtungen gelten unter der NIS2-Richtlinie eigene, teils noch kürzere Fristen. Wie diese aussehen, zeigt unsere Checkliste zur NIS2-Meldepflicht mit Fristen.

Bußgelder und Dokumentationspflicht: was auf dem Spiel steht

Wer eine meldepflichtige Datenpanne nicht, zu spät oder unvollständig meldet, riskiert ein Bußgeld von bis zu 10 Mio. Euro oder 2 % des weltweiten Jahresumsatzes (Art. 83 Abs. 4 DSGVO) – je nachdem, welcher Betrag höher ist. Kommt ein zugrunde liegender Datenschutzverstoß hinzu, kann der Rahmen sogar bei 20 Mio. Euro bzw. 4 % liegen.

Unabhängig davon gilt die Dokumentationspflicht nach Art. 33 Abs. 5 DSGVO: Sie müssen jede Datenpanne intern erfassen – auch die, die Sie als nicht meldepflichtig einstufen. Diese Dokumentation ist Ihr Nachweis gegenüber der Aufsichtsbehörde, dass Sie den Vorfall bewertet und richtig gehandelt haben. Wie sich solche Nachweis- und Datenschutzpflichten im Mittelstand mit vertretbarem Aufwand erfüllen lassen, ordnet unser Überblick zu Datenschutz im Mittelstand – Kosten und Pflichten ein.

Datenpannen vorbeugen statt nur melden

Vorbeugung heißt vor allem, die passenden technischen und organisatorischen Maßnahmen nach Art. 32 DSGVO festzulegen und aktuell zu halten – von Zugriffskontrolle über Verschlüsselung bis zum getesteten Backup.

Die beste Meldung ist die, die nie nötig wird. Die meisten Datenpannen entstehen nicht durch spektakuläre Hackerangriffe, sondern durch Alltagsfehler: falsche Empfänger, verlorene Geräte, schwache Zugriffsrechte. Wer technische und organisatorische Maßnahmen systematisch steuert, senkt sowohl die Häufigkeit als auch die Schwere solcher Vorfälle – und hat im Ernstfall Ablauf, Zuständigkeiten und Dokumentation bereits geregelt. Eine ISMS-Software hilft dabei, Risiken, Maßnahmen und Meldeprozesse an einer Stelle zu bündeln, statt sie im Vorfall erst zu improvisieren.

Häufige Fragen (FAQ)

Wie lange habe ich Zeit, eine Datenpanne zu melden?

Grundsätzlich unverzüglich und möglichst binnen 72 Stunden, nachdem Ihnen die Datenpanne bekannt geworden ist. Die Frist läuft kalendarisch, also auch über Wochenenden und Feiertage.

Muss ich jede Datenpanne melden?

Nein. Meldepflichtig ist sie nur, wenn ein Risiko für die Rechte und Freiheiten der betroffenen Personen besteht. Dokumentieren müssen Sie aber jede Panne, auch die nicht meldepflichtige.

Was passiert, wenn ich die 72 Stunden verpasse?

Die Meldung ist dennoch nachzuholen, dann mit einer Begründung für die Verzögerung. Ein Versäumnis kann mit einem Bußgeld von bis zu 10 Mio. Euro oder 2 % des weltweiten Jahresumsatzes geahndet werden.

Wann muss ich die betroffenen Personen informieren?

Wenn die Datenpanne voraussichtlich ein hohes Risiko für die betroffenen Personen mit sich bringt (Art. 34 DSGVO). Waren die Daten etwa stark verschlüsselt oder wurde das hohe Risiko nachträglich beseitigt, kann die Benachrichtigung entfallen.

Wer meldet die Panne, wenn ein Dienstleister sie verursacht?

Der Auftragsverarbeiter meldet die Verletzung unverzüglich an den Verantwortlichen. Die Meldung an die Aufsichtsbehörde verantwortet der Verantwortliche, nicht der Dienstleister.