Zum Inhalt springen
DORA Art. 8 · DORA Art. 5 (Governance-Bezug) · FINMA-RS 2023/1 · NIS-2-relevant · ISO/IEC 27001 A.5.9 · EU AI Act 2024/1689

Ein Asset-Inventar, das IT-Betrieb, Sicherheit, Drittparteien und Regulatorik gleichzeitig spricht.

Demo vereinbarenAngebot zum Modul anfragen

Ein Asset, einmal erkannt und abgeglichen, das IT-Betrieb, Sicherheit, Drittpartei und Regulatorik gleichzeitig spricht – statt vier getrennter Inventare, die einander widersprechen.

Im Kern

Drei Gründe für Avalon CMDB

01

Ein einziges, belastbares Asset-Inventar – konsolidiert aus aktivierten Cloud-, On-Premise- und Infrastructure-as-Code-Quellen, Importen und manuell gepflegten Beständen.

02

Jedes Configuration Item trägt von Beginn an Sicherheits- und Regulatorik-Kontext – Schutzbedarf-, Gap- und Risikoanalysen greifen direkt auf konsistente Daten zu, statt sie nachzupflegen.

03

Prüfungssichere Nachvollziehbarkeit – Änderungshistorie pro Attribut, Abfragen für jeden Stichtag und Soll-Ist-Abgleich liefern den Nachweis für das ICT-Asset-Inventar und die Zuordnung kritischer Funktionen nach DORA Art. 8.

KI-Arbeitsmodell

KI bereitet vor. Menschen führen.

Jedes Modul bleibt klassisch bedienbar. Wenn KI aktiviert ist, übernimmt sie operative Vorbereitung und Verdichtung: Vorbefüllungen, Zuordnungen, Zusammenfassungen und Review-Queues. Verantwortliche Rollen prüfen Qualität, treffen die Entscheidung und geben den Nachweis frei.

Was sich im Arbeitsalltag ändert

  • Weniger manuelle Vorbefüllung, Kopieren und Konsolidieren.
  • Schnellere Durchläufe, weil Fachrollen vorbefüllte Arbeitsentwürfe statt leere Masken sehen.
  • Mehr Ressourcen für Steuerung, Qualitätssicherung und prüffähige Entscheidung.
01

Operative Vorarbeit

KI befüllt definierte Assessment- und Workflow-Felder vor, entwirft Zuordnungen, Texte oder Report-Bausteine und legt Quellen, Begründung und Konfidenz offen.

02

Menschliche Qualitätssicherung

Fachrollen prüfen, korrigieren, bündeln oder verwerfen. Freigaben, Overrides und rechtlich relevante Entscheidungen bleiben menschlich.

03

Auditierbarer Nachweis

Input, Vorbefüllung oder Entwurf, Entscheidung, Begründung und Version werden protokolliert. Der Effizienzgewinn kommt ohne Kontrollverlust.

Interessentenperspektive

Für wen dieses Modul gebaut ist

Primär: CISO und ICT-Risk-Manager – verantwortlich für ein vollständiges, prüfbares ICT-Asset-Inventar und den Nachweis nach DORA Art. 8. Sekundär: CMDB Steward und CMDB Administrator im operativen Betrieb (Pflege, Datenqualität, Erkennung, Sicherheits- und Regulatorik-Kontext) sowie der CRO für die Abhängigkeits- und Auswirkungstransparenz.

DORA · Art. 8
Was heute bremst
blind

CMDB kennt Hostname und Lifecycle – nicht Schutzbedarf, kritische Funktion oder Drittpartei-Bindung.

widersprüchlich

Cloud-Scan, On-Premise-Liste und Alt-Inventar zählen dasselbe Asset dreimal, mit drei Wahrheiten.

ungeschrieben

Welche Services ein Ausfall mitreißt, steht in keinem Bestand – die Abhängigkeit lebt in Köpfen.

Avalon-Kern

Ein Asset, einmal erkannt und abgeglichen, das IT-Betrieb, Sicherheit, Drittpartei und Regulatorik gleichzeitig spricht – statt vier getrennter Inventare, die einander widersprechen.

ein objekt · vier sichten

Configuration-Item-Prisma

Ein abgeglichenes CI – das gleichzeitig in vier GRC-Sichten lebt

Vier Quellen werden zu einem abgeglichenen Configuration Item. Dasselbe Objekt spricht zugleich IT-Betrieb, Sicherheit, Drittpartei und Regulatorik – und liefert per Stichtags-Baseline die prüffähige Nachweisgrundlage für das ICT-Asset-Inventar nach DORA Art. 8, ohne Doppelerfassung.

Beispieldaten · Illustration. Belegt: ISO/IEC 27001 A.5.9 (Inventar von Informationen und damit verbundenen Werten), DORA Art. 8 (Identifikation und ICT-Asset-Inventar inkl. kritischer Funktionen). Avalon unterstützt die Erfüllung; die Nachweisverantwortung verbleibt bei Ihrer Organisation.

Kernbausteine

Was dieses Modul für Sie leistet

Ein Asset, einmal erkannt und abgeglichen, das IT-Betrieb, Sicherheit, Drittpartei und Regulatorik gleichzeitig spricht – statt vier getrennter Inventare, die einander widersprechen.

Avalon-Kern

ein objekt · vier sichten

01

Zentrales Inventar aufbauen

Alle Configuration Items zentral erfassen – aus aktivierten Quellen übernommen, importiert, manuell ergänzt und um Bestände aus anderen GRC-Modulen vervollständigt.

02

Sicherheit und Regulatorik mitführen

Schutzbedarf, kritische Funktion und regulatorische Pflichten leben am Configuration Item – einmal bewertet, modulübergreifend nutzbar ohne Doppelerfassung.

03

Nachweise prüfungssicher liefern

Änderungshistorie, Stichtags-Abfragen und Soll-Ist-Baselines liefern den belastbaren Nachweis für Audits und das ICT-Asset-Management nach DORA.

So arbeitet Avalon CMDB

Vom erkannten Asset zum prüfungssicheren Bestandsverzeichnis

Prozesslogik

Jeder Schritt zeigt, welche Vorarbeit entsteht, wer prüft und welcher Nachweis daraus wird.

VorarbeitQualitätsprüfungNachweis
  1. 01Schritt

    1. Bestand aus aktivierten Quellen übernehmen

    Was passiert in diesem Schritt

    Je Mandant aktivierte Konnektoren, Importe oder manuelle Pflegepfade erfassen Configuration Items aus Cloud, On-Premise, Container-Umgebungen, Infrastructure-as-Code oder bestehenden CMDBs. Abdeckung und Datenqualität werden sichtbar gemacht, statt als vollständig vorausgesetzt zu werden.

  2. 02Schritt

    2. Abgleichen und Datenqualität sichern

    Was passiert in diesem Schritt

    Mehrere Erkennungsquellen werden zu einem konsistenten Bestand zusammengeführt. Datenqualitäts-Dashboards machen Lücken, veraltete Einträge und Konflikte sichtbar; Konflikte landen in einer geführten Klärungs-Inbox.

  3. 03Schritt

    3. Sicherheits- und Regulatorik-Kontext anlegen

    Was passiert in diesem Schritt

    Jedes Configuration Item wird um Schutzbedarf, kritische Funktion und regulatorische Pflichten ergänzt – einmal bewertet, von anderen GRC-Modulen direkt weiterverwendet.

  4. 04Schritt

    4. Abhängigkeiten und Auswirkungen sichtbar machen

    Was passiert in diesem Schritt

    Service- und Abhängigkeitskarten verknüpfen Geschäftsservices bis zur Infrastruktur. Auswirkungs- und Blast-Radius-Analysen zeigen, welche Services bei Ausfall oder Änderung eines Configuration Items betroffen sind.

  5. 05Schritt

    5. Lebenszyklus und Lizenzhinweise steuern

    Was passiert in diesem Schritt

    Hardware, Software, Lizenzen und Verträge werden über ihren Lebenszyklus geführt, soweit die entsprechenden Daten angebunden oder gepflegt sind – mit Laufzeit-Erinnerungen, End-of-Life-Hinweisen und lizenzbezogenen Auswertungen.

  6. 06Schritt

    6. Nachweisen und berichten

    Was passiert in diesem Schritt

    Änderungshistorie pro Attribut, Stichtags-Abfragen und Soll-Ist-Baselines liefern den prüfungssicheren Nachweis; vorgefertigte Asset-Register und Reports sind aus dem versionierten Bestand exportierbar.

Funktionsumfang

Was die CMDB im Detail leistet

01

CI-Repository mit GRC-Sicht

Über 60 sofort einsatzbereite Objektklassen für Hardware, Software, Cloud, Netzwerk, Rechenzentrum, Services, Verträge und Identitäten – frei um eigene, validierte Objekttypen erweiterbar. Jedes Configuration Item trägt IT-, Sicherheits-, Drittpartei- und Regulatorik-Kontext zugleich.

02

Konnektoren, Importe und Discovery-Scope

Bestände werden aus aktivierten Cloud-, On-Premise-, Container-, Netzwerk- und Infrastructure-as-Code-Quellen sowie über Importe zusammengeführt. Welche Discovery- oder ITAM-Quellen genutzt werden, wird je Mandant und Systemlandschaft festgelegt; Datenqualität, Abdeckung und manuelle Ergänzungen bleiben transparent sichtbar.

03

Abgleich, Datenqualität und Konfliktklärung

Mehrere Erkennungsquellen werden über exakte und unscharfe Abgleichregeln zu einem konsistenten Bestand zusammengeführt. Datenqualitäts-Dashboards messen Vollständigkeit, Aktualität, Eindeutigkeit und Konsistenz; Konflikte landen in einer geführten Klärungs-Inbox.

04

Abhängigkeiten, Service-Mapping und Auswirkungsanalyse

Interaktive Abhängigkeits- und Topologie-Ansichten verknüpfen Geschäftsservices durchgängig bis zur Infrastruktur. Auswirkungs- und Blast-Radius-Analysen beantworten, was bei Ausfall oder Änderung eines Configuration Items betroffen ist – die fachliche Grundlage für kritische Funktionen und Notfallplanung.

05

IT-Asset-Kontext über den gesamten Lebenszyklus

Hardware- und Software-Asset-Kontext wie Beschaffung, Standort, Wartung, Abschreibung, Entsorgung, Lizenzbestand und Verträge lässt sich am Configuration Item führen, soweit die Datenquelle angebunden oder gepflegt ist. Laufzeit-, End-of-Life- und Lizenzhinweise machen Kosten- und Risiko-Treiber sichtbar; formelle Lizenz-Compliance bleibt abhängig vom aktivierten Datenumfang.

06

Prüfungssichere Historie, Stichtags-Abfragen und Baselines

Jeder Attributwert trägt Quelle und Zeitpunkt; Änderungen werden lückenlos und unveränderbar protokolliert. Abfragen für jeden Stichtag rekonstruieren vergangene Zustände – ein direkter Nachweis für das ICT-Asset-Inventar und das Mapping kritischer Funktionen auf ICT-Assets nach DORA Art. 8.

07

Suche, Reports und Asset-Register aus dem versionierten Bestand

Volltextsuche und strukturierte Abfragen über den gesamten Bestand, gespeicherte Auswertungen und Dashboards. Vorgefertigte Reports – etwa ICT-Asset-Register, Datenqualitätsübersichten, veraltete Einträge und lizenzbezogene Auswertungen – sind exportierbar und liefern prüffähige Bestandsverzeichnisse auf Basis des aktivierten Datenumfangs.

08

Standalone betreiben oder mit bestehender CMDB koppeln

Avalon CMDB lässt sich als alleinige CMDB betreiben oder optional mit einer etablierten IT-Service-Management-CMDB synchronisieren – als Einmal-Migration oder als laufender beidseitiger Abgleich, bei dem pro Attribut festgelegt wird, welches System führend ist. Eine geführte Aktivierung mit mehrstufigem Daten- und Rückfall-Schutz stellt sicher, dass bestehende Bestände und Bewertungen erhalten bleiben.

Typische Szenarien

Wann die CMDB im Avalon-Einsatz ist

DORA-Prüfung des ICT-Asset-Managements

Eine beaufsichtigte Bank muss nachweisen, dass ihr ICT-Asset-Inventar vollständig, aktuell und mit kritischen Funktionen verknüpft ist. In Avalon erkennt die CMDB Bestände aus Cloud und On-Premise über konfigurierte Erkennungspfade, jeder Attributwert trägt Quelle und Zeitpunkt, und Stichtags-Abfragen rekonstruieren den Bestand zu jedem vergangenen Datum – der DORA-Art.-8-Nachweis entsteht aus Baseline, Historie und Export statt aus manueller Tabellenkonsolidierung.

Kritische Funktion fällt aus

Bei der Notfallplanung ist die Frage: Welche Geschäftsservices hängen an diesem Server, dieser Datenbank, diesem Cloud-Dienst? Die Service- und Abhängigkeitskarten zeigen den Blast-Radius durchgängig bis zur Infrastruktur – die fachliche Grundlage, um kritische Funktionen nach DORA Art. 8 abzusichern und Wiederanlauf-Prioritäten zu setzen.

Ablösung einer Alt-CMDB ohne Bruch

Eine Organisation will von einer bestehenden IT-Service-Management-CMDB auf Avalon wechseln, kann die Altsysteme aber nicht über Nacht abschalten. Avalon läuft zunächst parallel über einen laufenden Abgleich – pro Attribut ist festgelegt, welches System führend ist – und wird nach geführter Aktivierung mit mehrstufigem Rückfall-Schutz zur alleinigen CMDB, ohne dass Bestände oder Bewertungen verloren gehen.

Verbindungen

Wie dieses Modul mit Avalon zusammenspielt

Die CMDB ist die belastbare Asset-Grundlage – einmal erfasst und bewertet, modulübergreifend nutzbar ohne Doppelerfassung.

ISMS

Configuration Items bilden die Grundlage des Informationsverbunds: Das ISMS übernimmt die erfassten Assets samt Abhängigkeiten und ergänzt seine Schutzbedarfsbewertung, die wiederum am Configuration Item sichtbar wird. Einmal erfasst, einmal bewertet – ohne Asset-Daten in zwei Systemen zu pflegen.

IT Risk Management

Schutzbedarf und kritische Funktion am Configuration Item liefern den Bewertungskontext für die Risikobewertung. Erkennt die CMDB Abweichungen oder veraltete Bestände, lässt sich daraus ein Risiko-Hinweis ableiten – Asset-Transparenz und Risikoarbeit greifen auf denselben Bestand zu.

TPRM

Cloud- und Dienstleister-bezogene Configuration Items lassen sich mit den Anbietern und Drittdienstleistungs-Arrangements im TPRM-Modul verknüpfen. So wird sichtbar, welche Assets auf welchem Drittanbieter laufen – die Brücke zwischen technischem Bestand, DORA-relevanter IKT-Drittdienstleistung und MaRisk-Auslagerung, soweit einschlägig.

Regulatorik und Standards im Detail

Welche Anforderungen und Standards die CMDB unterstützt

  • DORA Art. 8
  • DORA Art. 5 (Governance-Bezug)
  • FINMA-RS 2023/1
  • NIS-2-relevant
  • ISO/IEC 27001 A.5.9
  • EU AI Act 2024/1689
DORA Art. 8
Die CMDB führt ein zentrales, jederzeit prüfbares ICT-Asset-Inventar mit lückenloser Änderungshistorie, Stichtags-Abfragen und Soll-Ist-Baselines. Kritische oder wichtige Funktionen werden mit den unterstützenden Configuration Items verknüpft, sodass das nach DORA Art. 8 erwartete Inventar und Abhängigkeitsbild nachvollziehbar belegt werden kann – bis auf den einzelnen Attributwert mit Quelle und Zeitpunkt.
DORA Art. 5 (Governance-Bezug)
DORA Art. 5 adressiert Governance und Verantwortlichkeit. Die CMDB ersetzt diese Governance nicht, liefert aber die belastbare Daten- und Nachweisgrundlage dafür: Eigentümer, Quellen, Review-Stände und Baselines machen sichtbar, ob ICT-Assets geordnet geführt, überprüft und verantwortet werden.
FINMA-RS 2023/1 – ICT-, Cyber- und kritische-Daten-Risiken
Für Schweizer Banken kann die CMDB als Datenbasis für ICT-/Cyber-Risiken und kritische Daten im Sinne von FINMA-RS 2023/1 dienen: Assets, Eigentümer, Abhängigkeiten, Schutzbedarf und Historie bleiben nachvollziehbar. Ein pauschaler FINMA-Konformitätsnachweis ist damit nicht verbunden.
NIS-2 (Relevanz)
Das durchgängige Asset-Register und die Sicht auf kritische Komponenten unterstützen die von NIS-2 erwartete Bestands- und Risikotransparenz. Schutzbedarf und kritische Funktion am Configuration Item machen sichtbar, welche Komponenten besonderen Schutz benötigen.
ISO/IEC 27001 A.5.9
Das zentrale Inventar mit Eigentümern, Klassifizierung und Lebenszyklus unterstützt die Inventarisierung der Werte im Sinne von ISO/IEC 27001 A.5.9; ein vorgefertigtes Asset-Register stellt diese Bestandsübersicht ohne manuelle Tabellenpflege bereit.
EU AI Act 2024/1689
Der optionale KI-Co-Pilot der CMDB wird je aktiviertem Use Case im AI-Governance-Modul dokumentiert und klassifiziert. Unabhängig von der konkreten Risikoklasse sind Kennzeichnung, Begründung, Konfidenz, Modell-/Versionsangabe, Human-in-the-Loop und Audit-Trail vorgesehen; die Entscheidung bleibt beim Menschen.

Avalon unterstützt die Umsetzung dieser Rahmenwerke. Die Konformität bleibt in der Verantwortung Ihrer Organisation.

KI-PlattformEntscheidungshoheit: Mensch entscheidetStatus: Live

KI mit Kontrolle: optionaler Co-Pilot für Vorbefüllung

Die KI ist in der CMDB ein optionaler, standardmäßig deaktivierter Co-Pilot – jeder Workflow funktioniert vollständig auch ohne sie. Wo aktiviert, erstellt sie prüfbare Arbeitsentwürfe: mögliche Dubletten, vermutete Abhängigkeiten, Klassifizierungs- und Beschreibungs-Hilfen, Erläuterungen zum Datenqualitäts-Score und Service-Map-Entwürfe. Jede Vorbefüllung durchläuft eine menschliche Prüfung und kann übernommen, angepasst oder verworfen werden; die KI schreibt niemals Lebenszyklus-, Eigentümer-, Betriebs- oder regulatorische Felder. Aktivierte KI-Fähigkeiten werden mit System-Card, Datenhandling, Limitationen und Human-in-the-Loop dokumentiert; Scope und Freischaltung werden je Mandant abgegrenzt. Generell gilt: KI als Co-Pilot, nicht als Autopilot – jede Ausgabe bleibt nachvollziehbar, editierbar und auditierbar, die Entscheidung bleibt beim Menschen.

Optionaler KI-Baustein

Asset-Datenqualität wird schneller prüfbar

KI kann Dubletten, Abhängigkeiten, Beschreibungen, Klassifizierungsfelder und Service-Map-Entwürfe vorbereiten. Lebenszyklus, Owner und regulatorische Kernfelder bleiben geschützt.

Wo KI im Prozess eingreift
  • Discovery- und Inventardaten werden konsolidiert und auf Plausibilität geprüft.
  • Abhängigkeits- und Service-Map-Felder starten mit erklärbaren Arbeitsentwürfen.
  • Geschützte Lebenszyklus-, Ownership- und Regulatorikfelder bleiben menschlich bestätigt.
Assessment-VorbefüllungVORSCHLAG
Schutzbedarfs-Assessment
Vorbefüllt
Methode: CIA · Maximumprinzip · VVT-0091
IHRE ENTSCHEIDUNG
On-Premise · kein Datenabfluss · EU-AI-Act-konform
Ohne KI
  • CMDB-Teams pflegen Discovery-Ergebnisse, Beziehungen und Datenqualitätsbefunde manuell.
  • Baseline, Historie, Stichtagsabfragen und DORA-Nachweise bleiben vollständig verfügbar.
  • Entscheidungen zu Owner, Lifecycle und Kritikalität werden klassisch gesetzt.
Mit KI
  • KI bereitet Dublettenprüfung, Beziehungsentwürfe, Beschreibungen und Qualitätsbegründungen vor.
  • Review-Queues zeigen, welche CI-Felder bestätigt, angepasst oder verworfen werden müssen.
  • Asset-Verantwortliche gewinnen Tempo bei Bereinigung, Mapping und Audit-Vorbereitung.
  • Human-in-the-Loop: jede KI-Vorbefüllung wird einzeln geprüft – übernehmen, anpassen oder verwerfen; kein automatisches Übernehmen.
  • Optional und abschaltbar: die KI ist standardmäßig deaktiviert, jeder Workflow funktioniert vollständig auch ohne sie.
  • Auditierbar: jede KI-Aktion wird mit Begründung und Herkunft protokolliert; geschützte Lebenszyklus-, Eigentümer- und Regulatorik-Felder bleiben dem Menschen vorbehalten.
Wie KI mit Kontrolle bei Avalon funktioniert

Häufige Fragen zur CMDB

Avalon CMDB ist als GRC-native Configuration-Management-Datenbank ausgelegt: Erkennung, Service-Mapping, IT-Asset-Management, Historie und Reporting werden mit Sicherheits-, Drittpartei- und Regulatorik-Kontext verbunden. So liefert das Inventar unmittelbar die Grundlage für Schutzbedarf, Risikobewertung und regulatorische Nachweise.

Ja. Avalon CMDB lässt sich als alleinige CMDB betreiben oder optional mit einer etablierten IT-Service-Management-CMDB synchronisieren – als Einmal-Migration oder als laufender beidseitiger Abgleich, bei dem pro Attribut festgelegt wird, welches System führend ist. Eine geführte Aktivierung mit mehrstufigem Daten- und Rückfall-Schutz stellt sicher, dass bestehende Bestände erhalten bleiben.

Über ein zentrales, jederzeit prüfbares ICT-Asset-Inventar mit lückenloser Änderungshistorie pro Attribut, Abfragen für jeden Stichtag, Soll-Ist-Baselines und Mapping kritischer Funktionen auf unterstützende ICT-Assets. Damit lässt sich das nach DORA Art. 8 geforderte Inventar und Abhängigkeitsbild nachvollziehbar belegen.

Nein. Die KI ist ein optionaler, standardmäßig deaktivierter Co-Pilot; jeder Workflow funktioniert vollständig auch ohne sie. Wo aktiviert, liefert sie ausschließlich Vorbefüllungen und Arbeitsentwürfe, die einzeln geprüft, angepasst oder verworfen werden – die KI schreibt niemals Lebenszyklus-, Eigentümer- oder regulatorische Felder. Aktivierte KI-Fähigkeiten werden mit System-Card, Datenhandling, Limitationen und Human-in-the-Loop dokumentiert; Scope und Freischaltung werden je Mandant abgegrenzt.

Module

Welches Modul passt zu Ihrem nächsten Schritt?

Wir zeigen Ihnen Avalon entlang Ihrer aktuellen Fragestellung – konkret, in Ihrem Kontext, ohne Standard-Sales-Demo.

  • On-Premise
  • Human-in-the-Loop
  • EU-AI-Act-Governance
Kostenlosen Demo-Termin vereinbarenAngebot anfragen

On-Premise · KI-Inferenz auf Ihrer Appliance