Ein konsistenter und aktueller Informationsverbund steht heute für weit mehr als nur eine Dokumentationspflicht: Er ist die Basis für funktionierende Schutzbedarfsbewertungen, die Identifikation kritischer oder wichtiger IKT‑Assets und die DORA‑konforme Steuerung des gesamten IKT‑Assetmanagements. Doch in der Praxis zeigt sich immer wieder – selbst kleine Inkonsistenzen können große Wirkung entfalten.
Wie entstehen Inkonsistenzen im Informationsverbund / IKT-Assetmanagement?
Inkonsistenzen sind selten das Ergebnis eines einzelnen Fehlers. Viel häufiger entstehen sie über die Zeit hinweg – durch organisatorische, technische oder prozessuale Faktoren:
1. Dezentrale Pflege und unterschiedliche Verantwortlichkeiten
Wenn mehrere Rollen und Bereiche parallel Assets anlegen, ändern oder löschen, entstehen zwangsläufig Unterschiede in Struktur, Benennung oder Attributpflege. Besonders kritisch: fehlende oder abweichende Zuordnungen zu Prozessen, Anwendungen oder Dienstleistern.
2. Unvollständige oder verspätete Aktualisierungen
Änderungen in der Architektur, bei Dienstleistern oder beim Betrieb werden nicht immer zeitgleich in allen relevanten Systemen angepasst. Dadurch weichen technische Realitäten und dokumentierte Abhängigkeiten voneinander ab.
3. Fehlende Konsistenzregeln und Qualitätsprüfungen
Ohne klar definierte Muss-Felder, Namenskonventionen oder regelmäßige QS‑Schleifen entwickelt sich der Informationsverbund historisch und inhomogen. Die typische Folge ist: Assets, die in einem Tool als kritisch geführt werden, tauchen im Informationsverbund nur als „unterstützende Ressource“ oder gar nicht auf – oder umgekehrt.
4. Unklare Abgrenzungen
Besonders im Zusammenspiel zwischen Anwendungen, IKT‑Dienstleistungen und Infrastruktur kommt es häufig zu Unschärfen: Ist eine Komponente ein Vertrag? Eine Dienstleistung? Eine Anwendung oder doch ein IKT-Asset? Fehlt diese Klarheit in der Abgrenzung, wird sie von verschiedenen Personen unterschiedlich eingeordnet und dokumentiert.
Warum Inkonsistenzen so kritisch sind
1. Auswirkungen auf Schutzbedarfsbewertungen
Schutzbedarfe werden oft vererbt – vom Prozess auf die unterstützende Anwendung, von der Anwendung auf die technische Ressource usw. Ist die Abhängigkeit nicht sauber dokumentiert, passiert Folgendes:
- Schutzbedarfsvererbung greift nicht → Assets werden als weniger kritisch eingestuft, als sie es tatsächlich sind.
- Overengineering → Assets erhalten zu hohe Schutzmaßnahmen, weil sie fälschlich als kritisch gelten.
- Unvollständige Betrachtung → Risiken und Notfallanforderungen werden nicht vollständig erkannt.
Gerade bei DORA-relevanten Prozessen ist das fatal: Ein nicht erkanntes kritisches Asset kann bedeuten, dass notwendige Maßnahmen nicht umgesetzt werden – von Schwachstellenscans über Monitoring bis hin zu Ausstiegsstrategien.
2. Auswirkungen auf das IKT‑Assetmanagement nach DORA
Die DORA‑Vorgaben verlangen Transparenz über folgende Sachverhalte:
- Welche Funktionen sind kritisch oder wichtig
- Welche Assets unterstützen diese Funktionen
- Wie werden diese Assets betrieben, überwacht und abgesichert
- Welche IKT‑Dienstleister sind beteiligt
- Wie werden Risiken entlang dieser Kette gesteuert
Inkonsistenzen in den Asset‑ und Abhängigkeitsdaten führen zu erheblichen Nachteilen:
1a) Falsche oder unvollständige Klassifizierung von IKT‑Assets
Wenn die Zuordnung zu kritischen/wichtigen Funktionen fehlt, werden Assets nicht als „kritisch/wichtig“ klassifiziert – und entziehen sich damit dem DORA‑Regelwerk.
1b) Fehler in der Steuerung von IKT‑Dienstleistungen
DORA verlangt eine klare Identifikation (kritischer) IKT‑Dienstleistungen und die Umsetzung spezifischer Maßnahmen wie Ausstiegsstrategien, Steuerungsmaßnahmen, Vertragsergänzungen oder Berichtswege. Fehlt die korrekte Zuordnung, wird die Dienstleistung schlicht nicht nach DORA gesteuert.
1c) Fehlende oder unzutreffende Notfallplanung
DORA knüpft direkt an die Notfallrelevanz an. Wird ein Asset nicht als notfallrelevant erkannt, fehlt es später in diesen Bereichen:
- Notfallpläne bzw. Geschäftsfortführungspläne
- Wiederanlaufpläne
- Kommunikationspläne
- Testprogramme
1d) Schwierigkeiten in der DORA‑Berichterstattung
Inkonsistenzen erschweren die Erfüllung der umfangreichen Dokumentations‑ und Reportingpflichten – vom IKT‑Risikorahmen bis zur Aggregation kritischer Dienstleisterabhängigkeiten.
Fazit: Konsistenz ist kein „Nice-to-have“, sondern regulatorische Notwendigkeit
Ein sauber gepflegter Informationsverbund ist das Fundament, auf dem Schutzbedarfsbewertung, Notfallmanagement, IKT‑Drittparteiensteuerung und die gesamte DORA‑Compliance aufbauen.
Was nicht verbunden ist, wird nicht berücksichtigt.
Was nicht berücksichtigt wird, führt zu Fehleinschätzungen.
Fehleinschätzungen gefährden die DORA Compliance.
Was Institute jetzt tun sollten
- Governance klären: Rollen, Verantwortlichkeiten und Abläufe eindeutig und verbindlich definieren.
- Qualitätsstandards etablieren: Pflichtattribute für Dokumentationen, Change-Prozesse und QS‑Checklisten verbindlich machen.
- Abhängigkeiten vollständig dokumentieren: Jede kritische/wichtige Funktion klar mit Anwendungen, Services und technischen Ressourcen verknüpfen und deren maßgebliche Abhängigkeiten auf die Geschäftsfortführung der Funktionen klären
- Regelmäßige Synchronisation & Review‑Zyklen: Daten aus dem GRC‑Tool aktuell und konsistent halten.
- Sensibilisierung und Schulung: Einheitliches Verständnis sorgt für einheitliche Daten.
Sie haben Fragen oder möchten mit uns zu diesem Thema in den Austausch gehen? Sprechen Sie uns gerne an – wir freuen uns auf Sie!
