ISO 27001 Pflichtdokumente: kürzer als das Vorlagenpaket

Die Liste der ISO 27001 Pflichtdokumente ist kürzer als die Vorlagenpakete, die dir dazu verkauft werden, und sie passt auf eine halbe Seite. Ein ISMS-Handbuch steht nicht darauf.

Trotzdem sieht ein Zertifizierungsaudit selten so aus, dass jemand Dokumente zählt. Stell dir den Tisch im Audit der zweiten Stufe vor. Auf dem Laufwerk liegen Richtlinien, sauber formatiert, jede mit Versionsnummer und Freigabedatum. Der Auditor öffnet zwei davon. Danach fragt er, wann die Zugriffsrechte das letzte Mal durchgesehen wurden, wer das Ergebnis abgenommen hat und wo das steht.

An dieser Frage merkst du, ob ein ISMS-Projekt trägt. Die Anzahl der Dokumente spielt dabei keine Rolle. Es zählt, ob irgendwo festgehalten ist, dass jemand etwas getan hat.

Was ISO 27001 als Dokument verlangt

ISO/IEC 27001:2022 verlangt an wenigen, klar benannten Stellen ein Dokument:

den Geltungsbereich des ISMS (Abschnitt 4.3)
die Informationssicherheitspolitik (5.2)
den Prozess der Risikobeurteilung und den Prozess der Risikobehandlung (6.1.2 und 6.1.3)
die Erklärung zur Anwendbarkeit samt Risikobehandlungsplan (6.1.3)
die Informationssicherheitsziele (6.2)

Das ist die Liste. Dazu kommt der Abschnitt, der den Rest regelt. 7.5.1 nennt zwei Quellen für dokumentierte Information: die, die die Norm selbst fordert, und die, die die Organisation für die Wirksamkeit ihres ISMS als notwendig bestimmt. Der zweite Teil ist Spielraum, kein Pflichtenheft. Im selben Abschnitt hält die Norm fest, dass der angemessene Umfang je nach Grösse der Organisation, Tätigkeit, Komplexität der Prozesse und Kompetenz der Beteiligten unterschiedlich ausfällt.

Das heisst im Grunde: ein Treuhandbüro mit einem Standort und ein Industriebetrieb mit Produktion in zwei Ländern dürfen unterschiedlich dick dokumentieren, und beide erfüllen die Norm. Wer dir ein festes Vorlagenpaket als Pflicht verkauft, verkauft dir eine Auslegung.

Ein Dokument auf der Liste verdient eine eigene Erwähnung: die Erklärung zur Anwendbarkeit. Die Erklärung ist das Scharnier zwischen deiner Risikobeurteilung und den Controls aus Anhang A. Für jedes Control hält sie fest, ob es gilt und warum, und wenn es nicht gilt, warum nicht. Im Audit ist sie der Einstiegspunkt, weil sich von dort jede Stichprobe ziehen lässt. Übernimmst du sie aus einer Vorlage und lässt die fremden Begründungen stehen, erreichst du das Gegenteil: ein Dokument, das Prüfpunkte erzeugt, zu denen im Haus niemand etwas sagen kann. Eine Erklärung zur Anwendbarkeit, in der ein Teil der Controls mit nachvollziehbarer Begründung nicht gilt, steht im Audit stabiler da als eine, in der alles angeblich umgesetzt ist.

Die beiden Unterabschnitte danach werden meist überschätzt. 7.5.2 und 7.5.3 verlangen, dass ein Dokument erkennbar ist, also Titel, Datum und Version trägt, dass es in einem brauchbaren Format vorliegt, dass es vor der Freigabe auf Angemessenheit geprüft wird, und dass klar ist, wer darauf zugreifen darf und wie lange es aufbewahrt wird. Das ist in einem KMU eine halbe Seite plus die Einstellungen in der Dateiablage, kein eigenes Teilprojekt.

Dokument oder Nachweis: wo die ISO 27001 Pflichtdokumente enden

Der grössere Teil der Dokumentationsanforderungen sind keine Dokumente. Es sind Nachweise, in der Normsprache aufbewahrte dokumentierte Information, und sie entstehen erst, wenn das Managementsystem läuft. Die Norm verlangt sie an acht Stellen:

Nachweise der Kompetenz der Beteiligten (7.2)
Belege, dass die geplanten Prozesse wie geplant durchgeführt wurden (8.1)
die Ergebnisse der Risikobeurteilung (8.2)
die Ergebnisse der Risikobehandlung (8.3)
die Ergebnisse von Überwachung und Messung (9.1)
das Auditprogramm und die Auditergebnisse (9.2)
die Ergebnisse der Managementbewertung (9.3)
Abweichungen, getroffene Massnahmen und das Ergebnis der Korrekturmassnahmen (10.2)

Eine Richtlinie kannst du an einem Vormittag schreiben. Einen Nachweis nicht. Der ist entweder da, weil jemand im März die Zugriffsrechte durchgesehen und das Ergebnis festgehalten hat, oder er fehlt. Rückwirkend lässt sich das nicht herstellen, jedenfalls nicht ehrlich.

Dabei ist ein brauchbarer Nachweis unspektakulär. Für die Durchsicht der Zugriffsrechte reichen vier Angaben: wann sie stattgefunden hat, wer sie gemacht hat, was dabei aufgefallen ist und was damit entschieden wurde. Das ist ein Eintrag in einer Tabelle oder eine Mail mit Datum, kein formatiertes Dokument mit Deckblatt. Eine zehnseitige Richtlinie zum Berechtigungsmanagement beantwortet diese Frage nicht.

An dieser Stelle verliert ein Projektteam Monate. Sechs Monate Dokumente schreiben und dann ins Audit gehen funktioniert nicht, weil ein guter Teil der Anforderungen eine Vorgeschichte braucht. Das interne Audit muss stattgefunden haben. Die Managementbewertung muss ein Ergebnis haben, das jemand aufgeschrieben hat. Die Risikobeurteilung braucht Resultate mit Datum. In unserer Erfahrung ist das der häufigere Grund für eine Abweichung im Audit als eine fehlende Richtlinie.

Warum der Stapel trotzdem auf Paketgrösse wächst

Drei Gründe, und keiner steht in der Norm.

Der erste ist Anhang A. Die Controls dort sind eine Referenzliste, aus der die Erklärung zur Anwendbarkeit auswählt und begründet, was gilt und was nicht. Ein Teil der Controls verlangt im Wortlaut eine Regel, eine Anweisung oder eine Aufzeichnung. Für den Rest gilt das nicht. Eine Richtlinie pro Control ist eine Konvention von Vorlagenpaketen, die nach Umfang verkauft werden, und keine Anforderung der Norm.

Der zweite ist die Reihenfolge. Wer Dokumente schreibt, bevor der Geltungsbereich steht, schreibt zweimal. Der Geltungsbereich entscheidet, welche Standorte, Systeme und Prozesse überhaupt gemeint sind, und damit auch, welche Regeln für wen gelten. Steht er erst im dritten Monat, liegen bis dahin Dokumente da, die Dinge regeln, die am Ende nicht dazugehören.

Der dritte ist das Werkzeug. Ein ISMS-Werkzeug ist nützlich, wenn du weisst, was du verwalten willst. Vorher ist es ein Gefäss, das sich mit Platzhaltern füllt, und es erzeugt Arbeit, statt sie zu sparen. Die Lizenz ist dabei der kleinere Posten, wie wir bei den ISO 27001 Kosten beschrieben haben. Teurer ist die Zeit, die in die Pflege eines Systems geht, das im Betrieb niemand benutzt.

Was dein Kunde liest und was er nicht liest

Im Schweizer Mittelstand bringt meist ein Einkäufer die Dokumentenfrage auf den Tisch, nicht die Norm. Ein Lieferantenfragebogen fragt nach dem Zertifikat, und wer genau hinschaut, liest die Zeile mit dem Geltungsbereich darauf. Diese Zeile sagt ihm, welcher Teil deines Unternehmens geprüft wurde. Ein Zertifikat, dessen Geltungsbereich die Abteilung ausschliesst, die für ihn arbeitet, beantwortet seine Frage nicht.

Nach deinen Richtlinien fragt dabei fast niemand. Was der Kunde wissen will, ist, ob jemand bei dir zuständig ist, wie ihr mit Vorfällen umgeht und ob eure Angaben nachprüfbar sind. Das sind dieselben Nachweise, die auch der Auditor sehen will. Behandelst du Informationssicherheit im KMU als Betrieb, bedienst du beide Seiten mit derselben Arbeit.

Was du weglassen darfst

Die Streichliste ist in unserer Erfahrung der schnellste Hebel in einem ISMS-Projekt, weil sie Aufwand entfernt, ohne eine Anforderung zu verletzen:

Vorlagen zu Themen, die dein Geltungsbereich nicht enthält. Eine Richtlinie zur Softwareentwicklung in einem Haus, das keine Software entwickelt, belegt keine Sorgfalt, sie öffnet eine Fehlerquelle im Audit.
Die Richtlinie pro Control. Mehrere Regeln passen in ein Dokument, wenn sie dieselben Leute betreffen.
Englische Vorlagen, in ein Deutsch übersetzt, das im Betrieb niemand liest. Ein Dokument, dem keiner folgt, erzeugt im Audit die Abweichung, die du vermeiden wolltest.
Das Dokument über die Lenkung der Dokumente, solange 7.5.2 und 7.5.3 mit einer halben Seite erfüllt sind.

Was dafür ins Budget gehört, ist die Zeit für die Nachweise: die Durchsicht der Zugriffsrechte, das interne Audit, die Managementbewertung, die Nachverfolgung von Abweichungen. Diese Posten tauchen in Dokumentenangeboten selten auf, obwohl sie den grösseren Teil der Arbeit tragen.

Wer die Nachweise führt

Ein Dokument mit dem Titel Verantwortlichkeitsmatrix steht an keiner Stelle in der Norm. Nachweise verlangt sie an acht Stellen, und die entstehen nur, wenn jemand einen Termin im Kalender hat, an dem sein Name steht.

Das ist die Beschränkung hinter der ganzen Dokumentenfrage. Ein Vorlagenpaket lässt sich einkaufen, eine Zuständigkeit nicht. Fehlt sie, passiert mit dem Paket, was wir regelmässig sehen: Jemand führt es im ersten Jahr ein, im zweiten pflegt es niemand, und im Überwachungsaudit fällt auf, dass alle Versionsnummern aus dem Zertifizierungsmonat stammen.

Die nützlichere erste Frage ist deshalb nicht, welche Dokumente fehlen, sondern wer am Ende des Quartals aufschreibt, was passiert ist. Genau darum kümmern wir uns, wenn wir einen ISMS-Aufbau nach ISO 27001 begleiten: zuerst Geltungsbereich und Zuständigkeit, dann die kurze Dokumentenliste, und von Anfang an ein Takt, der Nachweise erzeugt. Wer den Weg dorthin schlank halten will, findet die Reihenfolge in unserem Beitrag zum pragmatischen ISMS-Aufbau.

Wenn du nicht sicher bist, welche Nachweise bei euch heute schon anfallen und nur niemand festhält, schau mit uns einmal strukturiert darauf. Ein Erstgespräch ist unverbindlich und kostet dich eine halbe Stunde.

Und falls morgen jemand nach der letzten Durchsicht der Zugriffsrechte fragt: findest du den Nachweis oder die Richtlinie, die ihn verlangt?

Häufige Fragen

Welche Dokumente verlangt ISO 27001 zwingend?

Die Norm nennt den Geltungsbereich des ISMS (4.3), die Informationssicherheitspolitik (5.2), den Prozess der Risikobeurteilung und der Risikobehandlung (6.1.2 und 6.1.3), die Erklärung zur Anwendbarkeit samt Risikobehandlungsplan (6.1.3) und die Informationssicherheitsziele (6.2). Alles Weitere bestimmt deine Organisation selbst.

Braucht jedes Annex-A-Control eine eigene Richtlinie?

Nein. Anhang A ist eine Referenzliste, aus der die Erklärung zur Anwendbarkeit auswählt und begründet. Ein Teil der Controls verlangt im Wortlaut eine Regel oder eine Aufzeichnung, der Rest nicht. Eine Richtlinie pro Control ist eine Konvention von Vorlagenpaketen, keine Anforderung der Norm.

Was ist der Unterschied zwischen Dokument und Nachweis?

Ein Dokument legt fest, wie ihr arbeiten wollt, und lässt sich an einem Vormittag schreiben. Ein Nachweis zeigt, dass ihr es getan habt, und entsteht nur im Betrieb. Die Norm verlangt Nachweise an acht Stellen, unter anderem für internes Audit, Managementbewertung und Korrekturmassnahmen.