Zum Hauptinhalt springen
CENEDRIL WIKI
EN
Starter Kit · Richtlinie

Richtlinie zu Informationssicherheit im Projektmanagement

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

Jedes Projekt verändert etwas: Systeme, Daten, Zugänge, Prozesse. Wo sich etwas verändert, entstehen Risiken — und genau deshalb gehört Informationssicherheit in den Projektlebenszyklus eingebaut, von der ersten Idee bis zum Abschluss.

ISO 27001 widmet dem Thema ein eigenes Control (A 5.8), das BSI verankert es in ISMS.1.A9 als organisationsweite Pflicht. Beide Rahmenwerke betonen: Informationssicherheit im Projektmanagement betrifft alle Projekte — Facility-Management, Organisationsentwicklung, Produkteinführungen, IT-Migrationen. Weiter unten findest du die komplette Vorlage auf Deutsch und Englisch.

Worum geht es konkret?

Projekte erzeugen temporäre Strukturen: eigene Teamzusammensetzungen, neue Zugänge, Testumgebungen, geteilte Dokumente mit externen Dienstleistern. Diese Strukturen existieren oft außerhalb der etablierten Betriebsprozesse — und genau dort entstehen Lücken.

Ein Beispiel: Ein Migrationsprojekt richtet eine Testumgebung mit Produktionsdaten ein. Das Projektteam bekommt erweiterte Zugriffsrechte. Externe Berater erhalten Zugang zum internen Netzwerk. Nach Projektende bleiben die Testumgebung, die Zugänge und die Daten bestehen — niemand räumt auf, weil kein Prozess dafür vorgesehen war.

Die Richtlinie definiert genau diesen Prozess: Wann werden Sicherheitsrisiken bewertet? Welche Anforderungen müssen vor der ersten Designentscheidung stehen? Wer prüft an welchem Gate? Und was passiert, wenn das Projekt endet?

Warum ist sie so wichtig?

Projekte sind die häufigste Quelle unkontrollierter Veränderungen. Im laufenden Betrieb greifen Change-Management-Prozesse. In Projekten gelten oft eigene Regeln, eigene Zeitpläne, eigener Budgetdruck. Sicherheitsanforderungen, die im Betrieb selbstverständlich sind (Zugriffskonzept, Datensicherung, Klassifizierung), werden im Projektkontext gerne auf „nach Go-live” verschoben — und dann vergessen.

Nachträgliche Sicherheit ist teuer. Wer Sicherheitsanforderungen erst nach der Architekturentscheidung einbringt, muss umbauen. ISO 27002 formuliert das klar: Frühzeitige Berücksichtigung in der Planungs- und Entwurfsphase führt zu wirksameren und kosteneffizienteren Ergebnissen.

Compliance-Klammer für das gesamte ISMS. Projekte berühren fast alle anderen Richtlinienbereiche: Zugriffskontrolle, Informationsklassifizierung, Lieferantensicherheit, sichere Entwicklung. Die Projektmanagement-Richtlinie stellt sicher, dass diese Querverweise bei jeder Projektinitiierung systematisch geprüft werden.

Was gehört in die Richtlinie?

Die Vorlage deckt sieben Abschnitte ab — hier die wichtigsten im Überblick:

  • Sicherheit im Projektlebenszyklus (A 5.8) — Risikobewertung bei Initiierung und an Meilensteinen, sichere Kommunikationskanäle, Wirksamkeitsprüfung von Maßnahmen
  • Frühzeitige Integration von Sicherheitsanforderungen — Anforderungs-Checkliste im Projektauftrag, Freigabe durch die Informationssicherheitsbeauftragte Person vor der Planungsphase
  • Informationsklassifizierung und Schutzbedarfsfeststellung — Inventar der im Projekt verarbeiteten Informationen, Klassifizierung nach Vertraulichkeit, Integrität und Verfügbarkeit
  • Authentisierung und Zugriffskontrolle — Zugriffsprofile für alle Nutzertypen (Projektteam, Betrieb, Externe), Provisionierung nach Least Privilege, Entzug bei Projektende
  • Lieferantensicherheit — Sicherheitsklauseln in Verträgen, Nachweispflichten, Rückgabe oder sichere Löschung von Informationen bei Vertragsende
  • Security-Gate-Reviews — Prüfpunkte an Projektphasen-Übergängen, Eskalationspfad für offene Findings
  • Rollen und Verantwortlichkeiten — Projektleitung, Sicherheitsansprechperson im Projekt, Informationssicherheitsbeauftragte Person, Geschäftsleitung

So führst du die Richtlinie ein

  1. 01

    Bestehende Projektmanagement-Methodik analysieren

    Bevor du die Richtlinie schreibst, brauchst du ein klares Bild davon, wie Projekte in deiner Organisation heute ablaufen. Gibt es ein standardisiertes Vorgehensmodell (Wasserfall, agil, hybrid)? Wo sind Entscheidungspunkte definiert? Gibt es bereits Gate-Reviews? Das Ziel: Sicherheitsaktivitäten in die bestehende Methodik einbetten, keinen Parallelprozess aufbauen.

  2. 02

    Sicherheits-Checkliste für den Projektauftrag erstellen

    Die Checkliste wird Teil des Projektauftrags und erfasst: Welche Daten verarbeitet das Projekt? Welche Klassifizierung haben sie? Welche Zugriffsrechte werden benötigt? Gibt es externe Beteiligte? Welche regulatorischen Anforderungen gelten? Die Informationssicherheitsbeauftragte Person gibt die ausgefüllte Checkliste frei, bevor das Projekt in die Planungsphase übergeht.

  3. 03

    Gate-Reviews in den Projektplan integrieren

    An mindestens vier Stellen — Initiierung, Planung, Umsetzung, Go-live — prüft die Informationssicherheitsbeauftragte Person (oder eine benannte Vertretung), ob die Sicherheitsanforderungen erfüllt sind. Findings werden dokumentiert und nachverfolgt. Ein Go-live mit offenen Findings erfordert eine formale Risikoakzeptanz durch die Geschäftsleitung.

  4. 04

    Vorlage anpassen und genehmigen lassen

    Ersetze die Platzhalter ([IHR_ORGANISATIONSNAME], [RICHTLINIEN_EIGENTÜMER_ROLLE]) und passe die Abschnitte an eure Projektlandschaft an. Kleine Organisation ohne externe Projektbeteiligte? Der Abschnitt zu Lieferantensicherheit kann gekürzt werden. Was übrig bleibt, muss eure Realität abbilden. Genehmigung durch die Geschäftsleitung einholen und an alle Projektverantwortlichen kommunizieren.

  5. 05

    Projektabschluss-Prozess etablieren

    Der am häufigsten vergessene Schritt: Bei Projektabschluss werden Zugänge entzogen, Testumgebungen abgebaut, Projektdaten klassifiziert übergeben oder sicher gelöscht und offene Findings in den Regelbetrieb überführt. Definiere eine Abschluss-Checkliste und mache sie zum festen Bestandteil deines Projektabschlussberichts.

Wo es in der Praxis schiefgeht

Aus Audit-Erfahrung, nach Häufigkeit sortiert:

1. Sicherheit wird auf „nach Go-live” verschoben. Im Projektplan steht „Sicherheitskonzept erstellen” als letzter Meilenstein. Dann gerät das Projekt unter Zeitdruck, und der Meilenstein fällt weg. Die Folge: ein System geht in Produktion ohne dokumentiertes Zugriffskonzept, ohne Klassifizierung der verarbeiteten Daten, ohne Härtung.

2. Kein Projektabschluss-Review. Das Projekt wird „abgeschlossen”, aber die Testumgebung mit Produktionsdaten läuft weiter, die erweiterten Zugriffsrechte des Projektteams bleiben bestehen, und die API-Keys für den externen Berater rotieren nie. Nach zwei Jahren weiß niemand mehr, wofür diese Ressourcen existieren.

3. Externe ohne Sicherheitsbriefing. Berater, Freelancer und Dienstleister werden ins Projektteam aufgenommen und erhalten Zugang zu Systemen und Daten — ohne dass sie über ihre Informationssicherheitspflichten informiert werden. Im Vorfall fehlt jede vertragliche Grundlage.

4. Risikobewertung als einmaliger Formalakt. Bei Projektstart wird eine Risikobewertung erstellt und abgeheftet. An den Meilensteinen findet keine Aktualisierung statt, obwohl sich Projektumfang, beteiligte Systeme und externe Abhängigkeiten verändert haben.

5. Fehlende Klassifizierung von Projektdaten. Projektdokumentation, Protokolle, Architekturdiagramme und Testergebnisse enthalten oft vertrauliche Informationen — werden aber auf allgemein zugänglichen Laufwerken oder in unverschlüsselten Collaboration-Tools abgelegt, weil niemand die Klassifizierung geprüft hat.

Vorlage: Informationssicherheit im Projektmanagement

Vollständige Richtlinie

Richtlinie zu Informationssicherheit im Projektmanagement

.md · DE.md · EN

Dokumentenkontrolle
Eigentümer: [RICHTLINIEN_EIGENTÜMER_ROLLE, z. B. Informationssicherheitsbeauftragte/r]
Genehmigt von: [GENEHMIGER_NAME_UND_ROLLE]
Version: [VERSION]
Gültig ab: [GÜLTIGKEITSDATUM]
Nächste Überprüfung: [NÄCHSTES_ÜBERPRÜFUNGSDATUM]

1. Rechtliche/Regulatorische Grundlage

ISO/IEC 27001:2022 / ISO/IEC 27002:2022, Anhang A — Organisatorische Maßnahmen:

  • A 5.8 — Informationssicherheit im Projektmanagement

BSI IT-Grundschutz:

  • ISMS.1.A9 (Integration der Informationssicherheit in organisationsweite Prozesse und Verfahren)

Weitere jurisdiktionsspezifische Gesetze — insbesondere Datenschutzrecht (DSGVO), sektorspezifische Projekt-Compliance-Anforderungen, Exportkontrolle und Beschränkungen grenzüberschreitender Datenübermittlungen — sind im Rechtsregister aufgeführt und werden durch Verweis einbezogen.

2. Zweck & Geltungsbereich

Diese Richtlinie legt fest, wie Informationssicherheit in das Projektmanagement bei [IHR_ORGANISATIONSNAME] integriert wird. Sie stellt sicher, dass Informationssicherheitsrisiken im Zusammenhang mit Projekten und deren Ergebnissen über den gesamten Projektlebenszyklus hinweg wirksam identifiziert, bewertet und behandelt werden, in Übereinstimmung mit ISO/IEC 27002:2022, A 5.8.

Die Richtlinie gilt für alle Projekte unabhängig von Komplexität, Größe, Dauer, Fachrichtung oder Anwendungsbereich — einschließlich Projekten für Kerngeschäftsprozesse, IKT, Gebäudemanagement, Produktentwicklung und andere unterstützende Prozesse. Sie erfasst alle an Projektarbeit beteiligten Personen, einschließlich Beschäftigter, Auftragnehmer, Berater und externer Lieferanten in Projektrollen.

Informationssicherheit wird nicht als separate Aktivität behandelt, die am Ende eines Projekts angefügt wird. Sie ist Teil der standardmäßigen Projektmanagement-Methodik von der Initiierung bis zum Abschluss und erfasst sowohl neue Projekte als auch laufende Aktivitäten.

3. Informationssicherheit im Projektlebenszyklus (A 5.8)

Informationssicherheit wird in das Projektmanagement integriert, um sicherzustellen, dass Sicherheitsrisiken als Teil jedes Projekts behandelt werden. Die verwendete Projektmanagement-Methodik erfordert, dass Informationssicherheitsaspekte von den frühesten Phasen an eingebettet und über den gesamten Projektlebenszyklus hinweg aufrechterhalten werden — nicht nur in IKT-Projekten, sondern in allen Projekttypen. Projektentwicklungsansätze, ob Wasserfall oder Agil, unterstützen Informationssicherheit auf eine strukturierte, der bewerteten Risikohöhe angepasste Weise. Die frühzeitige Berücksichtigung in den Planungs- und Designphasen führt zu wirksameren und kostengünstigeren Sicherheitsergebnissen.

3.1 Risikobewertung & -behandlung in Projekten

  • Integrierte Risikobewertung: Informationssicherheitsrisiken werden frühzeitig und periodisch über den gesamten Projektlebenszyklus hinweg als integrierter Teil des übergreifenden Projektrisikomanagements bewertet und behandelt. Das Projektrisikoregister umfasst Informationssicherheitsrisiken neben anderen Projektrisiken. Die Risikobewertung wird bei Projektinitiierung durchgeführt und an definierten Meilensteinen wiederholt — mindestens in der Planungs-, Ausführungs- und Vor-Abschluss-Phase.
  • Kommunikationssicherheit in der Ausführungsphase: Informationssicherheitsrisiken im Zusammenhang mit der Ausführung eines Projekts — einschließlich der Sicherheit interner und externer Kommunikationskanäle, des Datenaustauschs zwischen Projektbeteiligten und des Zugriffs auf Projektumgebungen — werden über den gesamten Projektlebenszyklus hinweg identifiziert und behandelt. Sichere Kommunikationskanäle werden für das Projekt definiert. Regeln für den Austausch von Projektinformationen mit internen Teams, externen Partnern und Kunden werden bei der Projektinitiierung festgelegt und während der Ausführung durchgesetzt.

3.2 Frühzeitige Integration von Sicherheitsanforderungen

  • Sicherheitsanforderungen bei der Initiierung: Informationssicherheitsanforderungen werden in den frühen Phasen jedes Projekts adressiert — bevor wesentliche Designentscheidungen getroffen oder externe Verpflichtungen eingegangen werden. Dies umfasst Anwendungssicherheitsanforderungen, Anforderungen zur Einhaltung geistiger Eigentumsrechte, Datenschutzanforderungen und Anforderungen aus anderen geltenden IS-Maßnahmen. Eine Checkliste für Sicherheitsanforderungen wird als Teil des Projektauftrags ausgefüllt. Das Projekt geht nicht in die Planungsphase über, ohne dass die Sicherheitsanforderungen dokumentiert und von der/dem Informationssicherheitsbeauftragten oder einer benannten Sicherheitsprüfinstanz freigegeben wurden.

3.3 Überprüfung & Wirksamkeitstests

  • Fortschrittsüberprüfung & Wirksamkeitstests: Der Fortschritt bei der Behandlung von Informationssicherheitsrisiken wird an vordefinierten Projektmeilensteinen überprüft. Die Wirksamkeit von Sicherheitsmaßnahmen wird bewertet und, wo machbar, getestet — etwa durch Sicherheitsüberprüfungen, Penetrationstests oder Code-Reviews — bevor ein Projektergebnis live geht oder formal abgenommen wird. Feststellungen werden bis zum Abschluss nachverfolgt und an den Projektsponsor gemeldet. Ergebnisse werden in der Projektakte dokumentiert.

4. Ermittlung der Informationssicherheitsanforderungen (A 5.8)

Informationssicherheitsanforderungen für Produkte oder Dienste, die durch ein Projekt bereitgestellt werden, werden mit mehreren Methoden ermittelt: durch Ableitung von Compliance-Anforderungen aus dieser Richtlinie, themenspezifischen Richtlinien und Vorschriften sowie aus Aktivitäten wie Threat Modelling, Vorfallanalysen, Nutzung von Schwachstellen-Schwellenwerten und Notfallplanung. Dies stellt sicher, dass Architektur und Design von Informationssystemen auf Basis der Betriebsumgebung vor bekannten Bedrohungen geschützt sind. Die folgenden Punkte werden bei der Ermittlung der Anforderungen für alle Projekttypen berücksichtigt:

4.1 Informationsklassifizierung & Schutzbedarf

  • Informationsinventar & Geschäftsauswirkungen: Bei der Projektinitiierung werden die Informationen identifiziert, die durch das Projekt erzeugt, verarbeitet, gespeichert oder übertragen werden. Jeder Informationstyp wird gemäß der Richtlinie zur Informationsklassifizierung und Kennzeichnung klassifiziert, und die potenziellen negativen Geschäftsauswirkungen unzureichender Sicherheit werden bewertet — einschließlich Szenarien wie unbefugte Offenlegung, fehlerhafte Änderung oder Nichtverfügbarkeit. Klassifizierung und Auswirkungsbewertung bestimmen die Auswahl der Sicherheitsmaßnahmen für das Projekt.
  • Vertraulichkeits-, Integritäts- & Verfügbarkeitsanforderungen: Die erforderlichen Schutzstufen für jeden identifizierten Informationstyp und zugehörigen Wert werden hinsichtlich Vertraulichkeit (C), Integrität (I) und Verfügbarkeit (A) festgelegt. Eine standardisierte Schutzbedarfsbewertungsmatrix bildet die Klassifizierungsstufe und CIA-Anforderungen auf spezifische Sicherheitsmaßnahmen ab. Diese Anforderungen werden vor Beginn der Designphase in der Projektanforderungsspezifikation dokumentiert.

4.2 Authentifizierung & Zugriffskontrolle

  • Authentifizierungsanforderungen: Der erforderliche Identitätsvertrauensgrad für jede Kategorie von Entitäten, die mit dem Projektergebnis interagieren — Nutzer, Systeme und Dienste — wird festgelegt. Authentifizierungsanforderungen werden aus diesem Vertrauensgrad abgeleitet: Interaktionen mit niedrigem Vertrauensgrad verwenden passwortbasierte Authentifizierung, Interaktionen mit mittlerem Vertrauensgrad erfordern Multi-Faktor-Authentifizierung, Interaktionen mit hohem Vertrauensgrad erfordern zertifikatsbasierte oder Hardware-Token-Authentifizierung. Diese Anforderungen werden in der Projektanforderungsspezifikation dokumentiert und stimmen mit der Zugriffskontroll-Richtlinie überein.
  • Zugriffsbereitstellung & Autorisierung: Zugriffsbereitstellungs- und Autorisierungsprozesse werden für alle Benutzertypen definiert, die mit dem Projekt und seinen Ergebnissen befasst sind: Kunden und geschäftliche Endnutzer, privilegierte und technische Nutzer, Projektteammitglieder, Betriebspersonal, das nach Projektabschluss übernimmt, und externe Lieferanten. Für jeden Benutzertyp werden Bereitstellungsworkflow, Genehmigungsbehörde, Zugriffsprüfzyklus und Trigger für die Deprovisionierung spezifiziert. Der Zugriff auf Projektumgebungen folgt dem Prinzip des geringsten Privilegs und wird entfernt, wenn er nicht mehr erforderlich ist.

4.3 Nutzerpflichten & -verantwortlichkeiten

  • Sicherheitsbriefing für Nutzer: Alle Personen, die einem Projekt beitreten — Beschäftigte, Auftragnehmer und externe Parteien — werden über ihre projektrelevanten Informationssicherheitspflichten und -verantwortlichkeiten informiert, bevor ihnen Zugriff auf Projektressourcen gewährt wird. Dazu gehören die akzeptable Nutzung von Projektsystemen und -daten, Verfahren zur Vorfallmeldung, Datenhandhabungsregeln basierend auf der Klassifizierung und die Konsequenzen von Richtlinienverstößen. Briefings werden dokumentiert und die Bestätigung wird erfasst.

4.4 Geschäftsprozessanforderungen

  • Transaktionsprotokollierung, Überwachung & Nichtabstreitbarkeit: Anforderungen aus den durch das Projekt unterstützten Geschäftsprozessen werden identifiziert und in die Projektanforderungen aufgenommen. Dies umfasst Anforderungen an die Transaktionsprotokollierung (welche Ereignisse protokolliert werden, Aufbewahrungsfristen), Überwachungsanforderungen (Echtzeit oder periodisch) und Nichtabstreitbarkeitsanforderungen (bei denen der Nachweis des Eintretens oder Nichteintretens einer Aktion erhalten bleibt). Integrationspunkte für die Überwachung mit der zentralen Protokollierungs- und SIEM-Infrastruktur der Organisation werden in der Designphase spezifiziert.
  • Integration mit IS-Kontrollinfrastruktur: Anforderungen, die durch andere Informationssicherheitsmaßnahmen vorgegeben sind, werden identifiziert und in das Projekt aufgenommen. Dies umfasst Schnittstellenanforderungen für Protokollierungs- und Überwachungssysteme, Data-Loss-Prevention-Systeme (DLP), Identitäts- und Zugriffsmanagement-Systeme, Schwachstellenmanagement-Feeds und Vorfallmanagement-Tools. Die Projektarchitektur ist so gestaltet, dass sie diese Integrationspunkte unterstützt, und wird in den Überprüfungsphasen dagegen validiert.

4.5 Rechtliche & regulatorische Compliance

  • Einhaltung des rechtlichen & regulatorischen Umfelds: Geltende rechtliche, gesetzliche, regulatorische und vertragliche Anforderungen, die für das Projekt relevant sind, werden bei der Initiierung identifiziert und als Sicherheitsanforderungen dokumentiert. Dies umfasst Datenschutzgesetzgebung (einschließlich DSGVO, wo anwendbar), sektorspezifische Vorschriften, vertragliche Sicherheitspflichten und etwaige Exportkontrollen oder Beschränkungen für grenzüberschreitende Datenübermittlungen. Die Rechtsberatung wird in die Validierung der Compliance-Anforderungen einbezogen. Die Compliance-Zuordnung wird in der Projektdokumentation geführt und bei Änderungen des regulatorischen Umfelds überprüft.

4.6 Drittparteien-Gewährleistung

  • Sicherheitsgewährleistung durch Dritte: Wenn ein Projekt Dritte einbezieht (Lieferanten, Subunternehmer, Berater, Cloud-Dienstleister), wird der erforderliche Grad der Gewährleistung festgelegt, dass diese Dritten die Informationssicherheitsrichtlinie und die themenspezifischen Richtlinien der Organisation erfüllen. Dieser Gewährleistungsgrad treibt die Aufnahme spezifischer Sicherheitsklauseln in Vereinbarungen und Verträge, einschließlich des Auditrechts, der Anforderungen an Sicherheitszertifizierungen, der Pflichten zur Vorfallmeldung und der Regelungen zur Rückgabe oder sicheren Vernichtung von Informationen am Vertragsende. Die Einhaltung vertraglicher Sicherheitsanforderungen wird während des Projekts und bei der Übergabe verifiziert.

5. Projekt-Governance & Rollen

Die Angemessenheit von Informationssicherheitsaspekten und -aktivitäten wird in vordefinierten Phasen durch geeignete Personen oder Governance-Gremien nachverfolgt. Verantwortlichkeiten und Befugnisse für Informationssicherheit, die für jedes Projekt relevant sind, werden bei der Projektinitiierung definiert und bestimmten Rollen zugewiesen.

Informationssicherheit ist in alle Geschäftsprozesse und Projektaufgaben integriert. Dies gilt nicht nur für neue Projekte, sondern auch für laufende Aktivitäten. Die/der Informationssicherheitsbeauftragte wird in alle sicherheitsrelevanten Entscheidungen über den gesamten Projektlebenszyklus hinweg einbezogen und koordiniert mit anderen Risikomanagementfunktionen innerhalb der Organisation.

  • Security-Gate-Reviews: Vordefinierte Projektphasen — mindestens: Projektinitiierung, Ende der Design-/Planungsphase, Ende der Bau-/Entwicklungsphase und vor Go-Live — enthalten ein Security-Gate, in dem die/der Informationssicherheitsbeauftragte oder eine benannte Prüfinstanz bewertet, ob die Sicherheitsanforderungen erfüllt wurden, bevor das Projekt in die nächste Phase übergeht.
  • Zuweisung der Projektsicherheitsrolle: Bei der Projektinitiierung wird ein Projektsicherheitsverantwortlicher benannt. Für größere Projekte ist dies eine dedizierte Rolle; für kleinere Projekte wird sie dem Projektmanager oder einem benannten Teammitglied zugewiesen. Der Projektsicherheitsverantwortliche koordiniert mit der/dem Informationssicherheitsbeauftragten, stellt sicher, dass die Checkliste der Sicherheitsanforderungen ausgefüllt wird, verfolgt Sicherheitsfeststellungen und vertritt Sicherheitsinteressen in Projekt-Governance-Sitzungen.
  • Eskalationspfad: Sicherheitsprobleme, die im Projektteam nicht gelöst werden können, werden an die/den Informationssicherheitsbeauftragte/n und, falls erforderlich, an die Geschäftsleitung eskaliert. Nicht gelöste Sicherheitsfeststellungen, die eine Go-Live-Entscheidung blockieren, werden dokumentiert, und die Entscheidung, mit oder ohne Behebung fortzufahren, wird auf einer angemessenen Governance-Ebene getroffen, wobei Restrisiken formal akzeptiert werden.

6. Rollen & Verantwortlichkeiten

  • Geschäftsleitung: Genehmigt diese Richtlinie, stellt sicher, dass ausreichende Ressourcen für Sicherheitsaktivitäten in Projekten bereitgestellt werden, und trifft endgültige Entscheidungen über aus der Projekt-Governance eskalierte Restrisiken.
  • Informationssicherheitsbeauftragte/r (ISB): Pflegt diese Richtlinie und den Rahmen der Projektsicherheitsanforderungen. Nimmt an Security-Gate-Reviews teil und berät Projektteams zu Sicherheitsanforderungen, Threat Modelling und Kontrollauswahl. Koordiniert mit anderen Risikomanagementfunktionen und wird in alle sicherheitsrelevanten Projektentscheidungen einbezogen. Verfolgt die Sicherheitsaspekte des Projektportfolios.
  • Projektsponsoren / Projekteigentümer: Stellen sicher, dass Projekte in ihrer Verantwortung gemäß dieser Richtlinie durchgeführt werden. Akzeptieren Informationssicherheits-Restrisiken auf Governance-Ebene und stellen ein angemessenes Budget für Sicherheitsaktivitäten im Projekt sicher.
  • Projektmanager: Integrieren Sicherheitsaktivitäten in den Projektplan und -zeitplan. Füllen die Checkliste der Sicherheitsanforderungen bei der Projektinitiierung aus. Benennen den Projektsicherheitsverantwortlichen. Eskalieren ungelöste Sicherheitsprobleme und stellen sicher, dass Sicherheitsfeststellungen bis zum Abschluss nachverfolgt werden.
  • Projektsicherheitsverantwortliche: Koordinieren Informationssicherheitsaktivitäten innerhalb des Projekts. Moderieren Threat Modelling und Schutzbedarfsbewertungen. Überprüfen Sicherheitsanforderungen mit der/dem Informationssicherheitsbeauftragten. Stellen sicher, dass Zugriffsbereitstellung und Nutzerbriefings abgeschlossen sind, bevor Zugriff gewährt wird.
  • IT & Systemarchitektur: Setzt Sicherheitsanforderungen im technischen Design um und stellt sicher, dass Schnittstellen zu Protokollierungs-, Überwachungs-, DLP- und IAM-Infrastruktur in die Lösung eingebaut werden. Nimmt an Sicherheitstests vor dem Go-Live teil.
  • Alle Projektbeteiligten: Befolgen das beim Projekt-Onboarding erhaltene Sicherheitsbriefing, handhaben Projektinformationen gemäß ihrer Klassifizierung, verwenden nur genehmigte Kommunikationskanäle und melden Sicherheitsvorfälle an den Projektsicherheitsverantwortlichen oder die/den Informationssicherheitsbeauftragte/n.

7. Überprüfung & Pflege

Diese Richtlinie und der zugehörige Rahmen der Projektsicherheitsanforderungen werden überprüft:

  • Mindestens jährlich, um zu verifizieren, dass die Anforderungen und Prozesse mit der aktuellen Bedrohungslage, dem organisatorischen Risikoprofil und den geltenden rechtlichen und regulatorischen Anforderungen im Einklang bleiben.
  • Nach jedem wesentlichen Sicherheitsvorfall, der aus einer Projektumgebung entsteht, um Lessons Learned zu identifizieren und den Anforderungsrahmen entsprechend zu aktualisieren.
  • Wenn wesentliche Änderungen an der Projektmanagement-Methodik, der IT-Landschaft der Organisation oder dem geltenden rechtlichen und regulatorischen Umfeld auftreten.
  • Wenn Aktualisierungen von ISO/IEC 27002, ISO 21500, ISO 21502 oder dem BSI IT-Grundschutz-Kompendium neue für die Informationssicherheit im Projektmanagement relevante Leitlinien einführen.

Die/der Informationssicherheitsbeauftragte koordiniert die Überprüfung und stellt sicher, dass etwaige Änderungen an Projektmanager kommuniziert und in die Projektmanagement-Methodik integriert werden.

Quellen

Abgedeckte ISO-27001-Kontrollen

A.5.8 Informationssicherheit im Projektmanagement

Häufig gestellte Fragen

Gilt die Richtlinie auch für kleine Projekte?

Ja. ISO 27002 A 5.8 unterscheidet ausdrücklich nicht nach Projektgröße. Auch ein zweimonatiges Migrationsprojekt mit drei Beteiligten verarbeitet Daten, erstellt Zugänge und produziert Ergebnisse, die geschützt werden müssen. Der Umfang der Sicherheitsaktivitäten skaliert mit dem Risiko — die Grundstruktur (Risikobewertung, Anforderungen, Abschluss-Review) bleibt gleich.

Brauche ich für jedes Projekt eine eigene Risikobewertung?

Ja, mindestens eine initiale. Bei Projektstart bewertest du die Informationssicherheitsrisiken des Projekts und dokumentierst sie im Projektrisiko-Register. An definierten Meilensteinen (Planung, Umsetzung, kurz vor Go-live) wird die Bewertung aktualisiert. Für Standardprojekte mit niedrigem Risiko reicht ein kompakter Fragebogen; komplexe Projekte brauchen eine vollständige Bedrohungsmodellierung.

Wer ist für die Sicherheit im Projekt verantwortlich?

Die Projektleitung trägt die operative Verantwortung und benennt bei Projektstart eine Ansprechperson für Informationssicherheit (bei großen Projekten eine eigene Rolle, bei kleinen die Projektleitung selbst). Die Informationssicherheitsbeauftragte Person berät, nimmt an Gate-Reviews teil und entscheidet bei Eskalationen. Die Geschäftsleitung genehmigt die Richtlinie und akzeptiert Restrisiken.

Was passiert bei Projektabschluss?

Beim Abschluss werden Projektzugänge entzogen, Projektdaten klassifiziert übergeben oder sicher gelöscht, temporäre Umgebungen abgebaut und Sicherheitsdokumentation archiviert. Offene Findings werden in den Regelbetrieb überführt. Ohne diesen Schritt bleiben verwaiste Zugänge und ungesicherte Testdaten zurück.

Wie hängt diese Richtlinie mit der Richtlinie zur sicheren Softwareentwicklung zusammen?

Die Projektmanagement-Richtlinie definiert den organisatorischen Rahmen: Risikobewertung bei Projektstart, Gate-Reviews, Rollen, Abschluss. Die Richtlinie zur sicheren Softwareentwicklung geht tiefer ins technische Detail — sichere Coding-Standards, Code-Reviews, Testverfahren. Bei Softwareprojekten greifen beide Dokumente ineinander: das eine steuert den Projektprozess, das andere den Entwicklungsprozess.