Security im Projektmanagement – warum eigentlich?

Warum Cybersicherheit ein zentraler Erfolgsfaktor für PM ist – Analysen, Zahlen & Fallbeispiele

Vielleicht habt ihr schon mal eine dieser Aussagen gehört:

• „Cybersecurity hat nichts im Projektmanagement zu suchen.“
• „Die Security sollen die Tekkies machen, wir kümmern uns darum, dass das Projekt endlich fertig wird.“
• „Der Grund für den Projektfehlschlag war doch, dass die Security nicht hinterherkam und ihre Aufgabe nicht wahrgenommen hat.“

Leider sind diese Aussagen mehr Realität, als sie es sein sollten. Gerade wegen dieses Mindsets passieren in Projekten gravierende und teure Fehler, die oft auch zu Angriffen führen, die genau diese Schwächen ausnutzen.

Was sagen die Zahlen?

Bevor wir uns die konkreten Stolpersteine anschauen, lohnt ein kurzer Blick auf das, was Studien und Berichte dazu sagen. Denn wenn man das Thema nicht aus eigener Erfahrung kennt, sprechen die Zahlen eine ziemlich deutliche Sprache. 

IBM Cost of a Data Breach Report 2024

Laut dem jährlich erscheinenden IBM-Bericht kostet ein durchschnittliches Datenleck heute 4,88 Millionen US-Dollar, ein Rekordwert und der größte Anstieg (+10 %) seit der Pandemie. Der Großteil der Kosten entsteht dabei nicht durch den Angriff selbst, sondern durch das, was danach kommt: Betriebsunterbrechung, Kundenverlust, Reaktion und Reputationsschaden.

Ein zweiter, oft missverstandener Fakt aus demselben Bericht: Unternehmen, die Sicherheitsarbeit umfassend mit KI und Automatisierung unterstützen (Prävention, Erkennung, Untersuchung, Reaktion), hatten mit durchschnittlich 3,84 Millionen US-Dollar deutlich niedrigere Kosten pro Vorfall als Unternehmen ohne diesen Einsatz (5,72 Millionen US-Dollar). Das ergibt eine Differenz von rund 1,9 Millionen US-Dollar. Das ist ein Argument für konsequente Investition in moderne Sicherheitswerkzeuge, sagt aber nichts darüber aus, wann im Projekt Security eingeplant wird. Für den „früher ist billiger“-Gedanken liefert dieser Bericht also kein eigenes Zahlenmaterial, das liefert stattdessen der nächste Abschnitt.

Verizon Data Breach Investigations Report 2024

Der DBIR von Verizon analysiert jedes Jahr tausende reale Sicherheitsvorfälle weltweit. Das Ergebnis 2024: 68 % aller Datenpannen haben eine nicht-böswillige menschliche Komponente: Fehlkonfigurationen, falsche Prozesse, Fehler bei der Rechtevergabe. Es sind also meist kein ausgefeilter Hack oder eine KI-gestützte Cyberwaffe, sondern Menschen und Prozesse, eben genau das, was Projektmanagement steuert. 

NIST: je später, desto teurer

Das National Institute of Standards and Technology (NIST) hat bereits 2002 dokumentiert, was viele intuitiv ahnen, aber selten so klar sehen: Fehler und Sicherheitslücken, die in der Planungs- und Designphase behoben werden, kosten deutlich weniger als dieselben Fehler nach dem Go-Live. Die in Fachkreisen kursierende Faustregel spricht von bis zu 30-facher Kostenersparnis bei früherer Behebung. Wichtig für die Einordnung: Die genauen Multiplikatoren (teils werden auch Werte von 60× bis 100× zitiert) stammen aus unterschiedlichen, teils methodisch nicht vollständig offengelegten Quellen und werden in der Fachcommunity kontrovers diskutiert. Unstrittig bleibt aber die Richtung: Wer Security-Anforderungen erst nach dem Livegang nachrüstet, zahlt spürbar drauf. Die genaue Zahl variiert je nach Studie. 

NIS2: jetzt auch rechtlich relevant

Seit dem 6. Dezember 2025 gilt in Deutschland das NIS2-Umsetzungsgesetz (NIS2UmsuCG). Rund 29.500 Unternehmen fallen damit unter neue, deutlich schärfere Anforderungen an Cybersicherheit von Risikomanagement über Meldepflichten bis hin zur Absicherung der Lieferkette. Wer das ignoriert, riskiert Bußgelder von bis zu 10 Millionen Euro. Das Entscheidende: Die Verantwortung liegt laut Gesetz ausdrücklich bei der Geschäftsführung, nicht bei der IT-Abteilung. Eine Übergangsfrist gibt es nicht; die Pflichten gelten seit Inkrafttreten unmittelbar. Wer ein Projekt leitet und NIS2-Anforderungen nicht einplant, seitzt seinem/ihrem Unternehmen damit einem echten Haftungsrisiko aus. 

Kurz gesagt: Security im Projektmanagement zu ignorieren, ist nicht nur fahrlässig, es ist teuer, riskant und inzwischen auch rechtlich gefährlich. 

Die vier Stolpersteine

Tatsächlich gibt es im Bereich PM und Security vier typische Stolpersteine, die oft für gescheiterte Projekte, fehlerhafte Systeme, durcheinandergeratene Systemdokumentationen und sogar für erfolgreiche Angriffe verantwortlich sind:

• Organisatorisch: Es gibt keinen klaren Security Owner.
• Prozessual: Security ist keine definierte Projektaufgabe.
• Kommunikativ: Warnsignale werden nicht eskaliert.
• Technisch/Compliance: Grundlegende Schutzprinzipien werden ignoriert.

Diese vier Stolpersteine wollen wir uns nun anhand von Fallbeispielen aus der realen Welt näher anschauen, von historischen Klassikern bis zu aktuellen Fällen aus den letzten zwei Jahren.

Equifax Datenleck 2017

Equifax, eine der größten Kreditauskunfteien der Welt, verlor die persönlichen Daten von 147 Millionen Menschen (Sozialversicherungsnummern, Geburtsdaten, Adressen). Die Ursache: eine bekannte Sicherheitslücke in einem Open-Source-Framework, die im laufenden IT-Projekt monatelang nicht gepatcht wurde.

Das Schlimme daran: Durch gutes Projektmanagement hätte dieser Schaden komplett vermieden werden können. Für die Lücke gab es längst einen Patch, er wurde schlicht nie eingespielt. Warum? Weil es im Projekt keinen wirklichen Security Owner gab. Vor dem Release wurde kein Penetrationstest durchgeführt und durch mangelhaftes Monitoring brauchte man 76 Tage, um den Einbruch überhaupt zu bemerken.

Organisatorisch: Es gab keine:n Verantwortliche:n für Security. Das Denken „die IT macht das schon“ wurde hier zum teuren Fehler. Ein Security Owner hätte sofort Alarm geschlagen.

Prozessual: Patch-Management war keine definierte Projektaufgabe. Keine Aufgabe – kein Patcher.

Kommunikativ: Meldungen zur Schwachstelle wurden intern nicht eskaliert. Bessere Kommunikationsstrukturen hätten den Schaden begrenzt und die Fehlersuche deutlich beschleunigt.

Aktueller Hinweis: Das gleiche Grundmuster – bekannte, ungepatchte Schwachstelle, die zum Masseneinbruch führt – zeigte sich auch beim MOVEit-Vorfall 2023/2024, der laut Verizon DBIR 2024 maßgeblich zum sprunghaften Anstieg von Angriffen über ausgenutzte Schwachstellen beitrug. Das Equifax-Muster ist also keine Altlast, sondern ein wiederkehrendes Risiko.

Target Kassensystem-Hack 2013

Angreifer:innen stahlen die Kreditkartendaten von 40 Millionen Kund:innen aus den Kassensystemen des drittgrößten US-Einzelhändlers. Der Angriff erfolgte nicht direkt über Target selbst, sondern über einen externen HVAC-Dienstleister (Heizung/Klima) mit Netzwerkanbindung zum System. Der Drittanbieter war nie Teil des Security-Konzepts, Supply Chain Security war schlicht kein Bestandteil des Projekts. Entstandener Schaden: 292 Millionen US-Dollar.

Organisatorisch: Der Drittanbieter wurde nicht ins Security-Konzept integriert. Die richtigen Fragen (Welche Zugriffsrechte braucht der Dienstleister wirklich? Wer prüft das?) wurden nie gestellt.

Prozessual: Die Zugriffsrechte der Drittanbieter wurden nicht kontrolliert. Netzwerkzugang für Externe muss auf das Minimum beschränkt und zeitlich begrenzt sein. Das ist eine Planungsaufgabe und keine reine IT-Entscheidung. Es gab sogar Alert-Meldungen im System, die schlicht ignoriert wurden.

Technisch/Compliance: Das Principle of Least Privilege wurde komplett ignoriert. Die Drittanbieter durften zu viel. Das ermöglichte den Angreifer:innen den Weg ins Kernsystem.

Aktueller Fall: Zwölf Jahre später zeigt der Fall Marks & Spencer (2025), dass sich am Muster kaum etwas geändert hat: Angreifer:innen verschafften sich über Social Engineering Zugang über einen externen Auftragnehmer, mit einem geschätzten Verlust von rund 300 Millionen britischen Pfund beim Betriebsergebnis und massiven Störungen im Logistikbetrieb. Auch strukturell nimmt das Risiko zu: Laut Verizon DBIR 2025 hat sich der Anteil von Datenschutzverletzungen mit Drittparteien-Beteiligung binnen eines Jahres von 15 % auf 30 % verdoppelt. Drittanbieter-Risiko ist damit kein historisches Randthema, sondern ein wachsender Schwerpunkt.

SolarWinds Supply Chain Angriff 2020

Das vielleicht erschreckendste Beispiel, weil der Angriff nicht von außen kam, sondern aus dem eigenen Entwicklungsprozess: Staatliche Angreifer:innen schleusten über 14 Monate Schadcode direkt in den Build-Prozess von SolarWinds ein. Das manipulierte Update wurde regulär als offizielle Software an 18.000 Organisationen weltweit ausgeliefert, darunter mehrere US-Bundesministerien und Fortune-500-Unternehmen. Entdeckt wurde der Angriff nicht intern, sondern durch den externen Sicherheitsanbieter FireEye.

Organisatorisch: SolarWinds hatte Zertifikate. Auf dem Papier war alles in Ordnung. Genau das erzeugte ein falsches Sicherheitsgefühl. Kein Security-Owner hatte den Auftrag, den Entwicklungsprozess selbst einzuschätzen oder abzusichern. Das nennt sich Paper Compliance: alle Dokumente vorhanden, keine echte Sicherheitskultur.

Kommunikativ: Anomalien im Build-System wurden nicht eskaliert oder gar nicht erst als solche erkannt. Sie blieben 14 Monate unentdeckt und wurden erst durch einen externen Hinweis aufgedeckt. Ein klares Zeichen, dass intern niemand wirklich hingeschaut hat …

Prozessual: Der Build-Prozess hatte keine eingebauten Security-Abnahmekriterien, also kein Gate, das Code-Integrität prüft. Security war kein Bestandteil der Definition of Done.

Technisch/Compliance: Die Supply Chain – der eigene Entwicklungsprozess als Lieferkette – war nie als Risiko im Projektplan erfasst. Die Lehre: Nicht nur das Produkt muss sicher sein, sondern auch der Weg, auf dem es entsteht, da er ebenfalls ein Angriffsziel ist.

Aktuelle Parallelen: Der XZ-Utils-Vorfall (2024) zeigt eine noch subtilere Variante desselben Musters: Ein:e Angreifer:in baute sich über rund zwei Jahre hinweg per Social Engineering gezielt eine Vertrauensposition als Maintainer eines zentralen Linux-Kompressionspakets auf und schleuste eine hochkritische Backdoor ein. Entdeckt wurde sie nur durch Zufall, als ein:e Entwickler:in eine ungewöhnliche Performance-Abweichung untersuchte und nicht durch ein etabliertes Kontrollsystem. Auch der weltweite CrowdStrike-Ausfall im Juli 2024 gehört in diesen Kontext: Hier war es kein Angriff, sondern ein fehlerhaftes Update eines einzelnen Sicherheitsanbieters, das weltweit IT-Systeme lahmlegte, Krankenhäuser, Flugverkehr und Produktion eingeschlossen. Das zeigt: Supply-Chain-Risiko im Projekt bedeutet nicht nur „Schutz vor Angriffen“, sondern auch robustes Change- und Release-Management gegenüber vertrauten Lieferanten.

Fazit

Vier Fälle, vier verschiedene Unternehmen, unterschiedliche Branchen sowie unterschiedliche Jahrzehnte und doch das gleiche Grundmuster: Security war keine Projektaufgabe. Sie war entweder an „die IT“ delegiert, in keinem Prozess verankert oder durch Zertifikate nur auf dem Papier vorhanden.

Das ist die eigentliche Botschaft: Security scheitert selten an Technik. Sie scheitert an Organisation, Kommunikation und Prozessen, also an genau dem, wofür Projektmanagement da ist. Und die aktuellen Beispiele (Marks & Spencer, XZ Utils, CrowdStrike) zeigen, dass das Problem nicht kleiner wird, sondern sich zunehmend in die Lieferkette verlagert.

Wer Security von Anfang an als Teil des Projekts versteht, spart am Ende nicht nur Geld, sondern auch aufwendige Nacharbeit und Dokumentation zur Lösung von Sicherheitsproblemen.

Was heißt das für euer nächstes Projekt?

Aus den Fällen lassen sich vier konkrete, sofort umsetzbare Schritte ableiten:

1. Security Owner als feste Rolle im Projekt-RACI bennenen und nicht als Nebenaufgabe der IT-Abteilung.
2. Security-Kriterien in die Definition of Done aufnehmen. Patch-Status, Code-Integrität und Penetrationstest gehören zu den Abnahmekriterien vor jedem Release.
3. Drittanbieter-Risikoregister führen: Jeder externe Dienstleister mit Systemzugang wird bewertet, seine Zugriffsrechte nach dem Least-Privilege-Prinzip begrenzt und regelmäßig geprüft.
4. Eskalationswege für Sicherheitsauffälligkeiten festlegen: klar definierte Meldeketten, damit Anomalien nicht erst durch Zufall oder externe Hinweise auffallen.

Kurz zusammengefasst:

• Security ist kein „Das macht die IT“-Thema.
• Security ist ein „Das muss ins PM“-Thema.

Entdecken Sie unser Seminarangebot im Projektmanagement-Umfeld