ISO 27001 A.5.8: Sicherheitsanforderungen in Scrum einbinden

Schnell, agil, innovativ – das ist der Herzschlag der modernen Softwareentwicklung. Zwei-Wochen-Sprints, User Stories und tägliche Stand-ups treiben den Fortschritt voran. Und dann kommt die Anforderung: ISO 27001. Ein Wort, das für viele Teams nach Bürokratie, starren Prozessen und endloser Dokumentation klingt. Ein Bremsklotz für die agile Rakete.

‍

Aber was, wenn dieser vermeintliche Widerspruch ein Missverständnis ist? Was, wenn Ihre agilen Rituale nicht das Problem, sondern die perfekte Lösung für die Informationssicherheit sind?

‍

Dieser Artikel ist Ihr Praxis-Guide, der den Mythos „Agil vs. ISO 27001“ entlarvt. Wir zeigen Ihnen, wie Sie die Anforderung A.5.8 „Informationssicherheit im Projektmanagement“ nicht nur erfüllen, sondern mit Ihren bestehenden Scrum-Prozessen meistern – und das Ganze schlank, effektiv und audit-sicher.

‍

Was verlangt ISO 27001 A.5.8 wirklich? Die Grundlage einfach erklärt

‍

Bevor wir die Brücke zur agilen Welt schlagen, lassen Sie uns kurz klären, was hinter der Anforderung A.5.8 steckt. Im Kern geht es darum, die Informationssicherheit von Anfang an und während des gesamten Lebenszyklus eines Projekts zu berücksichtigen. Es ist keine Checkliste, die man am Ende abhakt, sondern ein integrativer Ansatz.

‍

Das Ziel ist es, die drei Säulen der Informationssicherheit zu schützen:

‍

1. Vertraulichkeit: Sicherstellen, dass Daten nur von autorisierten Personen eingesehen werden können.
   ‍
2. Integrität: Gewährleisten, dass Daten korrekt und unverändert bleiben.
   ‍
3. Verfügbarkeit: Sicherstellen, dass Systeme und Daten dann zugänglich sind, wenn sie gebraucht werden.

‍

Anstatt riesiger, isolierter Sicherheitsdokumente fordert der Standard, dass Sicherheitsaspekte ein natürlicher Teil Ihrer Projektplanung und -steuerung werden. Und genau hier liegt der Schlüssel für agile Teams.

‍

Foundation: ISO 27001 A.5.8 in Plain Language

‍

Diese Konzeptkarte verdeutlicht die zentralen Prinzipien von ISO 27001 A.5.8 und zeigt ihre Verbindung zu agilen Softwareentwicklungsprozessen. So wird sichtbar, wie Informationssicherheit integrativ und handhabbar gestaltet werden kann.

‍

Der „Aha-Moment“: Wie Ihre Scrum-Events zu Compliance-Werkzeugen werden

‍

Die größte Hürde für viele ist die Übersetzung der ISO-Anforderungen in den agilen Alltag. Die gute Nachricht: Sie müssen keine neuen Prozesse erfinden. Ihre bestehenden Scrum-Zeremonien sind die perfekten Anknüpfungspunkte. ISO 27001 ist ein risikobasiertes Framework, keine starre Vorschrift. Nutzen Sie das!

‍

Stellen Sie sich Ihre Sprints nicht als Gegensatz zur Compliance vor, sondern als den Motor dafür. Jeder Sprint ist ein kleiner Projektzyklus, in dem Sie Sicherheit planen, umsetzen, überprüfen und verbessern können.

‍

Building: The Agile-Compliance Bridge (The "Aha" Moment)

‍

‍

Dieses Prozessdiagramm zeigt anschaulich, wie agile Scrum-Zeremonien als Mechanismen zur Umsetzung der Informationssicherheit gemäß ISO 27001 A.5.8 dienen. So wird Compliance im agilen Alltag praxisnah und nachvollziehbar.

‍

Schauen wir uns an, wie das konkret funktioniert:

‍

• Sprint Planning: Hier legen Sie den Grundstein. Neben den funktionalen Anforderungen planen Sie auch Sicherheitsaspekte. Fragen Sie sich: Welche neuen Risiken entstehen durch die Features in diesem Sprint? Gibt es Abhängigkeiten zu anderen Systemen, die Sicherheitsimplikationen haben? Das ist der perfekte Ort für ein schlankes ISO 27001 Risikomanagement im Kleinen.
  ‍
• Daily Scrum: Eine schnelle Frage genügt: „Gibt es irgendwelche Security-Blocker?“ Das schärft das Bewusstsein und sorgt dafür, dass Sicherheitsthemen nicht untergehen.
  ‍
• Sprint Development: Hier findet die eigentliche Umsetzung statt. Secure-Coding-Praktiken, Peer-Reviews mit Fokus auf Sicherheit und der Einsatz von Analyse-Tools sind Teil des täglichen Tuns.
  ‍
• Sprint Review: Zeigen Sie nicht nur, was das neue Feature tut, sondern auch, wie es sicher ist. Demonstrieren Sie die neue Zwei-Faktor-Authentifizierung oder erklären Sie kurz die umgesetzten Verschlüsselungsmaßnahmen. Das schafft Transparenz und belegt die Umsetzung.
  ‍
• Sprint Retrospective: Der Goldstandard für den von der ISO geforderten kontinuierlichen Verbesserungsprozess. Gab es im letzten Sprint ein Sicherheitsproblem? Was haben wir gelernt? Wie können wir unsere „Definition of Done“ anpassen, um das in Zukunft zu vermeiden? Diese Diskussionen, kurz im Protokoll festgehalten, sind ein wertvoller Nachweis für Auditoren.

‍

Meisterschaft: Praktische Umsetzung in Ihren Sprints

‍

Theorie verstanden? Perfekt. Jetzt machen wir es konkret. Hier sind vier Bausteine, die Sie sofort in Ihren agilen Prozess integrieren können:

‍

1. Security User Stories schreiben

‍

Ergänzen Sie Ihr Backlog um explizite Security Stories. Das macht Sicherheitsanforderungen greifbar, schätzbar und planbar.
‍

• Schlechtes Beispiel: „Die Anwendung muss sicher sein.“
  ‍
• Gutes Beispiel: „Als Benutzer möchte ich mein Passwort über einen sicheren Link zurücksetzen können, damit mein Konto nicht von Unbefugten übernommen wird.“
  ‍
  • Akzeptanzkriterien:
    • Der Reset-Link ist nur einmal gültig.
    • Der Link verfällt nach 60 Minuten.
    • Der Benutzer wird per E-Mail über den Reset-Versuch informiert.

‍

2. Eine „Definition of Done“ (DoD) mit Sicherheitsfokus

‍

Ihre DoD ist ein mächtiges Werkzeug. Erweitern Sie sie um Sicherheitskriterien, die für jede User Story gelten müssen.

‍

Beispiel für eine erweiterte DoD:

‍

• Code wurde einem Peer-Review unterzogen (inkl. Security-Check).
• Relevante Abhängigkeiten (Libraries) wurden auf bekannte Schwachstellen geprüft.
• Eingabevalidierung für alle User-Inputs ist implementiert.
• Notwendige Log-Events werden erzeugt.
• Die Dokumentation (z. B. im Wiki) wurde aktualisiert.

‍

3. „Threat Modeling“ leicht gemacht

‍

Threat Modeling klingt nach wochenlangen Workshops, muss es aber nicht sein. Führen Sie im Sprint Planning eine 30-minütige Mini-Session für kritische neue Features durch. Stellen Sie sich vier einfache Fragen (STRIDE-Modell als Inspiration):

‍

• Spoofing: Kann sich jemand als jemand anderes ausgeben?
• Tampering: Kann jemand unsere Daten unbemerkt verändern?
• Repudiation: Kann ein Benutzer eine Aktion abstreiten?
• Information Disclosure: Können sensible Daten nach außen dringen?
• Denial of Service: Kann jemand unseren Dienst lahmlegen?
• Elevation of Privilege: Kann ein Angreifer mehr Rechte erlangen als vorgesehen?

‍

Notieren Sie die wichtigsten Risiken direkt im Ticket der User Story. Das ist gelebtes Risikomanagement.

‍

4. Die Rolle des Security Champions

‍

Benennen Sie ein Teammitglied zum „Security Champion“. Diese Person ist nicht der alleinige Verantwortliche, sondern der Ansprechpartner und Coach für das Team. Sie hilft, das Sicherheitsbewusstsein hochzuhalten und unterstützt bei der Umsetzung von Best Practices, wie zum Beispiel bei der Dokumentierung und Versionskontrolle.

‍

Ihr Audit-Ready Agile Toolkit: So überzeugen Sie jeden Auditor

‍

Die größte Sorge vieler Teams ist das Audit. Wie beweist man einem Auditor, der vielleicht an klassische Wasserfallprojekte gewöhnt ist, dass der agile Ansatz konform ist? Der Trick ist, Ihre agilen Artefakte als Nachweise zu präsentieren.

‍

Auditor's Corner: Ein Auditor sucht nach Beweisen für einen funktionierenden Prozess. Ihre agilen Artefakte sind diese Beweise. Ein gut gepflegtes Jira-Board mit Security Stories und DoD-Checklisten ist oft aussagekräftiger als ein verstaubtes 100-Seiten-Sicherheitskonzept.

‍

Action: Your Audit-Ready Agile Toolkit

‍

Diese Checkliste dient als praxistauglicher Anker für Teams, die ISO 27001 A.5.8 in ihre agilen Prozesse integrieren möchten. Das Bild hilft beim schnellen Erinnern und effektiven Umsetzen von wichtigen Security-Maßnahmen.

‍

Ihre Checkliste für den Nachweis:

‍

• Risikobewertung: Zeigen Sie Ihre Sprint-Planning-Notizen oder Jira-Tickets, in denen Sicherheitsrisiken für neue Features diskutiert und bewertet wurden.
  ‍
• Sicherheitsanforderungen: Präsentieren Sie Ihr Backlog mit klar definierten Security User Stories und deren Akzeptanzkriterien.
  ‍
• Umsetzungskontrolle: Ihre „Definition of Done“ und die ausgefüllten Checklisten in den Tickets belegen die systematische Umsetzung von Sicherheitsmaßnahmen.
  ‍
• Kontinuierliche Verbesserung: Protokolle aus Sprint Retrospektiven, in denen Sicherheitsthemen besprochen und Maßnahmen abgeleitet wurden, sind der perfekte Nachweis.
  ‍
• Versionskontrolle & Dokumentation: Verweisen Sie auf Ihr Wiki und Ihre Git-Commit-History, um zu zeigen, wie Änderungen nachvollziehbar dokumentiert werden.

‍

Die Automatisierung der Nachweissammlung im Audit kann hierbei enorm helfen, indem sie diese Artefakte automatisch sammelt und für das Audit aufbereitet.

‍

Fazit: Agilität ist Ihr stärkster Compliance-Verbündeter

‍

Die Integration von ISO 27001 A.5.8 in agile Projekte ist kein Hexenwerk. Es erfordert kein Umkrempeln Ihrer Prozesse, sondern eine bewusste Erweiterung. Indem Sie Sicherheit als festen Bestandteil Ihrer Sprints, Stories und Rituale begreifen, verwandeln Sie eine gefühlte Belastung in einen echten Mehrwert.

‍

Sie erfüllen nicht nur die Norm, sondern bauen von Grund auf sicherere und robustere Produkte. Agilität und ISO 27001 sind keine Gegensätze – sie sind zwei Seiten derselben Medaille namens Qualität. Die Implementierung einer umfassenden ISO 27001-Strategie wird so zu einem natürlichen Teil Ihrer agilen DNA.

‍

Häufig gestellte Fragen (FAQ)

‍

Ist ISO 27001 nicht zu bürokratisch für Scrum?

‍

Nein, das ist ein weit verbreiteter Mythos. ISO 27001 ist ein risikobasierter Standard, der das „Was“ (Ziele) vorgibt, aber nicht das „Wie“ (Prozesse). Agile Methoden wie Scrum bieten einen exzellenten Rahmen, um die Anforderungen der Norm flexibel und iterativ umzusetzen. Der Schlüssel liegt darin, die agilen Zeremonien als Werkzeuge zur Erfüllung der Norm zu nutzen, statt zusätzliche bürokratische Prozesse zu schaffen.

‍

Wie dokumentiert man agil für ein Audit, ohne die Geschwindigkeit zu verlieren?

‍

Der Fokus liegt auf schlanker und effektiver Dokumentation. Statt langer Word-Dokumente nutzen Sie die Artefakte, die Sie ohnehin erstellen:

‍

• Jira/Azure DevOps Tickets: Gut geschriebene User Stories mit Sicherheitsakzeptanzkriterien.
  ‍
• Confluence/Wiki-Seiten: Kurze, prägnante Dokumentation von Architekturentscheidungen und Sicherheitskonzepten.
  ‍
• Retrospektiven-Protokolle: Nachweis der kontinuierlichen Verbesserung.Ein zentrales ISMS-Tool kann helfen, diese dezentralen Informationen zu bündeln und audit-sicher aufzubereiten.

‍

Was genau ist eine Security User Story?

‍

Eine Security User Story ist eine Anforderung aus der Perspektive eines Angreifers (als Anti-Pattern) oder eines Benutzers, der Sicherheit benötigt. Sie beschreibt ein Sicherheitsziel auf die gleiche Weise wie eine funktionale Anforderung und macht es damit im Sprint plan- und umsetzbar. Beispiel: „Als Angreifer möchte ich durch SQL-Injection auf die Benutzerdatenbank zugreifen, um sensible Daten zu stehlen.“ Das Entwicklerteam muss dann Maßnahmen implementieren, um genau das zu verhindern.

‍

Reicht es, wenn wir am Ende eines Projekts einen Penetrationstest machen?

‍

Ein Penetrationstest ist eine wichtige Maßnahme, aber er allein reicht nicht aus. ISO 27001 A.5.8 verlangt, dass Sicherheit während des gesamten Projektlebenszyklus berücksichtigt wird („Security by Design“). Ein Test am Ende findet Probleme nur sehr spät, was die Behebung teuer und aufwändig macht. Die Integration von Sicherheit in jeden Sprint ist weitaus effizienter und effektiver.

‍

Wir nutzen mehrere Frameworks wie ISO 27001 und NIS2. Gilt dieser Ansatz auch dort?

‍

Ja, absolut. Der hier beschriebene Ansatz zur Integration von Compliance in agile Prozesse ist universell. Eine gute Compliance-Strategie berücksichtigt, dass viele Anforderungen, zum Beispiel zum Risikomanagement, sich in verschiedenen Standards wie NIS2 und ISO 27001 ähneln. Durch die Integration in den Kernprozess können Sie Synergien nutzen und den Aufwand für mehrere Zertifizierungen minimieren.

‍