ISMS-Kommunikation: Pragmatische Umsetzung von ISO 27001 Kapitel 7.4

ISO 27001 Kapitel 7.4 verlangt von Organisationen, die Kommunikation rund um ihr ISMS zu regeln. Die Anforderung lässt sich auf fünf konkrete Fragen herunterbrechen:

1. Was soll kommuniziert werden?
2. Wann soll kommuniziert werden?
3. Wer ist für die Kommunikation verantwortlich?
4. An wen richtet sich die Kommunikation?
5. Über welche Kanäle erfolgt die Kommunikation?

Viele Organisationen neigen dazu, diese Anforderungen durch umfangreiche Richtliniendokumente zu erfüllen. Das führt häufig zu Texten, die niemand liest und die bei der ersten Personaländerung veraltet sind.

Eine ISMS-Kommunikationsmatrix als zentrales Werkzeug

Ein effektiverer Ansatz ist die Erstellung einer Kommunikationsmatrix. Diese Tabelle beantwortet die fünf Fragen der Norm in einem übersichtlichen Format:

Diese Matrix lässt sich als eigenständiges Dokument führen oder als Abschnitt in das ISMS-Handbuch integrieren.

Abgrenzung zu Incident- und Krisenmanagement

Die Kommunikationsmatrix aus Kapitel 7.4 regelt die alltägliche ISMS-Kommunikation. Sie ist nicht dafür gedacht, die Kommunikationsanforderungen bei Sicherheitsvorfällen oder Krisensituationen vollständig abzudecken. Diese müssen separat erarbeitet werden. Ob sie in eigenständigen Dokumenten geführt oder in die Kommunikationsmatrix integriert werden, hängt von der Größe und Komplexität der Organisation ab.

Grundprinzipien für die praktische Umsetzung

Rollen statt Namen verwenden

Dokumentieren Sie Verantwortlichkeiten anhand von Funktionsbezeichnungen wie "Leiter IT-Sicherheit" oder "Datenschutzbeauftragter". Personennamen in der Dokumentation erfordern bei jedem Personalwechsel eine Aktualisierung. Eine separate Zuordnungsliste von Rolle zu Person kann außerhalb des ISMS-Dokumentationsrahmens gepflegt werden.

Bestehende Strukturen nutzen

Sicherheitskommunikation benötigt keine eigenen Meeting-Formate. Integrieren Sie ISMS-Themen als festen Punkt in existierende Besprechungen: das monatliche Abteilungsleiter-Meeting, das Quartals-Review der Geschäftsführung oder die regelmäßige IT-Runde. Dies erhöht die Akzeptanz und reduziert den organisatorischen Aufwand.

Push und Pull unterscheiden

Nicht jede Information erfordert eine aktive Benachrichtigung. Unterscheiden Sie zwischen Push-Kommunikation (aktives Senden, z.B. Warnung vor einer laufenden Phishing-Welle) und Pull-Kommunikation (Bereitstellung zur Selbstabholung, z.B. Richtlinien im Intranet). Eine inflationäre Nutzung von Push-Nachrichten führt dazu, dass kritische Warnungen in der Masse untergehen.

Die oft vergessene sechste Spalte: Der Nachweis

Die ISO 27002 betont einen Aspekt, der in vielen Implementierungen zu kurz kommt: die Sicherstellung, dass Kommunikation tatsächlich angekommen und verstanden wurde.

Für unkritische Informationen wie allgemeine Richtlinienaktualisierungen reicht die Veröffentlichung im Intranet. Bei sicherheitsrelevanten Themen sollte jedoch dokumentiert werden, dass die Zielgruppe die Information erhalten hat. Möglichkeiten hierfür sind:

• Lesebestätigungen bei E-Mails

• Abschlussbestätigungen in E-Learning-Modulen

• Protokollierung in Meetings

• Unterschriftenlisten bei besonders kritischen Änderungen

Diese Nachweise sind nicht nur für Audits relevant, sondern schützen die Organisation auch rechtlich.

Dokumentationsumfang

ISO 27001 schreibt für Kapitel 7.4 keine spezifische dokumentierte Information vor. Die Norm überlässt es der Organisation zu bestimmen, welche Dokumentation für die Wirksamkeit des ISMS erforderlich ist. In der Praxis hat sich gezeigt, dass eine gepflegte Kommunikationsmatrix mit 15 bis 25 Zeilen für die viele Organisationen ausreichend ist. Sie sollte mindestens jährlich im Rahmen des Management Reviews auf Aktualität geprüft werden.

🥜 In A Nutshell

Die Anforderungen aus ISO 27001 Kapitel 7.4 lassen sich ohne aufwendige Richtliniendokumente erfüllen. Eine strukturierte Kommunikationsmatrix, die konsequent Rollen statt Namen verwendet und in bestehende Organisationsstrukturen eingebettet ist, deckt die Normforderungen ab und bleibt wartbar. Für Incident- und Krisenszenarien sind die Kommunikationsanforderungen separat zu erarbeiten.