Auf die, die „nicht anwendbar“ begründen, statt es anzukreuzen

Zwei Tage vor dem Audit. Die Erklärung zur Anwendbarkeit ist eine Tabelle mit allen Maßnahmen aus Anhang A der ISO 27001, und in der Spalte „anwendbar“ steht elf Mal „n. a.“. Daneben, in der Spalte für die Begründung: nichts. Die Tabelle stammt aus der Erstzertifizierung, die Kollegin, die sie damals ausgefüllt hat, ist nicht mehr im Haus.

Man könnte die Zellen so lassen. Der Auditor hat sie beim letzten Mal auch nicht angesprochen. Stattdessen nimmt sich jemand die elf Zeilen vor, fragt nach, sieht nach und schreibt zu jeder einen Satz: was nicht zutrifft, warum nicht, und seit wann. Bei neun Zeilen geht das schnell. Bei zweien stellt sich heraus, dass „nicht anwendbar“ nicht mehr stimmt.

Was die Begründung verhindert

Ein „n. a.“ ohne Begründung ist eine Entscheidung, die niemand mehr prüfen kann. Vielleicht war sie richtig, als sie getroffen wurde. Aber Umgebungen ändern sich: Ein Dienst, den es nicht gab, wird eingeführt; eine Aufgabe, die ausgelagert war, kommt zurück ins Haus. Das Kreuz bleibt stehen. Und manchmal war es nie eine Feststellung, sondern eine Abkürzung: Die Anforderung war unbequem, also war sie nicht anwendbar. Dann ist aus dem Kreuz stillschweigend eine Risikoübernahme geworden, für die niemand unterschrieben hat.

Wo sie verlangt wird

Die ISO 27001 verlangt in Abschnitt 6.1.3 d sinngemäß, dass die Erklärung zur Anwendbarkeit nicht nur die erforderlichen Maßnahmen nennt, sondern auch begründet, warum Maßnahmen aus Anhang A ausgeschlossen wurden. Der Normtext ist urheberrechtlich geschützt, deshalb hier nur sinngemäß.

Im IT-Grundschutz heißt der Status „entbehrlich“, und BSI-Standard 200-2 ist an dieser Stelle deutlich. Zur Dokumentation des IT-Grundschutz-Checks steht dort in Kapitel 8.4.3:

„Bei Anforderungen, deren Umsetzung entbehrlich erscheint, ist hier die Begründung zu nennen.“

Und warum das Feld überhaupt existiert: „Ein solches Feld ist wichtig, um getroffene Entscheidungen später nachvollziehen zu können“. In Kapitel 8.4.2 zieht der Standard außerdem eine Grenze, die für jede Abkürzung gilt: „Generell ist zu beachten, dass bei Basis-Anforderungen das entstehende Risiko nicht übernommen werden kann.“

Warum sie unsichtbar ist

Eine leere Begründungsspalte sieht fertig aus. Niemand liest sie, bis jemand fragt, und dann ist die Person, die es wusste, meist nicht mehr da. Wer die Sätze schreibt, erzeugt keinen sichtbaren Fortschritt: Die Zahl der umgesetzten Maßnahmen bleibt gleich, der Bericht sieht danach genauso aus wie vorher. Im besten Fall sogar schlechter, weil zwei Zeilen von „nicht anwendbar“ auf „offen“ gewechselt sind.

Genau diese zwei Zeilen sind der Grund, warum es sich gelohnt hat.

Auf sie

Auf die, die bei jedem „nicht anwendbar“ wissen wollen, warum. Die ein Datum dazuschreiben und eine Bedingung, unter der die Antwort nicht mehr gilt. Und die eine Zeile lieber auf „offen“ setzen, als ein Kreuz stehen zu lassen, das sie nicht erklären können.

Quellen

BSI-Standard 200-2, IT-Grundschutz-Methodik, Kapitel 8.4.2 und 8.4.3. ISO/IEC 27001:2022, Abschnitt 6.1.3 d und Anhang A, sinngemäß (Normtext urheberrechtlich geschützt).

In der nächsten Folge: Auf die, die das Verarbeitungsverzeichnis pflegen, wenn niemand fragt. Die vorige Folge: Auf die, die in der Stabsübung sagen: „Das wissen wir nicht“.