ISO 27001: Änderungen am ISMS richtig planen

Plötzlich ist das Risikoregister erfreulich grün. Nicht, weil jemand Risiken behandelt hätte. Auch nicht, weil neue Schutzmaßnahmen eingeführt wurden. Jemand hat einfach die Schwellenwerte verändert, ab denen ein Risiko als nicht mehr akzeptabel gilt.

„Das war doch nur eine kleine Anpassung an der Methode.“

Nur hat diese kleine Anpassung auf einen Schlag verändert, welche Risiken behandelt werden müssen, welche Maßnahmen Geld und Zeit bekommen und welches Bild die Geschäftsführung von der Informationssicherheit sieht. Beschlossen hat das niemand so richtig. Die zugehörige Richtlinie wurde nicht aktualisiert. Und warum die Grenzwerte jetzt anders sind, weiß drei Monate später auch keiner mehr.

Genau für solche Fälle gibt es Abschnitt 6.3 der ISO 27001. Wenn Änderungen am Informationssicherheitsmanagementsystem – kurz ISMS – notwendig werden, sollen sie geplant durchgeführt werden.

Abschnitt 6.3 verlangt keinen Passierschein A38 für jede Änderung. Er verlangt, dass Sie Ihr ISMS nicht versehentlich beim Herumbasteln umbauen.

Was verlangt ISO 27001 Abschnitt 6.3?

Die Anforderung ist ausgesprochen kurz: Stellt das Unternehmen fest, dass das ISMS geändert werden muss, ist diese Änderung geplant durchzuführen.

Das klingt zunächst nach einer jener Normforderungen, die sich mit einem Satz abhaken lassen. Praktisch steckt darin aber eine vernünftige Frage: Haben Sie vor der Änderung darüber nachgedacht, was Sie damit auslösen?

Eine geplante Änderung hat mindestens einen erkennbaren Zweck, einen Verantwortlichen und einen Blick auf die Folgen. Je größer und riskanter die Änderung ist, desto gründlicher sollte dieser Blick ausfallen. Eine Korrektur eines Tippfehlers braucht kein Change Advisory Board. Eine neue Methode zur Bewertung von Informationssicherheitsrisiken sollten Sie dagegen nicht zwischen zwei Videokonferenzen in einer Excel-Formel verstecken.

Was ist das überhaupt: eine Änderung am ISMS?

Viele denken bei „Änderungsmanagement“ zuerst an Software-Releases, Serverkonfigurationen oder neue Firewalls. Das ist nachvollziehbar, trifft Abschnitt 6.3 aber nur teilweise. Dort geht es um Änderungen am Managementsystem selbst.

Dazu gehören beispielsweise:

• ein veränderter Anwendungsbereich des ISMS;
• ein neuer Standort oder der Wegfall eines bisherigen Standorts;
• eine Umstrukturierung des Unternehmens;
• neue Rollen, Zuständigkeiten oder Berichtslinien;
• die erstmalige Bestellung oder ein Wechsel des Informationssicherheitsbeauftragten;
• eine neue Risikomethode oder andere Risikoakzeptanzkriterien;
• ein neues ISMS- oder GRC-Werkzeug;
• grundlegende Änderungen an Prozessen oder am Liefermodell;
• der Zukauf oder die Integration eines Unternehmens;
• größere Änderungen an Zielen, Richtlinien oder dem Maßnahmenportfolio.

Auch Veränderungen außerhalb des ISMS können also eine Änderung des ISMS notwendig machen. Wer einen Standort eröffnet, eine Abteilung ausgliedert oder ein neues Geschäftsmodell startet, verändert nicht automatisch nur das Organigramm. Plötzlich können andere interessierte Parteien, Risiken, Assets, Lieferanten, Kompetenzen oder Sicherheitsanforderungen relevant sein.

Deshalb lohnt sich bei größeren Vorhaben früh die Frage: „Muss sich wegen dieser Veränderung auch unser ISMS verändern?“ Wie Informationssicherheit rechtzeitig in Vorhaben einbezogen wird, beschreiben wir ausführlicher im Artikel Informationssicherheit in Projekten.

„Geplant“ bedeutet nicht: für jeden Tippfehler ein Projekt eröffnen

Normtexte verleiten manche Unternehmen dazu, für eine kleine Änderung ein Formular mit zwölf Unterschriften zu erfinden. Damit ist niemandem geholfen. Die Planung muss zur Bedeutung und zum Risiko der Änderung passen.

Eine Schreibfehlerkorrektur in einer Richtlinie kann mit einer neuen Version, einer kurzen Begründung und der vorgesehenen Freigabe erledigt sein. Wenn dagegen die gesamte Verteilung von Rollen, Verantwortlichkeiten und Befugnissen umgebaut wird, sollten Sie etwas genauer hinschauen. Sonst gibt es am Ende zwei Verantwortliche für die angenehmen Aufgaben und keinen für die unangenehmen.

Ein brauchbarer Grundsatz lautet:

Je stärker eine Änderung Risiken, Verantwortlichkeiten, Prozesse, Ressourcen oder Nachweise beeinflusst, desto gründlicher muss sie geplant werden.

Das ist risikobasiertes Denken und kein Bürokratiewettbewerb.

Sieben Fragen für eine sauber geplante Änderung

Für die meisten Änderungen brauchen Sie keine wissenschaftliche Abhandlung. Häufig reicht ein Ticket, ein Protokoll oder eine halbe Seite, auf der sieben Fragen nachvollziehbar beantwortet werden.

1. Warum ändern wir etwas – und was soll danach besser sein?

Eine Änderung sollte einen Zweck haben. Vielleicht hat ein Internes Audit eine Schwäche gezeigt. Vielleicht hat sich das Unternehmen verändert. Vielleicht funktioniert eine bisherige Regel schlicht nicht.

Ohne klares Ziel lässt sich später kaum bewerten, ob die Änderung funktioniert hat. „Wir wollten das mal moderner machen“ ist ein Anlass für ein Gespräch, aber noch kein besonders brauchbares Ergebnis.

2. Was ist von der Änderung betroffen?

Eine Änderung an einer Stelle zieht häufig weitere Änderungen nach sich. Neue Risikoakzeptanzkriterien betreffen nicht nur die Risikorichtlinie. Sie können vorhandene Bewertungen, Behandlungspläne, Freigaben und Berichte an die Geschäftsführung verändern.

Fragen Sie deshalb nach Abhängigkeiten: Welche Prozesse, Rollen, Dokumente, Systeme, Lieferanten, Standorte und Ziele hängen daran? Müssen auch die Informationssicherheitsziele angepasst werden?

3. Welche Risiken und Nebenwirkungen entstehen?

Änderungen sollen Probleme lösen und können neue erzeugen. Ein neues ISMS-Tool erleichtert vielleicht die Nachverfolgung von Maßnahmen, schafft aber auch einen neuen Dienstleister, neue Zugriffsrechte, eine Datenmigration und eine neue Abhängigkeit.

Sie müssen nicht für jede Kleinigkeit eine vollständige Risikobewertung veranstalten. Aber Sie sollten erkennen, wenn eine Änderung sicherheitsrelevante Nebenwirkungen haben kann – und diese dann angemessen behandeln.

4. Wer entscheidet und wer setzt um?

„Das macht das ISMS-Team“ klingt nur so lange klar, bis drei Personen im Team sitzen und jede davon glaubt, eine der anderen sei gemeint.

Legen Sie fest, wer die Änderung verantwortet, wer sie umsetzt und wer sie freigibt. Bei bedeutenden Änderungen gehört außerdem geklärt, ob die Geschäftsführung entscheiden oder Ressourcen bereitstellen muss. Ein ISMS verändert sich nicht zuverlässig durch kollektives Hoffen.

5. Welche Ressourcen und Termine sind notwendig?

Eine Änderung ohne Zeit, Zuständigkeit und nötige Fähigkeiten ist keine Planung. Sie ist eine freundliche Absichtserklärung.

Prüfen Sie deshalb, ob Personal, Budget, Werkzeuge und Kompetenzen vorhanden sind. Wenn nicht, muss entschieden werden: Ressourcen schaffen, Umfang verändern, Termin verschieben oder die Änderung anders lösen.

6. Wer muss informiert oder beteiligt werden?

Eine neue Regel, die nur der Autor kennt, ist noch keine wirksame Änderung. Betroffene Personen müssen wissen, was sich für sie ändert. Gegebenenfalls brauchen sie eine Einweisung oder Schulung. Bei externen Partnern können Verträge, Leistungsbeschreibungen oder Kommunikationswege betroffen sein.

Das gilt besonders dann, wenn die Änderung Verantwortlichkeiten verschiebt. Der beste neue Prozess hilft wenig, wenn die Mitarbeiter weiterhin nach der alten Aufgabenverteilung arbeiten.

7. Woran erkennen wir, dass die Änderung funktioniert?

Planen Sie schon vor der Umsetzung, wie die Wirkung geprüft wird. Das kann eine Stichprobe, eine Kennzahl, ein Review nach vier Wochen oder ein späteres Internes Audit sein.

Sonst endet der Change mit dem Status „erledigt“, sobald das neue Dokument hochgeladen wurde. Ob jemand danach arbeitet und ob das ursprüngliche Problem verschwunden ist, bleibt dann eine Glaubensfrage.

Wie hängen Abschnitt 6.3 und Dokumentenlenkung nach 7.5 zusammen?

Abschnitt 6.3 regelt, dass notwendige Änderungen am ISMS geplant durchgeführt werden. Abschnitt 7.5 regelt, wie die dabei betroffenen dokumentierten Informationen erstellt, aktualisiert und beherrscht werden.

Wenn Sie beispielsweise die Risikomethode ändern, betrifft das meist Richtlinien, Vorlagen, Risikoregister, Schulungsunterlagen und möglicherweise Managementberichte. Dann müssen Sie unter anderem klären:

• Welche Dokumente werden geändert?
• Wer prüft und genehmigt die neue Fassung?
• Wie wird die Version eindeutig erkennbar?
• Wo steht die gültige Fassung bereit?
• Wie verhindern Sie die weitere Nutzung alter Fassungen?
• Wie bleibt die Änderung nachvollziehbar?

Die Einzelheiten dazu finden Sie in unserem Beitrag ISO 27001 Dokumentenlenkung: Was verlangt Abschnitt 7.5?.

Wichtig ist die Reihenfolge: Eine perfekt versionierte Fehlentscheidung bleibt eine Fehlentscheidung. Dokumentenlenkung ersetzt nicht die inhaltliche Planung der Änderung. Sie sorgt aber dafür, dass die beschlossene Änderung kontrolliert in den dokumentierten Informationen ankommt.

Abschnitt 6.3 ist nicht dasselbe wie A.8.32

In Anhang A gibt es mit A.8.32 ebenfalls eine Anforderung zum Änderungsmanagement. Beide Anforderungen sind verwandt, haben aber unterschiedliche Schwerpunkte.

Abschnitt 6.3 bezieht sich auf Änderungen am ISMS als Managementsystem. Dazu zählen etwa Änderungen am Scope, an Methoden, Rollen, Prozessen oder der Steuerung des ISMS.

A.8.32 richtet den Blick auf Änderungen an informationsverarbeitenden Einrichtungen und Informationssystemen. Hier geht es typischerweise um technische und operative Changes: neue Releases, Konfigurationsänderungen, Infrastrukturumbauten, Migrationen oder Änderungen an produktiven Systemen.

Eine Veränderung kann beide Anforderungen berühren. Wenn ein Unternehmen ein neues zentrales Identitätsmanagement einführt, ist das zunächst ein technischer und organisatorischer Change. Ändern sich dadurch aber zugleich die eigenen Verfahren, Rollen, Nachweise oder Risikobehandlungen im ISMS, kommt auch Abschnitt 6.3 ins Spiel.

Die richtige Frage ist daher nicht: „Welchen der beiden Abschnitte nehmen wir?“ Sondern: „Welche Arten von Änderung liegen hier vor – und was müssen wir jeweils beherrschen?“

Was will der Auditor sehen?

Ein Auditor wird normalerweise nicht verlangen, dass jede minimale Textänderung durch ein monumentales Change-Verfahren gelaufen ist. Er wird aber bei bedeutenden Veränderungen nachvollziehen wollen, ob das Unternehmen bewusst und geplant gehandelt hat.

Typische Fragen sind:

• Welche wesentlichen Änderungen gab es seit dem letzten Audit?
• Woran haben Sie erkannt, dass das ISMS angepasst werden musste?
• Welche Auswirkungen und Abhängigkeiten wurden betrachtet?
• Wer hat entschieden, umgesetzt und freigegeben?
• Welche dokumentierten Informationen wurden angepasst?
• Wie wurden betroffene Personen informiert?
• Wie haben Sie geprüft, ob die Änderung wirksam ist?

Gute Nachweise können Tickets, Protokolle, Freigaben, aktualisierte Dokumente, Risikobetrachtungen oder Wirksamkeitsprüfungen sein. Entscheidend ist nicht das Dateiformat. Entscheidend ist, ob der rote Faden erkennbar ist.

Spätestens im Management Review sollte die Leitung außerdem ein belastbares Bild davon bekommen, ob wesentliche Veränderungen das ISMS beeinflussen und ob Handlungsbedarf besteht.

Ein schlankes Verfahren reicht – wenn es benutzt wird

Für ein kleineres Unternehmen kann ein einziges Change-Ticket genügen. Darin stehen Anlass, Ziel, Betroffenheit, Risiken, Verantwortliche, Termin, notwendige Dokumentenänderungen und die spätere Wirksamkeitsprüfung. Größere oder stark regulierte Unternehmen werden dafür oft abgestufte Verfahren nutzen.

Beides kann angemessen sein. Unangemessen ist vor allem ein Verfahren, das auf dem Papier prächtig aussieht und bei realen Änderungen regelmäßig umgangen wird.

Wer ohnehin Projekte sauber plant, Verantwortlichkeiten klärt und Dokumente lenkt, hat schon viel von Abschnitt 6.3 erledigt. Der zusätzliche Gedanke lautet lediglich: Prüfen wir bei Veränderungen bewusst, was sie mit unserem ISMS machen?

Dann bleibt das Risikoregister vielleicht nicht immer schön grün. Dafür bildet es weiterhin die Wirklichkeit ab – und nicht nur die neue Lieblingsfarbe seiner Excel-Zellen.

Interesse geweckt?

Sie möchten das Thema in Ihrem Unternehmen sauber und pragmatisch angehen? Sprechen Sie mit uns.