Policy Management ISO Compliance Governance

Wie du eine Informationssicherheitsleitlinie schreibst (ISO 27001 Abschnitt 5.2)

Maciej
Wie du eine Informationssicherheitsleitlinie schreibst (ISO 27001 Abschnitt 5.2)
TL;DR

Die von ISO 27001 Abschnitt 5.2 geforderte Informationssicherheitsleitlinie ist ein einzelnes übergeordnetes Dokument, das die oberste Leitung festlegt. Sie muss zum Zweck der Organisation passen, Informationssicherheitsziele oder den Rahmen zu deren Festlegung enthalten, sich zur Erfüllung der zutreffenden Sicherheitsanforderungen verpflichten und zur fortlaufenden Verbesserung des ISMS. Sie muss als dokumentierte Information verfügbar sein, innerhalb der Organisation kommuniziert werden und interessierten Parteien gegebenenfalls zur Verfügung stehen. Sie ist nicht deine Richtliniensammlung — Zugriffskontrolle, zulässige Nutzung und Incident Response gehören in eigene untergeordnete Richtlinien. Ein bis zwei Seiten sind die richtige Länge, und der praktische Test ist, ob ein Gründer sie korrekt zusammenfassen könnte, ohne sie zu lesen.

Die Informationssicherheitsleitlinie, die ISO 27001 in Abschnitt 5.2 fordert, ist ein einzelnes, übergeordnetes Dokument, das von der obersten Leitung festgelegt wird. Sie beschreibt, wozu sich die Organisation verpflichtet und warum — und sie ist bewusst kurz. Ein bis zwei Seiten sind normal. Zehn sind ein Zeichen dafür, dass sich etwas hineinverirrt hat, das in eine untergeordnete Richtlinie gehört.

Das ist das Dokument, das am häufigsten mit einer kompletten Richtliniensammlung verwechselt wird. Wenn du eigentlich das Set an Richtlinien brauchst — zulässige Nutzung, Zugriffskontrolle, Incident Response und den Rest —, dann fang mit dem Minimal-Set an Richtlinien, zugeordnet zu den Trust Services Criteria an oder mit unseren neun internen Unternehmensrichtlinien samt Vorlagen. In diesem Artikel geht es um die eine Leitlinie, die über allen anderen steht.

Was Abschnitt 5.2 fordert

Die Norm wird hier ungewöhnlich konkret. Die oberste Leitung muss eine Informationssicherheitsleitlinie festlegen, die:

  • Zum Zweck der Organisation passt. Ein Zahlungsdienstleister und eine Designagentur sollten nicht dieselbe Leitlinie haben. Generischer Text ist der schnellste Weg zu zeigen, dass sich niemand aus der Führung damit befasst hat.
  • Informationssicherheitsziele enthält oder den Rahmen zu deren Festlegung vorgibt. Entweder du nennst die Ziele, oder du beschreibst, wie und von wem sie festgelegt und überprüft werden. Die meisten Organisationen wählen die Rahmen-Variante und halten die Ziele selbst in einem separaten, häufiger aktualisierten Dokument fest.
  • Eine Verpflichtung zur Erfüllung der zutreffenden Anforderungen enthält, die sich auf Informationssicherheit beziehen — gesetzliche, regulatorische und vertragliche.
  • Eine Verpflichtung zur fortlaufenden Verbesserung des Informationssicherheits-Managementsystems enthält.

Und die Leitlinie selbst muss:

  • als dokumentierte Information verfügbar sein
  • innerhalb der Organisation kommuniziert werden
  • interessierten Parteien gegebenenfalls zur Verfügung stehen

An diesen letzten drei Zeilen scheitern Audits tatsächlich. Die Leitlinie zu schreiben ist die leichte Hälfte; nachzuweisen, dass sie die Leute erreicht hat, ist die Hälfte, die Teams vergessen. Dazu unten mehr.

Ein Gerüst, Kapitel für Kapitel

Ein Aufbau, der Abschnitt 5.2 erfüllt, ohne aufzublähen:

  1. Zweck und Geltungsbereich — ein Absatz dazu, warum die Leitlinie existiert und wofür sie gilt, abgestimmt auf deine Beschreibung des ISMS-Anwendungsbereichs. Wiederhole den Anwendungsbereich nicht; verweise darauf.
  2. Verpflichtungserklärung — wozu sich die Organisation beim Schutz verpflichtet, in klarer Sprache: Vertraulichkeit, Integrität und Verfügbarkeit von Kunden- und Unternehmensinformationen.
  3. Ziele oder der Rahmen zu ihrer Festlegung — entweder die Ziele selbst oder ein Satz, der erklärt, dass Ziele jährlich in der Managementbewertung festgelegt und als dokumentierte Information nachgehalten werden.
  4. Verpflichtung auf die zutreffenden Anforderungen — gesetzliche, regulatorische und vertragliche Pflichten mit Bezug zur Informationssicherheit.
  5. Verpflichtung zur fortlaufenden Verbesserung — des ISMS, in der Praxis mit Bezug auf Abschnitt 10, auch wenn du die Nummer nicht nennst.
  6. Rollen und Verantwortlichkeiten — wer das ISMS verantwortet, wer Richtlinien freigibt, was von jedem Mitarbeitenden erwartet wird. Nenne Rollen statt Personen, damit sich das Dokument nicht bei jeder Einstellung ändert.
  7. Unterstützende Richtlinien — eine Liste der untergeordneten Richtlinien, die unter dieser Leitlinie hängen, damit Lesende wissen, wo die Details stehen.
  8. Folgen von Verstößen — eine kurze, ehrliche Aussage, die zu deinen arbeitsvertraglichen Regelungen passt.
  9. Freigabe und Überprüfung — wer sie freigegeben hat, wann, und in welchem Turnus sie überprüft wird.

Ready to Streamline Your Compliance?

Discover how AuditBadger can simplify your compliance management process.

Was nicht hineingehört

Der klarste Weg, dieses Dokument kurz zu halten, ist Strenge dabei, was woanders hingehört. Operative Details gehören in untergeordnete Richtlinien und Verfahren:

  • Passwortlänge und MFA-Details → Zugriffskontrollrichtlinie
  • Was Mitarbeitende auf einem Laptop installieren dürfen → Richtlinie zur zulässigen Nutzung
  • Schweregrade und Eskalationswege → Incident-Response-Plan
  • Backup-Zeitpläne und Aufbewahrungsfristen → Backup- und Kontinuitätsdokumentation
  • Wie Lieferanten bewertet werden → Lieferantensicherheitsrichtlinie

Der Grund ist nicht Ordnungsliebe. Es ist die Änderungsgeschwindigkeit. Die übergeordnete Leitlinie sollte stabil genug sein, dass die oberste Leitung sie einmal im Jahr erneut freigeben kann, ohne ein Diff zu lesen. Alles, von dem du erwartest, dass es sich quartalsweise ändert, muss an einem Ort leben, der sich quartalsweise ändern kann — ohne Managementbewertungszyklus. Wie du diesen Lebenszyklus über das ganze Set hinweg betreibst, steht unter Verwaltung interner Richtlinien.

Der Test, der sich lohnt

Gib die Leitlinie einem Gründer oder einer Führungskraft, die sie nicht geschrieben hat, warte eine Woche und bitte diese Person, zusammenzufassen, wozu sich das Unternehmen verpflichtet. Wenn das gelingt — korrekt und ohne das Dokument vor sich —, dann passt sie in dem Sinne zum Zweck der Organisation, den Abschnitt 5.2 meint. Kommt nur ein Schulterzucken, hast du eine Vorlage mit deinem Logo darauf, und ein Auditor, der genau diese Person befragt, kommt zum selben Schluss.

Das ist keine hypothetische Audittechnik. Auditoren befragen tatsächlich Mitarbeitende, und "die oberste Leitung zeigt Führung und Verpflichtung" wird auch daran gemessen, ob die Leute an der Spitze über ihre eigene Leitlinie sprechen können. Abschnitt 5 zur Führung zeigt, was sonst noch unter diese Überschrift fällt.

Kommunizieren — und nachweisen, dass du es getan hast

"Innerhalb der Organisation kommuniziert" ist eine Anforderung, und ein Auditor wird dafür Nachweise verlangen. Das Dokument auf ein gemeinsames Laufwerk zu legen, ist keine Kommunikation; das ist Verfügbarkeit. Die beiden sind in der Norm nicht ohne Grund getrennte Anforderungen.

Was als Nachweis funktioniert:

  • Bestätigungsnachweise — pro Person ein Nachweis, dass sie die aktuelle Fassung gelesen hat, mit Datum und der bestätigten Version.
  • Abdeckung im Onboarding — die Leitlinie ist Teil der Einarbeitung, mit einem Nachweis für jede neue Person.
  • Erneute Bestätigung bei wesentlichen Änderungen — wenn sich die Leitlinie inhaltlich ändert, bestätigen die Leute die neue Fassung, statt dass die alte still als "akzeptiert" stehen bleibt.
  • Verfügbarkeit für interessierte Parteien — wo angemessen, eine öffentliche Zusammenfassung oder eine Fassung, die Kunden unter NDA bekommen. Ein Trust Center ist ein üblicher Weg, das zu erfüllen, ohne interne Details zu veröffentlichen.

Versionskontrolle zählt hier mehr, als Teams erwarten. Wenn Bestätigungen nicht an eine Version gebunden sind, kannst du nicht zeigen, wer was akzeptiert hat — und der Nachweis ist keiner mehr.

Freigabe und Überprüfungsturnus

Die Leitlinie wird von der obersten Leitung freigegeben — im Startup von einem Gründer oder dem CTO, also von der Person, die tatsächlich Autorität über das ISMS hat. Eine jährliche Überprüfung ist der übliche Turnus, meist eingebettet in die Managementbewertung nach Abschnitt 9.3, dazu eine außerplanmäßige Überprüfung, wenn sich etwas Wesentliches ändert: eine neue regulatorische Pflicht, ein schwerwiegender Vorfall, eine Änderung des Anwendungsbereichs oder eine Übernahme.

Halte die Freigabe fest. Eine Leitlinie, deren Freigabehistorie aus dem "Zuletzt geändert von"-Metadatum eines Dokumenteneditors besteht, ist ein dünner Nachweis dafür, dass die oberste Leitung irgendetwas festgelegt hat.

Das Fazit

Schreib ein bis zwei Seiten, die nach deinem Unternehmen klingen, decke die vier Punkte ab, die Abschnitt 5.2 nennt, und verweise auf die untergeordneten Richtlinien, in denen die Details stehen. Und steck den Rest deiner Energie in den Teil, an dem Audits wirklich scheitern: Bestätigungen einholen, Versionen führen und in einem Turnus überprüfen, den du belegen kannst.

Als Nächstes: Abschnitt 5 in voller Länge, das Minimal-Set an Richtlinien für alles, was darunter liegt, oder der komplette Durchgang durch die Abschnitte 4–10.

Weiterlesen

Mehr Implementierungsnotizen und Operator-Kontext aus demselben Themenbereich.

Nächster Schritt

Bereit, verstreute Compliance-Arbeit abzulösen?

Sieh dir an, wie AuditBadger Richtlinien, Nachweise, Risiken und Audit-Vorbereitung in ein Betriebssystem für schlanke Teams verwandelt.

Abo starten