Jedes InfoSec-Compliance-Projekt stolpert früher oder später über dieselbe Hürde: das Asset-Register.

Dass Sie eines brauchen, wissen Sie – die Norm verlangt es. Woran es meist fehlt, ist die praktische Anleitung: Was zählt überhaupt als Asset? Wem gehört es? Und wie hält man das Ganze aktuell? Die ISO 27001 stellt die Anforderung; dieser Leitfaden liefert Ihnen die Struktur, um sie zu erfüllen.

Ein Risiko lässt sich nicht bewerten, solange das betroffene Asset nicht erfasst ist. Und eine Maßnahme lässt sich keinem System zuordnen, von dessen Existenz niemand weiß. Genau hier wird das Asset-Register wichtig: Es ist der Punkt, an dem Klausel 4 (Kontext) und Klausel 6 (Risiko) ihre Abstraktheit verlieren und sich an etwas Konkretem festmachen – an einer dokumentierten Liste dessen, was Sie tatsächlich schützen.

Ein fehlendes oder veraltetes Register zählt zu den am häufigsten festgestellten Nichtkonformitäten im Stufe-2-Audit. Für Auditoren ist es keine Formsache, sondern der Prüfstein dafür, ob Ihr Risikomanagement überhaupt ein Fundament hat.

Wer vollständig in der Cloud arbeitet – ohne Serverraum, ohne eigene Infrastruktur –, hält das Asset-Inventar leicht für eine Nebensache. Ein Irrtum. Gerade dort wachsen Assets unbemerkt: hier ein neues Projektmanagement-Tool, dort der private Notion-Workspace einer Freelancerin. Die entscheidende Frage lautet dann nicht „Welche Hardware besitzen wir?", sondern „Wo liegen welche Daten, wer kontrolliert sie – und was passiert, wenn jemand das Unternehmen verlässt?"

Asset-Management in der ISO 27001

In der ISO 27001:2022 ist die Pflicht zum Asset-Register in Control A.5.9 geregelt – Teil der Maßnahmen rund um Asset- und Datenmanagement. Sie steht in einer Reihe mit vier eng verwandten Controls:

• A.5.10 – Akzeptable Nutzung von Informationen und anderen damit verbundenen Werten
• A.5.12 – Klassifizierung von Informationen
• A.5.13 – Kennzeichnung von Informationen
• A.5.14 – Informationsübertragung

Das Asset-Register ist das Fundament, auf das diese vier angewiesen sind. Eine akzeptable Nutzung lässt sich nicht durchsetzen und die Rückgabe von Assets beim Offboarding nicht sicherstellen, wenn nicht zuerst klar ist, welche Assets es überhaupt gibt. Konkret verlangt die Norm von Ihnen:

• alle Assets innerhalb des ISMS-Geltungsbereichs zu identifizieren,
• sie in einem Informations-Asset-Register (IAR) zu dokumentieren,
• jedem Asset einen benannten Eigentümer zuzuweisen und
• das Register vollständig und aktuell zu halten.

Im Idealfall weiß dadurch jedes Teammitglied, welche Tools im Einsatz sind, wer dafür verantwortlich ist und wie man Zugriff anfragt. Das Register ist dann kein Compliance-Artefakt mehr, sondern ein Referenzpunkt, den Ihr Team im Alltag tatsächlich nutzt.

Die Norm spricht bewusst von „Informationen und anderen damit verbundenen Werten". Diese Unterscheidung ist kein Zufall – und sie ist zugleich der beste Einstieg, wenn Sie Ihr Register zum ersten Mal aufbauen.

Assets lassen sich grundsätzlich auf zwei Ebenen betrachten – eine Unterscheidung, die auch der ISO 27001 zugrunde liegt:

• Primäre Assets (Informationen) – die Daten selbst: das, was Ihre Organisation erzeugt, verarbeitet und schützen muss.
• Sekundäre Assets (verbundene Werte) – die Systeme, Tools und Infrastruktur, über die diese Daten verarbeitet, gespeichert oder übertragen werden.

Starten Sie auf der primären Ebene. Das sind die Daten, deren Verlust, Offenlegung oder Manipulation Ihrer Organisation oder Ihren Kunden echten Schaden zufügen würde. Bei den meisten kleinen Unternehmen lassen sie sich auf drei Kategorien herunterbrechen:

• Kundendaten – Namen, Kontaktdaten, Lieferinformationen, kurz: alles, was Kundinnen und Kunden Ihnen anvertrauen.
• Geistiges Eigentum – Quellcode, Vorlagen, Methodiken; alles, was Ihre Art der Leistungserbringung einzigartig macht.
• Personaldaten – Verträge, Gehaltsdaten und weitere personenbezogene Informationen aus dem HR-Bereich.

Das sind Ihre Kronjuwelen. Alles Übrige im Inventar existiert nur, um sie zu verarbeiten, zu speichern oder zu übertragen.

Sind die primären Informationswerte erst einmal erfasst, folgt der nächste Schritt: die sekundären Assets – also alles, worüber diese Daten verarbeitet, gespeichert oder übertragen werden. Die ISO 27002:2022 ordnet sie fünf Kategorien zu. Die folgenden Beispiele zeigen, was einer remote arbeitenden, SaaS-orientierten Organisation typischerweise begegnet:

• Software & Cloud-Dienste – die Tools und Plattformen des täglichen Betriebs.
• Hardware – die physischen Geräte, mit denen das Team arbeitet.
• Dienste – Abhängigkeiten von Drittanbietern, auf die sich Ihr Betrieb stützt.
• Personen – Rollen und Personen, die für Verwaltung oder Verarbeitung von Informationen unverzichtbar sind.
• Standorte – die physischen oder logischen Orte, an denen Assets liegen.

Jedes SaaS-Tool, jede Cloud-Plattform und jeder ausgelagerte Dienst in Ihrem Register ist zugleich eine Lieferantenbeziehung – und jede bringt ein Drittparteienrisiko mit, das aktiv gesteuert werden muss. Das Asset-Register ist der Ort, an dem diese Abhängigkeiten sichtbar werden und eine Verantwortlichkeit erhalten.

Die Controls zum Lieferantenmanagement (A.5.19–A.5.22) unterstützen Sie dabei, Lieferanten zu bewerten, vertraglich einzubinden, zu überwachen und zu offboarden – bis hin zum Aufbau eines eigenen Lieferantenregisters.

Eine reine Auflistung von Assets reicht nicht. Die ISO 27001 verlangt, dass Sie die Sensibilität jedes Assets einschätzen – die sogenannte Informationsklassifizierung aus A.5.12, die unmittelbar an das Asset-Register anknüpft.

Das praktischste Werkzeug dafür ist die CIA-Analyse: Sie bewerten jedes Asset entlang dreier Dimensionen – Vertraulichkeit, Integrität und Verfügbarkeit – jeweils als hoch, mittel oder niedrig. Aus der Kombination ergibt sich ein Schutzbedarfsprofil, das Ihnen zeigt, welche Controls Vorrang haben.

Aus den drei Bewertungen ergibt sich der Gesamtschutzbedarf eines Assets – angesetzt als der höchste der drei Werte. So können Sie die Assets mit dem höchsten Schutzbedarf zuerst für die Risikoidentifikation priorisieren und in Ihren Richtlinien Regeln nach Kritikalität festlegen, bei denen die Einstufung die erforderlichen Controls auslöst: Beispielsweise muss für jedes Asset mit hohem Verfügbarkeitsbedarf ein Backup aktiviert sein.

Das folgende Beispiel zeigt ein gut strukturiertes IAR für eine kleine, remote arbeitende, SaaS-orientierte Organisation. Jede Zeile steht für ein Asset. Zwei Dinge vorab:

CIA-Score und Klassifizierung sind nicht dasselbe

Das wird häufig verwechselt, deshalb hier ausdrücklich:

Der CIA-Score misst die Auswirkung: Wie schwer wöge der Verlust von Vertraulichkeit, Integrität oder Verfügbarkeit für genau dieses Asset? Jede Dimension wird einzeln als hoch, mittel oder niedrig bewertet – das ist Ihr analytischer Input.

Die Klassifizierung ist das Ergebnis dieser Analyse: die verständliche Kategorie (öffentlich / intern / eingeschränkt / vertraulich), die festlegt, wie mit dem Asset umzugehen ist – das ist Ihr operativer Output.

Die Klassifizierung steuert die Controls

Sobald ein Asset ein Klassifizierungs-Label trägt, ergibt sich daraus, welche Controls gelten. Statt jeden Einzelfall neu zu entscheiden, definieren Sie die Regeln einmal und wenden sie konsistent an.

So schützen Sie Ihre Kronjuwelen mit Augenmaß: nicht, indem Sie überall das Maximum an Controls auffahren, sondern indem die Klassifizierung die Entscheidung übernimmt, welches Schutzniveau ein Asset wirklich braucht.

Sekundäre Assets den primären zuordnen

Als Best Practice – und als Auditoren-Erwartung – gilt, jedes sekundäre Asset mit dem primären Informationswert zu verknüpfen, den es enthält. Erst das macht das Register operativ nutzbar: Wollen Sie wissen, welche Controls für Supabase gelten, sehen Sie nach, welche primären Assets dort liegen, lesen deren Klassifizierung ab – und die nötigen Controls ergeben sich von selbst. Die Tabelle unten zeigt diese Zuordnung.

C = Vertraulichkeit (Confidentiality), I = Integrität (Integrity), A = Verfügbarkeit (Availability). H = hoch, M = mittel, L = niedrig.

Die Assets zu identifizieren ist nur die halbe Miete. Die andere Hälfte ist zu verstehen, wie sensibel jedes einzelne ist – und genau hier kommt A.5.12 ins Spiel.

Das Asset-Register sagt Ihnen, welche Assets existieren; A.5.12 sagt Ihnen, wie viel Schutz jedes davon braucht. Beide greifen ineinander, und Auditoren prüfen, ob sich beides im Register widerspiegelt – nicht nur eine Liste von Tools und Datentypen, sondern für jeden Eintrag eine klare, konsequent angewandte Sensibilitätsstufe.

Was Klassifizierung in der Praxis heißt

• Ein Klassifizierungs-Label spiegelt die mögliche Auswirkung von unbefugtem Zugriff, unbefugter Änderung oder Verlust wider.
• Die ISO 27001 schreibt kein bestimmtes Schema vor – Sie legen die Stufen fest, die zu Ihrer Organisation passen.
• Verbreitet ist ein vierstufiges Schema: öffentlich / intern / eingeschränkt / vertraulich.
• Jedes Asset erhält ein Label – und dieses Label steuert, welche Controls greifen.

Ein Register, das einmal erstellt und nie wieder angefasst wird, ist keine Compliance – es ist bloß ein Dokument. Die ISO 27001 verlangt aktive Pflege, und Auditoren suchen nach Belegen dafür: Datumsangaben, Bestätigungen der Eigentümer, eine nachvollziehbare Änderungshistorie – nicht bloß die Existenz einer Datei.

Aktualisiert werden muss das Register in jeder Phase des Asset-Lebenszyklus:

• Erstellung / Beschaffung – ein neues Tool, System oder eine neue Datenkategorie kommt in den Geltungsbereich: sofort erfassen, selbst bei einer reinen Testnutzung.
• Zuweisung – ein Teammitglied erhält Zugriff auf Assets: festhalten, was bereitgestellt wurde, an wen und wann.
• Änderung – ein Asset wird verändert oder migriert, oder eine Lieferantenbeziehung ändert sich (neuer Anbieter, Vertragsverlängerung, Scope-Änderung): das Register entsprechend nachziehen.
• Übertragung – die Eigentümerschaft wechselt, oder ein Teammitglied übernimmt eine neue Rolle mit anderem Zugriffsprofil: neu zuweisen und dokumentieren.
• Entzug / Rückgabe – ein Teammitglied verlässt das Unternehmen: bestätigen, dass Assets zurückgegeben und Zugriffe entzogen wurden – und beides festhalten.
• Entsorgung / Außerbetriebnahme – ein Tool wird abgeschaltet, ein Dienst beendet oder ein Datensatz gelöscht: als außer Betrieb markieren und den Eintrag für Audit-Zwecke aufbewahren, statt die Zeile zu löschen.

Stufe-2-Auditoren behandeln das Asset-Register als Frage der Nachvollziehbarkeit. Dass ein Register existiert, genügt ihnen nicht. Sie prüfen, ob es vollständig ist, ob die Eigentümerschaft real ist, ob die Klassifizierung tatsächlich Entscheidungen steuert – und ob das Register aktiv gepflegt oder nach der Erstzertifizierung still beerdigt wurde.

Geprüft wird insbesondere:

• ein dokumentiertes, zugängliches IAR, das primäre Informationswerte ebenso abdeckt wie die IT-Systeme, die sie verarbeiten, speichern oder übertragen;
• ein benannter, individueller Eigentümer je Asset – kein Team, keine Abteilung, sondern eine Person;
• Klassifizierungs-Labels, die durchgängig auf jeden Eintrag angewandt sind;
• Belege für die aktive Pflege – Datumsangaben, Freigaben der Eigentümer, Änderungshistorie;
• ein nachvollziehbarer Nachweis, dass das Offboarding die Rückgabe von Assets und den Entzug von Zugriffen auslöst (A.5.11).

Ihr Asset-Register fließt unmittelbar in Ihre Risikobeurteilung (Klausel 6) und Ihre Erklärung zur Anwendbarkeit (SoA) ein. Jede Maßnahme, die Sie aus Anhang A wählen, sollte sich auf ein Asset in Ihrem Register zurückführen lassen. Gelingt das nicht, lässt sich kaum begründen, warum die Maßnahme im Geltungsbereich liegt – und genau das fällt Auditoren auf. Wie das Asset-Register in die übergeordnete ISMS-Struktur eingebettet ist, lesen Sie in „ISO 27001 Klauseln 4–10: Die ersten Schritte beim Aufbau Ihres ISMS". Wie Sie den Geltungsbereich festlegen, der bestimmt, welche Assets überhaupt in Scope sind, erfahren Sie in „ISO 27001 Klausel 4: So führen Sie eine Kontextanalyse durch".