ISO 27001 goes agile: So klappt es ohne Bürokratie

Viele agile Unternehmen haben bei ISO 27001 denselben Reflex: Das wird doch jetzt bürokratisch.

Genau diese Sorge ist verständlich. Denn viele verbinden Managementsysteme mit dicken Ordnern, starren Prozessen und unnötiger Schwerfälligkeit.

Die gute Nachricht: ISO 27001 und Agilität schließen sich nicht aus. Im Gegenteil. Die Norm lässt bewusst Spielraum, weil sie an Größe, Bedürfnisse und Kontext einer Organisation angepasst werden soll. Entscheidend ist also nicht, ob Sie agil arbeiten, sondern wie Sie die Anforderungen umsetzen. 

Die kurze Antwort

Ja, ISO 27001 funktioniert auch in agilen Unternehmen.

Der Fehler liegt meistens nicht in der Norm, sondern in der Umsetzung. Wenn ein agiles Unternehmen versucht, ein Konzern-ISMS nachzubauen, wird es zäh. Wenn es die Norm dagegen als Rahmen nutzt und die Umsetzung zur eigenen Arbeitsweise passend aufsetzt, kann ein ISMS sehr gut schlank, wirksam und auditfähig sein. 

Warum agile Unternehmen oft skeptisch sind

Die Skepsis kommt meist nicht aus der Luft. Agile Unternehmen wollen in der Regel:

• schnell Entscheidungen treffen;
• Regeln nur dort einführen, wo sie wirklich helfen;
• Prozesse laufend verbessern;
• Verantwortung nah an den Teams halten;
• unnötigen Overhead vermeiden.

Genau deshalb wirkt ISO 27001 auf den ersten Blick wie das Gegenteil.

Der eigentliche Denkfehler: ISO 27001 ist kein Bürokratiegebot

ISO 27001 schreibt nicht vor, dass Sie Aktenschränke kaufen, alles in Word-Dokumente gießen oder jede Kleinigkeit in starre Verfahrensanweisungen pressen müssen.

Die Norm verlangt im Kern etwas anderes:

• einen klaren Anwendungsbereich;
• definierte Verantwortlichkeiten;
• ein Vorgehen für Risiken;
• sinnvolle Maßnahmen;
• Nachweise, dass das System funktioniert;
• regelmäßige Überprüfung und Verbesserung.

Wie genau Sie das organisatorisch abbilden, hängt von Ihrem Unternehmen ab. Genau das ist der Punkt, den die ISO auf ihrer eigenen Standardseite ausdrücklich macht: Das System soll an Größe und Bedürfnisse der Organisation angepasst werden.

Was agile Unternehmen stattdessen brauchen

Ein agiles Unternehmen braucht kein schweres ISMS. Es braucht ein passendes ISMS.

Das bedeutet meistens:

• wenige, klare Regeln statt Regelwüste;
• dokumentierte Informationen dort, wo sie wirklich gebraucht werden;
• Verantwortlichkeiten, die zu echten Rollen passen;
• saubere Nachweise in den Tools, die ohnehin genutzt werden;
• regelmäßige Steuerung statt einmaliger Papierproduktion.

Das Ziel ist nicht, möglichst „normgerecht auszusehen“. Das Ziel ist, Informationssicherheit so in die bestehende Arbeitsweise einzubauen, dass sie funktioniert.

So kann ISO 27001 in agilen Unternehmen

Nicht in der Aussage „Keine Sorge, nur Mut“, sondern in der Frage: Wie sieht eine schlanke Umsetzung konkret aus?

Sicherheitsvorfälle in bestehenden Tools steuern

Wenn Sie ohnehin mit Jira oder einem ähnlichen Tool arbeiten, können Sicherheitsvorfälle dort als eigener Ticket-Typ oder eigener Workflow abgebildet werden. Wichtig ist nicht das Tool selbst, sondern dass klar ist:

• wie ein Vorfall gemeldet wird;
• wer ihn bewertet;
• wie er bearbeitet wird;
• und wo die Nachweise liegen.

Leichte Regeln statt Dokumentenlawine

Viele agile Unternehmen arbeiten bereits mit Confluence, Notion oder ähnlichen Wissenssystemen. Für viele Regelungen reicht das völlig aus, solange Informationen auffindbar, aktuell und nachvollziehbar sind.

Regelmäßige Reviews statt Symbol-Meetings

Management Review heißt nicht automatisch steife Sitzung mit Krawatte und feinem Zwirn. Es geht darum, dass die Geschäftsführung regelmäßig auf Risiken, Ziele, Vorfälle, Verbesserungen und den Zustand des ISMS schaut. Wie dieses Format genau aussieht, kann zu Ihrem Unternehmen passen.

Klare Verantwortlichkeiten statt unendlicher Freigabeketten

Agil heißt nicht führungslos. Auch in einem schlanken ISMS muss klar sein, wer Themen verantwortet, Entscheidungen trifft und Nachweise liefert.

Was agile Unternehmen häufig falsch machen

Nicht jedes agile Unternehmen scheitert an zu viel Bürokratie. Manche scheitern am Gegenteil.

Alles bleibt nur implizit

„Wir wissen das doch alle, und wir vertrauen uns doch gegenseitig!“ reicht im Audit oft nicht. Ein Managementsystem braucht an den entscheidenden Stellen nachvollziehbare Regeln und Nachweise.

Flexibel wird mit beliebig verwechselt

Agilität heißt nicht, dass jede Regel morgen folgenlos wieder verschwinden darf. Ein ISMS braucht belastbare Steuerung.

Bestehende Rituale werden falsch etikettiert

Eine Retrospektive ist nicht automatisch ein internes Audit. Ein Weekly ist nicht automatisch ein Management Review. Bestehende Formate können helfen, aber sie ersetzen nicht automatisch die normativen Anforderungen.

Niemand will Verantwortung übernehmen

Gerade in sehr teamorientierten Umgebungen verschwimmen Verantwortlichkeiten schnell. Genau das wird im Audit problematisch.

Der beste Weg für agile Unternehmen

Der richtige Weg ist meistens, nicht zu fragen: Wie machen wir ISO 27001 trotz Agilität?

Sondern: Wie setzen wir ISO 27001 so um, dass sie zu unserer agilen Arbeitsweise passt?

Das ist ein großer Unterschied. Denn dann suchen Sie nicht nach Kompromissen, sondern nach einer sauberen, passenden Umsetzung.

Für wen dieser Ansatz besonders gut funktioniert

Das Thema ist besonders relevant für:

• Softwareunternehmen;
• Agenturen;
• Produktteams mit schneller Iteration;
• kleinere und mittlere Unternehmen mit schlanker Organisation.

Gerade dort ist die Angst vor Bürokratie oft groß. Gleichzeitig profitieren diese Unternehmen häufig besonders davon, wenn Sicherheitsfragen - oder sogar allgemeiner: Vorgehensweisen - einmal sauber geregelt werden, ohne dass Tempo und Anpassungsfähigkeit verloren gehen.

Agiles Unternehmen und agiles ISMS sind nicht dasselbe

Ein Unternehmen kann Software iterativ entwickeln und sein ISMS trotzdem erstaunlich schwerfällig betreiben. Umgekehrt kann ein Maschinenbauer mit klassischer Produktion Sicherheitsmaßnahmen sehr pragmatisch steuern. Agilität ist deshalb kein Branchenstempel, sondern zeigt sich darin, wie Entscheidungen, Rückmeldungen und Verbesserungen organisiert werden.

Für das ISMS sind drei Eigenschaften besonders hilfreich:

• Arbeit wird sichtbar gemacht.
• Verantwortliche entscheiden in kurzen, verlässlichen Schleifen.
• Ergebnisse werden anhand von Feedback und Nachweisen verbessert.

Das passt gut zu ISO 27001. Die Norm verlangt kein bestimmtes Ticketsystem, kein Wasserfallmodell und auch keine monatliche Dokumentenprozession. Sie verlangt ein gesteuertes Managementsystem, das Risiken behandelt, Verantwortlichkeiten klärt und seine Wirksamkeit bewertet.

Nutzen Sie bestehende Rituale, aber geben Sie ihnen einen klaren Zweck

Ein Security-Thema muss nicht automatisch einen neuen Jour fixe bekommen. Ein vorhandenes Team-Review kann Sicherheitsmaßnahmen prüfen, wenn die richtigen Informationen und Entscheider beteiligt sind. Eine Retrospektive kann Ursachen für einen Vorfall oder eine gescheiterte Maßnahme aufdecken. Ein Produkt-Backlog kann Aufgaben aufnehmen, wenn Verantwortlichkeit, Priorität und Termin sichtbar bleiben.

Die bloße Existenz des Rituals reicht allerdings nicht. „Das besprechen wir im Daily“ ist keine belastbare Regelung, wenn niemand zeigen kann, wann das Thema besprochen, was entschieden und wie die Umsetzung verfolgt wurde. Der Artikel über ISO 27001 ohne KPI-Theater zeigt, wie wenige aussagekräftige Informationen mehr helfen als eine Wand voller Kennzahlen.

Ein guter Anschluss an vorhandene Abläufe kann so aussehen:

• Sicherheitsrisiken werden wie andere wesentliche Produktrisiken priorisiert.
• Maßnahmen erhalten Akzeptanzkriterien statt nur einen wohlklingenden Titel.
• Änderungen durchlaufen eine schlanke Sicherheitsprüfung.
• Vorfälle und Abweichungen werden mit Ursachen und Wirksamkeitskontrolle abgeschlossen.
• Die Leitung bekommt regelmäßig ein verdichtetes Bild statt hundert Einzeltickets.

Dokumentation darf leicht sein, muss aber tragen

Agile Teams reagieren allergisch auf Dokumente, die nur für einen Freigabestempel geschrieben werden. Das ist verständlich. Die Alternative darf trotzdem nicht lauten, Wissen ausschließlich in Köpfen und Chatverläufen zu lagern.

Die praktische Frage lautet: Könnten die Mitarbeiter, die nach einem Prozess arbeiten müssen, ihn aus dem Kopf zuverlässig ausführen? Würden sie jemanden fragen? Oder würden sie improvisieren und dabei Sicherheitsanforderungen vergessen? Wenn die dritte Antwort realistisch ist, braucht es eine verständliche Vorgabe.

Dokumentierte Information kann als kurze Wiki-Seite, gepflegte Checkliste, Workflow im Ticketsystem oder automatisierte Regel vorliegen. Entscheidend sind Verfügbarkeit, Versionierung, Verantwortlichkeit und Eignung. Der Beitrag zur Dokumentenlenkung erklärt, was Abschnitt 7.5 wirklich verlangt.

Der Auditor prüft Ergebnisse, nicht Ihr Methodenbekenntnis

Im Audit hilft weder ein besonders agiles Vokabular noch eine besonders ehrfürchtige Normensammlung. Der Auditor verfolgt Anforderungen zu Nachweisen: Wie wurde ein Risiko bewertet? Wer hat eine Maßnahme freigegeben? Wo sieht man, dass ein Zugriff entzogen, ein Backup getestet oder ein Lieferant geprüft wurde?

Ein sinnvoller Auditindex kann zu jeder Anforderung zuständige Personen, Vorgaben und mögliche Nachweise nennen. Das passt hervorragend zu einer agilen Organisation: Informationen sind auffindbar, ohne dass für das Audit ein künstliches Paralleluniversum gebaut wird.

Wann Agilität nur als Ausrede dient

Misstrauisch sollten Sie werden, wenn agil regelmäßig bedeutet:

• Es gibt keine Deadline.
• Entscheidungen bleiben offen.
• Niemand übernimmt das Ergebnis.
• Aufgaben wechseln schneller als sie abgeschlossen werden.
• Dokumentation wird grundsätzlich vertagt.

Dann fehlt nicht Bürokratie, sondern Führung. Der Artikel „Wir machen das pragmatisch“ beschreibt genau diesen Unterschied. Ein schlankes ISMS braucht weniger Ballast, aber nicht weniger Verbindlichkeit.

So sieht ein schlanker ISMS-Takt aus

Ein agiles ISMS kann verschiedene Geschwindigkeiten verbinden. Vorfälle und kritische Schwachstellen brauchen sofortige Reaktion. Maßnahmen werden wöchentlich oder innerhalb vorhandener Teamzyklen verfolgt. Risiken und Leistungsdaten kommen in geplanten Abständen sowie bei Änderungen auf den Tisch. Die Geschäftsführung betrachtet das Gesamtsystem in ihrer Managementbewertung.

Ein möglicher Takt besteht aus:

• laufender Meldung und Bearbeitung von Vorfällen;
• kurzer wöchentlicher Sicht auf blockierte oder überfällige Maßnahmen;
• regelmäßiger Betrachtung wichtiger Risiken, Lieferanten und technischer Trends;
• geplantem Internen Audit mit risikobasierten Schwerpunkten;
• Management Review mit Entscheidungen zu Ressourcen und Verbesserung.

Diese Ebenen dürfen vorhandene Meetings nutzen. Sie müssen aber gemeinsam alle notwendigen Themen abdecken. Zehn Dailys ersetzen kein Management Review, wenn die Leitung dort nie über Eignung und Wirksamkeit des ISMS entscheidet.

Automatisierung ist gelebte Vorgabe

Agile und technische Organisationen können viele Sicherheitsregeln direkt in Werkzeuge einbauen. Eine Pipeline kann Codeanalysen erzwingen. Ein Identitätsdienst kann MFA und Rollen steuern. Ein MDM kann Gerätekonfigurationen durchsetzen. Das ist oft zuverlässiger als die Bitte, jeder möge vor einem Release an eine Checkliste denken.

Trotzdem braucht Automatisierung eine verantwortliche Stelle. Jemand muss Regeln festlegen, Ausnahmen bewerten und Fehlalarme behandeln. Eine technische Schranke ohne Pflege wird entweder umgangen oder blockiert irgendwann sinnvolle Arbeit. Schlank heißt deshalb: möglichst viel automatisch, aber nicht verantwortungslos.

Verbesserung darf klein anfangen

Nicht jede Verbesserung braucht ein Großprojekt. Ein unklarer Meldeweg kann durch einen sichtbaren Kanal verbessert werden. Ein schwer auffindbarer Nachweis durch einen Index. Ein wiederkehrender Konfigurationsfehler durch eine zentrale Richtlinie. Entscheidend ist, dass Ursache und Wirkung zusammenpassen und später geprüft wird, ob die Änderung geholfen hat.

So entsteht kontinuierliche Verbesserung nicht als jährliche Sammlung guter Vorsätze, sondern als normaler Teil der Arbeit. Genau an dieser Stelle passen agile Denkweise und Managementsystem besonders gut zusammen.

Wenige Werkzeuge, klare Zuständigkeiten

Ein agiles ISMS wird nicht besser, wenn Risiken in einem GRC-Tool, Maßnahmen im Ticketsystem, Ausnahmen in einer Tabelle und Entscheidungen in drei Chatkanälen liegen. Werkzeuge dürfen verteilt sein, aber die Verknüpfung muss sichtbar bleiben.

Legen Sie fest, welches System für welchen Gegenstand führend ist. Ein Risiko kann im Risikoregister leben und auf Umsetzungstickets verweisen. Das Ticket zeigt den Arbeitsstand, das Register enthält Bewertung und Akzeptanzentscheidung. Wird eine Maßnahme geschlossen, muss das Restrisiko geprüft werden. So arbeiten Teams in ihren vertrauten Werkzeugen, ohne dass das ISMS aus zehn widersprüchlichen Wahrheiten besteht.

Dasselbe Prinzip gilt für Dokumente und Nachweise. Eine kurze Wiki-Seite kann die Vorgabe erklären, während das Ticketsystem ihre Anwendung belegt. Niemand muss beide Systeme mit identischen Texten füttern. Der Zusammenhang muss nur auffindbar, aktuell und für die zuständigen Mitarbeiter verständlich sein.

Prüfen Sie diese Verknüpfungen gelegentlich. Tote Links und verwaiste Tickets sind die digitale Variante eines Aktenschranks, dessen Schlüssel irgendwann mit dem früheren Mitarbeiter verschwunden ist.

Ein schlanker Prozess bleibt nur schlank, wenn jemand auch seine kleinen technischen und organisatorischen Verbindungen pflegt.

Ein guter Prüfstein ist einfach: Würde die Organisation den vereinbarten Sicherheitsrhythmus auch dann weiterführen, wenn morgen kein Audit mehr im Kalender stünde?

Interesse geweckt?

Wenn Ihr Unternehmen schnell arbeitet und das ISMS diese Geschwindigkeit unterstützen statt ausbremsen soll, Sprechen Sie mit uns. Wir bauen bestehende Arbeitsweisen ein, ohne aus Flexibilität Beliebigkeit zu machen.