Informationssicherheitsziele

Informationssicherheitsziele sind die von der Organisation festgelegten, messbaren Absichten, die das ISMS erreichen soll. ISO/IEC 27001 verlangt sie in Abschnitt 6.2 auf den relevanten Ebenen und Funktionen: im Einklang mit der Leitlinie, messbar soweit praktikabel, überwacht, kommuniziert, aktualisiert und als dokumentierte Information verfügbar.

ISMSZuletzt geprüft:

Ziele sind der Punkt, an dem sich zeigt, ob ein ISMS gesteuert oder nur betrieben wird. Ohne Ziele lässt sich die Frage der Managementbewertung – ist das System weiterhin geeignet, angemessen und wirksam – nur mit einem Gefühl beantworten. Mit schlecht geschnittenen Zielen wird sie mit Zahlen beantwortet, die niemanden interessieren.

Was Abschnitt 6.2 verlangt

Die Norm stellt an jedes Ziel eine Reihe von Anforderungen: Es muss mit der Informationssicherheitsleitlinie im Einklang stehen, soweit praktikabel messbar sein, die geltenden Anforderungen aus Kapitel 4 und die Ergebnisse der Risikobeurteilung und Risikobehandlung berücksichtigen, überwacht, kommuniziert, bei Bedarf aktualisiert und als dokumentierte Information verfügbar sein.

Hinzu kommt eine zweite, oft übersehene Hälfte: Zu jedem Ziel ist zu planen, was getan wird, welche Ressourcen erforderlich sind, wer verantwortlich ist, wann es abgeschlossen sein soll und wie die Ergebnisse bewertet werden. Ein Ziel ohne diese fünf Angaben ist nicht geplant, sondern gewünscht.

Ziel, Kennzahl und Maßnahme sind nicht dasselbe

EbeneFrageBeispiel
ZielWelcher Zustand soll erreicht werden?Kritische Systeme sind innerhalb der vereinbarten Wiederanlaufzeit wiederherstellbar
KennzahlWoran wird das gemessen?Anteil der kritischen Systeme mit erfolgreich getestetem Wiederanlauf
MaßnahmeWas wird dafür getan?Wiederherstellungstests je System, Behebung der Befunde, Nachtest

Wird diese Trennung nicht gemacht, entstehen die beiden typischen Fehlformen: das Ziel, das in Wahrheit eine Maßnahme ist („Einführung eines SIEM“), und das Ziel, das in Wahrheit eine Kennzahl ohne Zielzustand ist („Anzahl der Vorfälle“).

Woraus Ziele entstehen sollten

Brauchbare Ziele haben eine erkennbare Herkunft. Sie stammen aus der Risikobehandlung, weil die wesentlichen Risiken die Prioritäten vorgeben; aus den Anforderungen interessierter Parteien, etwa vertraglich zugesagten Wiederanlaufzeiten; aus dem, was interne Audits, Vorfälle und Übungen zutage gefördert haben; oder aus strategischen Vorhaben mit Sicherheitsbezug wie einer Cloud-Migration.

Ziele, die sich aus keiner dieser Quellen herleiten lassen, sind meist aus einer Vorlage übernommen. Sie überstehen das erste Jahr, aber nicht die zweite Managementbewertung.

Messbar, soweit praktikabel

Die Einschränkung ist bewusst gesetzt. Nicht jedes sinnvolle Ziel lässt sich in eine Zahl fassen; Reifegradaussagen oder Ergebnisse einer Übung sind zulässige Messgrößen. Was die Norm nicht zulässt, ist ein Ziel, dessen Erreichung sich überhaupt nicht feststellen lässt. Wo eine Zahl gewählt wird, gehören drei Angaben dazu: Ausgangswert, Zielwert und Stichtag. Fehlt der Ausgangswert, ist am Jahresende nicht entscheidbar, ob etwas erreicht wurde.

Ein Hinweis zur Zielhöhe: Zielwerte sind organisationsspezifisch. Aus fremden Branchenwerten abgeleitete Vorgaben führen regelmäßig dazu, dass entweder das Ziel oder die Messung angepasst wird, bis es passt.

Kaskadierung auf Funktionen

Die Norm verlangt Ziele auf den relevanten Funktionen und Ebenen. Praktisch bedeutet das eine überschaubare Zahl von Zielen auf Ebene des Managementsystems und daraus abgeleitete Beiträge in den Bereichen, die tatsächlich etwas beitragen können: IT-Betrieb, Entwicklung, Personal, Einkauf. Eine Kaskade, die jedem Bereich dasselbe Ziel zuweist, erzeugt Aufwand ohne Steuerungswirkung.

Kommunizieren heißt nicht veröffentlichen

Die Norm verlangt, die Ziele zu kommunizieren. Gemeint ist nicht die Ablage im Intranet, sondern dass diejenigen, die zur Zielerreichung beitragen sollen, ihren Beitrag kennen. Der Prüfstein im Audit ist einfach: Ein Verantwortlicher aus dem IT-Betrieb wird gefragt, welches Ziel seinen Bereich betrifft und woran dessen Erreichung gemessen wird. Kommt darauf keine Antwort, hilft auch ein gepflegtes Zieldokument nicht weiter. Verankern Sie Ziele dort, wo ohnehin gesteuert wird: in Bereichszielen, in der Vorhabenplanung und im regelmäßigen Berichtsweg an die Leitung.

Beanstandungen zu Zielen

  • Ziele, die seit der Erstzertifizierung unverändert sind, obwohl sie erreicht oder gegenstandslos wurden.
  • Ziele ohne Umsetzungsplan: keine Ressourcen, keine Verantwortlichen, kein Termin, keine Aussage zur Bewertung.
  • Kein Bezug zur Risikobehandlung, sodass die wesentlichen Risiken in den Zielen nicht vorkommen.
  • Ziele, die nirgends kommuniziert wurden, sodass die Beteiligten sie im Audit nicht benennen können.
  • Zielerreichung wird berichtet, aber nicht bewertet; die Managementbewertung enthält keine Entscheidung darüber, wie es weitergeht.
Alle Einträge ansehenNach oben

Häufige Fragen

Compliance auf Ihren echten Assets

Rizzqo macht aus Framework-Anforderungen verantwortete Aufgaben auf Ihren vorhandenen Assets – und beziffert das Risiko in echtem Geld.

Made in GermanyEU-gehostetMulti-Framework