

KRITIS, NIS2, DORA – drei Kürzel, die in vielen Unternehmen gerade gleichzeitig aufschlagen. Und fast immer passiert dabei dasselbe: Es wird erst mal gesammelt. Anforderungen, Pflichten, Leitfäden, Listen, Zuständigkeiten. Dann entstehen Workstreams. Dann entstehen Überschneidungen. Und irgendwann stellt jemand die richtige Frage: „Moment – was davon betrifft uns wirklich, und wie vermeiden wir Doppelarbeit?“
Dieser Beitrag ist eine Landkarte. Nicht im Sinne eines juristischen Kommentars, sondern als Orientierung für Praktiker: Welche Themen liegen wo, was ist ähnlich, was ist wirklich anders – und welche Entscheidungen sollten Sie früh treffen, damit Sie nicht ein Jahr lang parallel aneinander vorbeiarbeiten. Ich vermeide bewusst Nebelbegriffe. Stattdessen arbeite ich mit einem einfachen Prinzip: Pflichten sind nur dann hilfreich, wenn sie sich in einen betrieblichen Ablauf übersetzen lassen.
Das wichtigste Missverständnis gleich am Anfang: KRITIS, NIS2 und DORA sind keine drei Varianten derselben Sache. Sie haben Überschneidungen, ja. Aber sie wurden für unterschiedliche Zielgruppen und unterschiedliche Risikorealitäten gebaut. Wenn man das nicht akzeptiert, macht man entweder zu viel (teuer, zäh, ungeliebt) oder zu wenig (Audit- und Aufsichtsstress).
Damit die Landkarte funktioniert, brauchen wir zwei einfache Blickrichtungen. Erstens: Für wen gilt was? (Branche, Rechtsraum, Rolle im Markt.) Zweitens: Was ist der Kernmechanismus? (Schutz, Meldung, Steuerung, Nachweis, Resilienz.) Wenn Sie diese zwei Fragen sauber beantworten, wird vieles automatisch klarer.
1) Der schnelle Überblick: Worum es in den drei Regimen im Kern geht
KRITIS (vereinfacht gesagt) betrachtet kritische Infrastrukturen: Die Gesellschaft soll auch dann funktionieren, wenn es Störungen gibt. KRITIS ist damit sehr stark am „Versorgungsauftrag“ orientiert und setzt häufig an Mindeststandards, Meldewegen und konkreter Schutzorganisation an.
NIS2 ist breiter und stärker als NIS1: Es adressiert eine große Menge an „wichtigen“ und „wesentlichen“ Einrichtungen, setzt Erwartungen an Sicherheitsmaßnahmen, Verantwortlichkeit und Meldung. Es ist weniger „Sektor-Sonderwelt“ als KRITIS, aber dafür mit einer klaren Erwartung: Sicherheit und Resilienz sind Chefsache und müssen im Betrieb funktionieren.
DORA ist wiederum sehr spezifisch: Finanzsektor und dessen IKT-Risiken – mit einem starken Fokus auf operative Resilienz, Nachweise, Tests und Drittparteiensteuerung. DORA fragt weniger: „Habt ihr ein ISMS?“ und mehr: „Kann das Unternehmen Störungen und Abhängigkeiten beherrschen – und kann es das belegen?“
Wenn Sie es als Bild mögen: KRITIS ist stark auf „Versorgungsschutz“ und strukturierte Sicherheitsorganisation ausgerichtet, NIS2 ist die breite „Sicherheits- und Governance-Schicht“ für viele Branchen, und DORA ist die „Resilienz- und Nachweismaschine“ für den Finanzsektor.
2) Die erste Landkarten-Achse: Geltungsbereich ohne Panik
Die häufigste Ursache für Nebel ist nicht Unwissen, sondern Unsicherheit: „Sind wir betroffen?“ und „Wenn ja, wie stark?“ Hier hilft eine pragmatische Vorgehensweise, die ohne stundenlange Legal-Diskussionen auskommt.
Frage A: In welchem Sektor sind wir unterwegs?
Wenn Sie klar im Finanzsektor unterwegs sind (oder dort als Dienstleister tief eingebunden), ist DORA sehr wahrscheinlich relevant – entweder direkt oder indirekt, weil Kunden die Anforderungen in Verträge, Kontrollen und Nachweise drücken. Wenn Sie in vielen anderen Sektoren sind, ist NIS2 häufig der dominante Rahmen. Wenn Sie in kritischen Versorgungsbereichen sind, können KRITIS-Logiken zusätzlich greifen.
Frage B: Welche Rolle haben wir in der Wertschöpfung?
Viele Unternehmen sind nicht „Regulierte“, aber sie sind Teil der Lieferkette. Das ist praktisch oft fast genauso relevant: Wenn Ihr Kunde reguliert ist, werden Sie über Third-Party-Anforderungen, Audits, Mindeststandards und Eskalationswege in die Pflicht genommen. Das ist keine Paragrafenfrage, sondern eine Marktrealität. Wer zentrale IT-Services liefert, kann sich der Erwartung nicht entziehen.
Frage C: Welche Services sind kritisch?
Unabhängig vom Rechtsrahmen: Kritische Services sind der Punkt, an dem Aufsicht, Audit und Betrieb zusammenkommen. Wenn Sie diese Services sauber identifizieren und steuern, können Sie Pflichten viel leichter bündeln.
Das klingt banal, ist aber in vielen Unternehmen der Unterschied zwischen „wir sind betroffen“ und „wir wissen, was wir tun müssen“.
3) Die zweite Landkarten-Achse: Themenblöcke, die wirklich zählen
Statt Pflichten in Paragraphen zu sortieren, sortieren wir sie in sechs Themenblöcke. Diese sechs Blöcke decken in der Praxis 90% dessen ab, was später im Audit und im Betrieb zählt. Und sie zeigen sehr klar, wo Überschneidungen liegen – und wo echte Unterschiede beginnen.
Block 1: Governance & Verantwortlichkeit
Alle drei Regime wollen Verantwortlichkeit. Der Unterschied liegt in der Schärfe und in der Erwartung an Sichtbarkeit. NIS2 betont Managementverantwortung sehr deutlich. DORA erwartet nicht nur Verantwortlichkeit, sondern auch eine Steuerungslogik, die in Kennzahlen, Tests und Nachweisen sichtbar wird. KRITIS ist stark in konkreter Sicherheitsorganisation und Mindeststandards, oft mit klaren Melde- und Schutzpflichten.
Praktischer Schluss: Wenn Sie heute Governance aufsetzen, designen Sie sie nicht als „Gremium“, sondern als Entscheidungsmechanik: Wer entscheidet, wer eskaliert, wie wird dokumentiert, wie werden Maßnahmen verfolgt. Damit bedienen Sie alle drei Welten mit derselben Grundlogik.
Block 2: Risikomanagement & Maßnahmen
ISO-Logik (Risiko → Maßnahme → Wirksamkeit) passt grundsätzlich gut. Der Unterschied ist, worauf der Fokus liegt. DORA will IKT-Risiken sehr betriebsnah sehen: Abhängigkeiten, Resilienz, Tests. NIS2 will ein robustes Sicherheitsniveau und erwartet, dass Risiken in Entscheidungen und Schutzmaßnahmen übersetzt werden. KRITIS ist häufig sehr konkret in Mindestmaßnahmen und Schutzorganisation.
Praktischer Schluss: Halten Sie das Risikoregister nicht als Verwaltung. Verankern Sie Risiko an drei Decision Points: Go-Live kritischer Services, wesentliche Provider-Änderungen, schwere Incidents. Das macht Risiko „wirksam“ und reduziert Papier.
Block 3: Incident Handling & Meldewesen
Hier entstehen im Alltag die meisten Probleme, weil es schnell, unangenehm und öffentlich werden kann. NIS2 und KRITIS haben klare Erwartungen an Meldung und Umgang mit Vorfällen. DORA hat zusätzlich eine ausgeprägte Nachweis- und Prozesssicht, die stark auf End-to-end-Fähigkeit zielt: erkennen, einstufen, kommunizieren, wiederherstellen, lernen – und das alles sauber dokumentiert.
Praktischer Schluss: Bauen Sie Incident Management nicht als „IT-Prozess“, sondern als Service-Prozess. Entscheidend sind Auswirkung, Entscheidungspunkte, Kommunikationsfreigaben und Maßnahmenverfolgung. Wenn das sauber ist, wird Meldewesen deutlich einfacher, weil die Informationen nicht gesucht werden müssen.
Block 4: Drittparteien & Lieferkette
Das ist der Block, in dem DORA besonders „zieht“. DORA betrachtet Third-Party Risk nicht als Fragebogen-Thema, sondern als betrieblichen Steuerungstakt: Reviews, Eskalation, Exit/Notbetrieb, Nachweise. NIS2 adressiert Lieferkette ebenfalls stark, oft als Erwartung an sichere Beschaffung und laufende Steuerung. KRITIS kann je nach Sektor zusätzliche, konkrete Vorgaben an Dienstleisterbeziehungen nach sich ziehen.
Praktischer Schluss: Für kritische Provider brauchen Sie einen wiederkehrenden Review-Takt und eine getestete Eskalationslogik. Bewertung ist nicht Steuerung. Wenn Sie das einmal als Standard eingeführt haben, können Sie es für alle Rahmenwerke wiederverwenden.
Block 5: Kontrollen, Nachweise, Auditfähigkeit
DORA macht „prüfbar“ zu einem echten Kernprinzip. NIS2 und KRITIS verlangen ebenfalls Nachweise, aber DORA zwingt viele Organisationen dazu, das Thema professioneller aufzuziehen: Evidenzpakete, klare Ablage, schnelle Auffindbarkeit. Die typische Falle ist, dass Unternehmen Nachweise als separate Welt pflegen. Das funktioniert kurzfristig, ist aber teuer und bricht unter Last.
Praktischer Schluss: Definieren Sie Evidenzpakete nach Betriebsereignissen: Incident-Paket, Provider-Review-Paket, Test-/Übungspaket, Change-Paket für kritische Services, Management-Entscheidungspaket. Wenn diese Pakete sitzen, sind Audits deutlich ruhiger – unabhängig davon, ob es um NIS2, KRITIS oder DORA geht.
Block 6: Tests, Übungen, Verbesserung
KRITIS kennt in vielen Bereichen Übungen und Nachweislogik. NIS2 verlangt, dass Maßnahmen wirksam sind und Sicherheitsniveau erhalten bleibt. DORA geht besonders weit in Richtung strukturiertes Testen operativer Resilienz (und in Teilen sehr anspruchsvoll). In der Praxis scheitert es selten daran, dass man „nie übt“, sondern daran, dass Übungen zu wenig Ergebnislogik haben: Was war das Ziel, was ist das Ergebnis, welche Maßnahmen folgen, wann wird nachgetestet?
Praktischer Schluss: Übungen müssen nicht groß sein. Tabletop-Übungen können sehr wirksam sein, wenn sie konsequent in Maßnahmen und Re-Tests übersetzt werden. Das ist die einfache Brücke zwischen Pflicht und echter Verbesserung.
4) Eine Landkarte, die Sie sofort in Ihrer Organisation nutzen können
Wenn Sie das Thema intern sauber erklären wollen, hilft eine sehr einfache Darstellung: Sie sagen nicht „wir müssen NIS2 und DORA umsetzen“, sondern: „Wir bauen ein stabiles Betriebs- und Nachweissystem, das diese Rahmenwerke bedient.“ Dann ordnen Sie Ihre Arbeit in drei Ebenen:
Ebene 1: Gemeinsamer Kern
Alles, was Sie sowieso brauchen: klare Verantwortlichkeit, saubere Incident-Kette, Risiko in Decision Points, kontrollierte Changes, Grundschutzmaßnahmen, Management-Review mit Entscheidungen, definierte Evidenzablage.
Ebene 2: Schärfungen je Rahmenwerk
DORA schärft besonders: Drittparteiensteuerung, Resilienztests, Nachweis- und Evidenzlogik, teils detaillierte Prozessanforderungen.
NIS2 schärft besonders: Managementverantwortung, organisatorische Maßnahmen und Meldelogik, breite Abdeckung über viele Unternehmenstypen hinweg.
KRITIS schärft besonders: sektorale Mindestanforderungen und Schutzorganisation, häufig mit sehr konkreten Pflichten je kritischer Infrastruktur.
Ebene 3: Nachweispakete
Nicht „noch ein Dokument“, sondern Pakete, die zeigen: Entscheidung → Umsetzung → Ergebnis. Diese Ebene macht im Audit den Unterschied, weil sie zeigt, dass Sie nicht nur planen, sondern betreiben.
Das ist eine Landkarte, die Praktiker sofort verstehen – und die verhindert, dass jede Einheit ihre eigene Liste baut.
5) Was Sie vermeiden sollten (weil es fast immer zu Chaos führt)
„Drei Programme parallel“
Wenn Sie KRITIS, NIS2 und DORA als getrennte Programme mit eigenen Kontrollen, eigenen Reportings und eigener Evidenz aufsetzen, gewinnen Sie kurzfristig Struktur – und verlieren langfristig Kontrolle. Sie erzeugen Widersprüche, doppelte Nachweise und Frust. Besser ist ein gemeinsames Operating Model mit klaren Schärfungen.
„Alles ist kritisch“
Wenn alles kritisch ist, ist nichts steuerbar. Kritikalität ist ein Instrument zur Priorisierung. Ohne Priorisierung wird jede Pflicht zur Dauerlast. Legen Sie klare Kriterien fest, und halten Sie die Liste der wirklich kritischen Services und Provider bewusst klein und belastbar.
„Nachweise nachträglich sammeln“
Das ist der Klassiker: Im Betrieb passiert viel, im Audit wird gesammelt. Das kostet Zeit, produziert Lücken und erzeugt Misstrauen. Nachweise müssen aus dem Prozess entstehen. Das ist weniger Arbeit, wenn man es einmal sauber gestaltet.
6) Ein realistischer Start: 5 Schritte, die Ordnung in Wochen bringen (nicht in Jahren)
Wenn Sie das Thema jetzt pragmatisch in den Griff bekommen wollen, empfehle ich einen kurzen, fokussierten Einstieg, der in vielen Organisationen funktioniert, ohne den Betrieb zu blockieren.
Sie werden sehen: Sobald diese fünf Schritte greifen, wird die „Regulatorik-Diskussion“ ruhiger. Nicht, weil Pflichten verschwinden, sondern weil Sie sie an ein System hängen, das ohnehin funktioniert.
7) Schlussgedanke: Die beste Landkarte ist die, die im Alltag benutzt wird
Regulatorische Rahmenwerke wirken schnell groß und abstrakt. In der Praxis gewinnt aber fast immer derjenige, der sie auf Betrieb herunterbricht: klare Services, klare Verantwortlichkeiten, klare Entscheidungspunkte, klare Nachweise. Wenn Sie KRITIS, NIS2 und DORA so verstehen, wird aus „drei Baustellen“ eine gemeinsame Struktur mit wenigen Schärfungen. Und genau das ist am Ende das Ziel: weniger Nebel, weniger Buzzwords – mehr Steuerung, die auch dann trägt, wenn es stressig wird.
| Hinweis: Teile dieses Beitrags könnten unter Einsatz von KI-gestützten Tools erstellt oder überarbeitet worden sein. Weitere Informationen finden Sie im Impressum/Disclaimer. | Marken- und Bildrechte: Dargestellte Logos und genannten Marken liegen ausschließlich bei den jeweiligen Rechteinhabern. Nutzung erfolgt ausschließlich zu illustrativen Zwecken. |
Wenn Sie den Blog-Beitrag abonnieren, senden wir Ihnen eine E-Mail, sobald es Updates auf dieser Website gibt.

Kommentare 54
Ich würde gern einen Punkt vertiefen: wie sich die Anforderung in einen belastbaren Arbeitsablauf übersetzen lässt. Wie lässt sich das mit überschaubarem Aufwand überprüfen?
Ich würde zunächst einen konkreten Ablauf auswählen und dort Ausgangslage, Entscheidung und Ergebnis gegenüberstellen. Sonst bleibt die Bewertung leicht abstrakt.
Ein konkreter Fall hilft, aber die Zuständigkeit muss von Anfang an klar sein. Sonst ist zwar das Problem sichtbar, die notwendige Entscheidung bleibt aber liegen.
Ich würde ebenfalls mit einem konkreten Fall starten. Wichtig sind dabei eine eindeutige Zuständigkeit, ein überprüfbares Ergebnis und ein Termin, an dem die Wirkung erneut bewertet wird.
Gerade der feste Termin zur erneuten Bewertung ist wichtig. Andernfalls wird aus einer vorläufigen Annahme schnell ein dauerhafter Status.
Das wirft eine praktische Frage auf. Wie würdest du die im Beitrag angesprochenen Anforderungen in überschaubare erste Schritte übersetzen?
Ich würde mit klaren Verantwortlichkeiten und einem begrenzten Anwendungsfall beginnen. So lässt sich prüfen, ob die Vorgehensweise im Alltag tatsächlich hilft.
Dazu eine Rückfrage: Woran erkennt man, dass die Maßnahmen dem eigenen Risiko angemessen sind? Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Ich würde es so einordnen: Ich würde die Auswahl mit den tatsächlichen Leistungen, Abhängigkeiten und möglichen Schäden begründen. Eine pauschale Maßnahmenliste wäre mir zu wenig.
Den Nutzen sehe ich. Trotzdem würde ich vermeiden, jede Ausnahme sofort mit einer weiteren Richtlinie zu beantworten. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Das würde ich an einem konkreten Szenario prüfen. Eine Beschreibung zeigt die Absicht; die gemeinsame Durchführung zeigt, wo Informationen oder Übergaben fehlen. Auf die Ausgangsfrage bezogen: Ich würde die Auswahl mit den tatsächlichen Leistungen, Abhängigkeiten und möglichen Schäden begründen. Eine pauschale Maßnahmenliste wäre mir zu wenig.
Den Zusammenhang sehe ich jetzt klarer. Die Übertragbarkeit auf andere Fälle würde ich trotzdem getrennt prüfen. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Ich lese das etwas anders. Für mich steht zuerst die Frage im Raum, ob der zugrunde liegende Bedarf überhaupt ausreichend geklärt ist. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Welche Entscheidung müsste zu Nachweis der Wirksamkeit im laufenden Betrieb zuerst fallen, wenn die verfügbaren Nachweise lückenhaft sind?
Ich würde zunächst die Lücke offen dokumentieren und einen überprüfbaren nächsten Schritt vereinbaren, statt Vollständigkeit zu unterstellen. Das schafft eine begrenzte, überprüfbare Arbeitsgrundlage für die weitere Umsetzung. Bei Nachweis der Wirksamkeit im laufenden Betrieb sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Dazu eine Rückfrage: Wo würdest du beginnen, wenn Personal und Zeit für die Umsetzung knapp sind? Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Ich würde es so einordnen: Für mich wäre zuerst wichtig, kritische Leistungen und Abhängigkeiten zu verstehen. Daraus ließe sich begründen, welche Lücken zuerst bearbeitet werden.
Das ist mir als Maßstab noch etwas zu weich. Welches Ergebnis müsste sich nach der Änderung nachweisbar verbessern? Meine Ausgangsfrage bleibt: Wo würdest du beginnen, wenn Personal und Zeit für die Umsetzung knapp sind?
Ich würde das Ergebnis vorher festlegen: Was soll danach klarer, schneller oder belastbarer sein? Ohne diesen Bezug ist der Erfolg einer Änderung schwer zu beurteilen. Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Ich bleibe beim Aufwand etwas skeptisch. Eine kleine, überprüfbare Lösung könnte hier zunächst mehr bringen als ein umfassendes Konzept. Die Ausgangsfrage „Wo würdest du beginnen, wenn Personal und Zeit für die Umsetzung knapp sind?“ ist damit für mich noch nicht vollständig beantwortet.
Einverstanden, mit einer Einschränkung: Wenn die notwendige Information fehlt, funktioniert die Abwägung nicht. Woher sollte sie kommen? Meine Ausgangsfrage bleibt: Wo würdest du beginnen, wenn Personal und Zeit für die Umsetzung knapp sind?
Wie verhindert ihr bei Nachweis der Wirksamkeit im laufenden Betrieb, dass eine vorläufige Lösung ohne erneute Prüfung dauerhaft bestehen bleibt?
Ich würde einen festen Wiedervorlagetermin und eine klare Entscheidung über Fortführung oder Abschluss vorsehen. Wichtig ist, dass die Ausnahme nicht allein deshalb bestehen bleibt, weil niemand mehr nachfragt. Mit Blick auf Nachweis der Wirksamkeit im laufenden Betrieb würde ich den Umfang der Prüfung bewusst auf diese Entscheidung begrenzen.
Was müsste die Geschäftsleitung tatsächlich entscheiden, statt nur eine Richtlinie zu unterschreiben? Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Das ist ein wichtiger Punkt. Ich würde Prioritäten, Ressourcen und akzeptierte Restrisiken ausdrücklich vorlegen. Sonst bleibt die Verantwortung auf einer sehr abstrakten Ebene. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Einverstanden, mit einer Einschränkung: Wenn die notwendige Information fehlt, funktioniert die Abwägung nicht. Woher sollte sie kommen?
Als ersten Schritt würde ich einen klar begrenzten Fall nehmen und den tatsächlichen Ablauf gemeinsam durchgehen. An diesem Fall lassen sich die offenen Zuständigkeiten meist konkreter besprechen. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Den Zusammenhang sehe ich jetzt klarer. Die Übertragbarkeit auf andere Fälle würde ich trotzdem getrennt prüfen. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Wie detailliert sollte eine Schutzbedarfseinstufung sein, damit sie noch gepflegt werden kann? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Für mich liegt der Schwerpunkt hier: Ich würde die Detailtiefe von den Entscheidungen abhängig machen, die sie unterstützen soll. Eine sehr feine Einteilung hilft wenig, wenn sie im Alltag nicht aktualisiert wird. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Mir wäre die laufende Pflege wichtiger als die perfekte erste Fassung. Wie könnte man das mit überschaubarem Aufwand organisieren?
Als ersten Schritt würde ich einen klar begrenzten Fall nehmen und den tatsächlichen Ablauf gemeinsam durchgehen. An diesem Fall lassen sich die offenen Zuständigkeiten meist konkreter besprechen. Auf die Ausgangsfrage bezogen: Ich würde die Detailtiefe von den Entscheidungen abhängig machen, die sie unterstützen soll. Eine sehr feine Einteilung hilft wenig, wenn sie im Alltag nicht aktualisiert wird.
Ja, so wird die Abwägung konkreter. Ich würde vor allem den Prüfanlass festhalten, damit die Lösung nicht unbegrenzt als gesetzt gilt. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Ich sehe den Nutzen, würde aber auch nach den Grenzen fragen. Wann wäre ein einfacheres Vorgehen angemessen?
Welche minimale Lösung wäre für Verbindung von Vorfallmanagement und Meldeprozessen vertretbar, wenn die Zuständigkeit beim Übergang in den Betrieb unklar bleibt?
Für diesen Fall wäre mein Ansatz: die Übergabe erst mit benanntem Verantwortlichen und nachvollziehbaren Abnahmekriterien abschließen. Damit bleibt sichtbar, was entschieden wurde und was noch offen ist. Bei Verbindung von Vorfallmanagement und Meldeprozessen sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Dazu eine Rückfrage: Welche Lücke wird am ehesten übersehen, wenn die Umsetzung vor allem als IT-Projekt behandelt wird?
Ich würde es so einordnen: Ich würde besonders auf Entscheidungen und Übergaben zwischen den Funktionen schauen. Sicherheit betrifft für mich auch Führung, Einkauf und den normalen Betrieb. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Das klingt nachvollziehbar, aber der Aufwand ist damit noch nicht geklärt. Welchen Teil würdest du zuerst angehen? Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Die Grenze sehe ich dort, wo zusätzlicher Aufwand keine bessere Entscheidung mehr unterstützt. Das müsste man an einem konkreten Fall prüfen und nicht pauschal behaupten. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Wie vermeidet man doppelte Nachweise, wenn bereits ein ISMS besteht? Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Das ist ein wichtiger Punkt. Ich würde vorhandene Kontrollen und Belege zunächst den konkreten Anforderungen zuordnen. Erst erkennbare Lücken wären für mich ein Grund für neue Dokumente. Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Den Nutzen sehe ich. Trotzdem würde ich vermeiden, jede Ausnahme sofort mit einer weiteren Richtlinie zu beantworten. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Ich würde das Ergebnis vorher festlegen: Was soll danach klarer, schneller oder belastbarer sein? Ohne diesen Bezug ist der Erfolg einer Änderung schwer zu beurteilen. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Da kommen wir näher zusammen. Ein gemeinsamer Ablauf wäre überzeugender als zwei Verfahren, die im Ernstfall unterschiedliche Antworten geben. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Welche Grenze sollte bei Verbindung von Vorfallmanagement und Meldeprozessen ausdrücklich festgelegt werden, damit der Umfang handhabbar bleibt?
Zunächst würde ich den konkreten Anwendungsfall und seine Grenzen festhalten. Ausnahmen sollten anschließend bewusst entschieden werden, damit der Umfang nicht unbemerkt wächst. Für Verbindung von Vorfallmanagement und Meldeprozessen würde ich den ersten Prüfschritt bewusst klein halten.
Wie trennt man die rechtliche Betroffenheitsprüfung von der eigentlichen Sicherheitsverbesserung? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Das ist ein wichtiger Punkt. Für mich wären das verbundene, aber getrennte Arbeitsschritte. Eine dokumentierte Einordnung beantwortet noch nicht, wie belastbar die vorhandenen Maßnahmen sind. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Hier würde ich widersprechen: Ein zusätzlicher Prozess kann auch neue Reibung schaffen. Welche vorhandene Aufgabe könnte man damit zusammenführen? Meine Ausgangsfrage bleibt: Wie trennt man die rechtliche Betroffenheitsprüfung von der eigentlichen Sicherheitsverbesserung?