ISO 27001: Kommunikation sauber regeln
Ein ISMS funktioniert nicht, wenn alle einfach davon ausgehen, dass „man schon irgendwie miteinander reden wird, wenn's nötig ist“.
Dann werden Dinge zu spät, doppelt, widersprüchlich oder an die falschen Leute kommuniziert. Genau deshalb gibt es in ISO 27001 eine eigene Anforderung zur Kommunikation.
Das Thema ist dabei viel breiter als reine Krisenkommunikation. Natürlich spielt die Kommunikation im Sicherheitsvorfall eine wichtige Rolle. Aber Abschnitt 7.4 meint genauso den laufenden Betrieb: Richtlinien, Änderungen, Ziele, Risiken, Auditergebnisse, Verbesserungen, Awareness, Lieferantenanforderungen und vieles mehr. Schlechte Kommunikation ist oft ein Grund dafür, dass Managementsysteme nicht sauber funktionieren. Kommunikation soll sinnvoll, rechtzeitig und fortlaufend sein, einen Rückkopplungsmechanismus enthalten und auf die Empfänger zugeschnitten werden.
Die kurze Antwort
Abschnitt 7.4 verlangt nicht, dass Sie eine riesige Kommunikationsmatrix bauen, in der alle internen und externen Rollen gegeneinander gekreuzt werden. Das wäre oft künstlich. Denn Kommunikation ist fast nie nur zweidimensional. Sie hängt immer auch am Anlass und am Inhalt. Genau deshalb ist es in vielen Unternehmen sinnvoller, auf Richtlinienebene und in den betroffenen Prozessen festzuhalten, wer in welchen Situationen worüber mit wem spricht. Die Norm verlangt Klarheit über Kommunikation. Sie verlangt nicht zwingend eine einzige 3x3 m große Master-Tabelle.
Das ist auch aus Auditsicht kein Fehler. Die ISO/IAF-Arbeitshilfe zur Kommunikation weist ausdrücklich darauf hin, dass eine allzu einfache Ja/Nein-Betrachtung oft nicht ausreicht und dass die Wirksamkeit von Kommunikation meist nicht aus einer einzigen Quelle beurteilt werden kann. Genau deshalb darf eine praxistaugliche Regelung über mehrere passende Dokumente und Prozesse verteilt sein, solange sie konsistent und auffindbar ist.
Worum es bei Abschnitt 7.4 praktisch wirklich geht
Praktisch geht es um eine einfache Frage: Wer spricht in welcher Situation worüber mit wem? Und zwar nicht erst dann, wenn es brennt, sondern schon im normalen Betrieb. Wenn neue Regeln gelten, Ziele geändert werden, Risiken eskalieren, Maßnahmen festhängen oder Lieferanten Sicherheitsanforderungen bekommen, dann muss klar sein, wie diese Informationen an die richtigen Stellen kommen. Genau dafür ist die Kommunikationsanforderung da.
Wichtig ist dabei auch die Gegenrichtung. Gute Kommunikation im ISMS bedeutet nicht nur, dass Informationen rausgeschickt werden. Es muss auch klar sein, wie Rückmeldungen wieder zurück ins System kommen: Feedback ist Teil sinnvoller Kommunikation. Das ist für ein ISMS hochpraktisch: Hinweise von Mitarbeitern, Rückfragen von Kunden, Eskalationen aus Projekten oder Beschwerden zu Sicherheitsabläufen müssen irgendwo ankommen, bewertet und weiterverarbeitet werden.
Kommunikation im laufenden Betrieb
Im Alltag geht es oft um deutlich bodenständigere Dinge als um Sicherheitsvorfälle. Mitarbeiter müssen Richtlinien und Verhaltensregeln kennen. Neue Kollegen müssen beim Onboarding verstehen, wie Informationssicherheit im Unternehmen funktioniert. Verantwortliche müssen über Ziele, Fortschritte, Änderungen und offene Maßnahmen informiert werden. Ergebnisse aus internen Audits oder Management Reviews müssen an die richtigen Stellen zurückgespielt werden. Die ISO/IAF-Arbeitshilfe nennt als typische Kommunikationsformen unter anderem E-Mail, Intranet, Meetings, Team-Briefings, Schulungen und dokumentierte Besprechungsergebnisse.
Gerade deshalb ist ein prozessorientierter Ansatz oft besser als eine allumfassende Tabelle. In der Awareness-Richtlinie kann stehen, wie Mitarbeiter informiert werden. Im Management-Review-Prozess kann geregelt sein, wie Status und Entscheidungen an die oberste Leitung gehen. Im Lieferantenprozess kann stehen, wer Sicherheitsanforderungen an externe Dienstleister kommuniziert. Und in Incident-Prozessen kann geregelt sein, wer wann nach außen spricht. So bleibt die Kommunikation dort geregelt, wo sie im Alltag tatsächlich gebraucht wird.
Sicherheitsvorfälle: vorher festlegen, nicht im Chaos improvisieren
Bei Sicherheitsvorfällen wird Kommunikation besonders schnell hektisch. Wer spricht mit betroffenen Kunden? Wer mit Behörden? Über wen werden die Mitarbeiter ins Boot geholt? Wer gibt eine Aussage gegenüber der Presse frei? Und wer darf technisch ins Detail gehen (und wer besser nicht)? Genau solche Fragen sollte man nicht erst beantworten, wenn der Vorfall schon läuft. NIST betont, dass Incident Response auch incident reporting, notification and other incident-related communications umfasst - und außerdem, dass vorab Richtlinien und Verfahren für den Austausch mit externen Stellen festzulegen sind.
NIST geht hier erfreulich praktisch vor: Organisationen sollten sich schon vor einem Vorfall mit Rechtsabteilung, Management und gegebenenfalls Kommunikationsverantwortlichen abstimmen. In den NIST-Leitlinien werden Medien, Strafverfolgungsbehörden und Meldestellen als typische externe Kommunikationspartner genannt. Für den Umgang mit den Medien empfiehlt NIST sogar, einen zentralen Ansprechpartner und mindestens eine Vertretung festzulegen.
Genau daraus ergibt sich für die Praxis ein sehr brauchbarer Ansatz: Nicht eine allgemeine Kommunikationsmatrix bauen, sondern im Incident-Prozess sauber festhalten, wer intern eskaliert, wer nach außen spricht, welche Freigaben es gibt, welche Informationen dokumentiert werden und in welchem Takt Updates erfolgen. Das hilft dem Unternehmen deutlich mehr als eine schöne Übersicht, die im Ernstfall niemand benutzt.
Der häufigste Denkfehler
Der häufigste Denkfehler lautet: „Kommunikation heißt, dass wir irgendwo eine große Tabelle malen.“
Eine solche Tabelle kann als Übersicht nützlich sein. Aber sie löst das eigentliche Problem nicht automatisch. Kommunikation wird erst dann belastbar, wenn sie in den passenden Regeln und Prozessen verankert ist. Die ISO/IAF-Arbeitshilfe warnt genau vor zu simplen Ansätzen und betont, dass Kommunikationswirksamkeit nicht aus einem einzelnen Häkchen-Schema ablesbar ist.
Kommunikation ist manchmal nicht nur sinnvoll, sondern Pflicht
Je nach Unternehmen gibt es Kommunikationspflichten, die nicht freiwillig sind. Bei Datenschutzverletzungen müssen Unternehmen unter der DSGVO die zuständige Aufsichtsbehörde informieren und in schwerwiegenden Fällen auch betroffene Personen benachrichtigen.
Für NIS2-relevante Unternehmen gibt es ebenfalls gestufte Meldepflichten. Auch wenn das nicht jedes Unternehmen betrifft, zeigt es sehr deutlich: Kommunikation ist in manchen Fällen nicht nur Organisationsfrage, sondern Rechtsfrage.
Was will der Auditor sehen?
Der Auditor hätte es natürlich gern auf einen Blick. Das Unternehmen braucht es aber funktionsfähig. Deshalb sucht ein guter Auditor hier nicht zwingend eine einzige große Kommunikationsmatrix, sondern nachvollziehbare Regelungen dazu, worüber, wann, mit wem und wie kommuniziert wird. Wenn diese Regeln in Richtlinien, Prozessen, Incident-Plänen, Lieferantenregelungen oder Review-Abläufen sauber verankert sind, ist das völlig in Ordnung.
Hilfreich ist trotzdem, wenn es eine kleine Übersichtsseite gibt, auf der steht, wo die relevanten Kommunikationsregeln geregelt sind. Das macht das System auditfreundlicher, ohne künstlich alles in ein einziges Dokument zu pressen.
Kommunikation beginnt beim Anlass
Eine Kommunikationsmatrix mit den Spalten wer, was, wann und an wen kann nützlich sein. Sie wird aber schnell zum Wandteppich, wenn jede denkbare Kombination eingetragen wird. Praktischer ist häufig, Kommunikation dort zu regeln, wo sie ausgelöst wird.
Im Incident-Prozess steht, wer bei einem Sicherheitsvorfall intern und extern informiert. Im Lieferantenprozess steht, wer Anforderungen und Änderungen an Dienstleister übermittelt. Im Auditprozess steht, wer Ergebnisse erhält und Maßnahmen übernimmt. Und bei Richtlinien ist klar, welche Mitarbeiter die neue Vorgabe kennen und verstehen müssen.
Senden ist nur die halbe Kommunikation
Eine E-Mail im Postausgang beweist, dass etwas versendet wurde. Sie beweist nicht, dass der Empfänger die Information verstanden hat oder sinnvoll reagieren konnte. Je nach Bedeutung braucht Kommunikation deshalb einen Rückkanal: Rückfragen, Bestätigung, Übung, Freigabe oder eine erkennbare Handlung.
Das wird bei Awareness besonders deutlich. Eine Schulung kann durchgeführt sein und trotzdem am Alltag vorbeigehen. Ebenso muss die Informationssicherheitspolitik nicht nur verteilt, sondern in ihrer Bedeutung verstanden werden.
Intern und extern unterscheiden
Intern geht es beispielsweise um Regeln, Risiken, Ziele, Änderungen, Vorfälle und Auditergebnisse. Extern können Kunden, Behörden, Zertifizierer, Dienstleister, Versicherer oder die Öffentlichkeit betroffen sein. Wer wann sprechen darf, muss besonders in hektischen Situationen vorher geklärt sein.
Das verbindet Kommunikation mit dem Incident Management, dem Management Review, den rechtlichen und vertraglichen Anforderungen und der Frage, wie man in Audits gute Fragen stellt.
Was will der Auditor sehen?
Der Auditor braucht nicht zwingend die eine große Kommunikationsmatrix. Er möchte nachvollziehen, dass relevante Kommunikationsanlässe geregelt sind: Inhalt, Zeitpunkt, Empfänger, Verantwortlicher und geeigneter Kanal.
Danach prüft er Beispiele. Wie wurde eine neue Richtlinie bekannt gemacht? Wer erfuhr von einem kritischen Lieferantenproblem? Wie kamen Auditergebnisse zu den Maßnahmenverantwortlichen? Was geschieht, wenn ein Mitarbeiter eine Sicherheitsbeobachtung meldet?
Gute Kommunikation hinterlässt nicht nur versendete Nachrichten, sondern passende Reaktionen.
Interesse geweckt?
Sie möchten das Thema in Ihrem Unternehmen sauber und pragmatisch angehen? Sprechen Sie mit uns.
Häufig gestellte Fragen
Geht es in Abschnitt 7.4 nur um Kommunikation im Sicherheitsvorfall?
Müssen wir dafür eine große Kommunikationsmatrix bauen?
Was sollte bei einem Sicherheitsvorfall kommunikativ vorab geregelt sein?
Müssen Rückmeldungen auch Teil der Kommunikation sein?
Kann Kommunikation rechtlich verpflichtend sein?
Was ist der häufigste Fehler?
Dieser Artikel gehört zum Thema ISO 27001 Zertifizierung — erfahren Sie mehr über die Zertifizierung.