März 5, 2026

Anhang A 8.25 Lebenszyklus einer sicheren Entwicklung

(nach ISO/IEC 27001:2022 und ISO/IEC 27002:2022)

Die Entwicklung von Software und Systemen beeinflusst maßgeblich die Informationssicherheit über deren gesamten Lebenszyklus hinweg. Sicherheitslücken entstehen häufig bereits in frühen Entwicklungsphasen und wirken sich bis in den Betrieb aus. Dieses Control stellt sicher, dass Informationssicherheit systematisch in alle Phasen des Entwicklungslebenszyklus integriert wird.

Zweck des Controls

A 8.25 soll gewährleisten, dass Sicherheitsanforderungen von Beginn an in den Entwicklungsprozess eingebunden werden. Ziel ist es, Sicherheitsrisiken frühzeitig zu identifizieren, Schwachstellen zu vermeiden und sichere Systeme über ihren gesamten Lebenszyklus hinweg bereitzustellen.

Anforderungen und Maßnahmen

1. Definition eines sicheren Entwicklungsprozesses

Organisationen müssen einen sicheren Entwicklungsprozess festlegen, insbesondere:

  • Integration von Sicherheitsanforderungen in alle Phasen
  • klare Rollen und Verantwortlichkeiten
  • Berücksichtigung von Sicherheitszielen
  • Abstimmung mit dem ISMS

Der Prozess muss dokumentiert und verbindlich sein.

2. Sicherheitsanforderungen und Design

Sicherheitsanforderungen müssen frühzeitig definiert werden:

  • Ableitung aus Risikoanalysen
  • Berücksichtigung gesetzlicher und vertraglicher Anforderungen
  • Definition sicherer Architekturprinzipien
  • Dokumentation der Sicherheitsanforderungen

Dies legt die Grundlage für sichere Entwicklung.

3. Sichere Entwicklung und Implementierung

Während der Entwicklung müssen Sicherheitsmaßnahmen umgesetzt werden:

  • Anwendung sicherer Programmierpraktiken
  • Nutzung geprüfter Bibliotheken und Frameworks
  • Vermeidung unsicherer Funktionen
  • Einhaltung von Coding-Guidelines

So werden Schwachstellen reduziert.

4. Trennung von Entwicklungs-, Test- und Produktionsumgebungen

Umgebungen müssen getrennt betrieben werden:

  • klare Trennung von Entwicklungs-, Test- und Produktivsystemen
  • Einschränkung von Zugriffen
  • Schutz produktiver Daten
  • Vermeidung unbeabsichtigter Änderungen

Dies verhindert Sicherheitsvorfälle.

5. Sicherheitsprüfungen und Tests

Sicherheitsprüfungen müssen fester Bestandteil des Lebenszyklus sein:

  • Code-Reviews und Sicherheitsreviews
  • automatisierte Sicherheitsprüfungen
  • Penetrationstests, sofern angemessen
  • Dokumentation der Ergebnisse

Tests erhöhen die Sicherheit vor dem Betrieb.

6. Umgang mit Änderungen und Schwachstellen

Änderungen müssen sicher gesteuert werden:

  • Integration von Change-Management
  • Behandlung entdeckter Schwachstellen
  • zeitnahe Korrekturmaßnahmen
  • Bewertung von Sicherheitsauswirkungen

So bleibt die Sicherheit erhalten.

7. Übergabe in den Betrieb

Die Übergabe in den Betrieb muss sicher erfolgen:

  • Sicherheitsfreigaben vor Produktivsetzung
  • Dokumentation von Konfigurationen
  • Schulung von Betriebsverantwortlichen
  • Definition von Wartungs- und Supportprozessen

Dies stellt einen sicheren Betrieb sicher.

8. Dokumentation und kontinuierliche Verbesserung

Der Entwicklungslebenszyklus muss dokumentiert und überprüft werden:

  • Entwicklungs- und Sicherheitsdokumentation
  • Nachweise über Prüfungen und Freigaben
  • Lessons Learned aus Vorfällen
  • regelmäßige Verbesserung des Prozesses

So bleibt der Prozess wirksam und aktuell.

Zusammenfassung

A 8.25 fordert, dass Organisationen Informationssicherheit systematisch in den gesamten Entwicklungslebenszyklus integrieren. Durch klare Prozesse, frühzeitige Sicherheitsanforderungen, sichere Entwicklung, regelmäßige Prüfungen sowie kontrollierte Übergabe in den Betrieb wird sichergestellt, dass Systeme von Anfang an sicher gestaltet und langfristig geschützt sind. Das Control ist ein zentraler Bestandteil der technischen und organisatorischen Sicherheitsmaßnahmen im Informationssicherheitsmanagementsystem.

Auditor prüft die Nachweis-Checkliste im ISO-27001-Audit
A 8.25 · in der Praxis

Was der Auditor hier sehen will

Vier Fragen, die im Zertifizierungsaudit zu A 8.25 tatsächlich gestellt werden – und woran sie sich entscheiden.

„Welche Sicherheitsschritte durchläuft eine Entwicklung bei Ihnen?“
Von der Anforderung bis zum Betrieb: Das Control verlangt Sicherheit über den ganzen Lebenszyklus, nicht nur einen Test am Ende.
„Wo sind diese Schritte festgelegt?“
Eine gelebte Praxis ohne Beschreibung geht mit dem Entwickler, der sie kennt.
„Wie trennen Sie Entwicklungs- und Betriebsumgebung?“
Diese Trennung ist Teil des sicheren Lebenszyklus und wird in kleinen Teams am häufigsten übergangen.
„Gilt das auch für Skripte und Automatisierung?“
Auch ohne Produktentwicklung entsteht Code. Das Control gilt dann sinngemäß.
Das Dokument dazu

A 8.25-1 Sichere Entwicklungsrichtlinie

Sicherheitsschritte über den Entwicklungslebenszyklus · Festlegung und Zuständigkeit · Trennung der Umgebungen und Geltung für Skripte. In der ISMS-Plattform entsteht das Dokument aus Ihren Angaben und ist mit dem Control und seinen Nachweisen verknüpft.

Sie arbeiten die Norm gerade durch? Alle Klauseln und Controls im Überblick