DORA und das integrierte Managementsystem: Ein Steuerungskern, viele Nachweise

In unserem ersten Beitrag zur integrierten Governance haben wir gezeigt, warum das interne Kontrollsystem (IKS) zum zentralen Steuerungsmechanismus wird, sobald Kontrollen automatisiert überwacht werden. Die nächste Frage: Wie lässt sich der Digital Operational Resilience Act (DORA) einordnen, ohne eine neue Parallelstruktur neben ISMS und IKS zu erzeugen?

Ein Steuerungskern, mehrere Sichten

Qualitätsmanagement, Informationssicherheit, Risikomanagement, IKS und DORA adressieren unterschiedliche Fragestellungen — greifen aber auf dieselben organisatorischen Realitäten zu: Prozesse, Rollen, Systeme, Entscheidungen. Ein integriertes Managementsystem entsteht genau an dieser Schnittstelle, nicht durch das Hinzufügen weiterer Module, sondern durch die gemeinsame Nutzung eines einheitlichen Steuerungskerns.

Unabhängig vom Regelwerk lassen sich Governance-Anforderungen auf wenige wiederkehrende Elemente zurückführen: Kontrollen, die Risiken adressieren, Aufgaben, die aus Kontrollen oder Abweichungen entstehen, Evidenzen, die Durchführung und Wirksamkeit belegen, und Reviews, in denen Abweichungen bewertet werden. In klassischen Ansätzen werden diese Elemente mehrfach modelliert — einmal für das ISMS, einmal für das IKS, einmal für DORA-Berichte. Ein integriertes System modelliert sie einmal und stellt sie unterschiedlichen Perspektiven zur Verfügung:

• IKS-Perspektive: Wirken die definierten Kontrollen zuverlässig und kontinuierlich?
• ISMS-Perspektive: Sind die Controls vollständig und aktuell gegen die Normanforderung bewertet?
• DORA-Perspektive: Ist die operative Resilienz messbar, überwacht und steuerbar — insbesondere bei Störungen?

Diese Perspektiven unterscheiden sich im Zweck, nicht im Fundament. Aufwand entsteht durch Redundanz: Werden Kontrollen mehrfach beschrieben und Evidenzen mehrfach gesammelt, steigt nicht nur der Pflegeaufwand, sondern auch das Risiko widersprüchlicher Bewertungen.

Was DORA konkret verlangt

DORA fordert die laufende Überwachung und Wirksamkeit von Maßnahmen — insbesondere bei ICT-Risikomanagement, Incident-Erkennung und Resilienzkennzahlen. Periodische Stichtagsprüfungen reichen dafür nicht aus; gefordert ist kontinuierliches Monitoring statt episodischer Prüfung.

Praxisbeispiel: Eine Kontrolle, zwei Nachweise

Der Incident-to-Resolution-Prozess eignet sich gut, um Integration greifbar zu machen, weil er gleichzeitig Anforderungen aus Informationssicherheit und operativer Resilienz berührt. Im integrierten Modell steht eine zentrale, funktional formulierte Kontrolle im Zentrum: Kritische Incidents werden innerhalb definierter Zeit erkannt, klassifiziert und innerhalb festgelegter Fristen behandelt.

Diese Kontrolle ist systemisch angebunden: Ein Monitoring-System erkennt relevante Ereignisse, das Ticketsystem übernimmt Klassifizierung und Fristsetzung, Statusänderungen und Eskalationen werden fortlaufend erfasst. Überschreitet die Reaktionszeit den definierten Schwellenwert, löst das automatisch eine Eskalation aus — die Kontrolle überwacht sich selbst. Auf Basis desselben Datensatzes lassen sich anschließend unterschiedliche Auswertungen erzeugen: die Wirksamkeit der Kontrolle über Zeit für die IKS-Sicht, und Reaktionszeiten sowie Störungstrends für die DORA-Sicht. Es entstehen dabei keine zusätzlichen Daten — nur unterschiedliche Perspektiven auf denselben Vorgang.

Technologie als Ermöglicher, nicht als Selbstzweck

Ein häufiger Fehler besteht darin, jede neue regulatorische Anforderung toolgetrieben zu interpretieren — für jedes Regelwerk eine neue Anwendung. Das Ergebnis sind fragmentierte Systemlandschaften. Der wirksamere Weg fragt zuerst nach dem Steuerungsmechanismus: Welche Kontrollen sind entscheidend, welche Daten fallen ohnehin in den Prozessen an, welche Entscheidungen sollen unterstützt werden? Erst danach wird entschieden, wie Systeme angebunden werden. KI kann dabei unterstützen — sie strukturiert große Datenmengen vor, priorisiert Auffälligkeiten und macht Muster sichtbar, ersetzt aber nicht die Verantwortung von Management und Fachbereichen.

Wo PRISM ISO ansetzt

Diese Integrationslogik ist der Grund, warum PRISM ISO Normen nicht als isolierte Module behandelt: ISO 27001 und NIS 2 sind vollständig als eigenständige, live geführte Standards abgebildet, das IKS-Modul steht als eigener Kontrollrahmen daneben, und die Multi-Framework-Crosswalk-Engine überträgt einen einmal gepflegten Control automatisch in alle verknüpften Normen. Einen Überblick über DORA-Anforderungen finden Sie auf unserer DORA-Themenseite. Jede Änderung an Controls bleibt dabei revisionssicher protokolliert.

Mehr Governance bedeutet nicht automatisch mehr Aufwand. DORA nutzt bestehende Governance-Strukturen, es verlangt keine neue Kontrollwelt neben ISMS und IKS.

---

Sprechen Sie mit uns darüber, wie sich Ihre bestehenden Kontrollen auf ISO 27001, NIS 2 und DORA gemeinsam abbilden lassen. PRISM ISO entdecken.