Fallstudie: Wie fehlende Rollen in der Informationssicherheit ein Projekt beinahe scheitern ließen.

Informationssicherheit ist mehr als nur IT-Schutz. Sie beginnt bei der Planung und braucht klare Rollen, strukturierte Prozesse und technische Einbindung. Diese Fallstudie zeigt, wie ein mittelständisches Unternehmen durch ein fehlendes Sicherheitskonzept und unklare Verantwortlichkeiten in ein kritisches Projektproblem geriet und welche Lehren daraus gezogen wurden.

Hintergrund des Projekts

Ein mittelständisches Fertigungsunternehmen mit rund 800 Mitarbeitenden plante die Einführung einer cloudbasierten Plattform für die Lieferantenkommunikation. Ziel war es, Lieferprozesse zu digitalisieren, Dokumente auszutauschen und Transparenz in Echtzeit zu schaffen.

Die Projektleitung lag im Einkauf, die technische Umsetzung erfolgte über einen externen IT-Dienstleister. Die interne IT war nur beratend eingebunden. Ein Sicherheitskonzept war zu keinem Zeitpunkt definiert.

Der Vorfall

Kurz vor dem geplanten Go-live wurde bei einem internen Review festgestellt, dass geschäftskritische Informationen wie Lieferverträge, Preisabsprachen und Absatzprognosen unverschlüsselt übermittelt wurden. Die Authentifizierung der Lieferantenkonten basierte ausschließlich auf schwachen Passwörtern ohne Mehr-Faktor-Authentifizierung oder Zugriffsbeschränkung.

Die Folge: Der Go-live wurde gestoppt, Projekte verzögerten sich um Monate und das Unternehmen musste kurzfristig Sicherheitsmaßnahmen nachziehen, die ursprünglich nicht eingeplant waren. Die internen Spannungen zwischen Projektleitung, IT und Geschäftsführung wuchsen erheblich.

Analyse: Warum kam es zu diesem Risiko?

1. Keine Sicherheitsarchitektur im Projekt
   Es fehlte eine übergeordnete Security-Architektur. Sicherheitsanforderungen waren weder definiert noch in die Systemlandschaft eingebettet.

2. Fehlende Risikoanalyse
   Die Schutzbedarfsfeststellung wurde komplett ausgelassen. Das System wurde behandelt wie ein generisches Kommunikationswerkzeug, obwohl es sensible Informationen verarbeitete.

3. Unklare Zuständigkeiten
   Weder Einkauf, IT noch Dienstleister fühlten sich für Sicherheit verantwortlich. Es gab keine benannte Rolle für Informationssicherheit im Projekt.

4. Fehlende Governance im Projektverlauf
   Es existierten keine Sicherheitsgates, keine verpflichtenden Prüfprozesse oder Abnahmekriterien mit Sicherheitsbezug.

Lessons Learned: Was Unternehmen daraus mitnehmen sollten

Sicherheitsarchitektur frühzeitig einplanen
Sicherheit muss fester Bestandteil der Projektarchitektur sein, nicht eine Zusatzanforderung zum Schluss.

Klare Rollen und Verantwortlichkeiten schaffen
Es muss im Projekt klar benannt werden, wer für Sicherheitsanforderungen verantwortlich ist, wer sie prüft und wer die Umsetzung sichert.

Schutzbedarf methodisch analysieren
Ein standardisierter Risiko- und Schutzbedarfsprozess sollte frühzeitig im Projektablauf stattfinden, unabhängig von Technologie oder Projektart.

Sicherheit messbar und dokumentierbar machen
Entscheidungen über Sicherheitsmaßnahmen müssen nachvollziehbar und dokumentiert sein, um sie später verteidigen oder verbessern zu können.

Sicherheits-Governance in Projektmethoden integrieren
Frameworks wie Scrum, PRINCE2 oder HERMES sollten um Security-Gates, Abnahmekriterien und Kontrollpunkte ergänzt werden.

Diese Fallstudie zeigt deutlich: Sicherheitslücken entstehen nicht nur durch technische Versäumnisse, sondern vor allem durch fehlende Struktur, unklare Zuständigkeiten und mangelnde Integration in Projekte. Informationssicherheit braucht mehr als gute Tools; sie braucht Verantwortung, Prozesse und Architektur. Wer sie von Anfang an einplant, spart nicht nur Zeit und Geld, sondern schützt auch das Vertrauen seiner Kunden und Partner.

Auch interessant: IT-Projektmanagement-Methoden

Lerneinheit des BSI: 2.8 Das Sicherheitskonzept