Diese SDLC-Sicherheits-Checkliste ordnet Softwareentwicklungskontrollen Klausel für Klausel der ISO/IEC 27001:2022 Annex A zu – insbesondere dem Cluster A.8.25–A.8.34 sowie verwandten Controls – damit Compliance-Beauftragte, IT-Manager und Sicherheitsverantwortliche anwendbare Controls in ihrer Erklärung zur Anwendbarkeit (Statement of Applicability) festlegen, prüffähige Nachweise erheben und den Implementierungsaufwand sicher budgetieren können. Lesen Sie weiter für Aufgaben auf Klauselebene, Nachweisbeispiele und Planungslinks zum Ismscalculator.
Was Sie aus dieser Checkliste mitnehmen:
- Klausel-für-Klausel-Mapping der SDLC-Controls auf ISO 27001 Annex A (A.8.25–A.8.34, A.5.23, A.8.8, A.8.9)
- Konkrete Checklistenaufgaben mit Mindestanforderungen an Nachweise und Verantwortlichkeiten
- Typische Audit-Warnsignale und schnelle interne Prüfungen vor dem Stage-2-Audit
- Aufwandsbänder und ein beispielhafter Gantt-Plan für die Budgetierung
- Links zu Ismscalculator-Tools für maßgeschneiderte Kosten- und Zeitschätzungen
Inhaltsverzeichnis
- Was deckt die SDLC-Sicherheits-Checkliste unter ISO 27001 ab?
- Wie erheben und präsentieren Sie Nachweise für jeden Checklistenpunkt?
- Wer ist wofür verantwortlich? Governance für SDLC-Controls im ISMS
- Wie lange dauert die Implementierung von SDLC-Controls, und was kostet sie?
- Wo erhalten Sie eine Checklistenvorlage und passen sie für Ihre Organisation an?
- Wichtigste Erkenntnisse
- Der häufigste Fehler bei SDLC-Controls
- Ismscalculator verwandelt diese Checkliste in ein Budget und einen Projektplan
- Nützliche Quellen und weiterführende Literatur
Was deckt die SDLC-Sicherheits-Checkliste unter ISO 27001 ab?
ISO/IEC 27001:2022 hat Annex A neu strukturiert und Anwendungssicherheit explizit verankert. Die Revision von 2022 konsolidierte Controls und führte neue ein, die den gesamten Software Development Lifecycle abdecken; der Übergang auf die 2022-Baseline wurde am 31. Oktober 2025 abgeschlossen. Zehn Controls im technologischen Themenbereich (A.8.25 bis A.8.34) sowie A.5.23, A.8.9 und A.8.16 bilden einen AppSec-Cluster aus 13 Controls, den Auditoren typischerweise im Stage-2-Audit durchgehen.
Die folgende Tabelle ordnet jede primäre Klausel Checklistenaufgaben, Mindestanforderungen an Nachweise und einem empfohlenen Verantwortlichen zu.
| ISO-Klausel | Checklistenaufgabe | Mindestnachweis | Verantwortlicher |
|---|---|---|---|
| Sicherer Entwicklungslebenszyklus | Regeln für Planung, Design, Programmierung, Test, Deployment und Wartung dokumentieren und anwenden | Richtlinie zur sicheren Entwicklung, unterzeichnet vom ISMS-Verantwortlichen; Verfahrensdokument mit Versionshistorie | ISMS-Manager / Product Owner |
| Sicherheitsanforderungen für Anwendungen | Sicherheitsanforderungen vor Entwicklungsbeginn definieren und dokumentieren | Anforderungsspezifikation mit Sicherheits-Abnahmekriterien; Bedrohungsmodell oder Risikoregistereintrag | Product Owner / Security Engineer |
| Sichere Systemarchitektur und -entwicklung | Sichere Designprinzipien anwenden (Least Privilege, Defense in Depth, Fail-Safe Defaults) | Architekturprüfungsprotokoll; Design-Freigabe mit Genehmigung des Security Engineers | Security Engineer / Dev Lead |
| Sichere Programmierung | Einen sicheren Programmierstandard einführen und durchsetzen (z. B. OWASP ASVS, SEI CERT) | Dokument zum Secure-Coding-Standard; SAST-Scan-Ergebnisse mit Commit-Referenz; Code-Review-Protokolle | Dev Lead |
| Sicherheitstests in der Entwicklung | Sicherheitstests in die Entwicklungspipeline integrieren | SAST/DAST-Scan-Berichte mit Build-ID-Referenz; Testplan mit Sicherheitstestfällen; Bestanden/Nicht-bestanden-Protokolle | QA Lead / DevOps Lead |
| Ausgelagerte Entwicklung | Sicherheitsanforderungen auf Drittanbieter- und ausgelagerten Code anwenden | Sicherheitsklauseln in Lieferantenverträgen; Nachweis eines Code-Reviews oder SAST-Ergebnisse des Lieferanten | Lieferantenverantwortlicher / ISMS-Manager |
| Trennung von Entwicklungs-, Test- und Produktionsumgebungen | Umgebungsisolierung durchsetzen; Produktivdaten in Testumgebungen untersagen | Topologiediagramm der Umgebungen; Zugriffskontrollprotokolle; Nachweise zur Anonymisierung von Testdaten | DevOps Lead |
| Änderungsmanagement | Änderungen an Systemen über einen formalen Prozess steuern | Änderungsantragsunterlagen mit Genehmigungen; Protokolle der Approval Gates in der Pipeline; Rollback-Verfahren | Dev Lead / Change Manager |
| Testinformationen | Testdaten schützen; Einsatz von Live-Personaldaten bei Tests vermeiden | Testdatenrichtlinie; Nachweise zur Anonymisierung oder synthetischen Datengenerierung | QA Lead / Datenschutzbeauftragter |
| Schutz von Informationssystemen während Audit-Tests | Zugriff während Audit- oder Penetrationstests einschränken und protokollieren | Scope-Vereinbarung für den Penetrationstest; Zugriffsprotokolle im Testzeitraum; Befundsbericht mit Maßnahmenplan | ISMS-Manager / Security Engineer |
| Informationssicherheit bei Cloud-Diensten | Sicherheitsanforderungen auf Cloud-gehostete Entwicklungsumgebungen anwenden | Cloud-Dienstleistungsvertrag mit Sicherheitsklauseln; Shared-Responsibility-Matrix | ISMS-Manager / Lieferantenverantwortlicher |
| Verwaltung technischer Schwachstellen | Einen Schwachstellenmanagementprozess für SDLC-Ergebnisse pflegen | Schwachstellen-Triage-Protokoll mit Datum und Schweregrad; SBOM-Nachweise; Behebungstickets mit SLA-Tracking | Security Engineer |
| Konfigurationsmanagement | Sichere Konfigurationen für Entwicklungswerkzeuge und -infrastruktur verwalten | Konfigurationsbasisdokumente; IaC-Templates mit Versionskontrolle; Drift-Detection-Protokolle | DevOps Lead |
Der AppSec-Control-Cluster erfordert ein dokumentiertes Verfahren, einen namentlich benannten Verantwortlichen und eine Stichprobe von Nachweisen, die mindestens einen Auditierungszeitraum abdeckt (typischerweise 3–12 Monate). Die Controls A.8.25, A.8.26, A.8.27 und A.8.28 verfolgen unterschiedliche Zwecke und müssen explizit adressiert werden, auch wenn sie über ein einziges Verfahrensdokument umgesetzt werden.
Mindestanforderungen an Nachweise, die Auditoren typischerweise akzeptieren:
- Git-verknüpfte SAST-Ergebnisse mit Befund, Commit-Hash und Behebungsdatum
- SBOM-Nachweise, die je Release mit Zeitstempel erzeugt wurden
- Protokolle der Approval Gates in der Pipeline, die den Abschluss der obligatorischen Sicherheitsstufe belegen
- Protokolle zur Umgebungsisolierung oder Zugriffskontrollnachweise
- Schwachstellen-Triage-Tickets mit Schweregrad, Eröffnungsdatum und Schließdatum
Wie erheben und präsentieren Sie Nachweise für jeden Checklistenpunkt?
Auditoren legen Wert auf Nachvollziehbarkeit: ein benannter Control, ein Nachweis und ein Datum. Abstrakte Prozessbeschreibungen reichen nicht aus. Jeder Checklistenpunkt sollte 3–5 reproduzierbare Artefakte erzeugen.
Richtlinie zur sicheren Entwicklung: Das Richtliniendokument benötigt einen Verantwortlichen, ein Genehmigungsdatum, eine Versionsnummer und ein Überprüfungsdatum. Bewahren Sie es in Ihrem Dokumentenmanagementsystem mit einer Versionshistorie auf. Die Dateinamenkonvention SDev-Policy-v1.2-2025-09-01.pdf gibt einem Auditor Datum und Version auf den ersten Blick.
Umgebungstrennung: Ein Topologiediagramm allein reicht nicht aus. Ergänzen Sie es durch Zugriffskontrollprotokolle, die zeigen, dass keine Entwicklerkonten in der Produktion vorhanden sind, sowie einen datierten Nachweis jeder Ausnahme mit einem unterzeichneten Risikoakzeptanzvermerk. CI/CD-Pipelines müssen obligatorische Sicherheitsteststufen, Approval Gates und unveränderliche Audit-Trails erzwingen, um die Unterkontrollen von A.14 zu erfüllen, und diese Pipeline-Protokolle dienen als unveränderlicher Nachweis.
Schwachstellen-Triage-Nachweise (A.8.8): Eine Tabelle ohne Datumsangaben ist ein Warnsignal. Verwenden Sie Ihr Ticketing-System (Jira, Linear oder ein vergleichbares Tool), damit jeder Befund einen Erstellungszeitstempel, einen Schweregrad, einen Verantwortlichen und ein Schließdatum hat. Exportieren Sie eine gefilterte Ansicht für den Auditierungszeitraum als Nachweisartefakt.
| Artefakt | Erforderliche Metadaten | Speicherort | Prüfmethode des Auditors |
|---|---|---|---|
| Richtlinie zur sicheren Entwicklung | Verantwortlicher, Version, Genehmigungsdatum, Überprüfungsdatum | Dokumentenmanagementsystem (versionskontrolliert) | Versionshistorie prüfen; Zeichnungsbefugnis des Unterzeichners bestätigen |
| SAST-Scan-Bericht | Build-ID, Commit-Hash, Tool-Name, Scan-Datum, Anzahl der Befunde | CI/CD-Artefaktspeicher (unveränderlich) | Commit-Hash in der Quellcodeverwaltung gegenchecken |
| SBOM-Datei | Release-Version, Erzeugungsdatum, Tool-Name, Komponentenliste | Artefakt-Registry oder sicherer Dateispeicher | Erzeugungsdatum mit Release-Datum abgleichen |
| Schwachstellen-Triage-Protokoll | Befunds-ID, Schweregrad, Eröffnungsdatum, Verantwortlicher, Schließdatum | Issue-Tracker (Jira, Linear usw.) | Nach Auditierungszeitraum filtern; SLA-Einhaltung prüfen |
| Umgebungszugriffsprotokoll | Benutzer, Aktion, Zeitstempel, Umgebungsname | SIEM oder Cloud-Zugriffsprotokollierungsdienst | Sicherstellen, dass kein umgebungsübergreifender Zugriff ohne Genehmigung erfolgte |
Praxistipp: Auditoren fordern zunehmend git-verknüpfte Nachweise statt periodischer Berichte. Konfigurieren Sie Ihre CI/CD-Pipeline so, dass der SAST-Bericht als Build-Artefakt angehängt wird und der Commit-SHA im Dateinamen eingebettet ist. Dieser einzelne Schritt beseitigt die häufigste Herausforderung hinsichtlich der Authentizität von Nachweisen.
Wer ist wofür verantwortlich? Governance für SDLC-Controls im ISMS
Klare Verantwortlichkeiten sind das, was ein funktionierendes ISMS von einer reinen Compliance-Übung unterscheidet. Das folgende Governance-Modell weist Rollen über die sechs Funktionen hinweg zu, die Auditoren zu sehen erwarten.
| Kontrollbereich | ISMS-Verantwortlicher | Control Owner | Dev Lead | Security Engineer | QA Lead | Lieferantenverantwortlicher |
|---|---|---|---|---|---|---|
| Richtlinie zur sicheren Entwicklung | A (Genehmigt) | R (Verantwortlich) | C (Konsultiert) | C | I (Informiert) | I |
| Sicherheitsanforderungen | I | C | R | C | C | C |
| Sichere Architektur | I | C | C | R | I | I |
| Secure-Coding-Standard | I | C | R | R | C | C |
| Sicherheitstests | I | C | C | C | R | I |
| Ausgelagerte Entwicklung | A | R | I | C | I | R |
| Umgebungstrennung | I | C | R | C | I | I |
| Schwachstellenmanagement | I | R | C | R | C | C |
Erforderliche Freigaben durch die Geschäftsleitung umfassen: initiale Richtliniengenehmigung durch den ISMS-Verantwortlichen, SoA-Freigabe mit Bestätigung der Anwendbarkeit und Begründung jedes Controls sowie ein jährliches Management-Review, das Nachweise aus dem vorangegangenen Zeitraum stichprobenartig prüft. Die Häufigkeit der Nachweiserhebung sollte bei hochriskanten Controls (A.8.28, A.8.29, A.8.8) mindestens quartalsweise und bei Controls mit geringerem Risiko halbjährlich erfolgen.
Wie lange dauert die Implementierung von SDLC-Controls, und was kostet sie?
Der Aufwand variiert je nach Reifegrad. Die folgende Tabelle zeigt realistische Bandbreiten für eine Organisation, die SDLC-Controls im Rahmen eines umfassenderen ISO-27001-Projekts implementiert.
| Reifegrad | Phase | Typische Dauer | Ressourcenprofil |
|---|---|---|---|
| Minimal (ad-hoc-Prozesse, keine formale SDLC-Richtlinie) | Richtlinienentwurf und SoA-Mapping | 3–4 Wochen | — |
| Minimal | Tool-Einrichtung (SAST, SBOM, Pipeline-Gates) | 4–6 Wochen | 1 VZÄ DevOps + — |
| Moderat (einige Richtlinien vorhanden, inkonsistente Nachweise) | Lückenbehebung und Nachweiserhebung | 4–6 Wochen | — |
| Moderat | Internes Audit und Pre-Audit-Review | 2–3 Wochen | 0,5 VZÄ ISMS-Manager |
| Vollständig (reifes DevSecOps, dokumentierte Controls) | Nachweis-Paketierung und SoA-Finalisierung | 2–3 Wochen | 0,25 VZÄ ISMS-Manager + 0,25 VZÄ Dev Lead |
Ein beispielhafter Gantt-Plan für den SDLC-Workstream in einer Organisation mit moderatem Reifegrad: Wochen 1–3 für Richtlinien- und Verfahrensentwürfe; Wochen 4–8 für die Tool-Integration und Pipeline-Gate-Konfiguration; Wochen 9–12 für die Nachweiserhebung über einen Stichprobenauditierungszeitraum; Wochen 13–14 für die interne Nachweisaudit und Lückenschließung; Woche 15 für die SoA-Aktualisierung und Auditvorbereitung.
Praxistipp: Führen Sie die 2-minütige Bereitschaftsprüfung des Ismscalculators durch, bevor Sie sich auf einen Zeitplan festlegen. Sie bildet Ihren aktuellen Reifegrad über alle vier Kontrollthemen der ISO/IEC 27001:2022 ab und zeigt auf, welche SDLC-Controls den größten Aufwand erfordern, damit Sie die richtigen Arbeitspakete vorzeitig einplanen können.
Die vollständige Bereitschaftsbewertung wandelt diese Aufwandsbänder in eine maßgeschneiderte Kostenschätzung und ein herunterladbares Gantt-Diagramm um – genau das, was Sie für ein Budgetgespräch benötigen.
Wo erhalten Sie eine Checklistenvorlage und passen sie für Ihre Organisation an?
Eine praxistaugliche Checklistenvorlage für dieses Control-Set sollte folgende Spalten enthalten: ISO-Klausel, Checklistenaufgabe, Nachweisartefakttyp, Dateinamenkonvention für Artefakte, Verantwortliche Rolle, aktueller Status (Nicht begonnen / In Bearbeitung / Abgeschlossen) sowie ein Link zum Musterartefakt.
Anpassungsschritte nach Organisationstyp:
- SaaS- und Technologieunternehmen: Fügen Sie eine Spalte für die CI/CD-Pipeline-Stufe hinzu, in der jeder Control durchgesetzt wird. Der Leitfaden ISO 27001 für SaaS- und Technologieunternehmen enthält SDLC-spezifische Vorlagen und Implementierungshinweise, die direkt anwendbar sind.
- Regulierte Branchen (Finanzen, Gesundheitswesen): Ordnen Sie jeden SDLC-Control den spezifischen Anforderungen Ihrer Branche zu (SOC 2, HIPAA, PCI DSS). Der Vergleich von Finanzdatensicherheitsstandards ordnet ISO-27001-Controls US-amerikanischen Finanzvorschriften zu.
Praxistipp: Führen Sie Ihre Checkliste in einem versionskontrollierten Dokument (Confluence, Notion oder eine in Git gehostete Markdown-Datei). Jede Statusänderung wird automatisch zu einem datierten Audit-Trail, und Sie können einen Snapshot für den Auditor exportieren, ohne ein separates Nachweispaket erstellen zu müssen.
Richtlinienskelette, SBOM-Mustervorlagen und Testplan-Snippets stehen über den ISO-27001-Annex-A-Controls-Leitfaden des Ismscalculators zur Verfügung, der jeden Control praktischen Nachweisanforderungen zuordnet.
Wichtigste Erkenntnisse
Eine prüffähige SDLC-Sicherheits-Checkliste erfordert einen namentlich benannten Verantwortlichen, ein datiertes Artefakt und eine nachvollziehbare Verbindung zwischen jedem ISO-27001-Annex-A-Control und seinem Nachweis – und zwar bevor das Stage-2-Audit beginnt.
| Punkt | Details |
|---|---|
| Jeden SDLC-Control explizit abbilden | Führen Sie A.8.25–A.8.34, A.5.23, A.8.8 und A.8.9 einzeln in Ihrer SoA auf, jeweils mit einem Verfahren und einem Nachweis. |
| Nachweise mit Builds und Commits verknüpfen | Hängen Sie SAST-Berichte und SBOMs an Build-IDs und Commit-Hashes an, damit Auditoren die Authentizität prüfen können. |
| Namentlich benannte Verantwortliche, keine Teams | Jedes Verfahren und jeder Checklistenpunkt benötigt eine konkrete Rollenbezeichnung als Verantwortlichen, nicht „das Entwicklungsteam". |
| Zuerst einen internen Traceability-Test durchführen | Ziehen Sie einen zufälligen Build und verfolgen Sie ihn durch SAST, Approval Gate, SBOM und Triage-Nachweise, bevor das Stage-2-Audit beginnt. |
| Ismscalculator für die Aufwandsplanung nutzen | Die Bereitschaftsprüfung und die vollständige Bewertung wandeln SDLC-Control-Lücken in einen budgetierten Zeitplan mit Gantt-Export um. |
Der häufigste Fehler bei SDLC-Controls
Die meisten Organisationen verbringen ihre ersten zwei Monate damit, Richtlinien zu schreiben, und investieren kaum etwas in die Nachweisinfrastruktur. Das ist die falsche Reihenfolge. Eine ausgearbeitete Richtlinie zur sicheren Entwicklung ohne pipeline-verknüpfte SAST-Ergebnisse oder datierte SBOMs führt im Stage-2-Audit zu einer wesentlichen Nichtkonformität – unabhängig davon, wie gut das Dokument formuliert ist.
Die Controls, an denen Teams am häufigsten scheitern, sind nicht die komplexen. A.8.31 (Umgebungstrennung) und A.8.8 (Schwachstellenmanagement) bestehen Audits regelmäßig nicht, nicht weil die Controls schwer umzusetzen wären, sondern weil die Nachweise verstreut oder undatiert sind. Beheben Sie die Nachweis-Kette, bevor Sie den Richtlinientext verfeinern.
Eine praktische Priorität: Automatisieren Sie die SBOM-Generierung zum Zeitpunkt des Releases, nicht als manuelle Quartalsaufgabe. Ein datiertes SBOM pro Release, das zusammen mit dem Release-Artefakt gespeichert wird, erfüllt die Nachweisanforderungen für A.8.8 und liefert Ihnen einen Abhängigkeits-Audit-Trail, der gleichzeitig mehrere Controls abdeckt. Dieser einzelne Pipeline-Schritt zahlt sich über mindestens vier Checklistenpunkte aus.
Ismscalculator verwandelt diese Checkliste in ein Budget und einen Projektplan
SDLC-Controls auf ISO 27001 zu mappen ist eine Sache. Zu wissen, was es Ihre Organisation kosten und wie lange es dauern wird, ist das, was ein Projekt genehmigungsfähig macht.
Der Ismscalculator berücksichtigt Ihre Unternehmensgröße, Branche und den aktuellen Sicherheitsreifegrad und erstellt eine maßgeschneiderte Kosten- und Aufwandsschätzung für Ihre vollständige ISO-27001-Implementierung – einschließlich des SDLC-Control-Workstreams. Die Plattform deckt alle vier Kontrollthemen der ISO/IEC 27001:2022 ab, generiert ein anpassbares Gantt-Diagramm, das Sie mit Stakeholdern teilen können, und exportiert einen PDF-Bericht, der für Budgetgespräche konzipiert ist. Die 2-minütige Bereitschaftsprüfung liefert Ihnen sofort und kostenlos einen Reifegrad-Snapshot. Wenn Sie tiefer einsteigen möchten, wandelt die vollständige ISO-27001-Bereitschaftsbewertung Ihre Checklisten-Lücken in einen phasenbasierten Projektplan mit Modellreferenzvergleichen um – damit Sie genau wissen, wo Sie im Vergleich zur Modellreferenz stehen.
Nützliche Quellen und weiterführende Literatur
Die nachstehenden Quellen unterstützen spezifische Abschnitte dieser Checkliste. Nutzen Sie sie, um den Klauseltext zu verifizieren, Auditorenerwartungen zu prüfen und die Checkliste für Ihre Umgebung anzupassen.
- ISO 27001 Application Security: Annex A Controls Guide (2022)
- ISO 27001 Application Security: Full Control Mapping
- ISO 27001 Secure SDLC: Key Requirements, Steps, and Templates (2026) | Konfirmity
- ISO 27001 A.14 Deep Dive — System Development and Maintenance in CI/CD - Regulated DevSecOps
- ICT Institute | ISO 27001 technological controls for software development
- Kostenloser ISO-27001-Bereitschaftscheck — 2-minütige Selbstbewertung | ISMS Calculator
- ISO 27001 für SaaS- und Technologieunternehmen: Ein praxisorientierter Leitfaden | ISMS Calculator