Die meisten Unternehmen haben nicht ein Asset-Inventar, sondern vier: eines für die IT, eines für den Datenschutz, eines für die ISO-27001-Zertifizierung und, seit Kurzem, eines für KI-Systeme. Diese Anleitung zeigt, wie sich das auf ein einziges Inventar reduzieren lässt, das alle vier Audits gleichzeitig besteht, ohne bei jedem Audit von vorn zu beginnen. Dass genau diese Zusammenführung von Datenschutz, Informationssicherheit und ISO-27001-Vorbereitung zu einem gemeinsamen Managementinstrumentarium der wirksamere Weg ist, bestätigt auch die einschlägige Fachliteratur zum integrierten Sicherheits- und Datenschutzmanagement.

Schritt 1: Welche Felder gehören ins Inventar

Ein Cross-Framework-Inventar braucht mehr Felder als ein reines IT-Register, aber deutlich weniger als vier separate Register zusammen. Der Kern besteht aus einem gemeinsamen Grundgerüst plus wenigen framework-spezifischen Zusatzfeldern:

FeldZweck
Asset-ID, Name, OwnerEindeutige Identifikation und Verantwortlichkeit
Standort / HostingOn-Premise, Cloud-Anbieter, Auftragsverarbeiter
Kritikalität (niedrig/mittel/hoch)Basis für NIS-2-Risikobewertung und DSFA-Schwelle
Personenbezogene Daten (ja/nein, Kategorie)Grundlage für DSGVO-Einordnung und VVT-Eintrag
KI-Komponente (ja/nein, Risikoklasse)Einordnung nach EU AI Act, falls zutreffend
ISO-27001-KontrollzuordnungVerweis auf Annex-A-Kontrollen, die das Asset abdecken
Letzte ÜberprüfungNachweis der Aktualität für alle vier Audits gleichzeitig

Schritt 2: Zuordnung zu den vier Frameworks

Statt für jedes Framework eine eigene Bewertung zu erheben, wird jedes Asset einmal bewertet und die Bewertung anschließend auf alle relevanten Frameworks gespiegelt. Ein System, das personenbezogene Kundendaten verarbeitet und als „wichtige Einrichtung" unter NIS-2 gilt, erhält eine einzige Kritikalitätsbewertung. Diese eine Bewertung entscheidet gleichzeitig, ob eine Datenschutz-Folgenabschätzung nötig ist, welche NIS-2-Risikomaßnahmen greifen und welche ISO-27001-Kontrollen dokumentiert sein müssen. Für die EU-AI-Act-Spalte gilt dasselbe Prinzip auf technischer Ebene: Eine aktuelle Forschungsarbeit zu einem EU-AI-Act-konformen Open-Source-Paket zeigt, wie die nach Art. 10 EU AI Act geforderte Data-Governance-Dokumentation direkt an eine Inventarisierung von Systemkomponenten gekoppelt werden kann, statt sie separat zu pflegen.

EIN ASSET CRM-System Kritikalität: hoch Personenbezogen: ja KI-Komponente: nein → DSGVO VVT-Eintrag NIS-2 Risikomaßnahme ISO 27001 Annex-A-Kontrolle EU AI Act Risikoklasse

ABB. 1 · EIN ASSET, EINE BEWERTUNG, VIER FRAMEWORK-ANSICHTEN

Schritt 3: Verantwortlichkeiten festlegen

Jedes Asset braucht genau einen Owner, keinen Owner pro Framework. Der Owner ist dafür verantwortlich, dass die Bewertung aktuell bleibt, nicht dafür, die DSGVO-, NIS-2-, ISO-27001- und EU-AI-Act-Anforderungen im Detail zu kennen. Diese Trennung zwischen operativer Verantwortung fürs Asset und fachlicher Verantwortung fürs jeweilige Framework verhindert, dass ein Systemverantwortlicher vier unterschiedliche Ansprechpartner mit vier unterschiedlichen Formularen bedienen muss.

Schritt 4: Pflegeprozess statt einmaliger Erhebung

Ein Inventar, das einmal erhoben und danach nicht mehr angefasst wird, ist nach wenigen Monaten wertlos. Entscheidend ist, an welchen Ereignissen eine Aktualisierung automatisch ausgelöst wird: bei einem Systemwechsel oder -austausch, bei einer neuen Verarbeitungstätigkeit, beim Hinzufügen einer KI-Komponente zu einem bestehenden System, und nach jedem sicherheitsrelevanten Vorfall. Wer diese vier Auslöser als festen Prozess etabliert, spart sich die jährliche Vollerhebung, die in der Praxis ohnehin selten vollständig gelingt.

Enterprise-Gespräch

Automatisierung für Ihr Asset-Inventar

Kostenloser Stresstest, im Anschluss auf Wunsch ein Gespräch zur Automatisierung mit BAM Enterprise.

Stresstest starten →

Typische Fehler beim Aufbau

Drei Fehler tauchen in der Praxis immer wieder auf. Der erste ist, zu viele Felder auf einmal einführen zu wollen. Ein Inventar mit vierzig Pflichtfeldern wird von niemandem konsequent gepflegt, ein Inventar mit den sieben Kernfeldern aus Schritt 1 dagegen schon. Zusätzliche framework-spezifische Details lassen sich später ergänzen, sobald das Grundgerüst läuft.

Der zweite Fehler ist, das bestehende IT-Asset-Management-Tool komplett zu ersetzen, statt es zu erweitern. Die meisten Unternehmen haben bereits ein CMDB- oder Inventar-Tool im Einsatz. Die vier zusätzlichen Compliance-Felder lassen sich in aller Regel als Erweiterung an das bestehende System anflanschen, statt ein Parallelsystem aufzubauen, das dann selbst wieder synchronisiert werden muss.

Der dritte Fehler ist, die Kritikalitätsbewertung als einmaligen Workshop zu behandeln statt als lebenden Prozess. Eine Kritikalität, die bei der Einführung vor zwei Jahren festgelegt wurde und seither unverändert ist, ist bei den meisten Systemen längst überholt, weil sich Nutzung, Datenvolumen oder Anbindungen verändert haben, ohne dass jemand die Bewertung angepasst hat.

BAM CROSS-Objekte als Beispieldaten

So sieht ein Cross-Framework-Asset in seiner einfachsten Form aus, mit den vier Framework-Referenzen als Verweise, nicht als Kopien:

{
  "asset_id": "AST-0142",
  "name": "CRM-System",
  "owner": "IT-Betrieb",
  "criticality": "hoch",
  "personal_data": true,
  "ai_component": false,
  "frameworks": {
    "dsgvo": { "vvt_ref": "VVT-0031" },
    "nis2": { "risk_measure_ref": "NIS2-RM-014" },
    "iso27001": { "annex_a_controls": ["A.8.9", "A.5.15"] },
    "eu_ai_act": null
  },
  "last_reviewed": "2026-07-01"
}

Jedes Framework greift auf dieselbe Kritikalität und dieselbe Klassifizierung zu, statt sie neu zu erheben. Genau das ist der Unterschied zwischen einem Inventar, das vier Audits parallel besteht, und vier Inventaren, die bei der ersten Nachfrage widersprüchliche Antworten geben.

Der Aufwand, ein solches Inventar aufzubauen, liegt nicht im Datenmodell selbst, das lässt sich in wenigen Tagen entwerfen. Er liegt darin, die vier bislang getrennt arbeitenden Teams, IT, Datenschutz, Informationssicherheit und, zunehmend, KI-Governance, auf ein gemeinsames Set an Kernfeldern zu einigen. Wer diesen organisatorischen Teil ernst nimmt, merkt beim nächsten Audit den Unterschied zuerst dort, wo es am meisten zählt: bei der Frage, wie schnell und wie widerspruchsfrei sich eine Anfrage der Aufsichtsbehörde beantworten lässt. Dass eine solche gemeinsame Datenbasis nicht nur Compliance-Aufwand reduziert, sondern zur Grundlage für ein insgesamt datengetriebenes Unternehmen wird, ordnet aktuelle Literatur zu Data Governance in datengetriebenen Unternehmen in einen größeren Zusammenhang ein.

Quellen