Diese Checkliste führt Teams ohne SSDLC-Vorkenntnisse durch die Planungsphase. Arbeitet jeden Punkt gemeinsam durch, dokumentiert Entscheidungen im Projektordner (z. B. docs/) und verknüpft die Nachweise mit eurem Ticket-System.

Vorbereitung #

• Plant ein Kick-off mit Product Owner, Entwicklung, QA und dem benannten Security Champion.
• Bestimmt eine verantwortliche Person, die offene Punkte trackt und Nachweise einsammelt.
• Legt einen asynchronen Abstimmungsrhythmus mit dem CISO fest (z. B. monatliche Sammelreviews).
• Richtet einen gemeinsamen Speicherort für Sicherheitsartefakte im Git-Unterordner /docs.
• Legt alle sicherheitsrelevanten Dokumente im Repository an. Hier ein Vorschlag, wie der Ordner docs/ aussehen kann:

  docs/
  ├─ auth.md
  ├─ betriebskonzept.md
  ├─ config-baseline.md
  ├─ hardening-guide.md
  ├─ logging.md
  ├─ mobile-release.md
  ├─ raci-matrix.md
  ├─ server-build-checkliste.md
  ├─ sicherheitsziele.md
  ├─ tech-stack.md
  ├─ testplan.md
  ├─ threat-model-v1.md
  └─ drittanbieter/
     └─ acme-assessment.md

Checkliste mit Erläuterungen #

1. Sicherheitsziele und Schutzbedarf dokumentieren #

   • Beschreibt, welche Daten verarbeitet werden und welches Niveau für Vertraulichkeit, Integrität und Verfügbarkeit erwartet wird.
   • Beispiel: Datenklassifizierung intern/vertraulich/geheim in /docs/sicherheitsziele.md. Siehe Beispiel.
   • Nachweis: Freigabekommentar oder Abnahme-Checklist im Product-Backlog-Item.

   ISO 27001 Annex A.8.28 verlangt dokumentierte Sicherheitsziele. Ohne diese fehlt der Nachweis, dass das Projekt den Schutzbedarf kennt.

2. Security Champion benennen und Eskalationspfad festlegen #

   • Bestimmt eine fachkundige Person im Team, die Sicherheitsfragen bündelt, Selbstprüfungen durchführt und nur Hochrisiko-Themen an den CISO eskaliert.
   • Dokumentiert den Eskalationsweg (Zeitfenster, Kontakt, Kriterien) mit regelmäßigen Check-in und Link zur Eskalationsmatrix.
   • “Regelmäßiger Check-in” bedeutet ein festes 15-minütiges Sync, in dem offene Risiken, eskalationswürdige Tickets und benötigte Entscheidungen geprüft werden. Der Security Champion oder PO sollte in einem der regelmäßigen Scrum-Meetings nach Security-Themen fragen.
   • Nachweis: Protokoll des Security-Champion-Meetings oder aktualisierte Verantwortlichkeitsmatrix (RACI).

   Die Norm fordert keinen dedizierten Champion. Ohne diese Rolle muss das Team sicherstellen, dass Aufgaben ersatzweise eindeutig verteilt und dokumentiert sind.

3. Sicherheitsschulungen sicherstellen #

   • Prüft, ob alle Entwickler die jährliche Pflicht-Schulung “Information security awareness” absolviert haben.
   • Nachweis: Schulungsmatrix mit Namen, Datum und Themen in docs/schulungsnachweise.md oder Ticket-Verweis auf zentrale HR-Dokumentation.

   Annex A.8.28 verlangt regelmäßige Sicherheitsschulungen für alle Entwickler. Teams ohne aktuelle Schulungsnachweise dürfen nicht mit der Entwicklung beginnen.

4. Bedrohungsmodell erstellen #

   • Identifiziert Angreifer, Angriffswege und Gegenmaßnahmen (z. B. STRIDE-Tabelle).
   • Beispiel: Diagramm aus Miro oder Bedrohungsmodell (Mermaid) als docs/threat-model-v1.md.
   • Nachweis: Verlinktes Modell im Architektur-Ticket.

   Threat Modeling ist nicht explizit vorgeschrieben. Es macht Risikoentscheidungen nachvollziehbar und stärkt den Audit-Nachweis für “Security by Design”.

5. Architektur-Patterns & AuthN/AuthZ definieren #

   • Dokumentiert Schichten, Services, Kommunikationsprotokolle und prüft sie mit dem Security Champion; vermerkt, ob Eskalation an den CISO nötig ist.
   • Beispiel: OAuth 2.0 Authorization Code Flow, API-Gateway mit Rate-Limits und Review durch den Security Champion im ADR.
   • Nachweis: docs/auth.md mit Kommentaren des Security Champions. Beispiel

   Annex A.8.28 fordert sichere Architekturvorgaben. Auditoren erwarten nachvollziehbare Entscheidungen zu AuthN/AuthZ.

6. Technologie-Stack und Coding-Standards festlegen #

   • Legt freigegebene Sprachen, Frameworks und Styleguides fest.
   • Beispiel: Backend Java 17 mit Spring Boot LTS; Frontend React 18 mit ESLint-Profil @company/security. Weitere Beispiele.
   • Nachweis: Tech-Stack-Liste in docs/tech-stack.md.

   Ohne freigegebenen Stack fehlt die Grundlage für sichere Programmierstandards (Annex A.8.28).

7. Validierung, Fehlerbehandlung, Logging und Monitoring planen #

   • Definiert Eingabevalidierung, Output-Encoding, Fehler-Handling und Logging-Anforderungen.
   • Beispiel: Validierung über class-validator, zentraler ErrorController, Logging nach OWASP-Empfehlung. Beispiel
   • Nachweis: Logging-Konzept in docs/logging.md.

   ISO 27001 verlangt kontrollierte Eingabe- und Fehlerbehandlung, um Schwachstellen zu vermeiden.

8. Geheimnisschutz, Schlüsselrotation und Konfiguration regeln #

   • Legt fest, wie Secrets gespeichert werden (z. B. HashiCorp Vault) und welche Rotationszyklen gelten.
   • Beispiel: Secrets ausschließlich via Azure Key Vault, Rotation alle 90 Tage, Deployment-Variablen als References.
   • Nachweis: Betriebskonzept-Eintrag oder Ticket mit Vault-Policy.
   • Vorlage: Betriebskonzept.

   Geheimnisverwaltung und Rotation sind Kernbestandteil von Annex A.8.27/A.8.29 und werden im Audit abgefragt.

9. Anforderungen an Drittanbieter & Schnittstellen dokumentieren #

   • Hält Mindestanforderungen wie Verschlüsselung, Audit-Logs und SLAs fest.
   • Onboarding-Checkliste = erfasst Stammdaten, NDA, Datenarten, Schnittstelle, Eskalationskontakte.
   • Risiko-Assessment = bewertet Impact/Likelihood, dokumentiert Rest-Risiko und Kontrollen.
   • Ohne Vertragsanhang: legt docs/drittanbieter-assessment.md an. Vorlage.
   • Nachweis: Ausgefüllte Checkliste/Assessment im Repo plus Ticket-Verweis.

   Annex A.15 verlangt dokumentierte Sicherheitsanforderungen für Lieferanten und Schnittstellen.

10. Review- und Testplan definieren #

• Plant SAST, DAST und Dependency-Scans, verantwortliche Personen und Freigabekriterien; vereinbart, wann Ergebnisse gebündelt an den CISO gehen.
• Beispiel: CI-Schritte für npm audit, trivy, manuelle Review-Gates im Merge-Request-Template plus monatlicher Security-Report.
• Nachweis: Testplan-Dokument inklusive Report-Termin in /docs/testplan.md.
• Vorlage: Testplan.

Ohne Testplan lässt sich kein Nachweis für A.8.29 erbringen; Audits prüfen diesen Punkt explizit.

Führt nach jedem Workshop die offenen Punkte in euer Backlog über, damit Verantwortlichkeiten und Fristen transparent bleiben. Konsolidiert offene Sicherheitsfragen vor dem vereinbarten Termin mit dem CISO, damit das Audit eine verlässliche Nachweiskette vorfindet.