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.
FAQ
Nein. Die Kommunikationsanforderung bezieht sich auf interne und externe Kommunikation rund um das ISMS insgesamt. Sicherheitsvorfälle sind ein wichtiger Teil davon, aber nicht der einzige. Auch Richtlinien, Ziele, Auditergebnisse, Änderungen, Awareness und Rückmeldungen gehören dazu.
Nein. Die Norm verlangt Klarheit über Kommunikationsbedarf, aber kein bestimmtes Darstellungsformat. Eine prozessorientierte Regelung in Richtlinien und Abläufen ist oft sinnvoller als eine überladene Universal-Matrix.
Mindestens sollte klar sein, wer intern eskaliert, wer mit Kunden spricht, wer mit Behörden spricht, wer gegenüber der Presse sprechen darf, welche Freigaben gelten und wie externe Kontakte dokumentiert werden.
Ja. Gute Kommunikation ist keine Einbahnstraße. Die ISO/IAF-Arbeitshilfe nennt Feedback-Mechanismen ausdrücklich als Bestandteil sinnvoller Kommunikation. Für ein ISMS ist das wichtig, damit Hinweise, Beschwerden und Verbesserungsimpulse nicht versanden.
Ja. Bei Datenschutzverletzungen können Melde- und Benachrichtigungspflichten nach der DSGVO greifen. Für NIS2-relevante Unternehmen gibt es zusätzlich gestufte Meldepflichten bei erheblichen Vorfällen.
Zu glauben, dass ein ISO-27001-Projekt im Grunde von einer Person "mitgemacht" werden kann. Genau daran scheitern Projekte oft unnötig, weil Führung, Ressourcen und Mitwirkung fehlen.
Unser Tipp
Machen Sie Kommunikation nicht unnötig kunstvoll. Regeln Sie lieber in den passenden Richtlinien und Prozessen, wer in welchen Situationen worüber mit wem spricht. Wenn Sie dazu noch eine kleine Übersicht bauen, wo diese Regeln jeweils stehen, haben Sie meistens genau die richtige Mischung aus Praxistauglichkeit und Auditfreundlichkeit.
Interesse geweckt?
Wenn Sie Kommunikation im Rahmen einer ISO 27001-Einführung sauber regeln wollen, lassen Sie uns sprechen oder schreiben uns etwas gleich hier rechts unten auf der Seite in den Chat!