ISO 27001 Prozesse planen und steuern: Was verlangt Anforderung 8.1?

In manchen Unternehmen gibt es einen ausgesprochen wichtigen Prozess. Er hat keinen Namen, keine Beschreibung und keinen festgelegten Ablauf. Er befindet sich vollständig im Kopf von Sabine.

Wenn jemand nicht weiterweiß, wird Sabine gefragt. Wenn eine ungewöhnliche Situation auftritt, entscheidet Sabine. Und wenn Sabine im Urlaub ist, entsteht aus dem vermeintlich geregelten Ablauf ziemlich schnell gemeinschaftliches Improvisationstheater.

Solange Sabine da ist, sieht das nach einem funktionierenden Prozess aus. Tatsächlich funktioniert aber vor allem Sabine.

Abschnitt 8.1 der ISO 27001 setzt genau an dieser Stelle an. Sicherheitsrelevante Tätigkeiten sollen nicht nur irgendwie stattfinden. Die notwendigen Prozesse müssen geplant, verwirklicht und gesteuert werden. Außerdem muss das, was zuvor in Abschnitt 6 geplant wurde, tatsächlich umgesetzt werden.

Die kurze Antwort

Abschnitt 8.1 der ISO 27001 enthält im Wesentlichen zwei Arbeitsaufträge:

1. Sie müssen die Prozesse planen, umsetzen und steuern, die zur Erfüllung der Anforderungen an Ihr ISMS notwendig sind.
2. Sie müssen die in Abschnitt 6 festgelegten Maßnahmen tatsächlich durchführen – insbesondere zur Behandlung von Risiken und Chancen, zur Risikobehandlung, zur Erreichung von Informationssicherheitszielen und zu geplanten Änderungen am ISMS.

Dafür sollen geeignete Kriterien für die Prozesse festgelegt und die Prozesse entsprechend gesteuert werden. Dokumentierte Information muss in dem Umfang verfügbar sein, der notwendig ist, damit man darauf vertrauen kann, dass die Abläufe wie geplant durchgeführt wurden.

Hinzu kommen der kontrollierte Umgang mit Änderungen und die Steuerung extern bereitgestellter Prozesse, Produkte und Dienstleistungen, soweit diese für das ISMS relevant sind.

Das klingt abstrakt. Praktisch geht es um eine sehr bodenständige Frage: Können Sie sich darauf verlassen, dass sicherheitsrelevante Arbeit zuverlässig und nicht bloß zufällig (und auch noch sicher) erledigt wird?

Zwei unterschiedliche Aufträge in einem Abschnitt

Abschnitt 8.1 wird leicht zu einem allgemeinen Satz über „Prozesse“ zusammengefasst. Dabei stecken darin zwei unterschiedliche Stoßrichtungen.

Die erste betrifft Prozesse, die benötigt werden, um Anforderungen zu erfüllen. Dazu gehören typische ISMS-Prozesse wie die kontinuierliche Verbesserung, die internen Audits oder das Abstellen von Nichtkonformitäten.

Es können aber auch Kerngeschäftsprozesse (mindestens die im Anwendungsbereich) sein, wenn innerhalb dieser Prozesse Sicherheitsanforderungen umgesetzt werden.

Die zweite Stoßrichtung betrifft die Planungen aus Abschnitt 6. Was dort beschlossen wurde, darf nicht als schöne Absicht in einer Tabelle enden. Es muss in kontrolliertes Handeln übersetzt werden.

Diese Trennung ist wichtig. Sonst beschränkt man sich entweder auf ein paar klassische ISMS-Prozessbeschreibungen oder nur auf die Verfolgung des Risikobehandlungsplans. Beides allein greift zu kurz.

1. Prozesse zur Erfüllung der Anforderungen

Zu den naheliegenden ISMS-Prozessen gehören beispielsweise:

• Risikomanagement;
• Dokumentenlenkung;
• Internes Audit;
• Behandlung von Nichtkonformitäten;
• Managementbewertung;
• Steuerung von Informationssicherheitszielen;
• Management von Sicherheitsvorfällen;
• Lieferantenmanagement.

Solche Prozesse sorgen dafür, dass das Managementsystem selbst funktioniert. Doch 8.1 kann weiter reichen.

Auch Kerngeschäftsprozesse können sicherheitsrelevant sein

Nehmen wir ein Softwareunternehmen. Es erfüllt Anforderungen an sichere Entwicklung nicht in einem separaten ISMS-Raum, sondern innerhalb seines Entwicklungsprozesses. Sicherheitsanforderungen müssen ermittelt, Änderungen geprüft, Code getestet und Releases freigegeben werden.

Ein Managed Service Provider erfüllt Anforderungen an Berechtigungen, Änderungen, Logging und Wiederherstellung innerhalb seiner Betriebsprozesse. Ein Rechenzentrum setzt Anforderungen an Zutritt und physische Sicherheit im Gebäudebetrieb um. Ein SaaS-Anbieter erfüllt Anforderungen an Verfügbarkeit und Wiederherstellung in seinen Deployment-, Betriebs- und Notfallprozessen.

Damit wird der Anwendungsbereich des ISMS wichtig. Mindestens die Kerngeschäftsprozesse, die im Scope liegen und auf deren sicheren Ablauf das Unternehmen vertraut, müssen betrachtet werden.

Das bedeutet nicht, dass jeder Prozess im Anwendungsbereich automatisch in epischer Breite dokumentiert werden muss. Es bedeutet aber: Wenn die Erfüllung einer Sicherheitsanforderung in einem Prozess steckt, darf dessen Ablauf nicht vollkommen dem Zufall überlassen bleiben.

Kriterien festlegen und danach steuern

Ein Prozess ist nicht schon deshalb gesteuert, weil er regelmäßig stattfindet. Es müssen Kriterien existieren, anhand derer er geplant und durchgeführt wird.

Je nach Prozess können das beispielsweise sein:

• erforderliche Eingaben und erwartete Ergebnisse;
• Verantwortlichkeiten und Befugnisse;
• notwendige Prüfungen und Freigaben;
• einzuhaltende Sicherheitsanforderungen;
• Fristen und Eskalationswege;
• Definition-of-Done-Kriterien;
• Messwerte oder andere Qualitätskriterien;
• zu erzeugende Nachweise.

Bei einem Release-Prozess könnte beispielsweise festgelegt sein, welche Sicherheitstests durchgeführt werden, wer ein Release freigibt und wie mit kritischen Schwachstellen umzugehen ist. Bei einem Berechtigungsprozess kann geregelt sein, wer Zugriff beantragt, genehmigt, einrichtet und später wieder entzieht.

Das passt zur grundsätzlichen Prozessorientierung der ISO 27001: Zusammenarbeit wird nicht dadurch verlässlich, dass alle Beteiligten guten Willen haben. Sie wird verlässlich, wenn wichtige Abläufe verständlich vereinbart und tatsächlich angewendet werden.

2. Die Maßnahmen aus Abschnitt 6 wirklich umsetzen

Die zweite Stoßrichtung von 8.1 verbindet Planung und Betrieb.

In Abschnitt 6 werden unter anderem Risiken und Chancen behandelt, Informationssicherheitsrisiken bewertet, Risikobehandlungen festgelegt, Informationssicherheitsziele geplant und Änderungen am ISMS vorbereitet. Abschnitt 8.1 sorgt dafür, dass diese Planungen nicht liegen bleiben.

Risiken und Chancen

Aus 6.1.1 können Maßnahmen entstehen, mit denen das ISMS seine beabsichtigten Ergebnisse erreicht, unerwünschte Auswirkungen verhindert oder verringert und kontinuierlich verbessert werden soll.

Diese Maßnahmen müssen in die relevanten ISMS-Prozesse integriert und umgesetzt werden. Das kann beispielsweise bedeuten, Verantwortlichkeiten neu zu regeln, einen Review einzuführen oder einen bisher ungeregelten Ablauf verbindlich zu machen.

Risikobehandlung

Im Risikomanagement nach ISO 27001 werden Risiken nicht nur identifiziert und bewertet. Für nicht akzeptable Risiken werden Behandlungen festgelegt.

Ein Risikobehandlungsplan ist aber noch keine Risikobehandlung. „MFA einführen“ in eine Tabelle zu schreiben, aktiviert keine Mehrfaktorauthentifizierung. „Backup verbessern“ stellt keine Daten wieder her.

8.1 bedeutet hier: Die geplanten Maßnahmen müssen mit Verantwortlichkeit, Kriterien, Ressourcen und Nachverfolgung in die Umsetzung gelangen. Dabei muss nicht jede Maßnahme ein eigener dauerhafter Prozess sein. Eine einmalige technische Einführung kann zunächst ein Projekt oder eine Aufgabe sein. Die Organisation benötigt aber eine beherrschte Vorgehensweise, mit der sie solche Maßnahmen zuverlässig umsetzt.

Informationssicherheitsziele

Dasselbe gilt für Informationssicherheitsziele. Abschnitt 6.2 verlangt bereits eine Planung: Was wird getan, welche Ressourcen werden benötigt, wer ist verantwortlich, wann soll das Ziel erreicht sein und wie wird das Ergebnis bewertet?

8.1 ist der Übergang vom Ziel zur tatsächlichen Durchführung. Ein Ziel ohne Umsetzung ist keine Steuerung, sondern ein Vorsatz. Und Vorsätze haben bekanntlich eine gewisse Neigung, sich bis zum nächsten Management Review unauffällig unter anderen Tagesordnungspunkten zu verstecken.

Änderungen am ISMS

Auch geplante Änderungen nach 6.3 müssen umgesetzt werden. Das betrifft beispielsweise einen neuen Standort, eine größere organisatorische Umstellung, neue Technologien, veränderte Verantwortlichkeiten oder eine Erweiterung des Scopes.

Darüber hinaus verlangt 8.1, geplante Änderungen zu steuern und die Folgen unbeabsichtigter Änderungen zu betrachten. Wenn etwas anders läuft als vorgesehen, sollen mögliche nachteilige Auswirkungen erkannt und soweit erforderlich begrenzt werden.

Ein gutes Change Management besteht deshalb nicht nur aus der Genehmigung einer Änderung. Es betrachtet auch Abhängigkeiten, Sicherheitsfolgen, notwendige Tests, Kommunikation, Rückfallmöglichkeiten und die Frage, ob das Ergebnis tatsächlich wie geplant funktioniert.

Muss man die Prozesse aufschreiben?

Hier wird es praktisch interessant. ISO 27001 verlangt nicht pauschal eine ausführliche Prozessbeschreibung für jeden Ablauf. Sie verlangt dokumentierte Information in dem Umfang, der erforderlich ist, damit darauf vertraut werden kann, dass die Prozesse wie geplant durchgeführt wurden.

Das Wort „erforderlich“ lässt Spielraum. Diesen Spielraum sollte man vernünftig und nicht bequem nutzen.

Der einfachste Test: Fragen Sie Ihre Mitarbeiter – zumindest im Kopf

Stellen Sie sich vor, Sie fragen alle Personen, die nach dem Prozess arbeiten müssen:

• „Wie würden Sie den Prozess jetzt durchführen? Erklären Sie doch mal von Anfang bis Ende!“
• „Würden Sie erst einmal jemanden fragen, wie das eigentlich geht?“
• „Oder würden Sie einfach irgendwie anfangen – und dabei womöglich die Sicherheitsanforderungen vergessen?“

Wenn alle Beteiligten den Prozess zuverlässig und auf identisch darstellen würden, müssen Sie möglicherweise gar nicht viel aufschreiben.

Wenn die Antwort aber lautet „Da fragen wir normalerweise Sabine“, dann haben Sie keinen beherrschten Prozess, sondern Sabine.

Und wenn verschiedene Mitarbeiter denselben Vorgang unterschiedlich durchführen, wichtige Kontrollen vergessen oder zunächst improvisieren würden, benötigen Sie mehr Führung im Prozess. Das kann dokumentierte Information sein, aber auch eine sinnvoll gestaltete technische Steuerung.

Dokumentation muss nicht immer eine Verfahrensanweisung sein

Geeignete dokumentierte Information kann beispielsweise sein:

• eine kurze Prozessbeschreibung;
• ein Ablaufdiagramm;
• eine Checkliste;
• ein verbindliches Ticket-Template;
• ein technisch erzwungener Workflow;
• eine Arbeitsanweisung;
• ein Freigabeprotokoll;
• Logs oder andere Ergebnisnachweise.

Je komplexer, seltener, variabler oder personenkritischer ein Prozess ist, desto schwieriger wird die Behauptung, alle hätten ihn zuverlässig im Kopf. Auch hohe Sicherheitsauswirkungen sprechen für eine stärkere Dokumentation und Steuerung.

Wer unsicher ist, sollte nicht fragen: „Wie viele Seiten Prozessbeschreibung verlangt die Norm?“ Die bessere Frage lautet: „Was brauchen unsere Mitarbeiter, damit dieser Ablauf auch unter Zeitdruck, bei Vertretung und in einem ungewöhnlichen Fall sicher funktioniert?“

Vorgabe und Nachweis gehören zusammen

Abschnitt 8.1 zielt nicht nur darauf, einen vorgesehenen Ablauf zu beschreiben. Es muss auch Vertrauen entstehen können, dass er tatsächlich wie geplant durchgeführt wurde.

Ein Freigabeprozess kann hervorragend dokumentiert sein. Wenn hinterher nicht feststellbar ist, ob die erforderliche Freigabe erfolgt ist, fehlt trotzdem etwas. Umgekehrt beweist ein einzelnes korrekt bearbeitetes Ticket nicht, dass der Prozess grundsätzlich geplant und gesteuert wird.

Oft braucht man daher beides:

• eine angemessene Vorgabe, die den Ablauf und seine Kriterien festlegt;
• geeignete Nachweise, die zeigen, dass der Ablauf angewendet wurde.

Wie viel davon nötig ist, hängt vom Risiko und von der Komplexität ab. Unser Artikel zu den wirklich benötigten ISO 27001-Dokumenten zeigt, warum dokumentierte Information nicht automatisch einen Berg aus Word-Dateien bedeutet.

Extern bereitgestellte Prozesse, Produkte und Dienstleistungen

Ein weiterer wichtiger Teil von 8.1 betrifft Leistungen von außen. Die aktuelle Fassung spricht breiter von extern bereitgestellten Prozessen, Produkten und Dienstleistungen. Die Änderung gegenüber der früheren Formulierung ist auch in unserem Überblick zu den Unterschieden der ISO 27001:2022 beschrieben.

Die praktische Frage lautet: Bei welchen externen Leistungen ist Ihnen der Ablauf nicht vollkommen egal, weil Ihre Informationssicherheit davon abhängt?

Das können beispielsweise sein:

• Cloud- und Hostingdienstleistungen;
• ausgelagerter IT-Betrieb;
• externe Softwareentwicklung;
• Managed Security Services;
• externe Backups;
• Rechenzentrumsleistungen;
• Support- und Administrationsleistungen;
• Dienstleister, die sensible Informationen verarbeiten.

Sie müssen nicht jeden internen Handgriff eines Lieferanten vorschreiben (das würden auch nur die wenigsten Lieferanten mit sich machen lassen). Aber wenn dessen Leistung eine wesentliche Sicherheitsanforderung für Ihr Unternehmen erfüllt, brauchen Sie eine angemessene Form der Steuerung.

Dazu können gehören:

• Sicherheitsanforderungen bei Auswahl und Beauftragung;
• vertragliche Regelungen und Service Levels;
• geregelte Zugriffe und Verantwortlichkeiten;
• Meldepflichten bei Vorfällen und wesentlichen Änderungen;
• vereinbarte Nachweise und Berichte;
• Überwachung der erbrachten Leistung;
• Maßnahmen bei Abweichungen.

Die Lieferantenbewertung ist deshalb nicht bloß eine einmalige Checkbox. Wie sich eine laufende Steuerung technisch abbilden lässt, zeigt beispielsweise unser Beitrag zum ISO 27001 Supplier Management mit Jira.

Der passende Leitsatz lautet: Sie können eine Leistung auslagern. Die Verantwortung dafür, dass sie zu Ihrem ISMS passt, lagern Sie nicht automatisch mit aus.

Was will der Auditor sehen?

Ein Auditor wird selten zufrieden sein, wenn Sie ihm lediglich ein Prozesshandbuch zeigen. Er möchte verstehen, welche Prozesse für Ihr ISMS notwendig sind, welche Kriterien gelten und ob die Abläufe tatsächlich gesteuert werden.

Typische Fragen können sein:

• Welche Kerngeschäftsprozesse liegen im Anwendungsbereich?
• Wo werden darin Sicherheitsanforderungen erfüllt?
• Wie stellen Sie sicher, dass wichtige Schritte zuverlässig durchgeführt werden?
• Wie verfolgen Sie Maßnahmen aus dem Risikobehandlungsplan?
• Wie werden Informationssicherheitsziele umgesetzt?
• Wie steuern Sie geplante und unbeabsichtigte Änderungen?
• Welche externen Leistungen sind sicherheitsrelevant?
• Woran erkennen Sie, dass ein Prozess wie geplant gelaufen ist?

Der Auditor kann dann einen konkreten Vorgang auswählen und ihn vom Anfang bis zum Ende verfolgen. Bei einem Benutzerzugang beispielsweise vom Antrag über die Genehmigung und Einrichtung bis zur späteren Änderung oder Entziehung. Dabei wird schnell sichtbar, ob der Prozess wirklich gesteuert ist oder nur in einer Präsentation ordentlich aussieht.

Typische Fehler bei Abschnitt 8.1

Besonders häufig sind diese Probleme:

• Es gibt Prozessbeschreibungen, die mit der tatsächlichen Arbeit wenig zu tun haben.
• Sicherheitsanforderungen stecken nur im Koipf einzelner Personen.
• Risikobehandlungsmaßnahmen haben weder Verantwortliche noch Termine.
• Ziele wurden geplant, aber nicht in konkrete Tätigkeiten überführt.
• Jeder Bereich führt denselben sicherheitsrelevanten Vorgang anders durch.
• Änderungen werden umgesetzt, ohne ihre Sicherheitsfolgen zu betrachten.
• Externe Leistungen wurden beauftragt, ohne Sicherheitsanforderungen festzulegen.
• Dokumentation wird als Selbstzweck verstanden und produziert Papier statt Steuerung.
• Es gibt Vorgaben, aber keine Nachweise für ihre Anwendung.

Die Lösung ist nicht automatisch mehr Text. Die Lösung ist ein passender Mix aus klaren Kriterien, Verantwortlichkeiten, praktikablen Abläufen, technischen Kontrollen und geeigneten Nachweisen. Auch die Controls der ISO 27001 sind in diesem Sinne nicht bloß Prüfhandlungen, sondern Sicherheitsmaßnahmen, die Risiken behandeln und Anforderungen praktisch umsetzen.

So gehen Sie pragmatisch vor

Für die Umsetzung von Abschnitt 8.1 bietet sich dieses Vorgehen an:

1. Listen Sie die notwendigen ISMS-Prozesse auf.
2. Betrachten Sie die Kerngeschäftsprozesse im Scope und markieren Sie, wo Sicherheitsanforderungen erfüllt werden.
3. Legen Sie für kritische Abläufe Kriterien, Verantwortlichkeiten und erforderliche Nachweise fest.
4. Prüfen Sie mit dem Mitarbeiter-Gedankentest, wo Wissen zu stark an einzelnen Personen hängt.
5. Überführen Sie Maßnahmen aus Abschnitt 6 in konkrete Umsetzung und Nachverfolgung.
6. Regeln Sie den Umgang mit geplanten und unbeabsichtigten Änderungen.
7. Identifizieren Sie extern bereitgestellte Leistungen, von denen Ihre Informationssicherheit abhängt.
8. Testen Sie an echten Vorgängen, ob die Prozesse wie vorgesehen funktionieren.

Fangen Sie mit den Prozessen an, bei denen ein Fehler hohe Auswirkungen hätte oder bei denen heute besonders viel improvisiert wird. Dort bringt Steuerung meist den größten praktischen Nutzen.

Interesse geweckt?

Wenn Sie die Prozesse Ihres ISMS pragmatisch aufsetzen, vorhandene Kerngeschäftsprozesse um Sicherheitsanforderungen ergänzen oder Abschnitt 8.1 auditfest umsetzen möchten, sprechen Sie uns gerne an. Wir helfen Ihnen dabei, die richtigen Abläufe zu steuern – ohne Ihr Unternehmen mit Prozessbeschreibungen zuzupflastern.

Dieser Artikel gehört zum Thema ISO 27001 Zertifizierung – erfahren Sie mehr über die Zertifizierung.

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