Zum Hauptinhalt springen
CENEDRIL WIKI
EN
Annex A · Organisatorische Kontrolle

A.5.8 — IS im Projektmanagement

Aktualisiert am 3 Min. Geprüft von: Cenedril-Redaktion
A.5.8 ISO 27001ISO 27002BSI ISMS.1

Ein Unternehmen migriert sein CRM in die Cloud. Das Projektteam fokussiert sich auf Funktionalität, Datenmigration und Schulung. Sicherheitsanforderungen tauchen erst drei Tage vor Go-Live auf — als der Datenschutzbeauftragte eine Datenschutz-Folgenabschätzung einfordert. A.5.8 verhindert dieses Szenario, indem Informationssicherheit von Anfang an in jeden Projektlebenszyklus integriert wird.

Was verlangt die Norm?

  • Sicherheitsanforderungen erheben. In jedem Projekt müssen Informationssicherheitsanforderungen identifiziert und dokumentiert werden — unabhängig von Projekttyp und -größe.
  • Risikobewertung durchführen. Projektbezogene Sicherheitsrisiken werden bewertet und in der Projektplanung berücksichtigt.
  • Sicherheits-Gates einrichten. An definierten Meilensteinen wird geprüft, ob die Sicherheitsanforderungen erfüllt sind.
  • Sicherheit in die Projektmethodik integrieren. Das Projektvorgehensmodell der Organisation enthält Sicherheitsaktivitäten als feste Bestandteile.
  • Ergebnisse dokumentieren. Sicherheitsbewertungen, Entscheidungen und Restrisikoakzeptanzen werden dokumentiert.

In der Praxis

Projektvorgehensmodell ergänzen. Füge deinem bestehenden Projektvorgehensmodell (PRINCE2, Scrum, V-Modell) Sicherheitsaktivitäten hinzu: Sicherheitsanforderungen in der Planungsphase, Sicherheits-Review an jedem Gate, Sicherheitsabnahme vor Go-Live.

Skalierbare Bewertung einführen. Kleine Projekte: Checkliste mit 10–15 Fragen. Mittlere Projekte: kurze Risikobewertung mit Maßnahmenplan. Große Projekte: vollständige Sicherheitsrisikobewertung mit dediziertem Security Architect. Die Schwellenwerte definierst du über Budget, Projektdauer oder Art der verarbeiteten Daten.

ISB als Berater einbinden. Der ISB muss nicht jedes Projekt begleiten, aber zu Beginn konsultiert werden. Bei der Checkliste-Variante reicht ein Review durch den ISB. Bei großen Projekten nimmt der ISB an den Gate-Reviews teil.

Lessons Learned nutzen. Nach Projektabschluss fließen die Sicherheitserfahrungen zurück in die Checkliste und das Vorgehensmodell. So verbessert sich der Prozess mit jedem Projekt.

Typische Audit-Nachweise

Auditoren erwarten bei A.5.8 typischerweise diese Nachweise:

  • Projektvorgehensmodell — mit integrierten Sicherheitsaktivitäten und Gates (→ IS im Projektmanagement im Starter Kit)
  • Sicherheits-Checklisten — ausgefüllte Checklisten für konkrete Projekte
  • Risikobewertungen — projektbezogene Sicherheitsrisikobewertungen
  • Gate-Review-Protokolle — Nachweis, dass Sicherheit an Meilensteinen geprüft wurde
  • Sicherheitsabnahme — Freigabe des ISB vor Go-Live

KPI

% der Projekte, in denen Informationssicherheitsanforderungen bewertet und dokumentiert wurden

Gemessen als Prozentsatz aller Projekte im Projektportfolio. Ziel: 100%. Projekte ohne Sicherheitsbewertung sind eine Lücke, die Auditoren sofort identifizieren. Die Bewertungstiefe darf skalieren — eine Checkliste zählt.

Ergänzende KPIs:

  • Anteil der Projekte mit ISB-Beteiligung an Gate-Reviews
  • Anzahl der nachträglich identifizierten Sicherheitsmängel nach Go-Live
  • Durchschnittliche Kosten für nachträgliche Sicherheitsmaßnahmen in Projekten

BSI IT-Grundschutz

A.5.8 mappt auf eine zentrale BSI-Anforderung:

  • ISMS.1.A9 (Integration der Informationssicherheit in organisationsweite Abläufe und Prozesse) — verlangt, dass Informationssicherheit in alle Geschäftsprozesse und Projekte integriert wird. BSI formuliert dies bewusst breit: Die Integration betrifft Projekte, Beschaffung, Entwicklung und den laufenden Betrieb gleichermaßen.

Verwandte Kontrollen

A.5.8 verknüpft Projektmanagement mit Sicherheitsanforderungen:

Quellen

Häufig gestellte Fragen

Gilt A.5.8 auch für kleine Projekte?

Ja. Die Norm unterscheidet nicht nach Projektgröße. In der Praxis passt du den Aufwand an: Große Projekte bekommen eine vollständige Sicherheitsrisikobewertung, kleine Projekte durchlaufen eine Checkliste. Entscheidend ist, dass Sicherheit berücksichtigt wird — der Umfang darf skalieren.

Wann im Projektlebenszyklus muss Sicherheit berücksichtigt werden?

Von Anfang an. Die Anforderungsanalyse ist der richtige Zeitpunkt, Sicherheitsanforderungen zu erheben. In späteren Phasen werden sie teurer und schwieriger umzusetzen. Ergänze dein Projektvorgehensmodell um Sicherheits-Gates an den Meilensteinen.

Wer ist für die Sicherheit im Projekt verantwortlich?

Die Projektleitung trägt die Verantwortung dafür, dass Sicherheitsanforderungen im Projekt berücksichtigt werden. Der ISB oder IT-Sicherheitsbeauftragte berät und prüft. Bei großen Projekten kann ein dedizierter Security Architect sinnvoll sein.