Braucht ISO 27001 einen CISO? Die Norm verlangt etwas anderes

Auf der Projektliste für ISO 27001 steht bei vielen KMU eine Zeile, die mehr Diskussion auslöst als der ganze Rest: CISO benennen. Was darunter folgt, Dokumente, Risikobewertung, Audits, wirkt daneben harmlos.

Die Zeile liest sich wie eine Personalentscheidung, und darum landet sie oft bei der Geschäftsleitung mit der Frage, ob man jetzt jemanden einstellen oder einkaufen muss. Nur ist das die falsche erste Frage. Die Norm will an dieser Stelle etwas anderes, und es ist deutlich weniger, als die Zeile vermuten lässt. Der Teil, auf den es ihr ankommt, ist allerdings schwerer zu besetzen als eine Stelle.

Braucht ISO 27001 einen CISO?

Nein. Die Norm nennt keinen Stellentitel und keine neue Funktion im Organigramm. Kapitel 5.3 verlangt, dass die oberste Leitung Verantwortlichkeiten und Befugnisse für die Rollen zuweist, die für die Informationssicherheit relevant sind, und dass diese Zuweisung im Unternehmen bekannt ist. Wer die Arbeit macht, bleibt eure Entscheidung.

Eine Zertifizierungsstelle prüft deshalb auch nicht, ob es einen CISO gibt. Sie prüft, wer wofür zuständig ist und woran man das sieht. Dass im Audit trotzdem jemand nach dem CISO fragt, kommt vor, gemeint ist dann die Zuständigkeit und nicht der Titel.

Ob die Rolle bei euch CISO heisst, Informationssicherheitsbeauftragte oder ein Absatz in der Stellenbeschreibung der Geschäftsführerin, ist der Norm gleichgültig. Geprüft wird die Zuweisung, nicht das Namensschild. Der Titel CISO ist für ein KMU trotzdem oft die praktischste Variante, weil er nach innen sofort klarmacht, dass hier jemand entscheiden darf. Ein Kommunikationsvorteil also, keine Normanforderung.

Was Kapitel 5.3 wirklich verlangt

Die Norm wird an genau zwei Punkten konkret. Die oberste Leitung weist die Befugnis zu, erstens dafür zu sorgen, dass das Managementsystem die Anforderungen der Norm erfüllt, und zweitens dafür, der obersten Leitung über die Leistung dieses Systems zu berichten.

Plain übersetzt: eine Person muss sagen dürfen, dass etwas nicht normkonform läuft, und sie muss damit bis zur Geschäftsleitung durchkommen. Nicht bis zur IT-Leitung, nicht bis ins Projektmeeting. Bis dorthin, wo über Geld und Prioritäten entschieden wird.

Dabei lohnt sich die Unterscheidung zwischen zwei Wörtern, die im Alltag durcheinandergehen. Verantwortlichkeit heisst, die Arbeit zu machen und für ihr Ergebnis einzustehen. Befugnis heisst, entscheiden zu dürfen. Die Norm will beides, und sie will es bei derselben Rolle. Ein KMU, das einen CISO benennt und ihm nur das Erste gibt, hat die Zeile auf der Projektliste abgehakt und die Anforderung offen gelassen.

In Anhang A kommt der Gedanke ein zweites Mal, als Massnahme 5.2: Informationssicherheitsrollen und Verantwortlichkeiten werden definiert und entsprechend den Bedürfnissen der Organisation zugewiesen. Wieder kein Titel, wieder dieselben zwei Verben. Definieren und zuweisen.

Zwei Stellen in derselben Norm, beide ohne Stellenbeschreibung. Das ist kein Versehen. Eine Norm, die für den Fünfzehn-Personen-Betrieb und für den Konzern gelten soll, kann keine Organisationsform vorschreiben. Vorgeschrieben wird, dass die Zuständigkeit zugewiesen ist und dass der Berichtsweg existiert.

Genau daran scheitert es im KMU, und zwar nicht am Titel. Es scheitert daran, dass die Person, die die Arbeit macht, die zweite Befugnis nicht hat. Das Problem wird gesehen, es wird aufgeschrieben, und es bleibt in der Ebene hängen, in der die Person selbst sitzt. Formal ist die Rolle besetzt. Praktisch fehlt die Hälfte, auf die es der Norm ankommt.

Wie die Zuweisung sichtbar wird

Eine zugewiesene Rolle, von der niemand weiss, ist keine zugewiesene Rolle. Kapitel 5.3 hält deshalb beides fest, das Zuweisen und das Bekanntmachen. Kapitel 7.4 führt den Gedanken weiter: Ihr legt fest, worüber ihr zur Informationssicherheit kommuniziert, wann, mit wem und von wem aus. Im KMU ist das keine Kommunikationsstrategie, sondern meistens ein Absatz im Intranet und ein Punkt in der Einarbeitung.

Der zweite Nachweis ist der Berichtsweg selbst, und er hat einen Rhythmus. Nach Kapitel 9.3 bewertet die oberste Leitung das Managementsystem in geplanten Abständen, mit festgelegten Themen als Eingaben und mit festgehaltenen Ergebnissen. Wer diese Eingaben zusammenträgt, lässt die Norm offen. In der Praxis ist es die Person aus Kapitel 5.3.

In unserer Erfahrung ist das der praktischste Prüfstein für die ganze Rollenfrage, und er kostet nichts. Schaut im letzten Protokoll der Geschäftsleitung nach, ob Informationssicherheit als eigener Punkt vorkommt, und wenn ja, wer dazu vorgetragen hat. Findet sich dort niemand, fehlt die zweite Hälfte der Rolle, unabhängig davon, wer den Titel trägt.

Die drei Entscheide, die vorher einen Namen brauchen

Hier liegt der eigentliche Grund, die Rollenfrage früh zu klären, und er hat nichts mit dem Audit zu tun. Ein ISO-Projekt verlangt drei Entscheide, die sich später nur teuer korrigieren lassen. Alle drei fallen in den ersten Wochen, oft bevor jemand formal zuständig ist. Ein CISO, der erst dazukommt, wenn das Projekt schon läuft, erbt sie, ohne sie getroffen zu haben, und muss sie entweder verteidigen oder aufmachen.

Der Geltungsbereich

Kapitel 4.3 verlangt den Geltungsbereich als dokumentierte Information. Was drin ist, wird geprüft. Was draussen ist, steht nicht auf dem Zertifikat, und darauf schaut der Kunde, der das Zertifikat sehen will.

Diesen Entscheid trifft in unserer Erfahrung selten die Person, die ihn tragen muss. Er entsteht im Projektmeeting, aus dem, was gerade machbar aussieht. Wie du die Grenze sinnvoll schneidest, haben wir im Beitrag zum Geltungsbereich bei ISO 27001 durchgespielt. Die Frage hier ist eine andere, nämlich wer diesen Satz am Ende verantwortet, auch wenn ein Kunde zwei Jahre später nachfragt, warum sein Werk nicht drin ist.

Die Akzeptanz der verbleibenden Risiken

Für den Risikobehandlungsplan fordert Kapitel 6.1.3 die Zustimmung der Risikoeigentümer und deren Akzeptanz der verbleibenden Risiken. Die Norm benutzt hier selbst das Wort Eigentümer. Wie weit du das fasst, lässt sie offen; in unserer Erfahrung trägt ein Risiko nur dann, wenn eine Person dahintersteht und keine Abteilung.

Diese Zeile ist die unbequemste im ganzen Projekt. Ein akzeptiertes Restrisiko ist eine Entscheidung mit Namen daran: Wir wissen das, wir lassen es so, und das hier ist der Grund. Ohne Namen bleibt es ein offener Punkt in einer Liste, die niemand mehr liest.

Wer akzeptieren darf, ist dabei keine Geschmacksfrage. Es muss jemand sein, der die Folgen auch tragen darf. Ein externer CISO kann die Bewertung liefern und die Entscheidung vorbereiten, akzeptieren kann er sie nicht. Was sich von dieser Verantwortung überhaupt weitergeben lässt und was nicht, haben wir beim Auslagern der Sicherheitsverantwortung aufgeschrieben.

Viel braucht so ein Eintrag nicht. Das Risiko, der Entscheid, die Begründung, der Name und das Datum, dazu ein Zeitpunkt, an dem die Sache wieder auf den Tisch kommt. Das passt in sechs Spalten, und in unserer Erfahrung bringt es im Audit mehr als ein Ordner voller Richtlinien.

Die Ausschlüsse in der Anwendbarkeitserklärung

Die Anwendbarkeitserklärung aus Kapitel 6.1.3 hält fest, welche Massnahmen aus Anhang A ihr einsetzt und welche nicht, mit Begründung. Jeder Ausschluss ist eine Behauptung über euren Betrieb, und Ausschlüsse gehören zu dem, was im Audit nachgefragt wird.

In unserer Erfahrung ist das die Stelle, an der Projekte still Arbeit erzeugen. Wenn niemand mit Überblick entscheidet, wird im Zweifel nichts ausgeschlossen. Anhang A der Fassung von 2022 umfasst 93 Massnahmen, verteilt auf organisatorische, personelle, physische und technologische. Wer von diesen 93 keine einzige begründet weglässt, fühlt sich auf der sicheren Seite. Tatsächlich stehen dann Massnahmen im System, die beschrieben, umgesetzt und jedes Jahr nachgewiesen werden müssen, obwohl sie den eigenen Betrieb nie betroffen haben. Diese Zusatzarbeit fällt im Projekt kaum auf. Sie fällt im zweiten und dritten Jahr auf, wenn das System ohne Projektbudget weiterlaufen soll.

Wer die Rolle im KMU übernimmt

Drei Besetzungen funktionieren in dieser Grössenordnung, und keine davon braucht eine neue Vollzeitstelle.

Ein Mitglied der Geschäftsleitung trägt den CISO-Hut selbst. Das löst die Befugnis sofort und sauber, weil beide Hälften ohnehin zusammenfallen. Es braucht aber die Zeit, sich in Risikobewertung und Nachweisführung einzuarbeiten, und diese Zeit ist in unserer Erfahrung der Punkt, an dem es kippt. Nicht am Verständnis, sondern am Kalender.

Die IT-Leitung übernimmt die Rolle. In unserer Erfahrung ist das die häufigste Variante, und sie funktioniert, solange der Berichtsweg an die Geschäftsleitung steht. Der bekannte blinde Fleck bleibt: Wer den Betrieb verantwortet, beurteilt im Zweifel seine eigene Arbeit und meldet den eigenen Rückstand. Den Unterschied zwischen dem CISO-Hut und dem Betriebshut haben wir in CISO und IT-Sicherheitsbeauftragter auseinandergenommen.

Oder die Arbeit und das Urteil kommen von aussen, und die Befugnis bleibt im Haus. Das ist unser Modell: Wir bringen die Rolle als externen CISO mit, die Geschäftsleitung behält die Entscheidung, und das ISMS nach ISO 27001 wird entlang dieser Entscheidungen aufgebaut statt um sie herum.

Eine Einschränkung gehört dazu, und sie wird im Markt gern übergangen. Kapitel 5.3 spricht von einer Zuweisung innerhalb der Organisation. Die Arbeit und die Beurteilung darf ein externer CISO übernehmen, die zugewiesene Zuständigkeit braucht trotzdem einen Namen im Haus. Wer ein Mandat kauft und sich damit die Rolle vom Tisch schiebt, hat am Ende nur ausgelagert, wer sie beschreibt.

Welche der drei passt, hängt weniger am Budget als an einer einzigen Grösse: wie viele Stunden pro Woche die Person, die ihr im Kopf habt, nächsten Monat tatsächlich frei hat. Wer diese Zahl nicht kennt, sollte sie klären, bevor das Projekt startet, nicht im dritten Monat. Für ein Gegenlesen eurer Besetzung stehen wir im Erstgespräch zur Verfügung.

Der Unterschied, den das Zertifikat nicht zeigt

Zwei Betriebe können dasselbe Zertifikat an der Wand haben. Beim einen steht hinter jedem akzeptierten Risiko und jedem Ausschluss ein Name, der das damals so entschieden hat und erklären kann, warum. Beim anderen sind die Begründungen entstanden, weil das Audit sie verlangt hat. Von aussen ist der Unterschied nicht zu sehen, im Audit meistens auch nicht. Sichtbar wird er zwei Jahre später, wenn sich etwas ändert und jemand wissen will, warum das eigentlich so beschlossen wurde. Er hängt nicht daran, ob jemand CISO auf der Visitenkarte stehen hatte, sondern daran, ob die Person entscheiden durfte, als es darauf ankam.

Wenn du heute in dein eigenes Risikoverzeichnis schaust: Bei wie vielen Einträgen fällt dir sofort eine Person ein, die diesen Entscheid verantwortet?

Häufige Fragen

Schreibt ISO 27001 einen CISO vor?

Nein. Die Norm nennt keinen Stellentitel. Kapitel 5.3 verlangt, dass die oberste Leitung Verantwortlichkeiten und Befugnisse für Rollen der Informationssicherheit zuweist und diese Zuweisung bekannt macht. Dazu gehört die Befugnis, über die Leistung des ISMS an die oberste Leitung zu berichten. Wie die Rolle heisst, entscheidet ihr.

Kann ein externer CISO die Rolle nach Kapitel 5.3 übernehmen?

Teilweise. Die Arbeit und die fachliche Beurteilung darf ein externes Mandat übernehmen. Kapitel 5.3 spricht aber von einer Zuweisung innerhalb der Organisation, deshalb braucht die zugewiesene Zuständigkeit weiterhin einen Namen im Haus. Ein Restrisiko akzeptieren kann nur, wer die Folgen auch tragen darf.

Welche Entscheide brauchen vor dem ISO-Projekt einen Verantwortlichen?

Drei. Der Geltungsbereich nach Kapitel 4.3, die Akzeptanz der verbleibenden Risiken durch die Risikoeigentümer nach Kapitel 6.1.3 und die begründeten Ausschlüsse in der Anwendbarkeitserklärung. Alle drei fallen in den ersten Wochen und lassen sich später nur teuer korrigieren.