¶ Asset-Inventar
Beispieldokument: Die aufgeführten Assets und Bewertungen sind fiktive Beispieldaten der „Muster GmbH“. Sie dürfen nicht als tatsächlicher Unternehmensbestand oder als abgeschlossene Schutzbedarfsfeststellung verwendet werden.
CIA-Pflicht: Jedes relevante Asset muss vor der fachlichen Freigabe getrennt nach C – Confidentiality/Vertraulichkeit, I – Integrity/Integrität und A – Availability/Verfügbarkeit bewertet und begründet werden. Eine Informationsklassifizierung oder pauschale Kritikalitätsstufe ersetzt diese drei Einzelbewertungen nicht.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | ISMS-REG-03-01 |
| Dokumentenart | Register / Asset-Inventar |
| Wiki.js-Pfad | /ISMS/03-Organisation-und-Assets/Asset-Inventar |
| Verantwortlich | ISMS-Beauftragte/r |
| Fachlich geprüft durch | Asset-, Prozess- und Systemverantwortliche |
| Freigabe durch | Geschäftsführung |
| Status | Entwurf – reale Assets, CIA-Bewertungen und Owner nicht bestätigt |
| Version | 0.4 |
| Stand | 09.08.2026 |
| Gültig ab | Nach Bestandsaufnahme und Freigabe |
| Nächste Prüfung | Fortlaufend sowie mindestens jährlich |
| Schutzklasse | Vertraulich |
| ISO-Bezug | ISO/IEC 27001:2022, insbesondere Annex A 5.9 bis 5.14 |
| VDA-ISA-Bezug | ISA 6.0.3, Kapitel 1.3 „Asset Management“ |
Jedes Asset wird eindeutig erfasst, einem Owner und Prozess zugeordnet und getrennt nach Confidentiality, Integrity und Availability bewertet. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Zweck
Das Asset-Inventar erfasst die für das Informationssicherheitsmanagementsystem relevanten Informationen und zugehörigen Werte. Es schafft eine nachvollziehbare Grundlage für:
- Schutzbedarfsfeststellung und Informationsklassifizierung,
- Zuweisung von Eigentümerschaft und Verantwortung,
- Informationssicherheits-Risikobewertungen,
- Zugriffs- und Berechtigungsentscheidungen,
- Datensicherung und Wiederanlaufplanung,
- Lieferanten- und Cloud-Steuerung,
- sichere Nutzung, Rückgabe, Löschung und Entsorgung,
- ISO-27001-Audits und TISAX-Assessments.
Das Inventar beantwortet damit nicht nur die Frage „Was besitzen oder nutzen wir?“, sondern insbesondere:
- Welchen Geschäftsprozess oder Dienst unterstützt das Asset?
- Welche Informationen werden verarbeitet?
- Wer entscheidet fachlich und wer betreibt das Asset technisch?
- Welche Schäden entstehen bei Offenlegung, Manipulation oder Ausfall?
- Welche Sicherheits-, Wiederanlauf- und Lebenszyklusmaßnahmen sind daraus abzuleiten?
¶ 2. Geltungsbereich
Erfasst werden alle Assets, die:
- Informationen innerhalb des ISMS-Geltungsbereichs enthalten oder verarbeiten,
- für kritische Geschäfts- oder Unterstützungsprozesse erforderlich sind,
- Sicherheitsmaßnahmen bereitstellen,
- Kunden-, Personen-, Entwicklungs- oder Prototypinformationen schützen,
- wesentliche Abhängigkeiten oder Ausfallrisiken verursachen,
- durch externe Dienstleister oder Cloud-Anbieter bereitgestellt werden.
Der verbindliche Scope ist unter Geltungsbereich und Standorte festgelegt.
Private Geräte und nicht freigegebene Dienste werden nicht als regulär zugelassene Assets behandelt. Werden sie erkannt, sind sie als Abweichung oder Risiko zu erfassen.
¶ 3. Grundsätze
- Jedes relevante Asset erhält eine eindeutige Asset-ID.
- Für jedes Asset wird eine verantwortliche Rolle benannt.
- Informationen werden unabhängig vom Speichermedium als eigene Assets betrachtet.
- Ausgelagerte und cloudbasierte Assets bleiben Bestandteil der Risikobetrachtung.
- Vertraulichkeit, Integrität und Verfügbarkeit werden für jedes relevante Asset einzeln bewertet und begründet.
- Abhängigkeiten zu Prozessen, Systemen, Standorten und Dienstleistern werden dokumentiert.
- Änderungen, Übergaben, Rückgaben, Löschungen und Entsorgungen werden nachvollziehbar gesteuert.
- Ein Asset gilt erst als aus dem Inventar entfernt, wenn Daten, Zugriffe, Verträge und Nachweise ordnungsgemäß behandelt wurden.
- Hochsensible technische Details werden in geschützten Systemen geführt und im Wiki nur referenziert.
- Das Inventar wird nicht allein durch eine jährliche Momentaufnahme gepflegt, sondern in relevante Änderungsprozesse eingebunden.
¶ 3.1 Freigaberegel für CIA
Ein Assetdatensatz ist fachlich unvollständig, solange mindestens eine der drei CIA-Bewertungen oder ihre Begründung fehlt. Die Gesamtstufe wird erst nach den Einzelbewertungen ermittelt. Dabei gilt im Muster das Maximumprinzip: Die höchste Einzelstufe bestimmt den Gesamtschutzbedarf. Eine Mittelwertbildung ist unzulässig, weil sie beispielsweise eine hohe Integritätsanforderung durch niedrigere Werte bei Vertraulichkeit oder Verfügbarkeit verdecken würde.
Eine Bewertung ist außerdem zu aktualisieren, wenn sich Informationsarten, Prozesskritikalität, Standort, Architektur, Lieferant, Vertrag, RTO/RPO oder der Asset-Lebenszyklus wesentlich ändern.
¶ 4. Asset-Kategorien und Kennzeichnung
| Präfix | Asset-Kategorie | Beispiele |
|---|---|---|
| INF | Informationen und Datenbestände | Zeichnungen, Verträge, Personal- oder Prüfdaten |
| PRO | Geschäfts- und Unterstützungsprozesse | Entwicklung, Produktion, Einkauf, Incident Management |
| APP | Anwendungen und Cloud-Dienste | ERP, CAD/PDM, E-Mail, Ticketsystem |
| SYS | Server, Plattformen und technische Systeme | Verzeichnisdienst, Virtualisierung, Backupplattform |
| NET | Netzwerke und Kommunikation | LAN, WLAN, VPN, Firewall, Standortverbindung |
| END | Endgeräte | Notebook, Smartphone, Engineering-Workstation |
| OT | Produktions- und Betriebstechnik | Maschinensteuerung, Produktionsnetz, Messsystem |
| PHY | Standorte und physische Infrastruktur | Gebäude, Serverraum, Archiv, Sicherheitsbereich |
| SUP | Lieferanten und externe Services | IT-Support, Hosting, Entsorgung, Logistik |
| PER | Personen, Rollen und Wissen | Schlüsselrollen, Spezialwissen, Administratoren |
| SEC | Sicherheitsdienste und -werkzeuge | SIEM, EDR, Zutrittskontrolle, Schwachstellenscanner |
Asset-IDs folgen dem Schema:
[Kategorie]-[laufende Nummer]
Beispiele: INF-001, APP-004, OT-012.
Eine Asset-ID wird nach Außerbetriebnahme nicht erneut vergeben.
¶ 5. Rollen und Verantwortlichkeiten
| Rolle | Verantwortung |
|---|---|
| Geschäftsführung | Rahmen, Ressourcen und wesentliche Risikoentscheidungen |
| ISMS-Beauftragte/r | Inventarstruktur koordinieren, Qualität prüfen und Gesamtstatus berichten |
| Asset Owner | Schutzbedarf, zulässige Nutzung, Zugriffe, Risiken und Lebenszyklus entscheiden |
| Information Owner | Klassifizierung, Weitergabe, Aufbewahrung und Löschung von Informationen festlegen |
| System-/Service Owner | Betrieb, Verfügbarkeit, Änderungen, Lieferanten und technische Nachweise steuern |
| Prozessverantwortliche/r | Prozesskritikalität, Abhängigkeiten sowie RTO/RPO fachlich bestimmen |
| IT-Betrieb | Technische Bestandsdaten, Konfiguration und Betriebsstatus pflegen |
| Einkauf/Service Owner | Verträge, Dienstleister und Exit-Regelungen pflegen |
| Benutzer/Asset-Nutzende | Assets entsprechend Vorgaben nutzen, schützen und Änderungen melden |
„Asset Owner“ bezeichnet die steuernde Verantwortung und nicht zwingend das rechtliche Eigentum oder den physischen Besitz.
¶ 6. Pflichtfelder je Asset
Die Feldstruktur orientiert sich an den vorhandenen Arbeitsvorlagen. Für die praktische Pflege werden fachliche Masterdaten und technische Detaildaten über dieselbe Asset-ID verbunden.
¶ 6.1 Fachliches Masterregister
| Feldgruppe | Felder aus der Vorlage | Zweck |
|---|---|---|
| Identität | Asset-ID, konkrete Bezeichnung/Systemname, Asset/Informationswert | Asset und geschäftlichen Wert eindeutig unterscheiden |
| Kontext | Beschreibung/Geschäftszweck, Geschäftsprozess/Dienst, Asset-Kategorie, Asset-Klasse | fachliche Nutzung und geeignete Granularität erklären |
| Verantwortung | Asset Owner, fachlicher Owner, operative beziehungsweise technische Verantwortung | Entscheidung, Betrieb und Vertretung trennen |
| Betrieb | Standort/Hosting, Anbieter/Partner | physische, cloudbezogene und externe Abhängigkeit zeigen |
| Datenbezug | Datenarten, Personenbezug, Prototypenbezug | besondere Schutz- und Complianceanforderungen erkennen |
| CIA | C – Vertraulichkeit, I – Integrität, A – Verfügbarkeit, jeweilige Begründung, Gesamtschutzbedarf | Schutzanforderungen transparent ableiten |
| Informationssteuerung | Informationsklassifizierung, Aufbewahrung/Löschung, Rückgabe/Exit | Nutzung und Lebenszyklus der Informationen steuern |
| Steuerung | ISO-/TISAX-Bezug, Status, letzte/nächste Prüfung, Quelle/Nachweis/Bemerkung | Prüfung, Aktualität und Nachvollziehbarkeit sichern |
¶ 6.2 Technisches Detailregister
| Feldgruppe | typische Detailfelder | Zweck |
|---|---|---|
| Technik | technische Asset-ID, Hersteller, Modell, Seriennummer, Hostname, Version/Build | technische Identifikation in geschützter Ablage |
| Abhängigkeiten | Netze, Plattformen, Identitäten, Schnittstellen, Personen, Versorgung | Ausfallradius und Wiederanlaufreihenfolge erkennen |
| Resilienz | Backup, RTO, RPO, Ersatzverfahren, letzter Restore-/Wiederanlauftest | Wiederherstellbarkeit und Notbetrieb steuern |
| Schutzstatus | MFA, Verschlüsselung, Monitoring, Patch-/Update-Verantwortung | zentrale Sicherheitsanforderungen referenzieren |
| Lieferant | Hersteller, Dienstleister, Vertrag, SLA, AVV und Exit | externe Pflichten und Abhängigkeiten steuern |
| Risiko und Maßnahmen | Risiko-ID, Maßnahmen-ID, Ausnahme, Restrisiko | Inventar mit Risikomanagement verbinden |
| Lebenszyklus | Status, Support/EOL, letzte Aktualisierung, Kommentar | Beschaffung bis Ausmusterung nachvollziehen |
Nicht jedes Feld ist für jede Asset-Kategorie gleich relevant. Nicht benötigte Felder werden begründet als „nicht anwendbar“ gekennzeichnet und nicht kommentarlos leer gelassen.
Seriennummern, Hostnamen, IP-Adressen, Versionen, genaue Standorte und technische Sicherheitsdetails gehören grundsätzlich nicht in eine öffentlich erreichbare Wiki-Tabelle. Das Wiki zeigt Aufbau und Steuerungslogik; operative Originalregister werden geschützt geführt.
¶ 7. Informationsklassifizierung
| Klassifizierung | Grundsätzliche Bedeutung | Beispiele |
|---|---|---|
| Öffentlich | Freigegebene Veröffentlichung verursacht keinen schädlichen Offenlegungseffekt | Veröffentlichte Website- und Marketinginformationen |
| Intern | Für betriebliche Nutzung; Offenlegung kann begrenzte Nachteile verursachen | Allgemeine Prozessinformationen |
| Vertraulich | Zugriff nur nach Aufgabe und Need-to-know; Offenlegung kann wesentliche Schäden verursachen | Verträge, Kalkulationen, personenbezogene Daten |
| Streng vertraulich | Stark beschränkter Zugriff; Offenlegung kann schwerwiegende oder kritische Schäden verursachen | Besonders schützenswerte Kunden-, Strategie- oder Prototypinformationen |
Die detaillierten Regeln für Kennzeichnung, Speicherung, Übertragung und Löschung werden unter Informationsklassifizierung festgelegt.
Die Klassifizierung beschreibt vor allem Anforderungen an die Vertraulichkeit. Hohe Anforderungen an Integrität oder Verfügbarkeit werden zusätzlich über den Schutzbedarf dokumentiert.
¶ 8. Schutzbedarfsfeststellung
¶ 8.1 CIA ist für jedes Asset getrennt zu bewerten
Wer darf die Information kennen und welcher Schaden entsteht bei unbefugter Offenlegung?
Welche Folgen haben unbemerkte Veränderung, unvollständige oder falsche Daten?
Wie lange darf das Asset fehlen und welche Folgen hat ein verspäteter Zugriff?
Die Bewertung bezieht sich auf mögliche Schäden für Geschäftsprozesse, Kunden, Beschäftigte, Verträge, Recht, Finanzen, Reputation, Produktion und gegebenenfalls Menschen oder Umwelt. Die reine Anschaffungssumme eines Geräts ist kein ausreichender Maßstab.
¶ 8.2 Schutzbedarfsstufen
| Stufe | Bedeutung |
|---|---|
| Normal | Begrenzte Auswirkungen; allgemeine Sicherheitsmaßnahmen sind grundsätzlich ausreichend |
| Hoch | Wesentliche Auswirkungen; zusätzliche oder verstärkte Schutzmaßnahmen sind erforderlich |
| Sehr hoch | Schwerwiegende oder kritische Auswirkungen; besonders wirksame und eng überwachte Maßnahmen sind erforderlich |
Die verwendete Stufenskala muss im gesamten Inventar einheitlich sein. Wird in einer operativen Arbeitsvorlage stattdessen mit niedrig / mittel / hoch gearbeitet, ist eine dokumentierte Zuordnung zur freigegebenen ISMS-Skala erforderlich. Werte aus unterschiedlichen Skalen dürfen nicht ungeprüft zusammengeführt werden.
¶ 8.3 Leitfragen und erforderliche Begründung
| Schutzziel | Leitfrage | Beispiel für eine nachvollziehbare Begründung |
|---|---|---|
| C – Vertraulichkeit | Welche Folgen hätte eine unberechtigte Offenlegung? | „Enthält Kunden-, Preis- und Vertragsdaten; Offenlegung kann Vertragsverletzungen und erhebliche Wettbewerbsnachteile verursachen.“ |
| I – Integrität | Welche Folgen hätte eine unbemerkte oder unberechtigte Veränderung? | „Fehlerhafte Mengen, Preise oder Freigaben können zu falscher Produktion, Lieferung und Rechnungsstellung führen.“ |
| A – Verfügbarkeit | Welche Folgen hätte ein Ausfall oder verzögerter Zugriff? | „Der Auftragsprozess ist nach vier Stunden wesentlich beeinträchtigt; ein manuelles Ersatzverfahren deckt nur 30 Prozent des Volumens.“ |
Die Schutzbedarfsstufe wird je Schutzziel begründet. Die höchste relevante Einzelbewertung darf nicht durch Mittelwertbildung abgeschwächt werden.
Der Schutzbedarf ist ein Eingangswert der Risikobewertung, aber nicht mit dem Risikowert oder einem TISAX-Reifegrad gleichzusetzen.
¶ 8.4 Schutzbedarf vererben, aber plausibilisieren
Informationswerte und Geschäftsprozesse geben häufig den Ausgangspunkt vor. Unterstützende Anwendungen, Systeme, Netze, Räume und externe Dienste übernehmen deren Schutzanforderungen nach nachvollziehbaren Vererbungsregeln. Dabei werden Kumulation, Verteilung und Ausweichmöglichkeiten berücksichtigt:
- verarbeitet ein System mehrere hoch vertrauliche Informationsbestände, darf der Schutzbedarf nicht niedriger sein als der höchste relevante Informationswert,
- unterstützt ein Identitätsdienst viele kritische Anwendungen, kann sein Verfügbarkeits- und Integritätsbedarf höher als der einzelner Anwendungen sein,
- kann ein Service durch ein belastbares Ersatzverfahren fortgeführt werden, darf dies nur mit belegter Kapazität und getesteter Dauer berücksichtigt werden,
- technische Segmentierung kann eine Vererbung begrenzen, wenn die Grenze nachweislich wirksam ist.
¶ 9. Beispielhaftes Asset-Inventar
¶ 9.1 Fachliche Asset-Liste nach der Vorlagenstruktur
Die folgende Darstellung übernimmt die Struktur der Arbeitsvorlagen, teilt sie für die Wiki-Lesbarkeit aber in zwei über die Asset-ID verbundene Tabellen. Alle Namen, Werte und Referenzen sind erfunden.
| Asset-ID | konkrete Bezeichnung/Systemname | Asset/Informationswert | Geschäftsprozess/Dienst | Kategorie/Klasse | fachlicher Owner | technische Verantwortung | Standort/Hosting | Personenbezug | C | I | A | Gesamt | Klassifizierung |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| DEMO-INF-001 | Auftrags- und Kundendaten | Kundenstammdaten, Angebote, Aufträge und Lieferinformationen | Vertrieb und Auftragsabwicklung | Information/Datensatz | Vertriebsleitung | IT-Betrieb | ERP und geschützte Cloud-Ablage | Ja | Hoch | Hoch | Hoch | Hoch | Vertraulich |
| DEMO-APP-001 | ERP-Auftragsbearbeitung | Anwendung für Angebote, Aufträge, Lager und Faktura | Auftragsabwicklung | Fachanwendung/Software | Kaufmännische Leitung | Application Owner | Rechenzentrum EU | Ja | Hoch | Sehr hoch | Hoch | Sehr hoch | Vertraulich |
| DEMO-SYS-001 | Identitäts- und Berechtigungsdienst | Konten, Rollen und Authentisierung | unterstützt alle wesentlichen Dienste | System/Sicherheitsdienst | IT-Leitung | IAM-Administration | Zentrale IT/Cloud EU | Ja | Sehr hoch | Sehr hoch | Sehr hoch | Sehr hoch | Streng vertraulich |
| DEMO-SUP-001 | Kollaborationsplattform als SaaS | E-Mail, Dateien, Besprechungen und Kalender | Kommunikation und Zusammenarbeit | Cloud-/SaaS-Dienst | IT-Leitung | Service Owner/Provider | Cloud EU – zu bestätigen | Ja | Hoch | Hoch | Hoch | Hoch | Vertraulich |
Bewertungsstatus: Sämtliche Einträge sind Beispieldaten. Die Einstufungen wurden nicht durch tatsächliche Asset Owner bestätigt und gelten daher nicht als freigegebene Schutzbedarfsfeststellung.
¶ 9.2 Technische, Resilienz- und Lebenszyklusfelder
| Asset-ID | Anbieter/Partner | Datenarten | Abhängigkeiten | Backup | RTO | RPO | MFA | Verschlüsselung | Patch-/Updateverantwortung | Vertrag/SLA/AVV | Risiko/Maßnahme | Status | letzte/nächste Prüfung | Quelle/Nachweis |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| DEMO-INF-001 | Muster-ERP-Anbieter | Kunden-, Vertrags- und Auftragsdaten | DEMO-APP-001, DEMO-SYS-001, Netzwerk, Fachrollen | über Anwendung | 4 h – Beispiel | 1 h – Beispiel | über Anwendung | im Speicher und Transport – zu prüfen | Application Owner | Vertrag und AVV zu prüfen | DEMO-RIS-001 / offen | Zu verifizieren | 09.08.2026 / 09.08.2027 | Prozessworkshop und geschütztes Register |
| DEMO-APP-001 | Muster-ERP-Anbieter | Auftrags-, Lager- und Finanzdaten | Identität, Datenbank, Netzwerk, Backup, Provider | Ja – Test offen | 4 h – Beispiel | 1 h – Beispiel | Ja – Nachweis offen | Ja – Nachweis offen | Application Owner/Provider | SLA, AVV und Exit offen | DEMO-RIS-002 / DEMO-MA-001 | Vorläufig erfasst | 09.08.2026 / 09.08.2027 | Vertrag, Architektur und Testreferenz |
| DEMO-SYS-001 | interner Betrieb/Cloud-Provider | Identitäten, Rollen, Protokolle | Netzwerk, Schlüssel, Administratoren, Provider | Ja – Restore offen | 2 h – Beispiel | 30 min – Beispiel | systembestimmend | Ja – Nachweis offen | IAM-Owner/Provider | SLA und Exit offen | DEMO-RIS-003 / offen | Zu verifizieren | 09.08.2026 / 09.02.2027 | IAM-Konzept und Wiederanlaufplan |
| DEMO-SUP-001 | Muster-Cloudanbieter | Kommunikation und Geschäftsdokumente | Internet, Identität, Endgeräte, Provider | Provider plus Export – offen | 8 h – Beispiel | 4 h – Beispiel | Ja – Konfiguration offen | Transport/Speicher – Nachweis offen | Provider/Service Owner | SLA, AVV und Exit offen | DEMO-RIS-004 / offen | Vorläufig erfasst | 09.08.2026 / 09.08.2027 | Vertrag, Sicherheitsnachweise und Exporttest |
¶ 9.3 Beispiel für die CIA-Begründung eines Assets
| Asset-ID | Schutzziel | Stufe | Begründung | bestätigende Rolle | Status |
|---|---|---|---|---|---|
| DEMO-APP-001 | C – Vertraulichkeit | Hoch | Die Anwendung verarbeitet Kunden-, Preis-, Vertrags- und gegebenenfalls personenbezogene Daten. Unbefugte Offenlegung kann erhebliche Vertrags-, Datenschutz- und Wettbewerbsfolgen verursachen. | Kaufmännische Leitung | Muster – nicht bestätigt |
| DEMO-APP-001 | I – Integrität | Sehr hoch | Unbemerkte Änderungen an Mengen, Preisen, Bankdaten oder Freigaben können zu Fehlproduktion, Falschlieferung, finanziellen Schäden und falschen Nachweisen führen. | Kaufmännische Leitung | Muster – nicht bestätigt |
| DEMO-APP-001 | A – Verfügbarkeit | Hoch | Nach vier Stunden ist die Auftragsbearbeitung wesentlich beeinträchtigt; das manuelle Ersatzverfahren deckt nur einen begrenzten Teil des Volumens. | Prozess-Owner Auftragsabwicklung | Muster – nicht bestätigt |
| DEMO-APP-001 | Gesamt | Sehr hoch | Maximum aus C = Hoch, I = Sehr hoch und A = Hoch. | Asset Owner | Muster – nicht bestätigt |
Das Beispiel zeigt: CIA-Werte ohne Begründung und bestätigende Rolle sind nur vorläufige Markierungen. Erst die dokumentierte Schadensbetrachtung macht die Einstufung prüfbar.
¶ 10. Abhängigkeiten und Vererbung
Die Schutzanforderungen von Informationen und Prozessen werden auf unterstützende Assets übertragen. Dabei gilt:
- Ein System, das streng vertrauliche Informationen verarbeitet, benötigt einen entsprechenden Vertraulichkeitsschutz.
- Ein Dienst, von dem ein sehr hoch verfügbarer Prozess abhängt, muss in die Verfügbarkeits- und Notfallplanung einbezogen werden.
- Ein Lieferant übernimmt keine Risiko- oder Kontrollverantwortung der Muster GmbH automatisch.
- Gemeinsame Plattformen werden nach dem höchsten relevanten Schutzbedarf der verarbeiteten Informationen bewertet.
- Werden technische oder organisatorische Grenzen verwendet, müssen deren Wirksamkeit und Scope nachgewiesen werden.
Abhängigkeiten werden nicht nur in Freitext beschrieben. Für kritische Assets werden Datenfluss-, System-, Lieferanten- oder Wiederanlaufbeziehungen in einer geschützten Detailablage dokumentiert.
¶ 11. Asset-Lebenszyklus
¶ 11.1 Aufnahme
Vor Beschaffung, Entwicklung oder produktiver Nutzung werden:
- Asset-ID und Kategorie vergeben,
- Asset und Zweck beschrieben,
- Owner und betroffene Prozesse benannt,
- Informationen und Schutzbedarf bewertet,
- Abhängigkeiten und Lieferanten erfasst,
- Risiken bewertet,
- Sicherheits- und Nachweisanforderungen festgelegt,
- Aufnahme und Nutzung freigegeben.
¶ 11.2 Änderung
Wesentliche Änderungen werden vor Umsetzung bewertet. Dazu gehören:
- neue oder geänderte Informationen,
- Standort-, Hosting- oder Providerwechsel,
- wesentliche Versions- oder Architekturänderungen,
- neue Schnittstellen und Fernzugriffe,
- geänderte Berechtigungen oder Nutzergruppen,
- geänderte RTO-/RPO-Anforderungen,
- neue Kunden-, Rechts- oder Vertragsanforderungen.
¶ 11.3 Rückgabe, Außerbetriebnahme und Entsorgung
Vor Abschluss des Lebenszyklus werden:
- Informationen übertragen, aufbewahrt oder sicher gelöscht,
- Zugriffe, Konten, Schlüssel und Zertifikate entzogen,
- Lizenzen und Verträge beendet oder übertragen,
- Geräte und Medien zurückgegeben oder nachweisbar vernichtet,
- Abhängigkeiten und Notfallpläne aktualisiert,
- Risiken und Dokumente geprüft,
- Entsorgungs- oder Löschungsnachweise hinterlegt,
- Assetstatus und Abschlussdatum dokumentiert.
¶ 12. Inventarisierung externer Dienste
Cloud-, Hosting-, Support- und sonstige externe Leistungen werden mindestens mit folgenden Angaben erfasst:
| Feld | Inhalt |
|---|---|
| Anbieter und Dienst | Vertragliche und technische Bezeichnung |
| Service Owner | Interne verantwortliche Rolle |
| Verarbeitete Informationen | Art, Klassifizierung und Personen-/Prototypenbezug |
| Standorte/Regionen | Hosting-, Support- und Unterauftragnehmerregionen |
| Zugriffe | Administrative, technische und Supportzugriffe |
| Sicherheitsnachweise | Verträge, Prüfberichte, Zertifikate und technische Nachweise |
| Verfügbarkeit | SLA, RTO/RPO, Backup und Wiederherstellung |
| Ausstieg | Datenexport, Löschung, Übergang und Vertragsbeendigung |
| Risiken | Verknüpfte Risiko-IDs und Restrisiken |
Das Detailverfahren ist unter Lieferanten und Dienstleister geregelt.
¶ 13. Review- und Prüfintervalle
| Schutzbedarf/Kritikalität | Mindestprüfung |
|---|---|
| Sehr hoch oder geschäftskritisch | Mindestens halbjährlich sowie bei wesentlichen Änderungen |
| Hoch | Mindestens jährlich sowie bei wesentlichen Änderungen |
| Normal | Mindestens jährlich oder nach genehmigtem risikobasiertem Turnus |
| In Außerbetriebnahme | Vor Abschluss und nach Löschung beziehungsweise Entsorgung |
Unabhängig vom Turnus wird geprüft bei:
- Sicherheitsvorfällen,
- wesentlichen Schwachstellen oder Auditfeststellungen,
- Änderungen von Ownern, Standorten oder Dienstleistern,
- Änderungen der Informationsklassifizierung,
- neuen Kunden- oder Prototypenschutzanforderungen,
- Ablauf oder wesentlicher Änderung von Verträgen,
- Änderungen der Verfügbarkeit oder Wiederanlaufanforderungen.
¶ 14. Nachweise und geschützte Detailablage
Im allgemein zugänglichen Wiki werden keine unnötigen Angriffs- oder Zugangsinformationen veröffentlicht. In geschützten Registern oder Systemen können insbesondere geführt werden:
- Seriennummern und Inventarnummern,
- IP-Adressen, Hostnamen und Netzwerkzonen,
- detaillierte Software- und Versionsstände,
- Administrationskonten und Berechtigungsgruppen,
- Schwachstellen- und Konfigurationsdetails,
- Schlüssel-, Zertifikats- und Geheimnisinformationen,
- genaue physische Lage kritischer Betriebsmittel,
- personenbezogene Zuordnungen zu Einzelgeräten,
- Verträge und nicht öffentliche Anbieterinformationen.
Die Wiki-Seite enthält eindeutige Referenzen, Verantwortlichkeiten und Statusangaben, ohne die Schutzwirkung durch unnötige Offenlegung zu schwächen.
¶ 15. Qualitätssicherung
Vor Freigabe eines Asset-Datensatzes wird geprüft:
| Prüffrage | Mindestanforderung |
|---|---|
| Ist das Asset eindeutig? | ID, Name, Kategorie und Zweck sind vorhanden |
| Ist eine verantwortliche Rolle benannt? | Asset-/Information-/Service Owner sind geklärt |
| Ist der Scope korrekt? | Standort, Prozess und Hosting sind nachvollziehbar |
| Ist die Klassifizierung begründet? | Informationsarten und Anforderungen wurden berücksichtigt |
| Ist der Schutzbedarf vollständig? | Vertraulichkeit, Integrität und Verfügbarkeit wurden bewertet |
| Sind Abhängigkeiten erfasst? | Systeme, Personen, Lieferanten und Versorgung sind berücksichtigt |
| Sind Risiken verknüpft? | Relevante Risiko-IDs oder eine begründete Bewertung liegen vor |
| Sind RTO/RPO plausibel? | Werte sind mit Prozess- und Notfallanalyse abgestimmt |
| Ist der Lebenszyklus aktuell? | Status, letzte und nächste Prüfung stimmen |
| Sind Nachweise geschützt und auffindbar? | Referenzen funktionieren und Berechtigungen sind angemessen |
¶ 16. Kennzahlen
Für die ISMS-Steuerung werden mindestens betrachtet:
- Anzahl aktiver Assets je Kategorie,
- Anteil der Assets mit bestätigtem Owner,
- Anteil vollständig klassifizierter Assets,
- Anteil mit bestätigtem Schutzbedarf,
- Anzahl überfälliger Reviews,
- Anzahl kritischer Assets ohne aktuelle Risikobewertung,
- Anzahl externer Dienste ohne aktuelle Sicherheitsbewertung,
- Anzahl außer Betrieb genommener Assets ohne Lösch-/Entsorgungsnachweis,
- Anzahl ungeklärter Prototypen- oder Personenbezüge,
- Anzahl kritischer Einzelabhängigkeiten.
Unvollständige Datensätze und überfällige Reviews bleiben bis zur Korrektur sichtbar.
¶ 17. Mitgeltende Dokumente
- Geltungsbereich und Standorte
- Informationssicherheitsleitlinie
- Methodik der Risikobewertung
- Risikoregister
- Statement of Applicability
- Standorte und Sicherheitsbereiche
- Informationsklassifizierung
- Zulässige Nutzung von Assets
- Prozesslandkarte
- Lieferanten und Dienstleister
- Zugriff und Berechtigungen
- Netzwerke und Kommunikation
- Datensicherung und Wiederherstellung
- Wiederanlaufplanung
- VDA-ISA-Selbsteinschätzung
- Prototypenschutz
- NIS2 Asset- und Systeminventar
¶ 18. Offene Punkte vor Freigabe
| Offener Punkt | Verantwortung | Status |
|---|---|---|
| Reale Assets aus Prozessen, IT, Produktion und Standorten erfassen | Asset-/Prozessverantwortliche | Offen |
| Asset Owner und Stellvertretungen bestätigen | Geschäftsführung / Bereichsleitungen | Offen |
| Informationsklassifizierung und Schutzbedarf fachlich freigeben | Information Owner | Offen |
| Personen- und Prototypenbezug prüfen | Datenschutz / TISAX-Koordination | Offen |
| RTO/RPO mit Business-Impact- und Notfallanalyse abstimmen | Prozessverantwortliche | Offen |
| Risiken und SoA-Maßnahmen verknüpfen | ISMS-Beauftragte/r | Offen |
| Externe Dienste und Unterauftragnehmer vervollständigen | Einkauf / Service Owner | Offen |
| Geschützte Detailablage und Berechtigungen festlegen | IT / ISMS | Offen |
| Formale Managementfreigabe dokumentieren | Geschäftsführung | Offen |
¶ 19. Externe Orientierung
Die Quellen beschreiben den fachlichen Rahmen. Die konkrete Inventarstruktur, Stufenskala, Schadensschwellen und Freigaberollen müssen in der Organisation verbindlich festgelegt werden.
¶ 20. Änderungshistorie und Freigabe
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.4 | 09.08.2026 | CIA-Pflicht, Begründungs- und Maximumprinzip, an Arbeitsvorlagen orientiertes Master-/Detailregister sowie vollständige Musterdatensätze ergänzt | ISMS-Beauftragte/r | Ausstehend | – |
| 0.3 | 08.08.2026 | NIS2-Scope-Sicht auf Assets und Systeme als Schnittstelle ergänzt | ISMS-Beauftragte/r / NIS2-Koordination | Ausstehend | – |
| 0.2 | 06.08.2026 | SVG-Titelgrafik ergänzt, Bildpfad auf /public-bilder vereinheitlicht und responsive Darstellung umgesetzt; keine Änderung der fachlichen Regelung | ISMS-Beauftragte/r | Ausstehend | – |
| 0.1 | 23.07.2026 | Asset-Inventar mit Pflichtfeldern, Schutzbedarfslogik und Beispieldatensätzen angelegt | ISMS-Beauftragte/r | Ausstehend | – |