ISMS-Projektmanagement bedeutet, Informationssicherheitsanforderungen als Projektliefergegenstände zu behandeln – nicht als nachträgliche Compliance-Maßnahmen. Gemäß ISO/IEC 27001 verlangt ein ISMS (Informationssicherheits-Managementsystem) eine dokumentierte Risikobeurteilung und Risikobehandlung. Diese Anforderungen lassen sich direkt auf die Standard-Prozessgruppen des PMBOK abbilden: Initiierung, Planung, Ausführung, Überwachung und Abschluss. Wer diese Zuordnung frühzeitig richtig vornimmt, erlebt Informationssicherheit nicht mehr als separaten, nachgelagerten Track.
Bevor Sie Ihren Projektplan anfassen, sollten Sie diese fünf Punkte klären:
- Den ISMS-Geltungsbereich für dieses spezifische Projekt definieren (welche Systeme, Daten und Prozesse einbezogen sind)
- Eine fokussierte Risikobeurteilung für neue oder veränderte Assets durchführen
- Einen Risikobehandlungsplan und passende Einträge in der Anwendbarkeitserklärung (SoA) erstellen
- Einen namentlich benannten Informationssicherheitsverantwortlichen bestimmen – keine geteilte Verantwortung
- Sicherheitstests und einen formalen Übergabepunkt vor dem Go-live einplanen
Wichtigste Erkenntnisse
ISMS-Anforderungen in die Standard-Projektphasen zu integrieren – anstatt die Zertifizierung als separaten Track zu behandeln – hält ISO 27001-Vorhaben im Zeitplan und macht sie auditbereit.
| Punkt | Details |
|---|---|
| Geltungsbereich zuerst, immer | Den ISMS-Geltungsbereich für das Projekt während der Initiierung definieren, bevor eine Risikobeurteilung beginnt. |
| SoA schrittweise aufbauen | Einträge in der Anwendbarkeitserklärung ergänzen, sobald eine Maßnahme relevant wird – nicht in einem Endspurt am Projektabschluss. |
| Sicherheitsverantwortlichen benennen | Einen eigenständigen Informationssicherheitsverantwortlichen getrennt vom Projektleiter bestimmen, um Verantwortungslücken zu vermeiden. |
| Jede Phase mit einem Gate absichern | Kurze Sicherheitsprüfungen an Phasengrenzen durchführen, statt kurz vor dem Abschluss in ein einziges Audit-Sprint zu verfallen. |
| Aufwand mit realen Zahlen schätzen | Tools wie die ISMS-Rechner Readiness-Bewertung übersetzen Unternehmensgröße und Reifegrad in konkrete Stundenangaben statt vager Schätzungen. |
Inhaltsverzeichnis
- ISMS-Projektmanagement-Grundlagen: Was ISO/IEC 27001 tatsächlich fordert
- Warum Sicherheitsanforderungen in den Projektplan integrieren?
- Was sollte in jeder Projektphase geschehen?
- Welche Dokumente und Nachweise benötigt ein ISMS-Projekt?
- Wer verantwortet was in einem ISMS-Projekt?
- Wie viel Mehraufwand verursacht ISMS-Arbeit tatsächlich?
- Welche Fehler bringen ISMS-Projekte am häufigsten zum Scheitern?
- Ein pragmatischer Ansatz für die Leitung ISMS-konformer Projekte
- Den ISMS-Aufwand schätzen, bevor Sie einen Zeitplan festlegen
- Weiterführende Literatur zu ISMS und Projektnormen
- Häufig gestellte Fragen
- Quellen
ISMS-Projektmanagement-Grundlagen: Was ISO/IEC 27001 tatsächlich fordert
Ein ISMS ist die Gesamtheit der Richtlinien, Risikoprozesse und Maßnahmen, mit denen eine Organisation Informationswerte dauerhaft schützt. ISO/IEC 27001 ist die internationale Norm, die dieses System zertifiziert. Sie verlangt eine dokumentierte Risikobeurteilung, einen Risikobehandlungsplan sowie Nachweise, dass die gewählten Maßnahmen tatsächlich wirksam sind.
Im Projektkontext bedeutet das konkrete Verpflichtungen, die bestimmten Klauseln zugeordnet sind: Die Risikobeurteilung muss neue Assets erfassen, die das Projekt einführt; die SoA muss aktualisiert werden, wenn das Projekt die Anwendbarkeit von Maßnahmen ändert; und jeder im Projektverlauf hinzugezogene Lieferant muss einer dokumentierten Sicherheitsprüfung unterzogen werden.
Stellen Sie sich vor, Ihr Team integriert mitten im Projekt eine Zahlungsschnittstelle eines Drittanbieters. Diese eine Entscheidung löst eine Lieferantensicherheitsprüfung aus, einen neuen SoA-Eintrag für Maßnahmen zur Lieferantenbeziehung und wahrscheinlich eine neue Risikobeurteilungszeile für Daten während der Übertragung. Das ist kein optionaler Papierkram – das ist genau das, was ein Auditor später einsehen will.
Ein wichtiger Hinweis: Das Akronym „ISM" taucht in anderen Fachgebieten auch für „Interpretive Structural Modeling" auf – eine völlig unverwandte Systemtechnik. Wer zu diesem Thema recherchiert und auf einen Artikel über strukturelles Modellieren stößt, ist beim falschen ISM gelandet.
Warum Sicherheitsanforderungen in den Projektplan integrieren?
Sicherheit nachträglich hinzuzufügen kostet mehr als sie von Anfang an einzubauen. Integration während der Planung – nicht nach der Lieferung – hält ein Projekt im Zeitplan, statt es in Nachbesserungen zu versenken.
- Weniger Nacharbeit, weil Maßnahmen parallel zu Features entwickelt statt nachträglich eingebaut werden
- Schnellere Zertifizierungsbereitschaft, da Nachweise sich beim Aufbau natürlich ansammeln
- Klarere Abnahmekriterien, denn „fertig" schließt eine Sicherheitsabnahme ein – nicht nur eine Demo
- Geringeres operatives Risiko nach der Übergabe, weil Lücken während des Tests und nicht im Produktivbetrieb entdeckt werden
- Ein Audit-Trail, der bereits existiert, statt eines, den man rekonstruieren muss
Für einen Sponsor, der Zeit, Kosten und Qualität abwägt, ist das ein klares Argument: Sicherheitsaufgaben parallel zur Lieferung erledigt verursachen kaum Netto-Verzögerung; nach der Lieferung erledigt, fast immer. Ein Faktor wiegt dabei schwerer als jede Checkliste: sichtbare Managementunterstützung. Projekte, bei denen ein Sponsor den Risikobehandlungsplan aktiv unterstützt und SoA-Einträge prüft, durchlaufen die Zertifizierung mit weit weniger Überraschungen.
Was sollte in jeder Projektphase geschehen?
Standardmäßiges Projektmanagement balanciert Zeit, Kosten und Qualität über Initiierung, Planung, Ausführung, Überwachung und Abschluss. ISMS-Arbeit fügt sich in dieselbe Struktur ein. Hier ist, was wohin gehört.
Initiierung
- Den ISMS-Geltungsbereich für das Projekt definieren: welche Assets, Systeme und Datenflüsse tatsächlich betroffen sind
- Die betroffenen Informationswerte identifizieren und deren aktuelle Eigentümer ermitteln
- Einen Projektsponsor und einen namentlich benannten Informationssicherheitsverantwortlichen – getrennt von der Projektleitung – benennen
- ISMS-Abnahmekriterien in den Projektauftrag aufnehmen, sodass die Sicherheitsabnahme ein definierter Liefergegenstand ist, keine späte Ergänzung
Planung
- Eine fokussierte Risikobeurteilung durchführen, die auf das beschränkt ist, was dieses Projekt verändert – keine vollständige Organisationsüberprüfung
- Einen Risikobehandlungsplan erstellen und die relevanten SoA-Einträge entwerfen
- Sicherheitstestfenster direkt in den Projektzeitplan einplanen – nicht als Puffer am Ende
- Sicherheitsanforderungen an Lieferanten in Beschaffungsunterlagen aufnehmen, bevor Verträge unterzeichnet werden
- Schulungs- und Sensibilisierungsmaßnahmen für alle einplanen, die das neue System betreiben werden
Ausführung
- Die in der Planung definierten Maßnahmen umsetzen
- Sicherheitstests auf Komponentenebene und erneut bei der Integration durchführen
- Nachweise laufend dokumentieren: Testprotokolle, Scan-Ergebnisse, Konfigurations-Screenshots
- Lieferantenleistungen anhand der vertraglich festgelegten Sicherheitsanforderungen verfolgen
Überwachung und Steuerung
- Ein aktuelles Risikoregister führen – kein statisches Dokument, das einmal erstellt und dann vergessen wird
- Behebungsmaßnahmen für Maßnahmen verfolgen, die Tests nicht bestehen
- Kurze Sicherheitsstatusberichte in die Lenkungsausschuss-Dashboards einspeisen – neben Kosten- und Terminmetriken
- Jede Änderung des Projektumfangs durch ein formales Änderungsmanagementverfahren leiten, mit beigefügter Sicherheitsfolgenabschätzung
Abschluss und Übergabe
- Das Nachweispaket fertigstellen: abgeschlossene SoA-Einträge, Testberichte, Schulungsteilnahmenachweise
- Lessons Learned speziell für die Sicherheitsarbeit erfassen – nicht nur Lieferlektionen
- Die betriebliche Verantwortung an das Informationssicherheits- oder Betriebsteam übertragen, mit einem namentlich benannten übernehmenden Verantwortlichen
- Das erste Folgeaudit oder die erste Verbesserungsüberprüfung ansetzen, bevor das Projektteam aufgelöst wird
Praxis-Tipp: Bauen Sie die SoA schrittweise auf – einen Eintrag pro Maßnahme, sobald sie relevant wird – und führen Sie an jeder Phasengrenze eine kurze Sicherheits-Gate-Prüfung durch, statt am Ende einen einzigen Audit-Sprint zu absolvieren. Projekte, die die SoA erst beim Abschluss abgleichen, finden fast immer Lücken, die es erfordern, abgeschlossene Arbeit wieder aufzunehmen.
Welche Dokumente und Nachweise benötigt ein ISMS-Projekt?
Auditoren verlassen sich nicht auf Ihr Wort. Sie wollen einen Dokumentenpfad – und ein Großteil dieses Pfades entsteht während des Projekts selbst, nicht aus dem bestehenden ISMS der Organisation.
Einige Dokumente gehören bereits der Organisation – etwa die übergeordnete ISMS-Richtlinie und die oberste SoA. Die Aufgabe Ihres Projekts besteht darin, die spezifischen Einträge und Nachweise zu liefern, die in diese Struktur einfließen: eine bereichsbezogene Risikobeurteilung, einen Risikobehandlungsplan für die durch das Projekt eingeführten Änderungen, aktualisierte SoA-Zeilen für neue oder geänderte Maßnahmen, Sicherheitstestberichte, Lieferantensicherheitsnachweise und Schulungsabschlussnachweise.
Für ein einzelnes geliefertes Feature erwartet ein Auditor typischerweise:
- Den Risikobeurteilungseintrag zu den Datenflüssen dieses Features
- Die SoA-Zeile, die zeigt, welche Maßnahme gilt und warum
- Testnachweis, der bestätigt, dass die Maßnahme wie vorgesehen funktioniert
- Lieferantendokumentation, falls ein Drittanbieter das Feature berührt hat
- Einen unterzeichneten Abnahmedatensatz, der belegt, dass die Sicherheitsfreigabe vor dem Release erfolgte
Unsere Zertifizierungs-Checkliste schlüsselt dies in einer ausführlicheren Schritt-für-Schritt-Liste auf, wenn Sie diese einem laufenden Projekt gegenüberstellen möchten.
Wer verantwortet was in einem ISMS-Projekt?
Unklarheiten über Verantwortlichkeiten sind einer der häufigsten Gründe, warum ISMS-Aufgaben in Projekten ins Stocken geraten. Sechs Rollen tragen typischerweise Verantwortung: der Projektsponsor (finanziert und fördert die Arbeit), der Projektleiter (plant und verfolgt sie), der Informationssicherheitsverantwortliche oder Fachverantwortliche (definiert, was „konform" für diesen Geltungsbereich bedeutet), der technische Leiter (implementiert Maßnahmen), Lieferantenverantwortliche (verwalten Sicherheitspflichten gegenüber Dritten) und der Lenkungsausschuss (prüft den Status und genehmigt Umfangsänderungen mit Sicherheitsauswirkungen).
Governance in der Praxis bedeutet: Sicherheits-Gates an definierten Checkpoints durchführen, jede sicherheitsrelevante Umfangsänderung durch das formale Änderungsmanagement leiten, einen regelmäßigen Berichtszyklus an den Lenkungsausschuss aufrechterhalten und explizite Freigaben für Nachweise vor dem Abschluss einholen. Fragen Sie jeden Rolleninhaber direkt, bevor Sie den Plan abschließen: Welche Nachweise brauchen Sie von mir, wann und wer übernimmt diese Arbeit bei der Übergabe? Wer dieses Gespräch auslässt, entdeckt Verantwortungslücken drei Wochen vor dem Go-live. Unser Leitfaden zur Verantwortung von IT-Managern zeigt, wie sich das in der Praxis typischerweise aufteilt.
Wie viel Mehraufwand verursacht ISMS-Arbeit tatsächlich?
Der Aufwand skaliert mit einigen konkreten Faktoren: wie viele Informationswerte das Projekt berührt, wie viele Lieferanten beteiligt sind, wie ausgereift das bestehende ISMS der Organisation bereits ist, wie viel Test- und Nachweisarbeit der Geltungsbereich erfordert und ob zusätzliche regulatorische Anforderungen neben ISO 27001 bestehen.
Als grobe Schätzungshilfe: Ein kleines, fokussiertes Feature mit ein oder zwei neuen Maßnahmen verursacht meist ein bis zwei Tage dedizierter Sicherheitsarbeit. Eine mittlere Integration – etwa die Anbindung eines neuen SaaS-Anbieters oder eines Zahlungsdienstleisters – erfordert typischerweise zwei bis drei Wochen für Beurteilung, Tests und Behebung. Bei großen Projekten, bei denen ISMS-Arbeit als eigener Parallel-Track läuft, braucht man einen geeigneten Schätzer oder einen organisatorischen Richtwert statt einer Faustregel.
Praxis-Tipp: Führen Sie in der ersten Planungswoche eine schlanke Gap-Analyse durch. Eine fehlende Maßnahme früh zu entdecken kostet eine Terminanpassung. Sie beim Abschluss zu entdecken kostet einen wiedereröffneten Sprint und ein Gespräch mit dem Sponsor, das niemand führen möchte.
Welche Fehler bringen ISMS-Projekte am häufigsten zum Scheitern?
In den meisten erstmaligen ISMS-Projekten tauchen immer wieder dieselben Fehler auf – und nahezu alle lassen sich durch frühere Planung statt durch mehr Aufwand vermeiden.
Die SoA als Dokument zu behandeln, das man am Ende einmalig schreibt, ist der größte. Dicht dahinter folgen: fehlende Lieferantennachweise, weil die Beschaffung einen Vertrag unterzeichnet hat, bevor Sicherheitsanforderungen darin verankert waren; das Überspringen des formalen Änderungsmanagements bei Umfangsänderungen; und das Schließen des Projekts ohne Erfassung von Lessons Learned – was dazu führt, dass das nächste Team dieselben Fehler wiederholt.
Die Lösung liegt meist in der Reihenfolge. Sicherheitsaktivitäten gestaffelt neben der Entwicklung einplanen statt sie am Ende zu stapeln, SoA-Einträge freigeben, sobald jede Maßnahme umgesetzt wird, Tests regelmäßig durchführen statt in einem großen Durchlauf, und Betriebsteams vor der Übergabe schulen – nicht danach.
Praxis-Tipp: Behandeln Sie die SoA als lebendes Dokument und führen Sie kleine Sicherheits-Gates an jeder Phasengrenze durch, statt kurz vor dem Abschluss in einen Audit-Sprint zu verfallen. Ein Projekt, das Nachweise wöchentlich abgleicht, erlebt in Woche elf selten böse Überraschungen.
Ein pragmatischer Ansatz für die Leitung ISMS-konformer Projekte
Die meisten erstmaligen ISMS-Projektleiter investieren zu viel in Dokumentation und zu wenig in die Entdeckungsphase. Der Scoping-Workshop in Woche eins ist wichtiger als jede Vorlage, die man herunterlädt – denn eine falsche Geltungsbereichsgrenze bedeutet, dass jede darauf aufbauende Risikobeurteilung später wiederholt werden muss.
Drei Dinge kommen zuerst, in dieser Reihenfolge: ein Scoping-Workshop mit dem Informationssicherheitsverantwortlichen und dem Sponsor gemeinsam im Raum, ein schneller Risiko-Scan der Assets, die dieses Projekt tatsächlich berührt (nicht der gesamten Organisation), und Sicherheits-Gates, die vor Abschluss der Planung in den Kalender eingetragen werden – nicht erst nach Beginn der Ausführung.
Der eigentliche Kompromiss liegt zwischen Geschwindigkeit und Auditierbarkeit. Schnell vorzugehen ohne Nachweiserfassung spart Wochen vorab und kostet sie bei der Zertifizierung zurück. Wenn diese Spannung spürbar wird, gehört sie genau dann vor den Sponsor – nicht vergraben in einem Statusbericht, den er überfliegen wird.
Den ISMS-Aufwand schätzen, bevor Sie einen Zeitplan festlegen
Der größte Teil der Ungewissheit bei der ISMS-Projektplanung lässt sich auf eine Frage reduzieren: Wie viele Stunden wird das tatsächlich benötigen? Ein Readiness-Rechner beantwortet das, indem er Unternehmensgröße, Branche und aktuellen Sicherheitsreifegrad in eine konkrete Schätzung und eine priorisierte Aufgabenliste umwandelt – statt Sie mit einer generischen Checkliste im Unklaren zu lassen.
Der einfachste Einstieg ist ein kostenloser, zweiminütiger Readiness-Check, der Ihnen einen Überblick über Ihre Lücken verschafft, bevor Sie eine einzige Projektaufgabe formulieren. Für eine ausführlichere Aufschlüsselung liefert die ISO 27001 Readiness-Bewertung geschätzte Stunden je Domäne und eine priorisierte Liste der zuerst zu bearbeitenden SoA-Punkte – die Sie direkt in Ihren Projektplan übernehmen können. Wenn Sie noch den vollständigen Implementierungszeitplan planen, führen Sie die Bewertung jetzt durch und bauen Sie Ihr Gantt-Diagramm auf realen Zahlen statt einer groben Schätzung auf.
Weiterführende Literatur zu ISMS und Projektnormen
Den genauen Klauselwortlaut finden Sie direkt in der Norm ISO/IEC 27001. Für die Lebenszyklus-Ausrichtung behandelt der PMBOK-Leitfaden Prozessgruppen und Governance ausführlich; das SANS-Whitepaper zur Umsetzung von ISO 27001 als Projekt bietet eine praktische Implementierungs-Zuordnung. Für die Schätzung Ihres eigenen Zeitplans lesen Sie unseren Implementierungszeitplan-Leitfaden und unsere Gap-Analyse-Anleitung.
Häufig gestellte Fragen
Was ist ISMS im Projektmanagement? Es bedeutet, Informationssicherheitsanforderungen – wie Risikobeurteilung, Maßnahmenumsetzung und Nachweiserfassung – als geplante Projektliefergegenstände zu behandeln, nicht als separate Compliance-Aktivität nach der Lieferung.
Benötige ich eine ISO 27001-Zertifizierung, um diese Grundlagen anzuwenden? Nein. Die hier beschriebenen Praktiken – Scoping, Risikobeurteilung, SoA-Einträge und Phasen-Gates – sind anwendbar, unabhängig davon, ob Sie eine formale Zertifizierung anstreben oder einfach verbessern möchten, wie Ihre Organisation Informationssicherheit in Projekten handhabt.
Wer sollte ISMS-Aufgaben innerhalb eines Projekts verantworten? Ein namentlich benannter Informationssicherheitsverantwortlicher, der von der Projektleitung getrennt ist, verantwortet typischerweise den Risikobehandlungsplan und die SoA-Einträge, während die Projektleitung die Terminplanung und Integration in den übergeordneten Projektplan verantwortet.
Wie viel Mehrzeit verursacht die Ergänzung um ISMS-Arbeit? Das hängt stark vom Geltungsbereich ab. Ein kleines Feature kann ein bis zwei Tage pro Maßnahme hinzufügen, während eine größere Integration mit mehreren Lieferanten zwei bis drei Wochen für Beurteilung und Tests erfordern kann – weshalb eine frühe Gap-Analyse so wichtig ist.
Was ist der häufigste einzelne Fehler bei ISMS-Projekten? Die Anwendbarkeitserklärung als Dokument zu behandeln, das am Ende fertiggestellt wird, statt sie während der Ausführung schrittweise aufzubauen, sobald Maßnahmen relevant werden.
Quellen
- Project management 2nd edition — Chapter 1.3 Project constraints
- ISO/IEC 27001 — Information security, cybersecurity and privacy protection — ISO
- Tackling ISO 27001: A Project to Build an ISMS — SANS Institute
- Knowledge management in project management: An ISM approach