1. Transparenz ist die Grundlage digitaler Resilienz

Im Mittelpunkt steht dabei nicht die Technologie selbst, sondern deren Beitrag zur Geschäftsfähigkeit. Die entscheidende Frage lautet nicht mehr:

Mit dem Digital Operational Resilience Act (DORA) verfolgt die Europäische Union ein ambitioniertes Ziel: Finanzinstitute sollen ihre kritischen Geschäftsprozesse auch bei Cyberangriffen, technischen Störungen oder Ausfällen von Drittparteien jederzeit sicher und kontrolliert aufrechterhalten können.

Welcher Server ist ausgefallen?

Sondern:

Welche kritischen Geschäftsfunktionen sind betroffen, welche Auswirkungen entstehen für das Unternehmen und wie kann die Resilienz schnell wiederhergestellt werden?

Genau hier setzt Artikel 8 von DORA an. Die Verordnung verlangt die Identifikation aller informations- und IKT-bezogenen Assets, deren Zuordnung zu kritischen oder wichtigen Geschäftsfunktionen sowie die transparente Darstellung ihrer gegenseitigen Abhängigkeiten. Ziel ist eine aktuelle, konsistente und nachvollziehbare Informationsbasis als Grundlage für Risikomanagement, Business Continuity, Incident Management und regulatorische Nachweise.

Viele Organisationen interpretieren diese Anforderungen zunächst als Aufgabe des Asset Managements oder der CMDB. Sie beginnen mit der Inventarisierung von Servern, Anwendungen oder Cloud-Services. Doch ein vollständiges Inventar allein schafft noch keine Resilienz.

Resilienz entsteht erst dann, wenn nachvollziehbar ist, wie Geschäftsprozesse, Business Services, Anwendungen, technische Plattformen, Infrastruktur, Daten, Lieferanten und Verantwortlichkeiten miteinander verbunden sind. Erst dieses Wissen ermöglicht es, Auswirkungen von Störungen zuverlässig zu bewerten, regulatorische Anforderungen effizient zu erfüllen und fundierte Entscheidungen im Betrieb zu treffen.

Damit verändert DORA die Rolle des Configuration Managements grundlegend. Eine moderne CMDB ist heute weit mehr als ein technisches Inventar. Sie entwickelt sich zum Digital Twin des IT Operating Models – einer digitalen Repräsentation der Betriebsorganisation, welche Geschäftsfunktionen, Services, Technologien und deren Beziehungen in einem konsistenten Informationsmodell zusammenführt.

Dieser Digital Twin schafft die Transparenz, die für ein resilientes IT-Betriebsmodell erforderlich ist. Er bildet die Grundlage für Impact-Analysen, Change- und Incident Management, Business Continuity Management, Third-Party-Risk-Management sowie für das DORA-konforme Reporting. Gleichzeitig entsteht ein gemeinsames Verständnis zwischen Business, IT, Risiko- und Compliance-Organisation – eine Voraussetzung, die in vielen Unternehmen heute noch fehlt.

In diesem Beitrag zeigen wir, welche Anforderungen DORA Artikel 8 tatsächlich stellt, warum ein klassisches Asset-Inventar dafür nicht ausreicht und wie eine serviceorientierte CMDB zum Digital Twin eines resilienten IT Operating Models aufgebaut werden kann. Dabei verbinden wir die regulatorischen Anforderungen von DORA mit bewährten Best Practices aus Configuration Management, Enterprise Architecture und modernen Service Data Models wie CSDM.

2. Was DORA Artikel 8 tatsächlich fordert

Artikel 8 von DORA wird häufig auf die Pflicht zur Führung eines Inventars von IKT-Assets reduziert. Diese Sichtweise greift jedoch zu kurz. Tatsächlich verfolgt die Verordnung ein wesentlich umfassenderes Ziel: Finanzinstitute sollen jederzeit nachvollziehen können, welche kritischen oder wichtigen Geschäftsfunktionen durch welche Informations- und IKT-Ressourcen unterstützt werden und welche Auswirkungen Störungen auf den Geschäftsbetrieb haben können.

Der Schwerpunkt liegt damit nicht auf der Dokumentation einzelner Assets, sondern auf der Transparenz der gesamten Wertschöpfungskette – von der Geschäftsfunktion über die unterstützenden Services bis hin zu Anwendungen, Infrastruktur und externen Dienstleistern.

Aus fachlicher Sicht lassen sich die Anforderungen von Artikel 8 in sechs zentrale Informationsbereiche gliedern.

Kritische oder wichtige Geschäftsfunktionen identifizieren

Ausgangspunkt sind die sogenannten Critical or Important Functions (CIF). Dabei handelt es sich um jene Geschäftsfunktionen, deren Ausfall erhebliche Auswirkungen auf Kunden, den Geschäftsbetrieb oder die Finanzstabilität hätte.

Die Identifikation dieser Funktionen bildet die Grundlage aller weiteren DORA-Anforderungen. Erst wenn klar ist, was geschützt werden muss, lässt sich bestimmen, welche Technologien, Services und Drittparteien hierfür relevant sind. Genau deshalb wird Artikel 8 als der eigentlichen “Motor” von DORA.

Informations- und IKT-Assets zuordnen

Im zweiten Schritt verlangt DORA die Identifikation aller Informations- und IKT-Assets, welche diese kritischen Geschäftsfunktionen unterstützen.

Dazu gehören unter anderem:

• Geschäftsanwendungen
• Datenbanken
• Server und virtuelle Systeme
• Netzwerke und Cloud-Plattformen
• Endgeräte
• Daten und Informationsobjekte
• externe ICT-Services

Dabei geht es nicht nur um die Existenz dieser Komponenten, sondern um deren eindeutige Zuordnung zu den unterstützten Geschäftsfunktionen.

Abhängigkeiten transparent machen

Die vielleicht wichtigste Anforderung von Artikel 8 besteht darin, die Abhängigkeiten zwischen den einzelnen Komponenten nachvollziehbar abzubilden.

Ein Ausfall betrifft selten nur einen Server oder eine Anwendung. Auswirkungen entstehen erst durch die Beziehungen zwischen Geschäftsprozessen, Services, Anwendungen, Plattformen, Infrastruktur und externen Dienstleistern.

DORA fordert deshalb ein Verständnis der gesamten Servicekette. Nur so lassen sich Auswirkungen von Incidents oder Changes zuverlässig beurteilen sowie Business-Continuity- und Recovery-Massnahmen wirksam planen.

Verantwortlichkeiten eindeutig festlegen

Ebenso fordert Artikel 8 klare Verantwortlichkeiten für die gepflegten Informationen.

Wer ist für eine kritische Geschäftsfunktion verantwortlich?

Wer bestätigt die Aktualität der Daten?

Wer verantwortet die unterstützenden Services und IKT-Assets?

Gerade hier zeigen viele Organisationen heute noch Schwächen. Während technische Systeme häufig einem Application Owner zugeordnet sind, fehlen klare Verantwortlichkeiten für Business Services oder kritische Geschäftsfunktionen. Diese fehlende Ownership ist oft einer der wesentlichen Gründe für unvollständige oder veraltete CMDB-Daten.

Informationen aktuell halten

Artikel 8 versteht die Dokumentation ausdrücklich nicht als einmaliges Projekt.

Die Informationen müssen kontinuierlich gepflegt, überprüft und bei wesentlichen Änderungen aktualisiert werden. Nur so entsteht eine belastbare Grundlage für regulatorische Nachweise, Incident Management oder Business Continuity.

Aktualität wird damit zu einem integralen Bestandteil der Governance und nicht zu einer administrativen Nebenaufgabe.

Drittparteien einbeziehen

Schliesslich verlangt DORA auch Transparenz über externe ICT-Dienstleister und deren Beitrag zur Erbringung kritischer Geschäftsfunktionen.

Dabei genügt es nicht festzustellen, dass beispielsweise Microsoft Azure oder AWS genutzt werden. Vielmehr muss nachvollziehbar sein, welche konkreten Services einer Drittpartei welche kritischen Geschäftsfunktionen unterstützen, welche Verträge zugrunde liegen und welche Auswirkungen ein Ausfall dieser Services hätte.

Mehr als ein Inventar – ein Informationsmodell für Resilienz

Betrachtet man diese Anforderungen im Zusammenhang, wird deutlich, dass Artikel 8 weit mehr verlangt als ein klassisches Asset-Register. Die Verordnung beschreibt vielmehr ein umfassendes Informationsmodell, welches Geschäftsfunktionen, Services, Anwendungen, Technologien, Drittparteien und deren Beziehungen miteinander verbindet.

Genau dieses Informationsmodell bildet die Grundlage eines resilienten IT Operating Models. Eine moderne CMDB kann diese Anforderungen erfüllen – allerdings nur dann, wenn sie nicht als technische Inventarliste verstanden wird, sondern als Digital Twin des IT Operating Models, der sämtliche relevanten Zusammenhänge transparent und nachvollziehbar abbildet.

3. Warum ein Asset-Inventar nicht genügt

Viele Unternehmen verfügen heute bereits über ein zentrales Asset Management, automatisierte Discovery-Werkzeuge oder sogar eine CMDB. Dennoch zeigt die Praxis, dass genau diese Organisationen Schwierigkeiten haben, die Anforderungen von DORA Artikel 8 vollständig zu erfüllen.

Der Grund liegt nicht in der Qualität der Werkzeuge, sondern in der Art der Informationen, die verwaltet werden.

Ein klassisches Asset-Inventar beantwortet Fragen wie:

• Welche Server betreiben wir?
• Welche Software ist installiert?
• Wo befindet sich ein System?
• Wer ist Eigentümer eines Assets?

Diese Informationen sind zweifellos wichtig. Für sich allein liefern sie jedoch kaum einen Beitrag zur operationellen Resilienz.

DORA stellt eine völlig andere Fragestellung:

• Welche kritische Geschäftsfunktion wird durch dieses System unterstützt?
• Welche Business Services wären bei einem Ausfall betroffen?
• Welche Anwendungen und technischen Services sind davon abhängig?
• Welche externen ICT-Dienstleister sind beteiligt?
• Welche Risiken entstehen für den Geschäftsbetrieb?
• Welche Recovery-Massnahmen müssen eingeleitet werden?

Diese Fragen lassen sich mit einer klassischen Inventarliste nicht beantworten.

Von der Inventarisierung zur Transparenz

Der eigentliche Mehrwert von Artikel 8 liegt deshalb nicht in der Inventarisierung von Assets, sondern in der Herstellung von Transparenz über die Zusammenhänge innerhalb der digitalen Organisation.

Erst wenn Beziehungen zwischen Geschäftsfunktionen, Services, Anwendungen, Infrastruktur und Drittparteien sichtbar werden, entsteht ein vollständiges Bild der digitalen Wertschöpfung.

Die folgende Abbildung verdeutlicht diesen Unterschied.

Klassisches Asset-Inventar	DORA Artikel 8
Welche Assets existieren?	Welche Geschäftsfunktion wird unterstützt?
Welche Software ist installiert?	Welche Services hängen davon ab?
Wer besitzt das Asset?	Wer trägt die End-to-End-Verantwortung?
Wo befindet sich das System?	Welche Risiken entstehen bei einem Ausfall?
Welche Konfiguration besitzt das Asset?	Welche Auswirkungen hat ein Incident oder Change auf den Geschäftsbetrieb?

Während das Asset Management einzelne Komponenten beschreibt, verlangt DORA ein Verständnis der gesamten Servicekette.

Beziehungen sind wichtiger als einzelne Assets

Ein einzelner Server ist selten kritisch.

Kritisch wird er erst dadurch, dass er Teil einer Anwendung ist, welche einen Business Service unterstützt, der wiederum eine kritische Geschäftsfunktion ermöglicht.

Genau diese Beziehungen entscheiden darüber,

• welche Auswirkungen ein Incident hat,
• welche Changes besonders sorgfältig geplant werden müssen,
• welche Systeme priorisiert wiederhergestellt werden,
• welche Drittparteien informiert werden müssen,
• und welche regulatorischen Meldepflichten ausgelöst werden.

Operationelle Resilienz entsteht deshalb nicht durch möglichst viele Informationen, sondern durch die richtigen Beziehungen zwischen diesen Informationen.

Die grösste Herausforderung ist nicht die Technik

Interessanterweise zeigt die Erfahrung aus zahlreichen DORA-Projekten, dass technische Discovery heute selten das eigentliche Problem darstellt.

Die deutlich grössere Herausforderung besteht darin,

• kritische Geschäftsfunktionen eindeutig zu definieren,
• Business und IT auf ein gemeinsames Servicemodell auszurichten,
• Verantwortlichkeiten festzulegen,
• und die Daten dauerhaft aktuell zu halten.

Genau diese Erkenntnis bestätigt auch die aktuelle DORA-Praxis: Viele Organisationen verfügen zwar über technische Inventare, jedoch nur wenige haben ihre kritischen Geschäftsfunktionen vollständig modelliert und mit den unterstützenden Services sowie den externen Abhängigkeiten verknüpft. Dadurch bleiben Impact-Analysen, Business-Continuity-Planung und regulatorisches Reporting häufig manuell, unvollständig oder nur mit erheblichem Aufwand möglich.

Die CMDB wird zum Informationsmodell der digitalen Organisation

An diesem Punkt verändert sich die Rolle der CMDB grundlegend.

Sie dokumentiert nicht länger ausschliesslich Configuration Items, sondern beschreibt die Zusammenhänge zwischen Business, Services, Technologie und Governance.

Sie beantwortet nicht mehr nur die Frage:

Welche Komponenten betreiben wir?

Sondern vielmehr:

Wie entstehen unsere digitalen Services, welche kritischen Geschäftsfunktionen unterstützen sie und welche Auswirkungen hat jede Veränderung auf den Geschäftsbetrieb?

Damit entwickelt sich die CMDB vom technischen Inventar zum Digital Twin des IT Operating Models.

Sie bildet nicht einzelne Systeme ab, sondern die digitale Organisation mit ihren Wertströmen, Geschäftsfunktionen, Services, Anwendungen, Plattformen, Lieferanten und deren gegenseitigen Abhängigkeiten.

Erst dieser ganzheitliche Blick schafft die Transparenz, welche DORA Artikel 8 fordert – und bildet gleichzeitig die Grundlage für ein resilientes IT Operating Model.

4. Die CMDB als Digital Twin des IT Operating Models

Die Anforderungen aus DORA Artikel 8 lassen sich nicht durch ein besseres Asset-Management allein erfüllen. Erforderlich ist vielmehr ein Informationsmodell, das den Zusammenhang zwischen Geschäft, Services, Technologie und Governance transparent abbildet.

Genau diese Aufgabe übernimmt eine moderne, serviceorientierte CMDB.

Sie dokumentiert nicht lediglich Server, Datenbanken oder Netzwerkkomponenten. Sie bildet die digitale Organisation in ihrer Gesamtheit ab und entwickelt sich damit zum Digital Twin des IT Operating Models.

Der Begriff Digital Twin beschreibt die digitale Repräsentation eines realen Systems. Während in der Industrie Maschinen oder Produktionsanlagen digital abgebildet werden, beschreibt der Digital Twin einer CMDB die gesamte digitale Betriebsorganisation – von der geschäftlichen Wertschöpfung bis hin zur technischen Infrastruktur.

Dadurch entsteht eine durchgängige Sicht auf sämtliche relevanten Zusammenhänge und Abhängigkeiten.

Das Operating Model als Ausgangspunkt

Der Aufbau einer DORA-konformen CMDB beginnt nicht bei den technischen Assets, sondern bei den geschäftlichen Anforderungen.

Jede Organisation verfügt über Geschäftsfunktionen, welche einen Wert für Kunden oder interne Stakeholder erzeugen. Diese Geschäftsfunktionen werden durch Business Services unterstützt, welche wiederum auf Anwendungen, Plattformen, Infrastruktur und externen ICT-Dienstleistern aufbauen.

Die CMDB bildet genau diese Wertschöpfungskette digital ab.

Das Informationsmodell folgt dabei einer klaren Hierarchie.

Ergänzt wird dieses Modell durch Informationen wie:

• Verantwortlichkeiten (Business Owner, Service Owner, Application Owner)
• Kritikalität
• Risiken
• Informationsklassifikation
• Verträge und SLAs
• Standorte
• Lifecycle
• Recovery-Anforderungen
• Compliance-Vorgaben

Dadurch entsteht nicht nur eine technische Sicht auf die IT, sondern ein vollständiges digitales Abbild der Betriebsorganisation.

Beziehungen schaffen den eigentlichen Mehrwert

Der eigentliche Wert einer CMDB liegt nicht in den einzelnen Objekten, sondern in deren Beziehungen.

Ein Business Service besteht aus mehreren Application Services.

Eine Application nutzt verschiedene Anwendungen.

Diese Anwendungen laufen auf technischen Plattformen, welche wiederum aus zahlreichen Configuration Items bestehen.

Zusätzlich bestehen Abhängigkeiten zu Cloud-Plattformen, Netzwerkdiensten und externen ICT-Dienstleistern.

Erst diese Beziehungen ermöglichen es, Fragen zu beantworten wie:

• Welche kritischen Geschäftsfunktionen sind von einem Incident betroffen?
• Welche Services werden durch einen geplanten Change beeinflusst?
• Welche Drittparteien unterstützen diese Funktion?
• Welche Recovery-Pläne müssen aktiviert werden?
• Welche regulatorischen Nachweise können automatisiert erstellt werden?

Damit wird die CMDB zur zentralen Wissensbasis für sämtliche Betriebsprozesse.

Eine gemeinsame Sprache für Business und IT

Eine der grössten Herausforderungen vieler Organisationen besteht darin, dass Business und IT unterschiedliche Modelle verwenden.

Während das Business in Geschäftsfunktionen, Prozessen und Wertschöpfung denkt, betrachtet die IT Anwendungen, Server und Netzwerke.

DORA Artikel 8 verlangt erstmals, beide Welten miteinander zu verbinden.

Die CMDB wird dadurch zur gemeinsamen Informationsplattform für Business, IT, Risiko-Management und Compliance.

Genau diese End-to-End-Sicht wird auch im aktuellen CSDM-Referenzmodell verfolgt. CSDM verbindet Business Capabilities, Business Applications, Business Services, Service Delivery und technische Konfigurationen innerhalb eines durchgängigen Service-Lebenszyklus. Damit entsteht ein konsistentes Datenmodell über alle Ebenen der digitalen Organisation hinweg.

Der Digital Twin als Grundlage eines resilienten Betriebsmodells

Die eigentliche Stärke einer modernen CMDB liegt deshalb nicht in der Dokumentation von Konfigurationen.

Sie liegt in der Fähigkeit, den aktuellen Zustand der digitalen Organisation jederzeit transparent darzustellen.

Der Digital Twin beantwortet nicht nur die Frage:

Welche Systeme betreiben wir?

Sondern vor allem:

• Welche Geschäftsfunktion wird unterstützt?
• Welche Services sind beteiligt?
• Welche Risiken entstehen bei einer Veränderung?
• Welche Auswirkungen hat ein Ausfall?
• Welche Lieferanten sind betroffen?
• Welche regulatorischen Anforderungen gelten?
• Welche Recovery-Massnahmen müssen eingeleitet werden?

Damit wird die CMDB zum operativen Rückgrat eines resilienten IT Operating Models.

Sie verbindet Strategie, Architektur, Service Management, Betrieb, Risiko-Management und Compliance auf einer gemeinsamen Datenbasis und schafft genau jene Transparenz, welche DORA Artikel 8 fordert.

5. Transparenz schafft Resilienz

Die eigentliche Stärke einer CMDB liegt nicht in der Anzahl der erfassten Configuration Items oder der Vollständigkeit eines Inventars. Ihr Wert entsteht erst dann, wenn die Informationen genutzt werden können, um fundierte Entscheidungen zu treffen.

Genau hier setzt DORA Artikel 8 an. Die Verordnung verlangt nicht Transparenz um ihrer selbst willen, sondern als Grundlage für ein widerstandsfähiges IT-Betriebsmodell.

Resilienz bedeutet letztlich, dass eine Organisation jederzeit beantworten kann:

• Welche Geschäftsfunktionen sind betroffen?
• Welche Services fallen aus?
• Welche Anwendungen sind beteiligt?
• Welche Infrastruktur ist betroffen?
• Welche Drittparteien müssen eingebunden werden?
• Welche Risiken entstehen?
• Welche Massnahmen müssen eingeleitet werden?

Ein Digital Twin des IT Operating Models liefert genau diese Antworten.

Vom reaktiven zum wissensbasierten Betrieb

In vielen Organisationen werden Auswirkungen eines Incidents heute noch durch Telefonate, Workshops oder Expertenwissen ermittelt.

Architekten, Service Owner oder langjährige Mitarbeitende müssen zunächst herausfinden,

• welche Systeme betroffen sind,
• welche Anwendungen darauf aufbauen,
• welche Geschäftsprozesse beeinträchtigt werden
• und welche externen Dienstleister involviert sind.

Dieser Ansatz funktioniert im Alltag häufig ausreichend gut. Im Krisenfall kostet er jedoch wertvolle Zeit.

Ein Digital Twin stellt diese Informationen unmittelbar zur Verfügung. Zusammenhänge werden nicht erst recherchiert, sondern sind bereits Bestandteil des Informationsmodells.

Aus einem reaktiven Betrieb wird ein wissensbasierter Betrieb.

Bessere Entscheidungen entlang des gesamten Service Lifecycle

Die Transparenz eines Digital Twins unterstützt weit mehr als nur das Incident Management.

Sie verbessert sämtliche Kernprozesse eines modernen IT Operating Models.

Incident Management

Bereits bei Eingang eines Incidents wird sichtbar,

• welche Critical Functions betroffen sind,
• welche Business Services beeinträchtigt werden,
• welche Kunden Auswirkungen spüren
• und welche Priorität der Incident besitzt.

Die Klassifizierung erfolgt nicht mehr ausschliesslich aufgrund der technischen Störung, sondern auf Basis der geschäftlichen Auswirkungen.

Change Management

Jede Änderung kann automatisch gegen die Abhängigkeitsstruktur geprüft werden.

Dadurch wird sofort sichtbar,

• welche kritischen Geschäftsfunktionen betroffen sein könnten,
• welche Wartungsfenster geeignet sind,
• welche Tests erforderlich werden,
• welche Risiken bestehen
• und welche Stakeholder informiert werden müssen.

Der Change wird dadurch geschäftsorientiert statt rein technisch bewertet.

Business Continuity und Disaster Recovery

Auch Business Continuity Management profitiert unmittelbar von einer serviceorientierten CMDB.

Recovery-Pläne orientieren sich nicht mehr an einzelnen Servern oder Anwendungen, sondern an den tatsächlich kritischen Geschäftsfunktionen.

Dadurch wird klar,

• welche Services zuerst wiederhergestellt werden müssen,
• welche Systeme voneinander abhängig sind,
• welche Recovery-Zeiten einzuhalten sind
• und welche Drittparteien beteiligt werden müssen.

Genau diese Integration von CMDB, Business Continuity und DORA wird heute als einer der wesentlichen Erfolgsfaktoren für operationelle Resilienz betrachtet.

Third-Party Risk Management

DORA legt einen besonderen Schwerpunkt auf Risiken aus externen ICT-Dienstleistungen.

Ein Digital Twin zeigt unmittelbar,

• welche Provider kritische Services unterstützen,
• welche Verträge bestehen,
• welche Cloud-Services genutzt werden,
• welche Subdienstleister beteiligt sind
• und welche regulatorischen Anforderungen daraus entstehen.

Damit wird Third-Party Risk Management integraler Bestandteil des Operating Models.

Compliance und Reporting

Auch regulatorische Nachweise profitieren erheblich.

Anstatt Informationen aus verschiedenen Excel-Listen, Architekturmodellen und Inventaren zusammenzuführen, können Berichte direkt auf Basis des gemeinsamen Informationsmodells erstellt werden.

Das reduziert manuellen Aufwand, verbessert die Datenqualität und erhöht gleichzeitig die Nachvollziehbarkeit gegenüber Aufsichtsbehörden.

Transparenz als Grundlage von Readiness

Ein resilientes IT Operating Model zeichnet sich dadurch aus, dass Informationen nicht erst im Krisenfall gesucht werden müssen.

Sie stehen jederzeit aktuell, konsistent und nachvollziehbar zur Verfügung.

Genau darin liegt der eigentliche Mehrwert eines Digital Twins.

Er verbindet Business, Architektur, Service Management, Betrieb, Risiko-Management und Compliance zu einer gemeinsamen Wissensbasis.

Damit entsteht nicht nur regulatorische Compliance.

Es entsteht Readiness.

Readiness bedeutet, jederzeit zu wissen,

• welche kritischen Geschäftsfunktionen geschützt werden müssen,
• wodurch sie unterstützt werden,
• welche Risiken bestehen,
• welche Auswirkungen Veränderungen haben,
• und welche Entscheidungen im Ereignisfall getroffen werden müssen.

Die CMDB wird dadurch weit mehr als ein Werkzeug des Configuration Managements. Sie entwickelt sich zum Informationsrückgrat einer resilienten digitalen Organisation.

6. Der Weg zum Digital Twin – Ein pragmatischer Implementierungsansatz

Die Erkenntnis, dass eine CMDB zum Digital Twin des IT Operating Models werden soll, ist nur der erste Schritt. Die eigentliche Herausforderung besteht darin, dieses Zielbild in einer bestehenden Organisation umzusetzen.

Viele Unternehmen versuchen noch immer, ihre CMDB vollständig aufzubauen, bevor sie einen Nutzen daraus ziehen. Die Erfahrung aus DORA-Projekten zeigt jedoch einen anderen Weg: Erfolgreiche Organisationen beginnen nicht mit der gesamten IT-Landschaft, sondern mit den geschäftskritischen Funktionen und erweitern das Modell schrittweise.

DORA Artikel 8 verlangt keine perfekte CMDB. Gefordert wird vielmehr eine belastbare, nachvollziehbare und kontinuierlich gepflegte Informationsbasis. Genau deshalb empfiehlt sich ein iteratives Vorgehen.

Schritt 1 – Kritische Geschäftsfunktionen identifizieren

Jede Umsetzung beginnt beim Business.

Ausgangspunkt sind die Critical or Important Functions (CIF) gemäss DORA. Diese müssen gemeinsam mit den Fachbereichen identifiziert und eindeutig beschrieben werden.

Dabei gilt ein wichtiger Grundsatz:

Nicht alles ist kritisch.

Wer ganze Unternehmensbereiche oder sämtliche IT-Services als kritisch klassifiziert, verliert den eigentlichen Fokus von DORA. Entscheidend ist die richtige Granularität. Kritische Geschäftsfunktionen müssen klar abgegrenzt, verständlich und langfristig pflegbar sein. Genau diese Fragestellung wird auch in der Praxis als einer der wichtigsten Erfolgsfaktoren beschrieben.

Schritt 2 – Das IT Operating Model definieren

Sind die kritischen Geschäftsfunktionen bekannt, folgt die Definition des Operating Models.

Dabei wird festgelegt,

• welche Business Services die Geschäftsfunktionen unterstützen,
• welche Application Services diese Business Services bereitstellen,
• welche Anwendungen und Plattformen eingesetzt werden,
• welche technischen Services erforderlich sind,
• welche externen ICT-Dienstleister eingebunden sind.

Damit entsteht erstmals eine durchgängige End-to-End-Sicht auf die digitale Wertschöpfung.

Diese Struktur bildet gleichzeitig das Zielmodell für die CMDB.

Schritt 3 – Das Informationsmodell entwickeln

Erst jetzt wird definiert, welche Informationen tatsächlich benötigt werden.

Neben den eigentlichen Objekten werden auch deren Beziehungen sowie die notwendigen Attribute beschrieben.

Zu den wichtigsten Informationen gehören:

• Business Owner und Service Owner
• Kritikalität
• Informationsklassifikation
• Risiken
• Recovery-Anforderungen
• Verträge und SLAs
• Lifecycle und Betriebsstatus
• Beziehungen zu Drittparteien

Damit wird aus einer technischen Datenbank ein unternehmensweites Informationsmodell.

Schritt 4 – Den Digital Twin schrittweise aufbauen

Der nächste Schritt besteht darin, die definierten Informationen in der CMDB abzubilden.

Dabei empfiehlt sich ein inkrementelles Vorgehen.

Nicht sämtliche Anwendungen oder Configuration Items werden gleichzeitig modelliert. Stattdessen beginnt man mit den wichtigsten Geschäftsfunktionen und erweitert den Digital Twin kontinuierlich.

Ein bewährtes Vorgehen ist:

1. Kritische Geschäftsfunktion modellieren.
2. Zugehörige Business Services ergänzen.
3. Application Services und Anwendungen zuordnen.
4. Infrastruktur und Configuration Items verbinden.
5. Externe ICT-Dienstleister und Verträge integrieren.

Mit jeder Ausbaustufe steigt sowohl die Transparenz als auch der unmittelbare betriebliche Nutzen.

Schritt 5 – Governance und Datenqualität etablieren

Ein Digital Twin ist nur so gut wie seine Aktualität.

Deshalb muss bereits während des Aufbaus festgelegt werden,

• wer welche Informationen verantwortet,
• wie Änderungen gepflegt werden,
• wann Reviews stattfinden,
• welche Qualitätskennzahlen überwacht werden,
• wie automatisierte Discovery mit manuell gepflegtem Business-Kontext zusammenspielt.

DORA fordert ausdrücklich nachvollziehbare Verantwortlichkeiten und aktuelle Informationen. Die Verantwortung endet deshalb nicht bei der technischen Discovery, sondern umfasst den gesamten fachlichen Kontext. Regelmässige Data Attestations und definierte Owner stellen sicher, dass die Informationen dauerhaft belastbar bleiben.

Schritt 6 – Den Digital Twin operativ nutzen

Der grösste Fehler vieler CMDB-Initiativen besteht darin, dass das Informationsmodell nach seiner Erstellung kaum genutzt wird.

Der eigentliche Mehrwert entsteht erst, wenn der Digital Twin Bestandteil der operativen Prozesse wird.

Dazu gehören insbesondere:

• Incident Management
• Major Incident Management
• Change Enablement
• Business Continuity Management
• Disaster Recovery
• Third-Party Risk Management
• Compliance und Reporting
• Continual Improvement

Der Digital Twin wird dadurch zur gemeinsamen Informationsbasis aller Betriebs- und Governance-Prozesse.

Von der Dokumentation zur Steuerung

Mit jedem dieser Schritte verändert sich die Rolle der CMDB.

Sie entwickelt sich

• vom technischen Inventar
• über ein integriertes Informationsmodell
• hin zum Digital Twin des IT Operating Models.

Damit wird sie nicht mehr primär gepflegt, um regulatorische Anforderungen zu erfüllen, sondern weil sie täglich zur Steuerung des Betriebs genutzt wird.

Genau darin liegt der eigentliche Mehrwert von DORA Artikel 8.

Die Verordnung fordert keine zusätzliche Dokumentation. Sie schafft den Anreiz, ein Informationsmodell aufzubauen, das Transparenz, Governance und operative Steuerung auf einer gemeinsamen Datenbasis vereint.

So entsteht nicht nur Compliance, sondern ein resilientes IT Operating Model, das Veränderungen beherrscht, Risiken sichtbar macht und im Ereignisfall schneller und fundierter reagieren kann. Genau darin zeigt sich der Unterschied zwischen einer CMDB als technischem Inventar und einem Digital Twin der digitalen Betriebsorganisation.

7. Der Digital Twin als Grundlage der resilienten digitalen Organisation

Mit der Umsetzung von DORA Artikel 8 endet die Entwicklung einer CMDB nicht. Im Gegenteil – sie beginnt erst.

Viele Unternehmen betrachten eine CMDB noch immer als Werkzeug des Configuration Managements oder als notwendige Grundlage für IT Service Management. Im Kontext moderner digitaler Organisationen wird ihre Bedeutung jedoch deutlich grösser.

Eine serviceorientierte CMDB entwickelt sich zum Digital Twin des IT Operating Models und damit zur zentralen Wissensbasis der gesamten digitalen Organisation.

Sie verbindet Business, IT, Risiko-Management und Compliance auf einer gemeinsamen Datenbasis und schafft erstmals eine durchgängige Sicht auf Wertschöpfung, Abhängigkeiten und Auswirkungen.

Von der Dokumentation zur Wissensplattform

Traditionell wurden Informationen über Geschäftsprozesse, Anwendungen, Infrastruktur, Verträge oder Risiken in unterschiedlichen Werkzeugen gepflegt.

Business Process Management verwaltet Prozesse.

Enterprise Architecture beschreibt Anwendungen.

IT Service Management dokumentiert Services.

Asset Management verwaltet Hardware.

Supplier Management führt Verträge.

Risk Management dokumentiert Risiken.

Jede dieser Disziplinen betrachtet einen Teil der Realität.

Erst der Digital Twin verbindet diese Informationen zu einem konsistenten Gesamtbild.

Dadurch entsteht eine gemeinsame Wissensplattform für sämtliche betrieblichen Entscheidungen.

Grundlage für intelligente Automatisierung

Mit der zunehmenden Automatisierung von Betriebsprozessen gewinnt diese gemeinsame Wissensbasis weiter an Bedeutung.

Moderne Automatisierungsplattformen und AI-Agenten benötigen Kontext.

Sie müssen verstehen,

• welche Geschäftsfunktion betroffen ist,
• welche Services zusammengehören,
• welche Risiken bestehen,
• welche Prioritäten gelten,
• welche regulatorischen Anforderungen berücksichtigt werden müssen.

Ohne diesen Kontext bleibt Automatisierung auf einzelne technische Abläufe beschränkt.

Erst der Digital Twin liefert den notwendigen Zusammenhang zwischen Business und Technologie.

Damit entwickelt sich die CMDB zunehmend vom Repository zum Kontextmodell der digitalen Organisation.

Readiness beginnt lange vor der Krise

Der eigentliche Wert eines Digital Twins zeigt sich nicht erst während eines Incidents.

Er entsteht bereits im täglichen Betrieb.

Organisationen mit einem aktuellen und konsistenten Informationsmodell können Veränderungen besser planen, Risiken früher erkennen und Auswirkungen realistischer bewerten.

Im Krisenfall müssen Informationen nicht mehr mühsam zusammengetragen werden.

Sie stehen bereits zur Verfügung.

Dadurch verkürzt sich die Reaktionszeit erheblich.

Gleichzeitig verbessert sich die Qualität der Entscheidungen.

Readiness bedeutet deshalb nicht nur vorbereitet zu sein.

Readiness bedeutet, jederzeit auf einer belastbaren Informationsbasis handeln zu können.

DORA als Katalysator für moderne Operating Models

DORA wird häufig als regulatorische Herausforderung wahrgenommen.

Tatsächlich bietet die Verordnung jedoch die Chance, bestehende Betriebsmodelle grundlegend weiterzuentwickeln.

Organisationen, welche Artikel 8 lediglich als Dokumentationspflicht verstehen, werden den regulatorischen Anforderungen zwar formal näherkommen.

Organisationen, welche Artikel 8 als Anlass nutzen, einen Digital Twin ihres IT Operating Models aufzubauen, schaffen dagegen einen nachhaltigen Mehrwert.

Sie verbessern nicht nur ihre Compliance.

Sie erhöhen gleichzeitig

• die Transparenz,
• die Steuerbarkeit,
• die Entscheidungsqualität,
• die Automatisierung,
• und letztlich ihre digitale Resilienz.

Fazit

DORA Artikel 8 verlangt Transparenz über kritische Geschäftsfunktionen, Informationswerte, IKT-Assets und deren gegenseitige Abhängigkeiten.

Eine moderne CMDB erfüllt diese Anforderung nicht, indem sie möglichst viele Configuration Items verwaltet, sondern indem sie die digitale Organisation als Ganzes beschreibt.

Als Digital Twin des IT Operating Models verbindet sie Business Capabilities, Geschäftsprozesse, kritische Funktionen, Services, Anwendungen, Infrastruktur und Drittparteien in einem konsistenten Informationsmodell.

Damit wird sie zum Informationsrückgrat eines resilienten Betriebsmodells.

Oder anders formuliert:

Die CMDB beantwortet heute nicht mehr die Frage, welche Systeme betrieben werden. Sie beantwortet die wesentlich wichtigere Frage, wie digitale Wertschöpfung entsteht, wodurch sie gefährdet wird und wie sie auch unter aussergewöhnlichen Bedingungen aufrechterhalten werden kann. Genau darin liegt der eigentliche Mehrwert von DORA Artikel 8.

Diese Sichtweise geht weit über die regulatorischen Anforderungen hinaus. Sie bildet gleichzeitig einen zentralen Baustein eines Next Generation IT Operating Models, in dem Governance, Wertströme, Business Capabilities, Plattformen, Services, Risiko-Management und Resilienz nicht mehr isoliert betrachtet werden, sondern als Bestandteile eines integrierten Steuerungsmodells zusammenwirken. Genau dieses Zusammenspiel schafft die organisatorische Readiness, um neue Technologien wie Cloud, Plattformen oder AI sicher und wirksam in die digitale Wertschöpfung zu integrieren.

Wer DORA Artikel 8 deshalb nicht als reine Compliance-Anforderung versteht, sondern als Chance zum Aufbau eines Digital Twins seines IT Operating Models nutzt, schafft weit mehr als regulatorische Konformität. Er legt das Fundament für eine transparente, steuerbare und resiliente digitale Organisation – und damit für die Fähigkeit, Veränderungen nicht nur zu bewältigen, sondern aktiv zu gestalten.

Wenn Sie diese Zusammenhänge weiter vertiefen möchten, finden Sie im Glenfis Whitepaper „Next Generation IT Operating Model – Readiness als Schlüssel zur resilienten digitalen Organisation“ eine umfassende Einordnung der organisatorischen Fähigkeiten, Governance-Modelle und Wertströme, welche den in diesem Beitrag beschriebenen Digital Twin in ein ganzheitliches Betriebsmodell einbetten. Next Generation IT Operating Model – Whitepaper

Readiness beginnt nicht erst im Incident. Readiness beginnt mit Transparenz. Und genau diese Transparenz schafft der Digital Twin des IT Operating Models.