ISM-Grundprinzipien und Risikomanagement: sechs Funktionen, sechs Schritte, Systemsicherheitsplan und Betriebsfreigabe

Problem in der Praxis

Vier Muster kehren wieder. Das erste ist der Zertifikatsreflex: Ein australischer Kunde fragt nach einem Systemsicherheitsplan und einem Bewertungsbericht, und das deutsche Unternehmen antwortet mit seinem Managementsystemzertifikat. Das ISM nennt als Bewertungsweg für nicht eingestufte Systeme sowie für OFFICIAL: Sensitive, PROTECTED und SECRET die Bewertung durch eigene Assessoren der Organisation oder durch Assessoren des Infosec Registered Assessors Program (IRAP); für TOP SECRET Assessoren des ASD. Ob und wie ein Kunde Zertifikate anderer Rahmenwerke anerkennt, regelt das ISM nicht.

Das zweite Muster ist ein Lesefehler bei den Anwendbarkeitsmarkierungen. Jede Kontrolle trägt Markierungen wie NC, OS, P, S und TS. NC steht nicht für "nicht anwendbar", sondern für den Schutz nicht eingestufter Systeme, und zwar ausdrücklich staatlicher wie nichtstaatlicher. Wer NC überliest, hält die Grundlinie für ein reines Behördenthema.

Das dritte Muster ist die Annahme, die Kontrollen seien eine abschließende Liste. Das ISM sagt das Gegenteil: Die Leitlinien bilden eine Grundlinie, sind aber für einen bestimmten Systemtyp oder eine Technologie nicht erschöpfend. Risikoanalyse und Risikobewertung muss die Organisation selbst leisten, weil jedes System, seine Betriebsumgebung und die Risikotoleranz der Organisation eigen sind.

Das vierte Muster ist die Einmalfreigabe. Die Betriebsfreigabe wird als Projektabschluss behandelt. Das ISM sieht dagegen laufende Überwachung vor, benennt Ereignisse, die zusätzliche Risikomanagementaktivitäten auslösen können, und sieht vor, dass Systemeigentümer dem authorising officer mindestens jährlich über den Sicherheitsstatus jedes Systems berichten.

CISO-Einordnung

Zwei Ebenen, eine Logik. Die Grundprinzipien geben die strategische Richtung, die Leitlinien die praktische Umsetzung. Das ISM verlangt, jedes Prinzip durch administrative und technische Kontrollen zu stützen, die der Größe, Komplexität, Betriebsumgebung und dem Risikoprofil der Organisation angemessen sind, und diese Kontrollen laufender risikobasierter Überwachung und Assurance zu unterwerfen. In der Ausgabe September 2026 sind es 49 Prinzipien. Innerhalb jeder Funktion stehen sie in einer logischen Reihenfolge für die Umsetzung; die Nummern sind nach dem ISM reine Kennungen und keine Umsetzungsreihenfolge.

Die sechs Funktionen auf Managementebene. Govern setzt bei der Leitung an: Vorstand oder Geschäftsleitung tragen die Verantwortung für Cybersicherheit und auch dafür, dass künstliche Intelligenz sicher, beherrschbar, menschlich beaufsichtigt sowie ethisch und verantwortlich eingesetzt wird. Dazu kommen die Führungsrolle des CISO mit regelmäßiger risikobasierter Berichterstattung an die Leitung, dokumentierte Verantwortlichkeiten für das Sicherheitsrisikomanagement auch gegenüber Lieferanten, Partnern und Kunden einschließlich geteilter Verantwortung, und die Akzeptanz der Restrisiken eines Systems, auch der geerbten und geteilten, bevor es zur Nutzung freigegeben wird. Identify verlangt eine laufende und zentrale Erfassung der Systeme, ihrer Abhängigkeiten, ihrer Geschäftskritikalität sowie ihrer Sicherheits- und Resilienzanforderungen. Protect reicht vom sicheren Lebenszyklus nach Secure by Design und Secure by Default über Identitäts- und Zugriffsmanagement, sichere Konfiguration und Verschlüsselung mit ASD-zugelassener Kryptografie bis zu Segmentierung, Isolation der Betriebstechnik und Datensicherung. Detect, Respond und Recover decken zentrale Protokollierung und Erkennung, Vorfallsplanung, Meldung und Lehren aus Vorfällen sowie die Wiederaufnahme des Normalbetriebs ab, vor der die Restrisiken zu akzeptieren sind. Die einzelnen Prinzipien stehen im ISM; dieser Artikel gibt sie nicht einzeln wieder.

Schritt 1, System definieren. Festzulegen sind Systemgrenze, Geschäftskritikalität sowie Sicherheits- und Resilienzziele, und zwar auf Grundlage einer Bewertung der Auswirkungen einer Kompromittierung oder eines Angriffs. Diese Festlegung steuert alles Weitere, vom Zuschnitt der Kontrollen bis zur Höhe des Restrisikos, das vor der Freigabe akzeptiert wird. Die Beschreibung des Systems gehört in den Systemsicherheitsplan. Nach den Leitlinien zu Rollen trifft der Systemeigentümer diese Festlegung im Benehmen mit dem authorising officer und führt mit ihm auch eine Bedrohungs- und Risikobewertung durch.

Schritt 2, Kontrollen auswählen und zuschneiden. Hier wirken die Anwendbarkeitsmarkierungen: NC für nicht eingestufte Systeme, OS für OFFICIAL: Sensitive, P für PROTECTED, S für SECRET und TS für TOP SECRET. Daneben trägt jede Kontrolle eine Essential-Eight-Markierung; deren Bedeutung behandelt ism-australien-004. Ausgewählt wird nach Eignung für die Ziele aus Schritt 1, ergänzt um zusätzliche Kontrollen, die die Eigenart des Systems, seiner Umgebung und der Risikotoleranz erfordern. Geerbte Kontrollen, etwa von einer Plattform oder einem Dienstleister, sind zu identifizieren. Dokumentiert wird die Auswahl mit der geplanten Umsetzung im Annex des Systemsicherheitsplans und, soweit passend, im Vorfallsreaktionsplan, im Änderungs- und Konfigurationsmanagementplan und im Plan zur kontinuierlichen Überwachung. Die Auswahl soll der authorising officer genehmigen. Unabhängig davon verlangen die Leitlinien zur Dokumentation, dass die Sicherheitsarchitektur eines Systems vor Beginn seiner Entwicklung genehmigt ist; nach dem erläuternden Text ist das die im Systemsicherheitsplan beschriebene und durch Vorfallsreaktionsplan, Änderungs- und Konfigurationsmanagementplan und Überwachungsplan gestützte Architektur, genehmigt durch den authorising officer. Systemspezifische Sicherheitsdokumentation genehmigt der authorising officer, organisationsweite der CISO. Ein eigenes Ausnahme- oder Dispensverfahren für einzelne Kontrollen beschreibt das ISM nicht; Abweichungen laufen über Zuschnitt und Risikoakzeptanz.

Schritt 3, umsetzen. Weicht die tatsächliche Umsetzung von der geplanten ab, wird das im Annex festgehalten. Der Annex ist damit kein Planungspapier, sondern der fortgeschriebene Iststand.

Schritt 4, bewerten. Assessor, Systemeigentümer und authorising officer einigen sich vorab auf Umfang, Art und Tiefe der Bewertung, gegebenenfalls in einem security assessment plan (Bewertungsplan). Für nicht eingestufte Systeme sowie OFFICIAL: Sensitive, PROTECTED und SECRET können eigene Assessoren der Organisation oder IRAP-Assessoren bewerten, für TOP SECRET Assessoren des ASD oder deren Delegierte. In allen Fällen sollen Assessoren eine angemessene Sicherheitsüberprüfung (security clearance) und Erfahrung mit dem Systemtyp haben. Ergebnis ist ein security assessment report (Bewertungsbericht) mit Umfang, Stärken und Schwächen, Risiken des Betriebs, Wirksamkeit der Kontrollen und empfohlenen Abhilfemaßnahmen; daraus erstellt der Systemeigentümer einen plan of action and milestones (Maßnahmen- und Meilensteinplan). Für Gateways sieht das ISM gesonderte, regelmäßige Bewertungen vor (ism-australien-006). Wie IRAP organisiert ist und welche Anforderungen an IRAP-Assessoren gelten, steht nicht im ISM-Snapshot dieses Tracks; dazu trifft dieser Artikel keine Aussage.

Schritt 5, autorisieren. Der authorising officer entscheidet auf Grundlage eines authorisation package (Freigabepaket) aus Systemsicherheitsplan, Vorfallsreaktionsplan, Änderungs- und Konfigurationsmanagementplan, Plan zur kontinuierlichen Überwachung, Bewertungsbericht und Maßnahmenplan. Das ISM kennt drei Ausgänge: eine fortlaufende Freigabe, wenn die Risiken akzeptabel sind; bei nicht akzeptablen Risiken kann der authorising officer Nacharbeit verlangen und in der Zwischenzeit eine Freigabe mit Auflagen erteilen, etwa mit eingeschränkter Funktion oder einem Ablaufdatum; und die Verweigerung, bis ausreichende Abhilfe erreicht ist. Authorising officer ist für nicht eingestufte Systeme sowie OFFICIAL: Sensitive, PROTECTED und SECRET der CISO der Organisation oder dessen Delegierter, für TOP SECRET der Director-General ASD oder dessen Delegierter, und bei kommerziellen Anbietern der CISO der unterstützten Organisation. Für multinationale und organisationsübergreifende Systeme kann per förmlicher Vereinbarung ein einzelner authorising officer bestimmt werden, oder mehrere entscheiden gemeinsam über eine gemeinsame Freigabe. Hat eine Organisation keinen CISO, kann ein Chief Security Officer, ein Chief Information Officer oder eine andere Führungskraft der oberen Ebene (senior executive) die Rolle übernehmen; in jedem Fall soll sie ausreichend hochrangig sein und die akzeptierten Risiken verstehen.

Schritt 6, überwachen. Bedrohungen, Risiken und Kontrollen werden nach einem Plan zur kontinuierlichen Überwachung laufend beobachtet. Als Ereignisse, die zusätzliche Risikomanagementaktivitäten erforderlich machen können, nennt das ISM unter anderem geänderte Sicherheitsrichtlinien, neue Bedrohungen, weniger wirksame Kontrollen als geplant, einen schweren Vorfall und größere Architekturänderungen. Nach neuen oder geänderten Kontrollen soll erneut bewertet und das Freigabepaket aktualisiert werden. Sind die Risiken nicht mehr akzeptabel, kann der authorising officer Auflagen erteilen, ein Ablaufdatum einführen oder ändern oder die Freigabe ganz entziehen. Davon getrennt sehen die Leitlinien zur Dokumentation vor, dass die Sicherheitsdokumentation mindestens jährlich überprüft wird und eine Standangabe ("current as at [Datum]" oder gleichwertig) trägt; weder anlassbezogene Aktualisierungen noch der jährliche Statusbericht ersetzen diese Prüfung.

Was das für ein deutsches ISMS heißt. Das ISM beschreibt sich als Rahmenwerk, das eine Organisation unter Nutzung ihres eigenen Risikomanagementrahmens anwenden kann, und verweist für Methoden unter anderem auf ISO 31000:2018, IEC 31010:2019, ISO/IEC 27005:2022 und NIST SP 800-30 Rev. 1. Die vorhandene Risikomethode kann also tragen. Neu ist die Granularität: Statt eines organisationsweiten Nachweises verlangt das ISM je System eine Kette aus Definition, Auswahl, Umsetzung, Bewertung und Freigabe mit benannten Rollen und eigenen Dokumenten. Für einen Konzern mit australischer Tochter stellt sich zudem die Rollenfrage: Das ISM ordnet den authorising officer dem CISO der Organisation zu und regelt Konzernstrukturen nicht. Es verlangt aber, dass die Berichterstattung des CISO nach Geschäftsfunktionen, Regionen oder Rechtseinheiten gegliedert ist und eine konsolidierte Sicht auf die Risiken erlaubt.

Umsetzungsperspektive

1. Systeme registrieren. Für jedes System, das unter eine australische Kundenanforderung fällt, einen Systemeigentümer und einen authorising officer benennen und das System beim authorising officer registrieren. Die Systemgrenze schriftlich festlegen, einschließlich der Teile, die bei Dienstleistern oder Plattformen liegen.
2. Rollen im Kundenverhältnis klären. Bei Leistungen für eine australische Organisation festhalten, dass deren CISO freigibt, und vertraglich regeln, welche Teile des Freigabepakets der Dienstleister liefert.
3. Markierungen bestimmen. Mit dem Kunden die maßgebliche Einstufung des Systems klären; daraus ergibt sich, welche Markierung den Kontrollumfang bestimmt. Wie die Einstufung zustande kommt, behandelt dieser Artikel nicht (Markierungen aus Kundensicht in ism-australien-002).
4. Architektur früh genehmigen lassen. Die Sicherheitsarchitektur im Systemsicherheitsplan vor Entwicklungsbeginn vom authorising officer genehmigen lassen.
5. Auswahl begründen. Kontrollen nach Eignung für die Ziele auswählen, zusätzliche Kontrollen aus der eigenen Risikoanalyse ergänzen, geerbte Kontrollen benennen und alles im Annex des Systemsicherheitsplans dokumentieren.
6. Bewertung vorab vereinbaren. Umfang, Art und Tiefe mit Assessor und authorising officer festlegen, bevor die Bewertung beginnt; klären, ob eigene Assessoren oder IRAP-Assessoren bewerten.
7. Freigabeausgänge einplanen. Mit einer Freigabe unter Auflagen rechnen und den Maßnahmenplan so führen, dass Auflagen und Ablaufdaten nachverfolgt werden.
8. Überwachung an Auslöser binden. Die vom ISM genannten Ereignisse als Auslöser im Änderungsprozess verankern, den jährlichen Statusbericht an den authorising officer terminieren und davon getrennt die mindestens jährliche Überprüfung der Sicherheitsdokumentation mit Standangabe einplanen.

Typische Fehler

1. Ein Managementsystemzertifikat wird als Ersatz für Systemsicherheitsplan, Bewertungsbericht und Betriebsfreigabe angeboten.
2. Die Markierung NC wird als "nicht anwendbar" gelesen, obwohl sie nicht eingestufte staatliche und nichtstaatliche Systeme bezeichnet.
3. Die Kontrollen werden als vollständige Liste behandelt, ohne eigene Risikoanalyse und ohne zusätzliche Kontrollen.
4. Geerbte und geteilte Risiken aus Cloud- und Plattformdiensten werden nicht benannt und deshalb auch nicht akzeptiert.
5. Der Dienstleister behandelt die Freigabe als eigene Entscheidung, obwohl authorising officer der CISO des Kunden ist.
6. Der Annex des Systemsicherheitsplans bleibt auf dem Planungsstand stehen, obwohl die Umsetzung abweicht.
7. Die Freigabe wird als einmaliger Projektschritt verstanden; Auslöser für Neubewertung, der jährliche Statusbericht und die jährliche Überprüfung der Dokumentation mit Standangabe fehlen.
8. Die Sicherheitsarchitektur wird erst nach Entwicklungsbeginn zur Genehmigung vorgelegt.
9. Ablaufdaten und Auflagen einer Freigabe werden nicht nachverfolgt, bis der Kunde die Freigabe einschränkt oder entzieht.

Risiken und Trade-offs

Der erste Zielkonflikt liegt zwischen Wiederverwendung und Systemtreue. Ein organisationsweites ISMS spart Aufwand, weil Richtlinien, Methoden und Prozesse einmal existieren. Das ISM fragt aber je System, und ein generischer Nachweis verfehlt die Frage. Die wirtschaftliche Lösung ist, gemeinsame Teile auf höherer Ebene zu führen, was das ISM ausdrücklich als Möglichkeit nennt, und nur das Systemspezifische je System zu dokumentieren.

Der zweite liegt zwischen eigener und externer Bewertung. Eigene Assessoren können im Einzelfall schneller oder günstiger sein, das ist je Vorhaben zu vergleichen; das ISM lässt sie für nicht eingestufte Systeme bis SECRET zu; für Gateways sieht es gesonderte Bewertungen vor. Ein Kunde kann aber eine IRAP-Bewertung verlangen; das ist eine Vertragsfrage, die man vor dem Angebot klären sollte, nicht danach.

Der dritte liegt zwischen schneller Freigabe und belastbarer Freigabe. Eine Freigabe unter Auflagen bringt ein System früher in Betrieb, bindet aber Nacharbeit und kann mit einem Ablaufdatum versehen sein. Wer sie annimmt, braucht einen Maßnahmenplan, der tatsächlich abgearbeitet wird.

Entscheidungspunkte

• Für welche Systeme gilt eine australische Kundenanforderung, und wer ist dort jeweils Systemeigentümer und authorising officer?
• Welche Teile des Freigabepakets liefern wir dem Kunden, und wie ist das vertraglich geregelt?
• Bewerten wir mit eigenen Assessoren, oder rechnen wir mit einer IRAP-Bewertung, und wer trägt die Kosten?
• Welche geerbten und geteilten Risiken aus Cloud- und Plattformdiensten benennen wir, und wer akzeptiert sie?
• Akzeptieren wir eine Freigabe unter Auflagen, und mit welchen Mitteln arbeiten wir den Maßnahmenplan ab?
• Wie verbinden wir die systembezogene ISM-Kette mit unserem bestehenden ISMS, ohne zwei Risikomethoden zu führen?

Praktische Empfehlungen

• Den bestehenden Risikomanagementrahmen weiterverwenden und um die systembezogenen Artefakte des ISM ergänzen, statt eine zweite Methode aufzubauen.
• Je System ein Register führen mit Systemgrenze, Kritikalität, maßgeblicher Markierung, Rollen, Freigabestatus, Auflagen und Ablaufdatum.
• Die Unterscheidung zwischen geplanter und tatsächlicher Umsetzung im Annex konsequent führen; sie ist die Grundlage, auf der eine Bewertung prüft, ob Kontrollen richtig umgesetzt sind und wie vorgesehen wirken.
• Vor jedem Angebot an einen australischen Kunden die Freigaberolle, den Bewertungsweg und die Lieferanteile am Freigabepaket schriftlich klären.
• Die vom ISM genannten Auslöser für zusätzliche Risikomanagementaktivitäten in den Änderungsprozess übernehmen und mit einem Termin für den jährlichen Statusbericht verbinden.
• Für die Einzelheiten jeder Kontrolle und für die Vorlage des Annex die aktuelle Ausgabe des ISM beim ASD heranziehen; das ISM verweist dafür auf eine Vorlage auf seiner Webseite.

Relevante Normreferenzen

• ASD, Information Security Manual, Ausgabe September 2026: "Using the cyber security framework" (Executive summary mit Purpose, Authority, Legislation and legal considerations, Cyber security principles und Cyber security guidelines; Applying a risk-based approach to cyber security mit den sechs Schritten).
• Ebenda, "Cyber security principles" (sechs Funktionen, Umsetzungshinweise).
• Ebenda, "Guidelines for cyber security roles", Abschnitte Chief information security officer (Berichterstattung, Register der Systeme) und System owners (Rollen in den sechs Schritten, jährlicher Statusbericht).
• Ebenda, "Guidelines for cyber security documentation", Abschnitte Development and maintenance of cyber security documentation (Genehmigung der Sicherheitsarchitektur durch den authorising officer) und System-specific cyber security documentation (Systemsicherheitsplan, Vorfallsreaktionsplan, Änderungs- und Konfigurationsmanagementplan, Überwachungsplan, Bewertungsbericht, Maßnahmenplan).
• Ebenda, "Cyber security terminology" (Begriffe authorising officer, authorisation to operate, authorisation package, system owner, system security plan).
• NIST SP 800-37 Rev. 2, auf das sich das ISM-Risikomanagement nach eigener Angabe stützt; im Korpus nicht vertieft.
• Abgrenzung: Das NIST Risk Management Framework selbst steht im nist-Track (nist-risk-006), hier nur die Anlehnung des ISM daran; ISO/IEC 27001 und das organisationsweite ISMS stehen im Track core-iso27001, hier nur der Anschluss des ISM an einen bestehenden Risikomanagementrahmen; IT-Grundschutz steht im it-grundschutz-Track und wird mit dem ISM nicht gleichgesetzt; die CIS Controls stehen im cis-Track, hier keine Zuordnung. Innerhalb dieses Tracks: Rechtsnatur und Aufbau in ism-australien-001, Betroffenheit und Markierungen aus Kundensicht in ism-australien-002, Essential Eight in ism-australien-004, Vorfälle, Beschaffung und Cloud in ism-australien-005, technische Leitlinien in ism-australien-006.