Wer in Deutschland ein strukturiertes Informationssicherheits-Managementsystem (ISMS) aufbauen will, steht früher oder später vor einer strategischen Weichenstellung: ISO/IEC 27001 oder BSI IT-Grundschutz? Beide Ansätze sind anerkannt, beide gelten als robust, beide können zu einer Zertifizierung führen. Und doch unterscheiden sie sich in Philosophie, Detailtiefe, Flexibilität, Nachweisführung und internationaler Reichweite. Die Entscheidung ist nicht trivial; sie hängt von Unternehmensgröße, Branche, Kundenanforderungen, regulatorischen Vorgaben, Lieferketteneinbindung und – nicht zu unterschätzen – von der Unternehmenskultur ab. Wer das für sich passende Modell wählen will, sollte verstehen, was beide Ansätze ausmacht, wie sie geprüft werden und wo ihre jeweiligen Stärken liegen. Genauso wichtig: Es ist keine dogmatische Entweder-oder-Frage. Hybride Wege sind nicht nur möglich, sondern oft sinnvoll.

ISO/IEC 27001: Risikobasiert, flexibel, weltweit anschlussfähig

ISO/IEC 27001 ist der international verbreitetste Standard für ISMS. Sein Kern ist Risikomanagement: Organisationen definieren ihren Kontext, identifizieren Informationswerte, analysieren Risiken und wählen angemessene Maßnahmen. Die Norm gibt die Management-Mechanik vor (Kontext, Führung, Planung, Unterstützung, Betrieb, Bewertung, Verbesserung), lässt aber bewusst Freiraum in der Ausgestaltung. Diese Flexibilität ist eine große Stärke:

Die NIS2-Richtlinie ist beschlossen, die Frist zur nationalen Umsetzung läuft – und für viele Unternehmen stellt sich jetzt die Frage: Wie fange ich an? Die Umsetzung ist mehr als ein paar technische Anpassungen. Sie verlangt ein strukturiertes Vorgehen, das rechtliche Anforderungen, organisatorische Prozesse und technische Maßnahmen sauber miteinander verbindet. Wer unvorbereitet startet, verzettelt sich leicht in Detailfragen, investiert zu früh in falsche Tools oder lässt kritische Lücken beim Incident-Handling, in der Lieferkette oder im Reporting. Gleichzeitig wächst der Druck: Sobald die Vorgaben im nationalen Recht scharf geschaltet sind, drohen Bußgelder, aufsichtsrechtliche Prüfungen und – wichtiger als alles andere – echte Sicherheitsrisiken bei unzureichender Resilienz.

Der rote Faden dieses Beitrags ist ein praktikabler 5-Schritte-Plan. Er beantwortet die drei Kernfragen „Bin ich betroffen?“, „Wo stehe ich?“ und „Wie komme ich planvoll in den Soll-Zustand?“ – und zwar mit der nötigen Tiefe, ohne in Bürokratismus abzurutschen. Ergänzend finden Sie konkrete Artefakte, Verantwortlichkeiten, Zeitpläne, Kennzahlen und Stolpersteine aus der Praxis, damit NIS2 nicht zum Großprojekt ohne Ende, sondern zum belastbaren Betriebszustand wird.

Die Digitalisierung der Finanzwelt hat in den letzten Jahren einen klaren Trend hervorgebracht: Immer mehr Leistungen werden an externe Partner ausgelagert. Cloud-Computing, spezialisierte IT-Dienstleister, externe Rechenzentren, Software-as-a-Service-Lösungen oder Managed Security Services – kaum ein Finanzunternehmen betreibt heute noch seine gesamte IT selbst. Diese Entwicklung hat enorme Vorteile: schnellere Innovation, flexiblere Skalierung, Zugang zu Spezialwissen und oft auch Kostenvorteile. Doch sie hat eine Schattenseite, die spätestens mit dem Inkrafttreten von DORA in den Mittelpunkt rückt: Die Abhängigkeit von Drittanbietern kann zur Achillesferse werden, wenn Risiken nicht konsequent gemanagt werden. DORA macht deshalb das Management von IKT-Drittparteien zu einer eigenen Säule der digitalen Resilienz – mit klaren Vorgaben, die deutlich über das hinausgehen, was bisher viele Unternehmen praktiziert haben.

Der Grundsatz: Auslagerung hebt Verantwortung nicht auf

Der Kern der DORA-Vorgaben ist einfach: Unternehmen bleiben auch dann vollständig verantwortlich, wenn sie kritische Funktionen an externe Partner auslagern. Es gibt kein „Das macht unser Dienstleister, darum kümmern wir uns nicht“ mehr. Vielmehr muss jedes Unternehmen sicherstellen, dass auch ausgelagerte Services den gleichen Resilienz- und Sicherheitsstandards entsprechen wie interne Leistungen. Das bedeutet, dass die Auswahl, Überwachung und vertragliche Absicherung von Drittanbietern einen zentralen Platz im Risikomanagement bekommt. Schon vor Vertragsabschluss muss geprüft werden, ob ein Anbieter die technischen, organisatorischen und finanziellen Voraussetzungen erfüllt, um die ausgelagerten Leistungen sicher und stabil zu erbringen. Diese Prüfung ist keine reine Formalität, sondern muss dokumentiert, nachvollziehbar und auf die kritischen Funktionen des Unternehmens zugeschnitten sein.

Es beginnt oft mit einem Formular: zweihundert Fragen, die jeder Lieferant ausfüllen soll; Häkchen bei „ja/nein“, Freitextfelder für „bitte beschreiben“, angeheftet ein PDF mit Zertifikaten. Man schickt es an zehn, fünfzig, hundert Drittparteien – und spürt Erleichterung, wenn die Antwort im Posteingang landet. Doch die Erleichterung ist trügerisch. Spätestens beim ersten Lieferkettenvorfall zeigt sich: Fragebögen sind keine Feuerlöschanlage. Third-Party Risk Management (TPRM), das vor allem aus Kontrolle, Formalitäten und verspäteter Dokumentation besteht, liefert die Illusion von Sicherheit – aber nicht die Fähigkeit, Risiken zu verhindern, zu erkennen und gemeinsam zu bewältigen.

2026 markiert in vielen Häusern einen Wendepunkt. Die Schlagzahl von NIS2-Pflichten, DORA-Anforderungen, Branchennormen, Audit-Nachweisen, SBOM-Erwartungen und KI-Integrationen hat TPRM aus der Compliance-Ecke geholt und in die operative Führung geschoben. Aus „kontrollieren“ wird „kooperieren“. Aus „prüfen“ wird „prüfen und beweisen“. Aus „Dienstleister“ wird „Mitgestalter“. Diese Verlagerung ist kein weicher Kulturwunsch, sondern harte Ökonomie: Nur wer Lieferanten zur Partnerschaft befähigt, erhält die Geschwindigkeit, Transparenz und Resilienz, die moderne Geschäftsmodelle benötigen.

Wer in einer Organisation für Informationssicherheit, Compliance oder IT verantwortlich ist, weiß: Sicherheitsvorfälle passieren nicht nur bei anderen. Irgendwann kommt der Tag, an dem ein System ausfällt, Daten abfließen oder ein Cyberangriff den Geschäftsbetrieb stört. Für viele Unternehmen ist das ein Schreckmoment, der Adrenalin freisetzt und schnell in hektisches Handeln münden kann. Genau hier setzt DORA mit klaren Vorgaben für das Incident Reporting an – der strukturierten Meldung von schweren IKT-Vorfällen an die zuständigen Behörden. Die Idee dahinter ist einfach: Wenn Vorfälle einheitlich, zeitnah und vollständig gemeldet werden, können Aufsichtsbehörden die Lage besser einschätzen, koordinierte Gegenmaßnahmen einleiten und vor allem verhindern, dass ähnliche Angriffe unbemerkt andere Unternehmen treffen. Für die betroffenen Organisationen bedeutet das aber auch, dass sie ihre internen Prozesse so aufstellen müssen, dass sie im Ernstfall nicht improvisieren, sondern nach einem klaren Plan vorgehen.

Was unter DORA als schwerwiegender IKT-Vorfall gilt – und warum das nicht nur „große Hacks“ sind

Der erste Schritt ist das Verständnis, was unter DORA überhaupt als „schwerwiegender IKT-Vorfall“ gilt. Hier geht es nicht nur um spektakuläre Hackerangriffe oder großflächige Systemausfälle. Auch lang anhaltende Beeinträchtigungen einzelner kritischer Prozesse, der Verlust sensibler Daten oder sicherheitsrelevante Störungen in der Lieferkette können meldepflichtig sein. DORA definiert Kriterien, die sich an der Auswirkung auf Verfügbarkeit, Integrität, Vertraulichkeit und Authentizität orientieren. Dazu zählen unter anderem die Anzahl betroffener Kunden, die Dauer der Störung, die geographische Reichweite, die potenziellen finanziellen Verluste und mögliche Auswirkungen auf die Stabilität des Finanzsystems. Unternehmen müssen diese Kriterien nicht erst im Ernstfall nachschlagen, sondern schon vorab in ihre eigenen Bewertungsverfahren integrieren. Gute Praxis ist eine interne Schwellwertmatrix, die technische Indikatoren (z. B. Umfang der Beeinträchtigung, Exfiltrationsindikatoren) mit Geschäftsauswirkungen (z. B. SLAs, verpasste Zahlungen, Marktkommunikation) verbindet und so schnell zur Entscheidung „meldepflichtig – ja/nein“ führt.