Agiles ISO 27001-Projekt: So funktioniert es wirklich

Viele Unternehmen aus der agilen Ecke haben bei ISO 27001 denselben Reflex:
"Klassischer Projektplan, feste Phasen, dicke Dokumente - das passt doch gar nicht zu uns."

Der Reflex ist nachvollziehbar. Er führt aber oft in die falsche Richtung. Denn die Alternative zu schlechtem Wasserfall ist nicht Chaos. Und die Alternative zu Planung ist nicht Beliebigkeit. Ein ISO 27001-Projekt kann sehr gut agil aufgesetzt werden.

Nur eben nicht in der Bedeutung: "Wir machen mal lose irgendwas und schauen, was passiert.", sondern eher: "Unter welchen Bedingungen funktioniert es wirklich?"

Die kurze Antwort

Ja, ein agiles ISO-27001-Projekt kann sehr gut funktionieren. Aber nur dann, wenn Sie drei Dinge sauber auseinanderhalten:

• Agilität ist nicht Planlosigkeit.
• Iteration ersetzt nicht Verantwortung.
• Das Schlagwort Selbstorganisation ersetzt nicht Führung.

Ein Projekt darf iterativ, sprintbasiert und mit Backlog laufen. Das ist völlig legitim. Projektmanagement-Guidance wie ISO 21502 ist ausdrücklich delivery-agnostisch und nennt gerade auch iterative, adaptive, hybride und agile Ansätze.

Gleichzeitig bleibt ISO 27001 ein Managementsystem, das aufgebaut, umgesetzt, betrieben und verbessert werden muss. Ein agiles Vorgehen ändert also die Form der Projektsteuerung, nicht die Verbindlichkeit des Ziels.

Warum "agil" bei ISO 27001 überhaupt Sinn ergeben kann

Die Unsicherheit liegt bei ISO 27001-Projekten oft nicht im Ziel, sondern in der Wegstrecke. Das Ziel ist meist klar - Auditfähigkeit oder Zertifizierung. Unklar ist oft, wie viel Aufwand einzelne Themen wirklich machen, wie schnell ein Unternehmen Entscheidungen trifft und wie viele Schleifen zwischen Entwurf, Anwendung und Verbesserung nötig sind. Genau dafür kann ein agiler Ansatz sinnvoll sein: nicht, weil das Ziel unklar wäre, sondern weil der Weg dorthin in vielen Unternehmen nicht präzise vorhersagbar ist.

Was "agil" hier nicht bedeuten darf

Agil heißt nicht:

• kein Zieltermin;
• keine Prioritäten;
• keine Verantwortlichkeit;
• keine Managemententscheidungen;
• keine klare Definition dessen, was fertig ist.

Sobald "agil" im Projekt praktisch bedeutet, dass niemand verbindlich sagen kann, was als Nächstes passiert, wer etwas liefert und woran Fortschritt gemessen wird, ist das kein agiles ISO 27001-Projekt mehr. Dann ist es einfach schlecht geführt. ISO 21502 bleibt auch für agile Projekte bei den Grundlagen von Projektmanagement: initiieren, planen, steuern, überwachen und abschließen.

Der eigentliche Vorteil eines agilen Vorgehens

Der Vorteil liegt nicht darin, dass man weniger nachdenken muss. Der Vorteil liegt darin, dass man schneller lernt.

Gerade bei ISO 27001 wissen viele Projektteams am Anfang noch nicht genau,

• wie gut ihre Prozesse wirklich schon sind;
• welche Themen besonders zäh werden;
• wo im Unternehmen Widerstände sitzen;
• und welche Regelungen im Alltag tatsächlich tragen.

Ein iteratives Vorgehen hilft, diese Dinge früher sichtbar zu machen. Statt monatelang einen vermeintlich perfekten Masterplan zu verfolgen, arbeitet man sich in sinnvollen Schleifen an die Auditfähigkeit heran.

Wie ein agiles ISO-27001-Projekt sinnvoll aufgebaut sein kann

Ein brauchbarer agiler Ansatz kann so aussehen:

1. Ziel und Zeitrahmen stehen fest

Agil heißt nicht, dass der Zieltermin unbekannt bleibt. Im Gegenteil: Gerade wenn auf ein Zertifizierungsaudit hingearbeitet wird, muss klar sein, bis wann Stage 1 oder Stage 2 realistisch angestrebt werden. Der Zeitrahmen gibt dem Projekt Richtung. Die Iteration hilft nur bei der Frage, wie man den Weg dorthin flexibel und lernfähig gestaltet. Der alte Artikel nennt genau diesen Zeitfaktor bereits als zentrale Unsicherheit.

2. Ein Projekt-Backlog ersetzt nicht das Denken, aber es strukturiert es

Ein Backlog ist sinnvoll, wenn dort nicht nur "irgendwelche Aufgaben" liegen, sondern die wirklich relevanten Themen des ISMS: Scope, Rollen, Risiken, Leitlinie, dokumentierte Informationen, Annex-A-Maßnahmen, Awareness, internes Audit, Management Review und Nachweise. Genau das beschreibt der bestehende Artikel bereits in seiner Backlog-Logik. Die Stärke daran ist: Nichts verschwindet im Nirgendwo, und das Team kann priorisieren statt nur reagieren.

3. Iteration über das ganze System, nicht nur über Lieblingsthemen

Auditoren finden es in der Regel deutlich besser, wenn alle wesentlichen Themen wenigstens tragfähig angedacht, geregelt und erprobt wurden, als wenn zwei oder drei Themen "perfekt" sind und der Rest leer bleibt. Der agile Vorteil liegt also nicht darin, an Einzelpunkten zu polieren, sondern darin, das gesamte System in mehreren Schleifen gleichmäßig zu heben.

4. Jede Schleife muss näher an die Praxis führen

Ein häufiger Fehler ist, Iteration nur als Dokumentationsschleife zu verstehen. Dann gibt es Version 1, 2 und 3 einer Richtlinie, aber keine echte Anwendung. Regeln müssen auch angewendet und später auditierbar gemacht werden. Ein agiles ISO 27001-Projekt wird nicht besser, weil Texte häufiger umgeschrieben werden, sondern weil Entwurf, Anwendung, Feedback und Verbesserung schneller zusammenkommen.

Was in agilen ISO-27001-Projekten oft schiefläuft

1. "Agil" wird als Schonbegriff für mangelnde Disziplin benutzt

Dann heißt agil in Wahrheit:

• keine saubere Priorisierung;
• keine Verbindlichkeit;
• keine Verantwortung;
• kein echter Fortschritt.

Das ist kein Methodenproblem, sondern Führungsversagen.

2. Es gibt ein Backlog, aber keine Entscheidungen

Dann sammeln sich Tickets, Themen und Ideen, aber niemand entscheidet, was jetzt wirklich fertig werden muss. Ein Backlog ist nur dann hilfreich, wenn es gesteuert wird.

3. Das Team iteriert, aber das Management führt nicht

ISO 27001 bleibt ein Managementsystem. Wenn die Geschäftsführung oder Leitungsebene die Richtung nicht trägt, hilft auch der schönste Sprint-Rhythmus nichts. ISO 27001 verlangt Führung und fortlaufende Verbesserung des Systems, nicht bloß operative Bewegung.

4. Es wird verwechselt: flexibel im Weg, unklar im Ziel

Ein agiles Projekt darf flexibel in der Umsetzung sein. Es darf aber nicht unklar lassen, worauf es hinarbeitet und wann ein Ergebnis als ausreichend tragfähig gilt.

Agilität - eine Methode für Fortschritt unter Unsicherheit

Agilität ist ursprünglich nicht angetreten, um Planung abzuschaffen, sondern um unter unsicheren Randbedingungen belastbar voranzukommen.

Der klassische Wasserfall hatte oft den eingebauten Glauben: Wenn wir nur früh genug alles detailliert planen, können wir auch unbekannte Unbekannte sauber in einen Plan pressen.

Genau das wurde in vielen Projekten zu Recht als Unsinn entlarvt. Für echte Unsicherheit sind agile Methoden oft sinnvoller, weil sie Iteration, Lernen und Fortschritt trotz offener Fragen ermöglichen.

Die spannende Frage ist nur: Gilt das in derselben Härte auch für ein ISO 27001-Projekt?

Ja, für das interne Team fühlt sich so ein Projekt anfangs oft unsicher an, weil die Beteiligten den Weg noch nie gegangen sind. Aber gleichzeitig ist ISO 27001 kein unerforschtes Gelände. Vor Ihnen sind schon tausende Unternehmen erfolgreich durch diese Zertifizierung gegangen, und ihre Erfahrungen, Muster und typischen Stolperstellen sind längst bekannt.

Genau deshalb ist die Unsicherheit hier oft weniger strukturell als gefühlt. Und genau deshalb kann erfahrene Begleitung (siehe separater Artikel) einen großen Unterschied machen: Nicht weil sie das Projekt "unagil" macht, sondern weil sie viele der unnötigen Unbekannten aus dem Weg räumt, bevor sie überhaupt zu Problemen werden.

Was will der Auditor sehen?

Ein Auditor will nicht sehen, dass Sie ein Scrum-Board hatten. Und er will auch nicht sehen, dass Sie besonders klassisch oder besonders modern gearbeitet haben.

Er will sehen, dass Ihr ISMS am Ende:

• klar abgegrenzt ist;
• die wesentlichen Anforderungen abdeckt;
• in der Praxis angewendet wird;
• intern kritisch geprüft wurde;
• und von der Leitung getragen wird.

Wie Sie projektmethodisch dorthin gekommen sind, ist zweitrangig. Wenn ein agiler Ansatz das besser schafft als starre Phasenplanung, ist das völlig in Ordnung. Aber das Ergebnis muss belastbar sein. Diese Einordnung ergibt sich aus der Normlogik von ISO 27001 und aus dem Fokus der bestehenden Seite auf Anwendung und Auditierbarkeit.

FAQ

Interesse geweckt

Wenn Sie Ihr ISO 27001-Projekt agil aufsetzen wollen, ohne dass daraus Planlosigkeit wird, sprechen Sie mit uns oder chatten Sie mit uns (direkt rechts unten auf dieser Seite).