ISO 27001: Änderungen am ISMS geplant statt nebenbei

Ein ISMS ist kein Möbelstück, das man einmal hinstellt und dann nie wieder anfasst. Unternehmen ändern sich laufend: neue Kunden, neue Tools, neue Standorte, neue regulatorische Anforderungen, neue Prozesse, neue Verantwortlichkeiten. Anforderung 6.3 der ISO 27001 trägt genau diesem Umstand Rechnung. Die Anforderung ist kurz, aber wichtig: Änderungen am ISMS sollen geplant durchgeführt werden, damit es nach wie vor funktioniert.

Das Thema ist deshalb so praktisch, weil viele Unternehmen Änderungen zwar ständig vornehmen, aber oft nicht sauber zwischen "Wir ändern etwas in der IT" und "Wir ändern etwas am ISMS" unterscheiden. 6.3 sitzt in der Planungslogik des Managementsystems. Es geht also nicht um irgendeine beliebige Änderung, sondern um Änderungen, die das ISMS selbst betreffen oder beeinflussen - nicht ein System (dazu gibt es Anforderung A.8.32 im Anhang).

Die kurze Antwort

Abschnitt 6.3 bedeutet in der Praxis: Wenn Ihr Unternehmen merkt, dass das ISMS angepasst werden muss, dann sollte das nicht zwischen Tür und Angel und "irgendwie" passieren (jemand doktort alleine im stillen Kämmerchen vor sich hin und niemand weiß davon). Stattdessen sollte vorher klar sein, warum geändert wird, welche Folgen die Änderung haben kann, wer verantwortlich ist, welche Ressourcen gebraucht werden und wie sichergestellt wird, dass das ISMS danach immer noch zusammenpasst.

Das heißt nicht, dass jede kleine Anpassung ein Großprojekt werden muss. Aber relevante Änderungen am ISMS sollen erkennbar gesteuert werden und nicht einfach beiläufig passieren.

Worum es bei Anforderung 6.3 praktisch wirklich geht

Der Kern von 6.3 ist nicht "Veränderung vermeiden", sondern "Veränderung beherrscht durchführen". Das ISMS soll sich ja weiterentwickeln. Nur eben nicht so, dass man am Ende feststellt, dass zwar irgendwo eine neue Richtlinie geschrieben oder ein neues Tool eingeführt wurde, aber nichts passt mehr zusammen. Advisera beschreibt Clause 6.3 genau als geplante Durchführung notwendiger ISMS-Änderungen, um Integrität und Wirksamkeit des Systems zu erhalten.

Damit ist 6.3 im Grunde eine Führungsanforderung. Das Unternehmen soll relevante Änderungen nicht nur zulassen, sondern bewusst einbauen. Das passt auch sehr gut zur Management-Review-Logik in Anforderung 9.3, wonach das Management das ISMS regelmäßig daraufhin überprüft, ob es weiterhin geeignet, angemessen und wirksam ist.

Der häufigste Denkfehler

Der häufigste Denkfehler lautet: "Wir haben doch schon Change Management für unsere IT und auch ein paar Organisationsberater, die wir immer für 'Change' buchen und die dann immer viele Workshops machen, Flipboards vollschreiben und auch ansonsten sehr ganzheitlich unterwegs sind."

Technisches oder operatives Change Management ist nicht automatisch dasselbe wie Anforderung 6.3. Anhang A.8.32 behandelt ausdrücklich Änderungen an Informationsverarbeitungseinrichtungen und -systemen. Dort geht es also um Änderungen an Technik, Systemen und Facilities. Anforderung 6.3 dagegen betrifft die geplante Änderung des ISMS selbst. Das sind zwei benachbarte, aber nicht identische Themen.

Ein Firewall-Change, ein Release oder eine neue SaaS-Konfiguration kann also durchaus unter A.8.32 fallen, ohne dass damit 6.3 sauber adressiert ist, denn hier geht es darum, ob ISMS-Dokumente, Verantwortlichkeiten, Scope, Risiken, Ziele, Maßnahmen oder Prozesse angepasst werden müssen. Genau an dieser Stelle trennen sich operatives und IT-Change Management und Managementsystem-Änderung.

Typische Auslöser für Änderungen am ISMS

In der Praxis entsteht der Bedarf für 6.3 meist nicht aus Theorie, sondern aus ganz normalen Entwicklungen im Unternehmen. Typische Auslöser sind neue Kundenanforderungen, neue regulatorische Pflichten, ein neuer Standort, Wechsel zu neuen Cloud-Diensten, neue kritische Lieferanten, organisatorische Umbauten, gewachsene Teams, Erkenntnisse aus Sicherheitsvorfällen, Changen/ Verbesserungen, Audits oder Management-Reviews.

Der Punkt ist also nicht, jede Veränderung zu dramatisieren. Der Punkt ist, relevante Veränderungen zu erkennen, bevor das ISMS ihnen hinterherläuft.

Was bei der Planung der Änderung festgelegt werden sollte

Praktisch sollten bei einer relevanten Änderung am ISMS ein paar Dinge klar beantwortet werden: Was ist der Anlass der Änderung? Welchen Zweck verfolgt sie? Welche Teile des ISMS sind betroffen? Wer entscheidet und wer setzt um? Welche Ressourcen werden benötigt? Und woran erkennt man später, ob die Änderung funktioniert hat? Dies entspricht genau der Managementsystem-Planung von Änderungen: mögliche Konsequenzen, Erhalt der Systemintegrität, Ressourcen und Verantwortlichkeiten gehören auf den Tisch.

Das muss nicht in einem bürokratischen Mammutformular enden. Aber es sollte nachvollziehbar sein. Sonst hat man schnell genau das, was 6.3 vermeiden will: Änderungen mit guten Absichten, aber ohne sauberen Anschluss an den Rest des Systems.

Nicht jede kleine Änderung braucht eine große Bühne

Anforderung 6.3 fordert geplante Änderungen am ISMS, aber nicht zwangsläufig ein schweres Verfahren für jede Kleinigkeit. Es ist deshalb sinnvoll, zwischen kleinen operativen Anpassungen und wirklich relevanten ISMS-Änderungen zu unterscheiden. Es geht vor allem um wesentliche Änderungen, die das Managementsystem spürbar betreffen.

Ein guter Maßstab lautet: Würde diese Änderung Einfluss auf Scope, Risiken, Ziele, Rollen, zentrale Prozesse, dokumentierte Informationen oder wesentliche Kontrollen haben? Wenn ja, sollte sie bewusst geplant werden. Wenn nein, reicht oft das normale operative Vorgehen.

Management Review ist hier ein guter Anker

Größere oder strategisch relevante Änderungen gehören nicht nur in irgendein Arbeitspaket, sondern oft auch ins Management Review. 9.3 verlangt regelmäßige Überprüfungen des ISMS durch das Management, damit es weiterhin geeignet, angemessen und wirksam bleibt. Genau dort ist ein sinnvoller Ort, um geplante größere Änderungen zu diskutieren, nachzuschärfen, freizugeben oder Ressourcen nachzulegen.

Das ist auch deshalb klug, weil man dort nicht nur über die Änderung selbst spricht, sondern über deren Wirkung auf das Gesamtsystem. Und genau das ist ja der Kern von 6.3.

Was will der Auditor sehen?

Ein Auditor will hier meist keinen Roman über Veränderungskultur lesen. Er will sehen, dass relevante Änderungen am ISMS nicht zufällig passieren. Also zum Beispiel: Es gab einen Auslöser, die Änderung wurde geplant, Verantwortliche und Ressourcen waren klar, betroffene Dokumente oder Prozesse wurden angepasst und es ist erkennbar, dass die Änderung nicht die innere Logik des ISMS zerstört hat. Genau das ist die Prüflogik in 6.3.

Als Nachweise helfen dafür oft schon recht einfache Dinge: Management-Review-Protokolle, , aktualisierte Richtlinien, geänderte Rollenbeschreibungen, angepasste Risiko- oder Maßnahmenpläne, Projektunterlagen zu relevanten ISMS-Änderungen oder ein schlanker Change-Log für wesentliche Managementsystem-Anpassungen. Es gibt kein bestimmtes Pflichtdokument für 6.3 - aber für Änderungen sind Tickets immer großartig, gerade weil hier auch der Workflow zeigt, wie der Change von "geplant", über "genehmigt", "in Artbeit", "in Überprüfung" bis hin zu "fertig" verlaufen ist.

FAQ

Interesse geweckt?

Wenn Sie Änderungen am ISMS im Rahmen einer ISO 27001-Einführung sauber planen und steuern wollen, sprechen Sie mit uns oder schreiben uns etwas gleich hier rechts unten auf der Seite in den Chat!