IT-Sicherheit im Interim-Mandat: Warum Verantwortung nicht automatisch mitwandert

Ein Interim-Programmleiter ist drei Wochen im Mandat, als eine E-Mail hereinkommt: Ein externer Logistikpartner bittet um erweiterten Zugriff auf das neue System, das gerade ausgerollt wird – Deadline übermorgen, sonst platzt der nächste Meilenstein. Der Interim-Manager kennt das Projekt in- und auswendig. Er weiß nur nicht genau, wer im Unternehmen eine solche Freigabe eigentlich unterschreiben darf. Die reguläre Geschäftsführung ist im Urlaub, der IT-Sicherheitsbeauftragte in einem anderen Projekt gebunden. Am Ende entscheidet er selbst – aus Zeitdruck, nicht aus Zuständigkeit.

Szenen wie diese sind kein Einzelfall. Sie sind eine strukturelle Folge davon, wofür Interim Management überhaupt gebraucht wird.

Zwei Rollen, eine Grauzone

Interim-Manager kommen typischerweise genau dann ins Haus, wenn Strukturen im Umbruch sind: eine Systemeinführung, eine Restrukturierung, eine vakante Führungsposition. Genau in solchen Phasen sind Zuständigkeiten für IT-Sicherheit oft am unklarsten definiert – die alten Prozesse gelten nicht mehr, die neuen stehen noch nicht. Der Interim-Manager füllt dann nicht nur die fachliche Lücke, sondern faktisch auch eine Entscheidungslücke, die eigentlich in der Governance des Unternehmens hätte geschlossen sein müssen.

Das Problem: Ein Interim-Mandat ist vertraglich meist eng auf das Projekt- oder Programmziel zugeschnitten – Zeitplan, Budget, Lieferantensteuerung. Zu Sicherheitsfragen steht darin häufig nichts, weil beide Seiten sie zum Zeitpunkt der Vertragsunterschrift nicht auf dem Schirm hatten.

Was der Rechtsrahmen dazu sagt

Seit Dezember 2025 gilt in Deutschland das NIS-2-Umsetzungsgesetz, seit dem 1. Oktober 2026 in Österreich das NISG 2026 – beide setzen die europäische NIS2-Richtlinie um und verschärfen die Anforderungen an Risikomanagement in der IT-Sicherheit spürbar. Für die Frage, wer im Projekt was entscheiden darf, ist vor allem eine Unterscheidung wichtig, die § 38 BSIG trifft: Operative Umsetzung von Sicherheitsmaßnahmen lässt sich delegieren. Die Genehmigung von Risikomanagementmaßnahmen und ihre laufende Überwachung bleiben dagegen unverzichtbar bei der Geschäftsleitung – ebenso die persönliche Teilnahme an Sicherheitsschulungen, mindestens alle drei Jahre.

Für ein Interim-Mandat heißt das: Ein Interim-Manager kann und soll operative Sicherheitsentscheidungen im Projekt treffen. Er kann aber nicht die Rolle der Geschäftsleitung übernehmen, ohne dass das irgendjemand vereinbart hätte.

Quelle: § 38 BSIG (NIS-2-Umsetzungsgesetz), Stand 2026

Die Falle in beide Richtungen

Zu viel faktische Entscheidungsmacht ohne dokumentierte Rückkopplung zur Geschäftsleitung ist für einen Interim-Manager kein Ruhmesblatt, sondern ein Risiko: Wer über längere Zeit eigenständig strategisch wirkende Sicherheitsentscheidungen trifft, kann im Streitfall wie ein faktischer Geschäftsführer behandelt werden – mit entsprechender persönlicher Haftung. Das betrifft nicht nur spektakuläre Fälle, sondern auch den ganz normalen Projektalltag, wenn Freigaben, Ausnahmegenehmigungen oder Zugriffsrechte immer wieder über den Schreibtisch des Interim-Managers laufen, ohne dass jemand anderes sie gegenzeichnet.

Das andere Extrem ist genauso teuer: zu wenig Entscheidungsbefugnis, weil niemand sich traut, dem Interim-Manager Sicherheitsfragen zu überlassen. Dann stehen Projekte still, während alle auf eine Freigabe warten, die formal niemand erteilen will.

Was in der Praxis wirklich hilft

Eine kurze Kompetenzmatrix zu Mandatsbeginn schafft hier mehr Klarheit als jede nachträgliche Diskussion: Wer entscheidet bei sicherheitsrelevanten Fragen selbstständig, wer wird nur informiert, wessen Zustimmung ist zwingend nötig. Dazu gehört eine Vertretungsregelung für den Fall, dass die zuständige Person – wie im Beispiel oben – gerade nicht erreichbar ist. Jede sicherheitsrelevante Entscheidung sollte in wenigen Sätzen dokumentiert werden: Datum, Grund, wer informiert wurde. Das ist kein Misstrauensvotum gegen den Interim-Manager, sondern schützt beide Seiten gleichermaßen. Und am Mandatsende gehört ein kurzes Übergabeprotokoll dazu, das offene sicherheitsrelevante Punkte für den Nachfolger festhält – Interim-Mandate enden, Verantwortung für Systeme nicht.

Vorher hoffte man, nachher wusste man

Eine Interim-Programmleiterin übernimmt bei einem Speditionsunternehmen mit Standorten in Polen und Rumänien die Einführung eines neuen Transportmanagementsystems. Im Mandat steht: Verantwortung für Zeitplan, Budget, Lieferantenkoordination. Zur IT-Sicherheit steht nichts – man ist schließlich für die Rollout-Organisation da, nicht für Zugriffsrechte. Als der rumänische Standort um kurzfristigen Zugriff für einen externen Dienstleister bittet, entscheidet sie aus dem Bauch heraus: freigeben, sonst steht die Anbindung still.

Einige Wochen später, ein ähnlicher Vorfall am polnischen Standort – diesmal mit einem Anbieter, dessen Zugriff eigentlich längst hätte enden sollen. Jetzt liegt eine knappe Kompetenzmatrix im Projektordner: Wer entscheidet, wer wird informiert, wessen Zustimmung ist nötig, wenn es um Zugriffsrechte geht. Gelöst ist damit nicht alles – die frühere Freigabe für Rumänien bleibt ungeklärt, weil zu diesem Zeitpunkt niemand dokumentiert hat, wer sie eigentlich abgesegnet hat. „Die Matrix kam eine Eskalation zu spät“, sagt die Programmleiterin später trocken, „aber immerhin nicht zwei.“

Auf den Punkt

IT-Sicherheit gehört selten explizit ins Mandat eines Interim-Managers – und taucht im Projektalltag trotzdem fast immer auf. Der Rechtsrahmen zieht eine klare Linie zwischen operativer Umsetzung, die delegierbar ist, und strategischer Verantwortung, die es nicht ist. Wer diese Linie zu Mandatsbeginn gemeinsam zieht und Entscheidungen unterwegs kurz dokumentiert, erspart sich am Ende die Diskussion, die sonst erst nach dem Vorfall geführt wird.