Risikomanagement im IT-Outsourcing war noch nie eine reine IT-Aufgabe – inzwischen ist es vor allem eine Compliance-Aufgabe. NIS2, DSGVO, DORA, Cyber Resilience Act, AI Act – dazu interne IT-Sicherheitsrichtlinien, Einkaufsvorgaben und Datenschutzkonzepte. Wer heute IT-Leistungen auslagert, muss die Risiken dieser Auslagerung gegen ein Dutzend Regelwerke gleichzeitig prüfen. In der Praxis führt das zu einem bekannten Muster: Für jede Vorgabe entsteht eine eigene Analyse, ein eigener Maßnahmenkatalog und ein eigener Lieferantenfragebogen. Der Aufwand vervielfacht sich, die Ergebnisse widersprechen sich – und trotzdem bleiben Lücken. Der folgende Artikel zeigt, warum das nicht nötig ist. Er erklärt, wie sich sämtliche relevanten EU-Compliance-Anforderungen und internen Vorgaben in einer einzigen Risikoanalyse bearbeiten lassen, welche Rolle ein Common Controls Framework dabei spielt und mit welchen Standards und Vorlagen Sie starten können.

 

Warum IT-Outsourcing zum Compliance-Brennpunkt geworden ist

Auslagerung verlagert Leistung, aber nicht Verantwortung. Genau hier setzen die aktuellen EU-Regelwerke an. Die für Betreiber kritischer Infrastruktur geltende NIS2-Richtlinie ist in Deutschland seit dem 6. Dezember 2025 über das NIS2-Umsetzungsgesetz im novellierten BSI-Gesetz verankert. Sie macht Lieferkettensicherheit zum Pflichtbestandteil des Risikomanagements. Die den Umgang mit personenbezogenen Daten vorgebende DSGVO regelt über Artikel 28 die Auftragsverarbeitung. DORA verpflichtet Finanzunternehmen zu einem Register aller IKT-Dienstleister, zu Ausstiegsstrategien und zur Bewertung von Konzentrationsrisiken. Der Cyber Resilience Act ergänzt Anforderungen an digitale Produkte (Hard- und Software mit Kommunikationsfähigkeiten), der AI-Act an KI-Systeme.

Die Folge: Ein einziger Cloud-Vertrag berührt schnell vier oder fünf Regelwerke parallel. Und die Geschäftsleitung haftet dafür persönlich.

 

Das eigentliche Risiko ist nicht Non-Compliance, sondern Doppelarbeit

Die meisten Organisationen scheitern nicht daran, dass sie die Anforderungen ignorieren. Sie scheitern an der Organisation ihrer Compliance-Arbeit. Ein häufig auftretendes Problem: Die Rechtsabteilung bearbeitet NIS2, die IT-Sicherheit kümmert sich um DORA, der Datenschutzbeauftragte um die DSGVO. Das Ergebnis sind dann mehrere Fragebögen an denselben Dienstleister, widersprüchliche Risikobewertungen und Lücken, die niemand bemerkt, weil jeder nur seinen Ausschnitt sieht.

Dabei überlappen die Regelwerke sich erheblich. Ein Risiko für die IKT-Verfügbarkeit nach DORA ist fast immer auch ein Risiko für die Versorgungssicherheit nach NIS2 – und häufig zusätzlich ein Datenschutzrisiko. Wer diese Überschneidungen gezielt nutzt, senkt den Aufwand deutlich und erhöht gleichzeitig die Qualität der Analyse.

 

Common Controls Framework: eine Kontrollbibliothek für alle Regelwerke

Der Lösungsansatz heißt Common Controls Framework. Die Idee ist einfach: Statt pro Regelwerk eine eigene Analyse zu fahren, werden alle externen und internen Anforderungen auf einen gemeinsamen Kontrollkatalog gemappt. Jede Kontrolle wird einmal definiert, einmal bewertet und einmal umgesetzt – dokumentiert wird jedoch, welche Anforderungen sie jeweils erfüllt.

Ein Beispiel aus dem Outsourcing-Alltag: Das vertraglich vereinbarte Auditrecht beim Dienstleister erfüllt gleichzeitig DORA Art. 30, die Lieferkettenanforderungen aus § 30 BSIG und Art. 28 DSGVO. Eine Maßnahme, drei Nachweise. Genau dieses Mapping erzeugt die Effizienzgewinne – und liefert Prüfern eine konsistente Nachweislage.

Als Rückgrat für den Kontrollkatalog eignen sich ISO/IEC 27001 mit Anhang A oder der BSI IT-Grundschutz. Das ist kein Zufall: Die zehn Maßnahmenbereiche aus § 30 BSIG entsprechen weitgehend den Anforderungen der ISO 27001, und auch DORA baut strukturell auf etablierten Frameworks auf, statt sie zu ersetzen.

 

In fünf Schritten zur integrierten Risikoanalyse

1. Regulatorisches Inventar erstellen.
   Klären Sie zuerst die Betroffenheit: Fällt Ihr Unternehmen unter NIS2, und in welche Kategorie? Gilt DORA? Welche Branchenstandards und internen Richtlinien kommen hinzu? Diese Prüfung ist die häufigste Fehlerquelle, insbesondere bei Konzern- und Beteiligungsstrukturen.

2. Anforderungen auf den Kontrollkatalog mappen.
   Übersetzen Sie jede regulatorische und interne Anforderung in Kontrollen Ihres gewählten Rahmenwerks. Am Ende steht eine einzige Kontrollbibliothek mit Referenzspalten für NIS2, DSGVO, DORA und interne Vorgaben.

3. Eine Risikoanalyse nach einer Methodik durchführen.
   Nutzen Sie ISO/IEC 27005 oder den BSI-Standard 200-3. Speziell für Outsourcing liefert ISO/IEC 27036 zur Informationssicherheit in Lieferantenbeziehungen die passende Ergänzung. Im Finanzumfeld gibt es für das Outsourcing die Leitlinien der Europäischen Bankenaufsichtsbehörde (EBA).

4. Outsourcing-spezifische Bausteine ergänzen.
   Erstellen Sie ein Inventar aller IT-Dienstleister und markieren Sie jene, die kritische oder wichtige Funktionen unterstützen. Prüfen Sie anschließend die Verträge per Gap-Analyse auf Auditrechte, SLAs zur Vorfallmeldung, Transparenz über Subunternehmer und belastbare Exit-Regelungen. Ergänzen Sie datenschutzseitig den Auftragsverarbeitungsvertrag und – bei Drittlandtransfer – Standardvertragsklauseln.

5. Verträge am strengsten Maßstab ausrichten.
   Ein pragmatischer Hebel: Gestalten Sie Ihre Lieferantenverträge nach dem „Goldstandard“ DORA. Damit decken Sie die NIS2-Anforderungen an die Lieferkettensicherheit weitgehend automatisch mit ab.

 

Diese Standards und Vorlagen können Sie nutzen

Eine fertige „Eine-Analyse-für-alles”-Vorlage zum Download existiert leider nicht – die Bausteine dafür schon. Öffentlich verfügbare Mappings zwischen den Regelwerken ersparen den Großteil der Fleißarbeit, etwa die Gegenüberstellungen von NIS2 zu ISO 27001 bei OpenKRITIS oder die Veröffentlichungen der ENISA. Das Secure Controls Framework (SCF) stellt einen frei verfügbaren Meta-Kontrollkatalog mit Mappings auf NIS2, DSGVO, DORA, ISO und NIST bereit. Der BSI IT-Grundschutz liefert mit dem Baustein OPS.2.3 „Nutzung von Outsourcing” eine sofort einsetzbare Maßnahmenbasis. Für die Lieferantenabfrage haben sich standardisierte Fragebögen wie das „SIG Questionnaire“ etabliert.

Ein Hinweis zur Skalierung: Bei einer zweistelligen Zahl an Dienstleistern funktioniert meist eine gepflegte Tabelle. Bei hunderten Lieferanten werden manuelle Excel-Listen fehleranfällig – dann lohnt der Umstieg auf eine GRC-Plattform (Governance, Risk and Compliance), die Nachweise automatisiert einsammelt und den Status laufend überwacht.

 

Fazit: Integration schlägt Vollständigkeit im Einzelfall

Die Zahl der Regelwerke wird weiter steigen. Wer darauf mit immer neuen Einzelanalysen reagiert, erhöht seinen Aufwand schneller als sein Sicherheitsniveau. Der integrierte Ansatz über ein Common Controls Framework dreht diese Logik um: einmal analysieren, einmal bewerten, mehrfach nachweisen.

Der Einstieg ist unspektakulär und genau deshalb wirksam. Erstellen Sie das regulatorische Inventar, wählen Sie ein Rahmenwerk als Rückgrat und mappen Sie die Anforderungen konsequent dagegen. Behandeln Sie Ihr Risikomanagement im IT-Outsourcing dabei nicht als Abteilungsaufgabe, sondern als gemeinsamen Prozess aller Beteiligten, d.h. insbesondere von IT, Datenschutz, Recht und Einkauf. Dann wird aus einer Pflichtübung ein belastbarer Nachweis digitaler Resilienz – gegenüber Aufsichtsbehörden ebenso wie gegenüber Kunden.

Am 29. Juni 2026 hat der Oberste Gerichtshof der USA in der Rechtssache Trump v. Slaughter entschieden: Die gesetzlich verankerte Unabhängigkeit der Federal Trade Commission (FTC) ist verfassungswidrig. Die Mehrheit lag bei 6 zu 3 Stimmen. Was auf den ersten Blick wie eine rein innenpolitische Frage der amerikanischen Gewaltenteilung wirkt, ist tatsächlich mehr: Es ist eine ernsthafte Bedrohung für den transatlantischen Datentransfer. Denn das EU-US Data Privacy Framework (DPF) – die zentrale Rechtsgrundlage für die Übermittlung personenbezogener Daten von der EU in die USA – stützt sich maßgeblich auf genau diese Unabhängigkeit. Für tausende europäische Unternehmen, die täglich US-Cloud-Dienste, SaaS-Tools oder Marketing-Plattformen nutzen, stellt sich damit erneut eine Frage: Ist der Datentransfer in die USA noch rechtssicher?

 

Was hat der US Supreme Court entschieden?

Auslöser des Verfahrens war die Entlassung der demokratischen FTC-Kommissarin Rebecca Kelly Slaughter und ihres Kollegen Alvaro Bedoya. Präsident Trump entließ beide zu Beginn seiner zweiten Amtszeit im Jahr 2025 – ohne die gesetzlich vorgesehenen Entlassungsgründe wie Pflichtverletzungen. Während die Vorinstanzen die Entlassung noch als rechtswidrig einstuften, entschied der Supreme Court zugunsten der Regierung.

Das Gericht folgte dabei einem klaren Grundsatz: Die US-Verfassung weist die exekutive Gewalt dem Präsidenten zu. Dieser müsse deshalb die uneingeschränkte Kontrolle über alle Bundesbehörden haben – einschließlich der Befugnis, deren Leitungspersonal jederzeit und ohne Angabe von Gründen zu entlassen. Damit kippte das Gericht faktisch einen fast hundert Jahre alten Präzedenzfall. Dieser hatte unabhängige Regulierungsbehörden bislang vor dem direkten Durchgriff des Weißen Hauses geschützt. Die Konsequenz: Eine wirklich unabhängige FTC darf es nach dieser Verfassungsauslegung nicht mehr geben.

 

Warum die FTC das Fundament des Data Privacy Framework ist

Die Übermittlung personenbezogener Daten in Drittstaaten ist für EU-Unternehmen nach der DSGVO nur unter einer Bedingung zulässig: Dort muss ein „im Wesentlichen gleichwertiges” Datenschutzniveau herrschen. Für die USA bescheinigt dies der Angemessenheitsbeschluss der EU-Kommission nach Art. 45 DSGVO – das EU-US Data Privacy Framework von 2023.

Das Problem: EU-Primärrecht und die EU-Grundrechtecharta verlangen ausdrücklich, dass die Datenschutzaufsicht durch unabhängige Stellen erfolgt. Genau diese Rolle nimmt in den USA seit dem Jahr 2000 die FTC ein. Im Angemessenheitsbeschluss beruft sich die EU-Kommission sage und schreibe 259 Mal auf die Kontrollfunktion der FTC. In Erwägungsgrund 60 heißt es sogar wörtlich, die FTC sei „eine unabhängige Behörde”. Diese Annahme ist mit dem Urteil hinfällig – parallel sorgt die DSGVO-Reform 2025 ohnehin für Bewegung. Datenschutzaktivist Max Schrems und seine Organisation noyb haben bereits eine Klage vor dem EuGH angekündigt. Sie fordern die EU-Kommission auf, den Angemessenheitsbeschluss in einem geordneten Prozess aufzuheben. Nach „Schrems I” (Safe Harbor, 2015) und „Schrems II” (Privacy Shield, 2020) droht damit „Schrems III” – benannt nach Max Schrems, der jeweils als Kläger auftrat.

 

Welche Unternehmen sind betroffen?

Betroffen ist praktisch jedes Unternehmen in der EU, das personenbezogene Daten in die USA übermittelt. Das sind deutlich mehr, als viele denken:

Nutzer von US-Cloud- und SaaS-Diensten: Wer Microsoft 365, Google Workspace, AWS, Salesforce, HubSpot, Zoom oder Mailchimp einsetzt, überträgt regelmäßig personenbezogene Daten in die USA. Das geschieht oft auf Basis des Data Privacy Frameworks. Das betrifft Konzerne genauso wie KMU (siehe auch unseren Beitrag zu Cloud Compliance).

Unternehmen mit Standardvertragsklauseln (SCCs) oder Binding Corporate Rules (BCRs): Auch wer das Framework bewusst umgeht, ist nicht aus dem Schneider. SCCs und BCRs erfordern eine Transfer-Folgenabschätzung (Transfer Impact Assessment, TIA). Darin wird regelmäßig auf US-Kontrollinstanzen wie den „Data Protection Review Court” verwiesen. Das ist kein echtes Gericht, sondern eine Behörde im US-Justizministerium, deren Unabhängigkeit lediglich auf einer präsidialen Exekutivverordnung beruht. Nach der Logik des Supreme-Court-Urteils steht auch diese Grundlage zur Disposition.

Zertifizierte US-Anbieter selbst: Rund 2.800 US-Unternehmen aller Branchen haben sich unter dem Data Privacy Framework zertifiziert – von Cloud- und SaaS-Anbietern über Marketing- und HR-Dienstleister bis zu Pharma- und Beratungsunternehmen. Sie verlieren perspektivisch ihr wichtigstes Argument gegenüber europäischen Kunden: Rechtssicherheit.

 

Was Unternehmen jetzt tun können – und müssen

Wichtig vorab: Das Data Privacy Framework ist formal weiterhin gültig. Der Angemessenheitsbeschluss bleibt in Kraft, bis die EU-Kommission ihn widerruft oder der EuGH ihn für nichtig erklärt. Ein Klageverfahren dauert erfahrungsgemäß zwei bis drei Jahre. Es besteht also kein Grund zur Panik, aber sehr wohl Handlungsbedarf:

1. Datenflüsse inventarisieren: Verschaffen Sie sich einen vollständigen Überblick, welche Dienste personenbezogene Daten in die USA übermitteln und auf welcher Rechtsgrundlage (DPF, SCCs, BCRs). Das Verzeichnis von Verarbeitungstätigkeiten (VVT) gemäß Art. 30 DSGVO ist dafür der richtige Ausgangspunkt.
2. Transfer-Folgenabschätzungen aktualisieren: Bestehende TIAs, die auf die Unabhängigkeit von FTC oder Data Protection Review Court verweisen, müssen neu bewertet werden.
3. SCCs als zweites Standbein etablieren: Wer sich bislang ausschließlich auf das Data Privacy Framework stützt, sollte mit US-Anbietern zusätzlich Standardvertragsklauseln vereinbaren – viele Anbieter bieten dies bereits standardmäßig an.
4. Technische Schutzmaßnahmen ausbauen: Ende-zu-Ende- und clientseitige Verschlüsselung der Daten reduzieren das Transferrisiko unabhängig von der Rechtslage erheblich.
5. Europäische Alternativen prüfen: Für besonders sensible Daten (Gesundheits-, HR- und Kundendaten) lohnt die Evaluierung europäischer Cloud- und Software-Anbieter – nicht aus Prinzip, sondern aus strategischem Pragmatismus.
6. Exit-Fähigkeit sicherstellen: Bauen Sie Ihre Datenverarbeitung so auf, dass ein Anbieterwechsel im Ernstfall ohne Betriebsunterbrechung möglich ist.
7. Entwicklung beobachten: Verfolgen Sie die Reaktion der EU-Kommission, das angekündigte noyb-Verfahren („Schrems III“) sowie das laufende „Latombe”-Verfahren vor dem EuG. Beide Verfahren sind nach dem jeweiligen Kläger benannt.

 

Fazit: Kein Todesstoß – aber ein Weckruf für digitale Souveränität

Das Urteil Trump v. Slaughter beendet den transatlantischen Datentransfer nicht über Nacht. Das EU-US Data Privacy Framework gilt formal weiter. Doch die strukturelle Schwäche des Abkommens ist nun offensichtlicher denn je: Ein Datenschutzrahmen, der auf der Unabhängigkeit einer US-Behörde beruht, die es verfassungsrechtlich nicht mehr geben darf, steht auf tönernen Füßen. Nach Safe Harbor und Privacy Shield droht dem dritten Abkommen der EU mit den USA dasselbe Schicksal. Unternehmen sollten die verbleibende Zeit nutzen: Wer heute seine Datenflüsse dokumentiert, Risikoanalysen aktualisiert und Ausweichstrategien vorbereitet, muss morgen nicht hektisch reagieren. Digitale Souveränität ist damit endgültig kein Nice-to-have mehr, sondern strategische Notwendigkeit.

Wer IT-Services heute nicht mehr von einem einzigen Provider, sondern von einem Geflecht interner und externer Dienstleister bezieht, kennt die Herausforderung: Wie lässt sich sicherstellen, dass für den Kunden am Ende eine einheitliche, durchgängige Servicequalität entsteht – unabhängig davon, wie viele Provider im Hintergrund zusammenarbeiten müssen? Genau hier setzt Service Integration and Management (SIAM) an. SIAM ist eine Managementmethode, die die Steuerung multipler Service-Provider so organisiert, dass eine Ende-zu-Ende-Verantwortung für Verfügbarkeit und Qualität aller Services entsteht. Und dies über Provider- und Vertragsgrenzen hinweg.

Der am Markt etablierte Referenzrahmen für diese Managementmethode ist der „SIAM Body of Knowledge“. Im November 2025 ist davon die Version 3 erschienen – die erste größere Überarbeitung seit längerer Zeit. Aus unserer Sicht lohnt sich ein genauer Blick: Was hat sich strukturell verändert, welche inhaltlichen Akzente wurden neu gesetzt? Und was bedeutet das für Organisationen, die SIAM bereits einsetzen oder gerade einführen?

 

Eine neue Struktur: Das Layered Model

Die auffälligste Neuerung in Version 3 ist zunächst struktureller Natur. Erstmals liegt dem SIAM Body of Knowledge ein dreistufiges „Layered Model“ zugrunde (siehe Abbildung 1).

 

Im Zentrum steht der Core Layer mit den beiden bekannten Kerndokumenten „SIAM Foundation“ und „SIAM Professional“. Diese beschreiben Theorie und Methodik von SIAM. Die  beiden Dokumente bildeten bereits in Version 2 das Rückgrat des Frameworks.

Neu hinzugekommen ist der Compendium Layer. Er besteht aus vierzehn eigenständige Kompendien, die einzelne SIAM-Themen aus den Kerndokumenten vertiefen. Die Themen reichen von Prozessen über Skills bis hin zu Vertrauen und Ki. In Version 2 gab es mit den „SIAM Process Guides“ nur ein einziges vergleichbares Zusatzdokument; dieses ist in Version 3 selbst zu einem der vierzehn Kompendien geworden.

Den äußeren Rahmen bildet schließlich der Expanded Layer. Er enthält Whitepaper, Fallstudien, Vorlagen und weiterer Content aus der SIAM-Community, der nun gebündelt und für alle Interessierten zugänglich gemacht wird.

Diese Schichtung ist mehr als Kosmetik. Sie schafft Flexibilität für die Zukunft. Während die beiden Core-Dokumente als stabiles Fundament dienen, lassen sich künftig einzelne Kompendien – voraussichtlich vor allem solche zu sich schnell wandelnden Themen – bei Bedarf aktualisieren, ohne dass das gesamte Framework neu aufgelegt werden müsste.

 

Core Layer: Evolution statt Revolution

Wer eine grundlegende Neuausrichtung von SIAM wartet hatte, wird in den beiden Kerndokumenten nicht fündig. Die Grundarchitektur – SIAM-Layer, -Strukturen und -Terminologie – bleibt ebenso erhalten wie die vierstufige SIAM-Roadmap („Discovery & Strategy“, „Plan & Build“, „Implement“, „Run & Improve“). Dasselbe gilt für die grundsätzliche Bedeutung von Governance, Rollen und Verantwortlichkeiten. Viele Textpassagen aus Version 2 wurden unverändert übernommen. Die Gliederung ist weitgehend stabil geblieben – wenn auch an einigen Stellen sinnvoll neu sortiert. So wurden etwa die bislang je Roadmap-Phase separat ausgewiesenen Kapitel zu anwendbaren SIAM-Practices aufgelöst und inhaltlich in die jeweils passenden Themenkapitel integriert, was den Lesefluss merklich verbessert.

 

Business-bezogene Neuerungen in Version 3 des SIAM Body of Knowledge

Innerhalb dieses stabilen Fundaments setzt Version 3 jedoch deutliche neue Akzente, die sich durch beide Kerndokumente ziehen.

Zentral ist zunächst die Betonung, dass SIAM kein starres „One-Size-fits-all“-Modell ist. Stattdessen ist sie eine flexible Managementmethode, die sich an die jeweilige Unternehmenssituation anpassen lässt. Damit einher geht eine klare Verschiebung des Steuerungsfokus. Nicht mehr die reine Vertragseinhaltung der einzelnen Provider steht im Vordergrund, sondern der tatsächliche Business-Outcome. SIAM wird in der neuen Version konsequent als Teil eines am Business ausgerichteten Operating-Modells positioniert – nicht mehr nur als isolierte Steuerungsmethodik. Das spiegelt sich auch im gestiegenen Stellenwert von Business Cases wider, ebenso wie in einer insgesamt stärkeren Ausrichtung von SIAM-Strategie und Tooling-Strategie an der übergeordneten Business-Strategie.

Eng damit verbunden ist ein zweiter neuer Schwerpunkt: die Kundenausrichtung. Neben dem Business-Outcome rückt das Thema Experience Management neu in den Mittelpunkt. Im Performance Management sollen künftig neben klassischen Service Levels (SLAs) auch Experience Levels (XLAs) berücksichtigt werden, um sich besser an der Zufriedenheit der Nutzer ausrichten zu können. Die neue Version ergänzt den Umfang des Experience Management um eine Betrachtung der Experience aller am SIAM-Ökosystem beteiligten Stakeholdergruppen.

 

Weitere Neuerungen in Version 3 des SIAM Body of Knowledge

Auch kulturell schärft Version 3 das Bild. Sie betont viel deutlicher und immer wieder den Fokus auf „Kollaboration“ statt nur „Kooperation“. Dies bedeutet konkret eine Zusammenarbeit aller Parteien des Ecosystems mit Ausrichtung auf ein gemeinsames Ziel und nicht nur ein Nebeneinander einzelner Provider. Eine solche kollaborative Kultur soll auf Transparenz, Wertschätzung und vor allem Vertrauen aufbauen. Vertrauen wird dabei ausdrücklich als messbares Ziel verstanden, nicht nur als Wunschvorstellung.

Um die angestrebte „One-Team“-Kultur etablieren zu können, rückt in Version 3 zum einen Organizational Change Management als zentraler Erfolgsfaktor deutlich stärker in den Vordergrund. Zudem wird die gezielte Gestaltung von Providerverträgen im Sinne eines „SIAM-aware Contracting“ betont. Alle diese Faktoren sollen die angestrebte kollaborative Kultur unterstützen.

Des Weiteren interpretiert die neue Version Governance neu. Governance ist nicht mehr nur Rahmen für Steuerung und Kontrolle, sondern wird zunehmend als Enabler für die Weiterentwicklung von Services, Zusammenarbeit und Gesamtorganisation verstanden.

Schließlich trägt Version 3 dem Umgang mit kontinuierlicher Veränderung stärker Rechnung. Dies zeigt sich insbesondere bei Service-Gruppierung und deren regelmäßigem Review, der nun ausdrücklich auch Innovations- und Automatisierungsoptionen einbezieht. Auch der Security-by-Design-Ansatz, also die Integration von Security Management von Beginn an statt als nachträgliche Ergänzung, wird deutlicher betont. Aktuelle Themen wie KI, ESG, XLAs, Agile und Continuous Delivery werden in den Kerndokumenten zwar erwähnt, ihre Vertiefung erfolgt aber erst in den neuen Kompendien.

 

Compendium Layer: Vierzehn Vertiefungen für die Praxis

Während der Core Layer das stabile Fundament liefert, stellen die vierzehn neu entstandenen Kompendien wesentliche Aspekte der Managementmethode detaillierter dar. Jedes Kompendium greift dafür ein Thema aus den Kerndokumenten auf. Meist sind dies die oben erwähnten Neuerungen in den Kerndokumenten. In den Kompendien gibt die Version 3 praktische Handlungsempfehlungen, die vieles für die Umsetzung in die Praxis etwas konkreter werden lassen. Sie wurden erstellt von erfahrenen SIAM-Praktikern und -Beratern aus unterschiedlichen Organisationen, was der Sammlung eine breite praktische Perspektive verleiht.

Die nachfolgende Abbildung gibt einen Überblick über die Kompendien, ihren jeweiligen Umfang und Inhalt.

In Summe zeigt die Themenverteilung der Kompendien sehr deutlich, wo die fachlichen Schwerpunkte von Version 3 liegen: Vertrauen, Kultur, Experience Management und die strategische Einbettung von SIAM ins Operating-Modell erhalten mit Abstand den größten Raum. Dies ist ein klares Indiz dafür, dass „weiche“ Erfolgsfaktoren im SIAM-Betrieb zunehmend als mindestens ebenso entscheidend gelten wie Prozesse und Strukturen.

 

Fazit – SIAM Body of Knowledge Version 3

Der SIAM Body of Knowledge Version 3 ist eine evolutionäre und keine revolutionäre Weiterentwicklung. Die Grundarchitektur, die Roadmap-Phasen und die Kernprinzipien von SIAM bleiben unverändert – Organisationen, die bereits nach Version 2 arbeiten, müssen ihr SIAM-Modell nicht neu erfinden.

Gleichzeitig setzt Version 3 unverkennbar neue Schwerpunkte: weg von reiner Vertragssteuerung, hin zu Business-Outcome und Experience; weg von „Kooperation wo nötig“, hin zu echter Kollaboration auf Basis von Vertrauen.

Zudem bietet das neu eingeführte Layered Model der Version 3 eine Struktur, die künftige punktuelle Aktualisierungen deutlich erleichtert.

Für IT-Sourcing-Verantwortliche lohnt sich aus unserer Sicht vor allem ein Blick in drei Bereiche: die eigene Vertragsgestaltung im Sinne eines „SIAM-aware Contracting“, die Einführung von Experience Levels neben klassischen SLAs, und – nicht zuletzt – eine ehrliche Bestandsaufnahme, wie viel Vertrauen im eigenen Provider-Ökosystem tatsächlich vorhanden ist. Die umfangreichen neuen Kompendien bieten dafür einen strukturierten, praxisnahen Einstieg.

Seit dem 6. Dezember 2025 gilt in Deutschland das NIS2-Umsetzungsgesetz (NIS2UmsuCG) – ohne Übergangsfrist, ohne Schonfrist, ohne Aufschub. Rund 29.500 Unternehmen ab 50 Mitarbeitenden oder 10 Millionen Euro Umsatz in 18 Sektoren sind betroffen und sollten NIS2-konform aufgestellt sein, darunter Energie, Produktion, Logistik, Chemie und Abfall. Doch die Realität sieht anders aus: Zum Registrierungsstichtag am 6. März 2026 hatten sich lediglich rund 11.500 von geschätzten 29.850 betroffenen Unternehmen beim BSI-Portal registriert – das entspricht einer Quote von gerade einmal 38,5 Prozent. Zwei Wochen vor Fristablauf (06.03.2026) waren es sogar erst 4.856 Einrichtungen. Dieser Leitfaden erklärt, warum so viele Unternehmen noch immer nicht registriert sind, wer tatsächlich betroffen ist – und in welchen konkreten Schritten sich Unternehmen jetzt systematisch vorbereiten sollten.

 

Der alarmierende Stand der BSI-Registrierungen: Unwissenheit als größtes Risiko

Das Bild, das sich nach Ablauf der Registrierungsfrist ergibt, ist alarmierend. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat in den letzten Wochen mehrfach öffentlich betont, dass die Zahl der eingegangenen Registrierungen deutlich hinter den Erwartungen zurückbleibt.

Dafür gibt es mehrere Ursachen. Da nicht aktiv auf Unternehmen zugegangen wird, wissen viele schlicht nicht, dass sie betroffen sind. Die NIS-2-Richtlinie erfasst Organisationen ab 50 Beschäftigten oder mit mehr als 10 Millionen Euro Jahresumsatz in 18 verschiedenen Sektoren. Das BSI nimmt keine automatische Prüfung vor – jede Organisation muss selbst klären, ob sie dazugehört. Zweitens schrecken die weitreichenden Folgepflichten viele Unternehmen ab: Es geht nicht nur um eine einmalige Registrierung, sondern um laufende Meldepflichten und weitere Risikomanagement-Vorgaben. Das Bewusstsein für mögliche hohe Strafzahlungen und eben die persönliche Haftung der Geschäftsführung bei verpasster Unternehmensregistrierung scheint nicht vorhanden zu sein.

Ein weiterer Grund ist der massiv erweiterte Anwendungsbereich. Betroffen sind nicht mehr nur klassische kritische Infrastrukturen (KRITIS), sondern ein breites Spektrum an Sektoren und Tätigkeiten. Dadurch kommt man eventuell nicht auf die Idee, zur kritischen Infrastruktur zu gehören. Die Gesetzesbegründung geht von rund 30.000 betroffenen Unternehmen aus – tatsächlich dürfte die Zahl deutlich höher liegen.

 

Plötzlich betroffen: drohen unmittelbare Strafen?

Besonders tückisch: Die Betroffenheit ergibt sich oft nicht aus dem unmittelbaren Tätigkeitsfeld. Wer etwa anderen Konzerngesellschaften IT-Anwendungen wie Confluence oder Microsoft bereitstellt, gilt bereits als Anbieter von Managed Services. Wer einen eigenen Online-Shop betreibt und auch Dritten erlaubt, darüber Waren zu vertreiben, gilt als Betreiber eines Online-Marktplatzes im Sinne von NIS2. In beiden Fällen werden Mitarbeiter und Umsätze verbundener Unternehmen dabei für die NIS2-Betroffenheit in der Regel mitgezählt.

Dass das BSI nach Fristablauf nicht sofort mit Sanktionen vorgeht, ist zwar eine vorübergehend beruhigende Nachricht – sie ist jedoch keine Einladung zum Abwarten. Das BSI hat nach Ablauf der Registrierungsfrist angekündigt, nicht registrierte Unternehmen aktiv zu identifizieren. Die Behörde kann betroffene Einrichtungen zur Registrierung auffordern und bei Nichtbefolgung Bußgelder verhängen.

Nachfolgend wird in 4 Schritten dargestellt, wie eine NIS2-Betroffenheit identifiziert werden kann und was im Anschluss umzusetzen ist.

 

Schritt 1: Betroffenheit prüfen und intern klären

Der erste und wichtigste Schritt für jedes Unternehmen ist die Beantwortung der Frage: „Fallen wir unter das Gesetz?” Diese Selbstprüfung ist keine Kür, sondern gesetzliche Pflicht – und sie muss gründlich erfolgen.

NIS2 gilt für Unternehmen ab 250 Mitarbeitern oder 50 Millionen Euro Umsatz in 11 wesentlichen Sektoren sowie ab 50 Mitarbeitern oder 10 Millionen Euro Umsatz in 7 weiteren wichtigen Sektoren. Die 18 Sektoren und Schwellenwerte sind komplex, und die Abgrenzung zwischen wichtigen und besonders wichtigen Einrichtungen ist nicht trivial. Deshalb empfiehlt es sich, die Betroffenheitsprüfung auf der BSI-Website zu nutzen und im Zweifel rechtliche Beratung hinzuzuziehen.

Besondere Aufmerksamkeit verdient die sogenannte mittelbare Betroffenheit: Auch Dienstleister und Zulieferer kritischer Infrastrukturen können als NIS2-reguliert eingestuft werden, selbst wenn sie nicht unmittelbar in einem KRITIS-Sektor tätig sind. Unternehmen sollten daher auch prüfen, ob ihre Kunden oder Auftraggeber selbst NIS2-pflichtig sind und entsprechende Anforderungen an sie weitergeben.

Für die interne Klärung empfiehlt sich ein strukturierter Workshop auf Leitungsebene, bei dem Sektor, Unternehmensgröße und Rolle in der Lieferkette gemeinsam bewertet werden. Ein solcher Workshop sollte durch die zuständige Stelle im Unternehmen angestoßen werden, wie etwa der Compliance Abteilung. Das Ergebnis sollte schriftlich dokumentiert werden – denn im Falle einer späteren BSI-Prüfung muss diese Selbsteinschätzung lückenlos nachvollzogen werden können.

 

Schritt 2: BSI-Registrierung durchführen – der Einstieg in die Compliance

Wer festgestellt hat, dass sein Unternehmen unter NIS2 fällt, muss sich unverzüglich beim BSI registrieren. Das BSI stellt seit dem 6. Januar 2026 ein neu entwickeltes Portal bereit, das unter anderem auch als zentrale Meldestelle für erhebliche Sicherheitsvorfälle dient. Die Registrierung für NIS-2-Meldungen erfolgt zweistufig.

Technisch läuft die NIS2-Registrierung über ein ELSTER-Organisationszertifikat ab, mit dem man sich gegenüber „Mein Unternehmenskonto” (MUK) authentifiziert. Dieses Zertifikat dient als digitaler Identitätsnachweis des Unternehmens, die damit verknüpften Stammdaten werden später ins BSI-Portal übernommen. Viele Unternehmen besitzen bereits ein ELSTER-Organisationszertifikat aus Steuer- oder Verwaltungsprozessen – in diesen Fällen ist kein neues Zertifikat erforderlich.

Für die Registrierung im BSI-Portal werden unter anderem Unternehmensgröße und Rechtsform, eine NIS2-Kontaktstelle sowie die Zuordnung zu Sektor und zuständiger Bundesbehörde abgefragt. Alle Angaben sind aktuell zu halten und spätestens zwei Wochen nach Änderungen im Portal zu aktualisieren.

Wichtig: Die Registrierung ist kein Abschluss, sondern ein Anfang. Sie ist die Grundlage dafür, dass das BSI das Unternehmen als NIS2-regulierte Einrichtung führt und dass Vorfälle gemeldet werden können. Danach kann den weiteren Pflichten aus dem BSI-Gesetz (BSIG) nachgekommen werden.

 

Schritt 3: Technische und organisatorische Maßnahmen umsetzen

Nach der Registrierung beginnt die eigentliche inhaltliche Arbeit: die Umsetzung der gesetzlich vorgeschriebenen Sicherheitsmaßnahmen. Da das Gesetz keine Übergangsfristen für die technischen und organisatorischen Maßnahmen nach § 30 BSIG vorsieht, müssen diese bereits seit dem 6. Dezember 2025 implementiert sein. Diese Maßnahmen gleichen denen aus Artikel 21 der NIS2-Richtlinie. Ein zu langes Abwarten kann bereits als Organisationsverschulden gewertet und mit Strafgebühren sanktioniert werden.

NIS2 fordert im Kern ein Informationssicherheitsmanagementsystem (ISMS). Wer ISO 27001 bereits umsetzt, deckt erfahrungsgemäß 70 bis 80 Prozent der Anforderungen ab. Wer noch kein ISMS hat, sollte jetzt unverzüglich mit dem Aufbau beginnen.

Besonderes Augenmerk verdient die Lieferkettensicherheit: Unternehmen müssen die Cybersicherheit ihrer Zulieferer und Dienstleister aktiv managen und vertraglich absichern. Das betrifft auch Unternehmen, die selbst nicht unter NIS2 fallen, aber als Zulieferer regulierter Einrichtungen arbeiten – ein indirekter Betroffenenkreis, der die 29.500 Einrichtungen noch deutlich übersteigt.

 

Schritt 4: Meldeprozesse und Governance etablieren

Ein oft unterschätzter Baustein der NIS2-Compliance sind die Meldepflichten und die Governance-Anforderungen. Die Pflicht, erhebliche Sicherheitsvorfälle unverzüglich zu melden, gilt seit dem 6. Dezember 2025 – unabhängig vom Stand der Registrierung. Unternehmen dürfen nicht abwarten, bis das BSI-Portal verfügbar oder die Registrierung abgeschlossen ist.

Der Meldeprozess folgt einem festen Dreistufenmodell: Eine Frühwarnung innerhalb von 24 Stunden, eine Detailmeldung innerhalb von 72 Stunden und ein Abschlussbericht innerhalb eines Monats – diese Maximalfristen sind verbindlich einzuhalten. Wer keinen dokumentierten Incident-Response-Plan hat, wird diese Fristen im Ernstfall nicht einhalten können. Hier empfiehlt sich auch die Etablierung eines Security Event & Incident Management Systems (SIEM).

Auf Leitungsebene gelten besondere Pflichten: Leitungsorgane müssen NIS2-spezifische Schulungen absolvieren, die selbstverständlich über ein Schulungskonzept erst erarbeitet werden müssen. Zusätzlich sind Schulungsangebote für alle Mitarbeitenden Pflicht – nicht als einmalige Veranstaltung, sondern als kontinuierliches Programm, welches natürlich auch dokumentiert werden muss. Die Pflicht zur Teilnahme an Schulungen und die persönliche Haftung für die Überwachung der Risikomanagementmaßnahmen nach § 38 BSIG gilt seit dem 6. Dezember 2025.

 

Fazit

Die niedrige Registrierungsquote von gerade einmal 38,5 Prozent zum Stichtag ist ein deutliches Warnsignal: Ein Großteil der betroffenen Unternehmen in Deutschland hat NIS2 entweder falsch eingeschätzt oder schlicht nicht auf dem Radar. Die Unwissenheit schützt dabei nicht vor Konsequenzen.

Viele Geschäftsführer wissen bis heute nicht, ob ihr Unternehmen betroffen ist – und riskieren damit nicht nur Bußgelder, sondern auch die persönliche Haftung nach § 38 BSIG. Wer die Registrierungsfrist verpasst hat, sollte diese sofort nachholen – das BSI-Portal ist weiterhin geöffnet, und eine verspätete Registrierung zeigt zumindest guten Willen.

Die eigentliche Botschaft von NIS2 ist jedoch eine grundlegendere: Cybersicherheit ist kein IT-Thema, sondern Chefsache. Unternehmen, die jetzt strukturiert vorgehen – Betroffenheit prüfen, sich registrieren, ein ISMS aufbauen, Meldeprozesse etablieren, Resilienz aufbauen – schützen nicht nur sich selbst vor Bußgeldern und Haftungsrisiken, sondern auch ihre Geschäftsbeziehungen und ihre Reputation. Denn der Druck zur Compliance kommt nicht nur vom BSI, sondern zunehmend auch aus der Lieferkette selbst: Wer keine NIS2-Konformität nachweisen kann, riskiert den Verlust wichtiger Geschäftspartner.

Hier geht es zur:

Anmeldung

Sie werden weitergeleitet auf die Anmeldeseite unseres Partners Deutscher Outsourcing Verband e.V.

Eine Ausschreibung von IT-Hardware für ein Unternehmen bzw. den öffentlichen Sektor durchzuführen, klingt zunächst simpel: Man braucht Laptops, Monitore, Smartboards oder Server – also schreibt man aus, vergleicht Preise und bestellt. In der Realität und insbesondere im öffentlichen Sektor ist die Sache häufig komplexer. Ausschreibungsunterlagen müssen einerseits glasklar beschreiben, was benötigt wird, andererseits (im öffentlichen Sektor) produktneutral bleiben und dürfen den Wettbewerb nicht unzulässig einschränken. Nur so lässt sich wirtschaftlich einkaufen. Gleichzeitig sollen sie so präzise sein, dass möglichst wenige Bieterfragen entstehen – denn jede Rückfrage kostet Zeit, erhöht den Koordinationsaufwand und kann im schlechtesten Fall zu Fristverlängerungen und im öffentlichen Sektor zu Rügen oder einer Aufhebung des Verfahrens führen. Dieser Artikel beleuchtet typische Schwierigkeiten bei der Gestaltung von Ausschreibungsunterlagen und zeigt praxisnahe Wege, wie Leistungsbeschreibungen und Vergabeunterlagen so aufgebaut werden können, dass sie klar, marktoffen, nachfragearm sind und wirtschaftliche Preise sicherstellen.

Gerade bei IT-Hardware ist die Gefahr hoch: Schnelllebige Produktzyklen, unterschiedliche Konfigurationslogiken, Kompatibilitätsfragen, Lieferkettenrisiken und heterogene Bestandslandschaften treffen insbesondere im öffentlichen Sektor auf ein Regelwerk, das Transparenz, Gleichbehandlung und Wettbewerb sicherstellen soll.

 

Der Kernkonflikt: Präzise Bedarfslage versus produktneutrale Ausschreibung

Die wichtigste Herausforderung lässt sich in einem Satz zusammenfassen: Je genauer die Anforderungen, desto größer das Risiko einer indirekten Produktfestlegung – je offener die Formulierung, desto größer das Risiko von Missverständnissen und Bieterfragen. Dies gilt nicht nur für den öffentlichen Sektor, sondern auch für private Unternehmen: Die Festlegung auf ein konkretes Produkt schafft weniger Konkurrenz und damit schlechtere Einkaufspreise.

Bei Hardware zeigt sich das besonders deutlich. Ein konkreter Akku-Wert, ein spezieller Port-Mix oder eine bestimmte Docking-Station kann faktisch nur von wenigen Modellen erfüllt werden. Andererseits führen schwammige Vorgaben („aktueller Business-Laptop“) zu Interpretationsspielräumen, die zu nicht vergleichbaren Angeboten führen. Und wenn am Ende Angebote eingehen, die formal passen, aber im Betrieb nicht funktionieren (Treiber, Management-Tools, Kompatibilität), ist die Beschaffungsstelle in der Zwickmühle.

Die Kunst der Unterlagen liegt deshalb darin, Anforderungen auf Funktion, Leistung und Einsatzszenario zu beziehen – und nicht auf ein konkretes Modell. Das bedeutet: weg von „genau dieses Gerät“, hin zu „diese Leistungsfähigkeit im definierten Umfeld“.

 

Bedarf und Einsatzszenario sauber beschreiben – bevor man technische Werte festlegt

Viele Ausschreibungsverfahren erzeugen Nachfragen, weil der Bedarf nur als Liste technischer Mindestwerte formuliert ist, ohne den Kontext zu erklären. Dabei reduziert eine gute Beschreibung der Ausgangslage Rückfragen erheblich, weil Anbieter verstehen, wofür die Hardware gedacht ist und welche Anforderungen zwingend sind.

Praktisch bedeutet das die Beschreibung von folgenden Punkten:

• Nutzungsprofile
  z.B. Office/Standard, Power-User, Mobile/Field-Work, Entwickler, Grafik/CAD, Schulungsräume
• Betriebsmodell
  z.B. zentraler Rollout, Auto-Pilot/Imaging, Geräteverwaltung via Mobile Device-Management/Endpoint-Management, On-Prem/Cloud-Anbindung
• Bestandsumgebung
  z.B. vorhandene Docking-Stations/Monitore, Peripherie, Zertifikate, Smartcards, WLAN-Standards
• Mengengerüst und Laufzeit
  z.B. Abrufmengen, Rahmenvertrag, Erweiterungsoptionen
• Service- und Austauschlogik
  z.B. Vor-Ort-Service, Next-Business-Day, Bring-In, Ersatzteilverfügbarkeit, Ersatzgerätepool

Wenn diese Punkte klar sind, lassen sich technische Anforderungen gezielter und marktgerechter formulieren – und die Zahl der „Bitte präzisieren Sie…“-Fragen der Bieter sinkt spürbar.

 

Produktneutral, aber eindeutig: Leistungsbeschreibung ohne versteckte Markenbindung

Produktneutralität heißt nicht, dass man keine Anforderungen stellen darf – sondern dass Anforderungen sachlich gerechtfertigt und wettbewerbsoffen sind.

Bei Hardware sollten beispielsweise die folgenden Punkte vermieden werden:

• Markentypische Begriffe („MagSafe“, „ThinkPad-Dock“, „iGPU-Feature X“) ohne funktionales Pendant
• Zu enge Grenzwerte (z. B. „genau 1,35 kg“, „genau 16:10 und 2560×1600“, „genau Portkombination A+B+C“)
• Anforderungslisten ohne Priorisierung (alles „MUSS“)

Solche Vorgaben wirken oft wie ein verdeckter Modellfilter und führen zum Ausschluss vieler Angebote sowie einer Erhöhung des Aufhebungsrisikos.

Hier ist es besser, funktional zu beschreiben.

Statt „USB-C Dock Modell XYZ“ besser: „Dockinglösung, die Stromversorgung, Datenübertragung und Bildausgabe über eine kabelgebundene Verbindung ermöglicht; kompatibel mit den angebotenen Endgeräten; unterstützt mindestens zwei externe Displays im definierten Auflösungs-/Hz-Bereich.“

Wenn eine Nennung eines Fabrikats ausnahmsweise unvermeidbar ist (z. B. wegen vorhandener Infrastruktur), gehört in die Unterlagen eine klare Gleichwertigkeitsregel. Das reduziert Rückfragen und schützt im öffentlichen Sektor vor Rügen, weil Bieter nachvollziehen können, wie Gleichwertigkeit bewertet wird.

 

Mindestanforderungen, Soll-Kriterien und Ausschlusslogik: Weniger ist oft mehr

Ein typischer Grund für Bieterfragen sind überladene Muss-Kataloge. Je mehr Muss-Kriterien, desto mehr Interpretationsbedarf entsteht („zählt das auch?“, „wie wird gemessen?“, „welcher Nachweis?“).

Hier sind einige Empfehlungen für eine robuste Anforderungsstruktur:

• MUSS-Kriterien nur für wirklich betriebsnotwendige Punkte (z. B. Security-Funktionen, Management-Fähigkeit, bestimmte Schnittstellen, Mindestleistung für definierte Anwendungen).
• SOLL-Kriterien für Komfort, Zukunftsfähigkeit und Differenzierung im Wettbewerb.
• KANN-Kriterien für Add-ons oder Varianten, die separat bepreist werden.

Im öffentlichen Sektor ist eine eindeutige Ausschlusslogik zu formulieren:

• Wann wird ein Angebot ausgeschlossen? (nur bei Nichterfüllung von Muss-Kriterien)
• Wie werden Soll-Kriterien bewertet? (Punkte, Gewichtungen, klare Skalen für die Punktevergabe)

Je transparenter diese Logik ist, desto weniger Rückfragen kommen auf und desto geringer das Risiko, dass die Wertung angreifbar wird.

 

Vergleichbarkeit herstellen: Konfigurationen, Zubehör, „versteckte“ Leistungsbestandteile

Bei der Ausschreibung von IT-Hardware entstehen viele Rückfragen nicht wegen CPU oder RAM, sondern wegen Randthemen, die in der Praxis entscheidend sind:

• Netzteile (Leistung, Anzahl, EU-Stecker, Ersatznetzteil ja/nein)
• Tastatur-Layout (DE), Touch/Non-Touch, Stift-Support
• Garantiebedingungen (Laufzeit, Reaktionszeit, Abwicklung)
• Imaging/Autopilot-Bereitstellung, Treiberpakete, BIOS-Konfigurierbarkeit
• Nachhaltigkeit/Verpackung/Rückgabe
• Kompatibilität mit vorhandenen Monitoren, Docks, Zertifikaten

Hier empfiehlt es sich, ein eigenes Kapitel „Lieferumfang und Nebenleistungen“ mit klaren Vorgaben zu erstellen:

• „Pro Gerät: Netzteil, mind. X m Kabel, deutsche Tastatur, Seriennummernliste, Asset-Tags nach Vorgabe, BIOS-Konfiguration gemäß Profil, Dokumentation der Treiberversionen.“
• „Zubehör in separaten Positionen“ (Dock, Monitor, Tasche, Adapter), damit Angebote vergleichbar bleiben.

Je klarer der Lieferumfang, desto weniger Fragen wie etwa „Ist Adapter XY enthalten?“ kommen auf und desto geringer die Gefahr, dass Bieter unterschiedliche Annahmen kalkulieren und Angebote am Ende nicht vergleichbar sind.

 

Zuschlagskriterien so formulieren, dass sie nicht angreifbar sind

Oft kommt es vor, dass Unterlagen zwar technisch sauber sind, die Zuschlagskriterien aber zu schwammig („Qualität“, „Service“, „Nachhaltigkeit“) und ohne Bewertungsmethodik aufgeführt sind. Das führt zu Rückfragen und erhöhtem Konfliktpotenzial mit den Bietern.

Zuschlagskriterien müssen das Folgende leisten:

• Sie müssen messbar oder zumindest nachvollziehbar bewertbar sein
• Gewichtungen müssen klar sein
• Der Bewertungsmaßstab muss bei Angebotsabgabe ebenfalls vorliegen
• Gewünschte Nachweise müssen benannt sein (Datenblätter, Zertifikate, SLA-Dokumente etc.)

Beispiele für klare Kriterien:

• Energieeffizienz/Umweltlabels (definierte akzeptierte Nachweise)
• Servicelevel (Reaktionszeit, Reparaturzeit, Abwicklungskanal)
• Lieferfähigkeit (verbindliche Lieferfristen, Pönalen bei Verzug)
• Total Cost of Ownership-Elemente (Garantieverlängerung, Ersatzteilpreise, Standardzubehör)

Je konkreter die Bewertungslogik, desto weniger Nachfragen kommen auf. Gleichzeitig sinkt das Risiko, dass die Wertung später als „intransparent“ kritisiert wird.

 

Bieterfragen minimieren: Typische Ursachen und Gegenmaßnahmen

Um möglichst wenige Nachfragen zu erzeugen, lohnt es sich, die häufigsten Ursachen zu betrachten und bei der Erstellung der Ausschreibungsunterlagen zu vermeiden.

Häufige Auslöser von Rückfragen sind etwa:

• Widersprüche zwischen Leistungsbeschreibung, Preisblatt, Vertragsentwurf und Anlagen
• Unklare Begrifflichkeiten („gleichwertig“, „kompatibel“, „Business-Klasse“)
• Fehlende Mengengerüste oder unklare Abruflogik in Rahmenverträgen
• Unvollständige Leistungsverzeichnisse (z. B. fehlende Zubehörpositionen)
• Unklare Nachweis-Forderungen (was muss konkret eingereicht werden und in welcher Form?)

Gegenmaßnahmen, die hier entgegenwirken:

• Konsistenzcheck:
  Einmal querlesen mit „Bieterbrille“ (am besten durch eine Person, die nicht am Text mitgeschrieben hat).
• Begriffsdefinitionen:
  Ein Glossar oder ein Abschnitt „Definitionen und Nachweise“.
• Beispielkonfigurationen:
  Für jedes Nutzungsprofil eine Beispielkonfiguration, damit klar ist, was gemeint ist.
• Preisblatt optimieren:
  Keine Mischpositionen; klare Einheit (Stück, Set, Jahr), klare Optionslogik.
• Abnahme- und Testkriterien:
  Was gilt als erfüllt? Welche Tests sind vorgesehen (z. B. Docking mit zwei Monitoren, WLAN-Roaming, Gerätemanagement)?.

 

Die häufigsten Ursachen für eine Aufhebung

Eine Aufhebung ist selten „Pech“, sondern oft die Folge struktureller Probleme, die bereits beim Erstellen der Ausschreibungsunterlagen entstehen. Typische Ursachen sind:

• Kein wirtschaftliches Ergebnis (Budget/Marktpreis klaffen auseinander)
• Zu geringe Konkurrenz (zu detaillierte Muss-Kriterien, unnötige Ausschlüsse)
• Wertungsprobleme (intransparente oder widersprüchliche Zuschlagskriterien)
• Formale Fehler (fehlende Angaben, falsche Fristen, unklare Eignungskriterien)

Wie man das Aufhebungsrisiko bei der Gestaltung der Ausschreibungsunterlagen senkt:

• Markterkundung/Marktsichtung im Vorfeld (ohne sich auf ein Produkt festzulegen):
  Welche Leistung ist marktüblich? Welche Bandbreiten sind realistisch?
• Anforderungen priorisieren:
  Muss-Kriterien auf das Notwendige begrenzen, Soll-Kriterien für Differenzierung nutzen.
• Mögliche Änderungen beachten:
  Auch bei schnelllebiger Hardware sind Rahmenverträge häufig sinnvoll – allerdings nur, wenn ein Produktwechsel/Refresh sauber geregelt ist (z. B. Nachfolgemodelle als gleichwertig, Preislogik).
• Faire Eignungskriterien:
  Keine überzogenen Anforderungen vorgeben (z. B. Referenzen so formulieren, dass marktüblich viele Anbieter sie erfüllen können, ohne die Qualität zu gefährden).
• Interne Freigaben vor Veröffentlichung:
  Budget, Bedarf, IT-Architektur, Security, Datenschutz, Betrieb – alles vorab abgestimmt. Viele Aufhebungen entstehen, weil intern nach Veröffentlichung neue Anforderungen gestellt werden.

 

Fazit

Gute Ausschreibungsunterlagen für IT-Hardware sind weniger ein „Datenblatt-Abschreiben“, sondern eine Disziplin aus Bedarfsanalyse, marktoffener Leistungsbeschreibung, eindeutiger Bewertungslogik und sauberer Konsistenzarbeit. Die größten Schwierigkeiten entstehen dort, wo Anforderungen entweder zu eng (produktähnlich) oder zu vage (interpretierbar) formuliert werden. Wer stattdessen konsequent vom eigenen Einsatzszenario ausgeht, Muss-Kriterien schlank hält, Gleichwertigkeit prüfbar definiert und Lieferumfang sowie Nachweise klar regelt, erreicht vier zentrale Ziele gleichzeitig: weniger Bieterfragen, bessere Vergleichbarkeit der Angebote, ein deutlich geringeres Risiko einer Aufhebung (im öffentlichen Sektor) und wirtschaftliche Preise.

Nach 6 Jahren ITIL4 kommt jetzt, d.h. noch im Februar die neue ITIL-Version. Dies wollen wir zum Anlass nehmen, eine erste Einschätzung der neuen Version vorzunehmen. Erfreulich ist aus unserer Sicht, dass ITIL 5 nicht wie einige vorherige Versionen einen Bruch darstellt, sondern eine schlüssige Weiterentwicklung der Version 4 ist – Evolution statt Revolution. Bewährtes bleibt erhalten, während das neue Framework gleichzeitig wichtige neue Entwicklungen am Markt aufgreift und integriert. Dies betrifft insbesondere die Themen KI, automatisierte Betriebsformen und Experience-Orientierung.

 

ITIL 5 ist da – was ist neu?

• Digital Product & Service Management statt reinem Service Management – ITIL 5 erweitert den bisherigen Service-lastigen Fokus, indem es digitale Produkte und Services stärker gemeinsam in einem Modell abbildet. So können Produkt‑ und Service-Teams besser kooperieren.
• Erweitertes, einheitliches Lifecycle‑Modell – in der Service-Value-Chain wird der in der Version 4 etwas fragmentierte Lifecycle in 8 Schritte aufgeteilt. Dies sind: Discover, Design, Acquire, Build, Transition, Operate, Deliver, Support. Hierdurch wird das Modell klarer, einfacher und flexibler.
• ITIL 5 ist „KI-native“ – Künstliche Intelligenz ist nicht nur Add‑on, sondern wird vollständig in das Framework integriert, d.h. die Prinzipien für Automatisierung und KI-Nutzung sind durchgängig im Framework verankert. Neben der Darstellung der KI-Governance-Gestaltung sind KI-Aspekte unter anderem auch in allen Practice Guides enthalten.
• Stärkere Experience‑Orientierung – Nutzer‑ und Mitarbeitererlebnisse rücken stärker in den Mittelpunkt. Für jede Aktivität und jeden Service wird geprüft, welchen Beitrag er zur Wertgenerierung leistet. Und dies wird an den Erfahrungen von Nutzern und Mitarbeitern gemessen.

 

Was bleibt gleich?

• Guiding Principles, Four Dimensions, Service Value System aus der Version 4 bleiben das stabile Fundament.
• Alle 34 Practices der letzten ITIL-Version behalten ihre Gültigkeit.
• Bestehendes Wissen, Erfahrungen und Zertifizierungen behalten ihren Wert – es ist kein Neustart erforderlich.

 

Was bedeutet das für Unternehmen?

• Investitionsschutz: Bestehende Strukturen und Verfahren im Servicemanagement der eigenen Organisation können weiter genutzt werden. Mit den Erweiterungen in ITIL 5 können sie sukzessive weiterentwickelt werden.
• Mehr Alignment über die Organisation hinweg – ITIL wird mit seiner evolutionären Entwicklung noch stärker zum Enterprise‑Service‑Management‑Framework.
• Vorbereitung auf KI‑getriebene Digitalisierung: Die gute Integration von KI in dem Framework schafft einen soliden Rahmen, um intelligente Automatisierung im Service-Management zu etablieren und immer weiter auszubauen.

 

Unser erstes Fazit:

ITIL 5 schafft eine gute Grundlage für alle Organisationen, die sich im digitalen Produkt‑ und Servicezeitalter auf Basis der bisherigen eigenen Aufstellung weiterentwickeln wollen. So können sie weiterhin und ohne großen Bruch verlässlich, skalierbar und zukunftsfähig agieren.

Das NIS2-Umsetzungsgesetz war noch keinen Monat in Kraft, als die Notwendigkeit solcher Richtlinien mehr als deutlich wurde. Anfang Januar 2026 hat ein Brand auf einer Kabelbrücke in Berlin die Stromversorgung in mehreren Stadtteilen tagelang unterbrochen – mit Folgen, die weit über „kein Licht“ hinausgehen: Heizung, Internet, Mobilfunk, Kassen- und Logistiksysteme, Pflegeeinrichtungen und betriebliche Abläufe gerieten schnell unter Druck. Dieser Brandanschlag ist vor allem ein physischer Angriff. Aber er zeigt, wie eng physische Infrastruktur und digitale Abhängigkeiten inzwischen ineinandergreifen – und warum das NIS2-Umsetzungsgesetz nicht als „reines IT-Thema“ verstanden werden sollte. Denn NIS2 zielt auf ein höheres gemeinsames Sicherheitsniveau für Netz- und Informationssysteme, gerade dort, wo Ausfälle gesellschaftlich besonders teuer werden: Energie, Gesundheit, Verkehr, digitale Infrastruktur und öffentliche Verwaltung.

 

Was ist NIS2 – und warum brauchte es ein Umsetzungsgesetz?

NIS2 ist die EU-Richtlinie (EU) 2022/2555. Sie ersetzt die frühere NIS-Richtlinie und verschärft Pflichten, Aufsicht und Sanktionen. Wichtig: Als Richtlinie gilt sie nicht „automatisch“ in jedem Mitgliedstaat, sondern muss in nationales Recht übertragen werden. Dafür gab es eine verbindliche Umsetzungsfrist: bis 17. Oktober 2024.

Deutschland hat diese Umsetzung mit einem Jahr Verspätung mit einem entsprechenden Gesetzespaket vorgenommen. Ziel ist ausdrücklich, die Abwehrfähigkeit von wichtigen Einrichtungen zu stärken, Meldepflichten zu konkretisieren und europaweit einheitlichere Standards zu schaffen. Das Gesetz trat am 6. Dezember 2025 in Kraft.

 

Was ändert das NIS2-Umsetzungsgesetz in Deutschland konkret?

Das NIS2-Umsetzungsgesetz ist kein einzelner „IT-Paragraf“, sondern erweitert und ordnet einen ganzen Rahmen neu. In der Begründung des Gesetzes wird sehr klar gemacht, worum es geht: Resiliente Infrastruktur im physischen und digitalen Bereich, gestiegene Bedrohungen (Sabotage, Hacktivismus, Lieferkettenangriffe) und der Bedarf an verbindlicheren Mindestanforderungen.

Zentrale Bausteine sind u. a.:

• Neue Kategorien betroffener Einrichtungen (insb. „wesentliche“ bzw. in Deutschland „besonders wichtige“ sowie „wichtige“ Einrichtungen) – und damit eine spürbare Ausweitung gegenüber dem bisherigen Fokus auf klassische KRITIS-Betreiber.
• Mindestmaßnahmen-Katalog: Die (EU-weit vorgegebenen) Mindestsicherheitsanforderungen werden ins nationale Recht überführt und nach Kategorien abgestuft.
• Mehr Aufsichtsbefugnisse für das BSI und weiteren zuständigen Stellen sowie ein verbindlicherer Rahmen für die Bundesverwaltung (inkl. IT-Grundschutz-Orientierung und Koordination).

Das NIS2-Umsetzungsgesetz reiht sich ein in die Liste der deutschen IT-Sicherheitsgesetze und hat darüber hinaus Einfluss auf das BSI-Gesetz sowie weitere KRITIS relevante Gesetze. Einen Überblick geben die Abbildungen 1 und 2.

Kurz gesagt: NIS2 macht aus „Best Effort“ in vielen Bereichen eine nachweis- und prüfbare Pflicht.

 

Wer ist betroffen – nicht nur „Mehr Unternehmen“

Die Bundesregierung betont, dass NIS2 mehr Unternehmen und Branchen zu einheitlichen Sicherheitsstandards verpflichtet, insbesondere in zentralen Versorgungsbereichen wie Energie, Gesundheit und Infrastruktur.

Praktisch bedeutet das: Betroffen sind nicht nur die „üblichen Verdächtigen“ der KRITIS-Welt, sondern auch viele mittelgroße Organisationen in definierten Sektoren – plus bestimmte digitale Dienste (z. B. Cloud-/Rechenzentrumsleistungen, Managed Services etc., je nach genauer Einordnung).

Eine detaillierte Übersicht, wer in welchem Bereich betroffen ist, haben wir in einem früheren NIS2-Artikel aufgelistet.

 

Pflichten aus NIS2: Mehr als nur Firewall und Antivirus

NIS2 verlangt ein systematisches Sicherheits- und Risikomanagement. Der Maßnahmenkatalog, wie er im Gesetzentwurf abgebildet ist, liest sich wie eine „To-do-Liste moderner Resilienz“ – und zwar ausdrücklich inklusive Betriebskontinuität, Lieferkette und Notfallkommunikation. Dazu zählen u. a.:

• Risikoanalyse- und Sicherheitskonzepte
• Aufrechterhaltung des Betriebs: Backup-Management, Wiederherstellung nach Notfall, Krisenmanagement
• Schwachstellenmanagement & Offenlegung
• Sicherheit im Betrieb (MFA, Verschlüsselung etc.)

Eine detailliertere Darstellung des Maßnahmenkatalogs ist einem unserer früheren NIS2-Artikel zu finden.

Was viele unterschätzen: Punkte wie etwa Backup/Wiederanlauf/Krisenmanagement sind in der IT auch dann betroffen, wenn es sich wie in Berlin um einen physischen Angriff handelt. Ohne Strom laufen irgendwann auch USVs leer, Mobilfunkstandorte fallen aus, Netzknoten verlieren Versorgung, Rechenzentren schalten in Notbetrieb – und plötzlich ist ein „IT-Vorfall“ da, obwohl kein Hacker je ein Passwort gesehen hat.

Der EU Data Act ergänzt diese Bausteine, indem er die technische und vertragliche Grundlage für fairen, transparenten Datenaustausch legt – besonders zugunsten von KMU, die so leichter Zugang zu wertvollen Datensätzen erhalten und neue Geschäftsmodelle entwickeln können.

 

Melde- und Registrierungspflichten

NIS2 verschärft die Verbindlichkeit und Geschwindigkeit der Kommunikation bei erheblichen Sicherheitsvorfällen mit einem dreistufigen Ablauf:

1. spätestens innerhalb von 24 Stunden nach Kenntnis: frühe Erstmeldung (inkl. Einschätzung, ob böswillig/rechtswidrig und ob grenzüberschreitende Auswirkungen möglich sind)
2. spätestens innerhalb von 72 Stunden nach Kenntnis: qualifiziertere Meldung mit erster Bewertung, Schweregrad, Auswirkungen, ggf. Indikatoren
3. spätestens einen Monat nach der 72h-Meldung: Abschlussmeldung mit detaillierter Beschreibung, Ursache/Bedrohungsart, Abhilfemaßnahmen, ggf. grenzüberschreitende Auswirkungen

Gleichzeitig wurde eine gemeinsame Meldestelle vom Bundesamt und dem Bundesamt für Bevölkerungsschutz und Katastrophenhilfe eingerichtet (u. a. mit Beteiligung von BSI), was die Verzahnung von Cyber- und Krisenmanagement unterstreicht.

 

Aufsicht, Sanktionen und Geschäftsleitung: NIS2 wird „Chefsache“

NIS2 ist nicht nur technisch, sondern auch Governance-getrieben: Pflichten sollen nicht „irgendwo in der IT“ versanden, sondern von oben getragen und überwacht werden. Das zeigt sich im deutschen Gesetzestext u. a. durch explizite Regelungen zur Verantwortung von Geschäftsleitungen in bestimmten Bereichen: Umsetzungs- und Überwachungspflichten, Schulungspflichten sowie eine Haftungsanbindung an gesellschaftsrechtliche Regeln werden im Gesetzestext adressiert.

Bei Verstößen drohen zudem empfindliche Sanktionen. Auf EU-Ebene sieht NIS2 für Verstöße gegen zentrale Pflichten (u. a. Risikomanagement und Meldungen) Mindestobergrenzen für Geldbußen vor – z. B. für wesentliche Einrichtungen mindestens 10 Mio. EUR oder 2 % des weltweiten Umsatzes (je nachdem, was höher ist) und für wichtige Einrichtungen mindestens 7 Mio. EUR oder 1,4 %.

Die Botschaft dahinter ist klar: NIS2 will Wirkung – nicht nur Dokumentation.

 

Der Brandanschlag in Berlin als Realitätscheck

Beim Berliner Vorfall wurde deutlich, wie schnell sich ein physischer Angriff zu einer systemischen Störung auswachsen kann. Zeitweise waren laut Berichten rund 45.000 Haushalte und 2.200 Betriebe betroffen; zudem ging es eben nicht nur um Strom, sondern auch um Wärme und Kommunikation.

Genau hier trifft NIS2 einen Nerv: Viele NIS2-Maßnahmen sind darauf ausgelegt, Ketteneffekte zu begrenzen – etwa durch Wiederanlaufkonzepte, Notfallkommunikation, Lieferkettenkontrollen und Krisenmanagement.

Für Energie- und Versorgungsunternehmen (und alle, die davon abhängen) heißt das konkret:

• IT (Telekommunikation, Wartungszugänge) und OT (Leitstellen, Sensorik, Netzbetrieb) als Gesamtsystem betrachten.
• Blackout-Szenarien in Business-Continuity-Planung aufnehmen: Was passiert nach 2, 6, 24, 72 Stunden ohne stabile Versorgung?
• Kommunikationsfähigkeit als eigene Sicherheitsanforderung behandeln (interne Notfallkommunikation, Out-of-band-Kanäle).
• Krisenübungen nicht als Pflichtübung, sondern als Funktionstest verstehen: Wer entscheidet, wer informiert, wer dokumentiert, wer meldet – und wie schnell?

Der Berliner Brandanschlag ist ein drastisches Beispiel dafür, warum „kritische Infrastruktur schützen“ nicht nur Zaun und Wachschutz bedeutet – aber eben auch nicht nur Patchmanagement.

 

Praxis-Fahrplan: So starten Organisationen jetzt sinnvoll

Wer potenziell unter NIS2 fällt, sollte pragmatisch vorgehen:

• Eigene Betroffenheit klären: Sektor/Leistung, Rolle, Größe, ggf. konzernweite Einordnung.
• Gap-Analyse gegen den Maßnahmenkatalog: Was ist bereits im ISMS/ITSM vorhanden – und was fehlt (z. B. Lieferkettenrisiken, Notfallkommunikation, Schwachstellenprozesse)?
• Meldeprozesse „24h-ready“ machen: Entscheiderkette, Incident-Kriterien, Vorlagen, Kontaktpunkte, Beweis- und Log-Sicherung, Kommunikationsregeln.
• Registrierungspflichten operationalisieren (Datenpflege, Änderungen, Verantwortlichkeiten, Fristen).

Management einbinden: Reporting, Schulung, Verantwortungs- und Budgetklarheit – weil NIS2 eben Governance verlangt.

 

Fazit

Das NIS2-Umsetzungsgesetz macht Cybersicherheit und Resilienz in Deutschland durch einen klaren Maßnahmenkatalog, strikte Meldefristen, stärkere Aufsicht und spürbareren Sanktionen verbindlicher und schneller. Durch deutlich mehr betroffene Unternehmen und Organisationen ist auch die Aufstellung nun breiter.

Der Brandanschlag auf die Berliner Stromversorgung führt vor Augen, dass moderne Versorgungssicherheit nicht in Silos funktioniert. Egal ob die Ursache für eine Attacke oder einen Schaden physisch oder digital ist: Die Auswirkungen treffen fast immer beide Bereiche. Wer NIS2 nur als „Compliance-Projekt der IT-Abteilung“ behandelt, verfehlt den Kern. Wer es dagegen als Chance nutzt, Betrieb, Kommunikation, Lieferketten und Krisenfähigkeit messbar robuster zu machen, gewinnt – unabhängig davon, ob der nächste Störfall durch Malware oder durch Feuer ausgelöst wird.

Die Entscheidung für IT-Outsourcing ist gefallen, die Konzeptionsphase abgeschlossen, Ausschreibung und Verhandlungen sind erfolgreich beendet – der Vertrag ist unterzeichnet. Viele Unternehmen lehnen sich bezüglich der anstehenden Phase “IT-Transition” jetzt zurück und vertrauen darauf, dass der Dienstleister beziehungsweise Service Provider die Übernahme der Services eigenständig vorbereitet. Doch Vorsicht: Dieser Ansatz birgt erhebliche Risiken.

Ein Dienstleister kennt weder die spezifische Architektur des aktuellen Services des Kunden noch dessen internen Abläufe und Strukturen. Damit die Transition gelingt und der externe Betrieb später reibungslos funktioniert, müssen beide Parteien aktiv zusammenarbeiten. Nur durch eine gemeinsame Steuerung und klare Rollenverteilung entsteht ein stabiler und den Qualitätsanforderungen gerecht werdender Service sowie eine vertrauensvolle Partnerschaft. Im Folgenden zeigen wir, worauf Auftraggeber besonders achten sollten.

 

Einführung

Die weit verbreitete Annahme, der Dienstleister werde „alles regeln“, ist trügerisch. Ohne die aktive Beteiligung des Auftraggebers fehlt essenzielles Wissen über bestehende Systeme, Prozesse und Verantwortlichkeiten beim Dienstleister. Das kann zu Verzögerungen, Qualitätsproblemen und erhöhten Kosten führen. Deshalb empfiehlt sich, die Transition als ein gemeinsames Projekt anzugehen – und der Kunde trägt hierbei eine Schlüsselrolle. Wir zeigen im Folgenden vier Schlüsselfaktoren auf, die dazu beitragen, dass mit der Transition eine vernünftige Basis für einen guten externen IT-Service, eine gute Zusammenarbeit und eine effiziente Steuerung des Dienstleisters gelegt wird.

 

 

Schlüsselfaktoren für eine erfolgreiche IT-Transition

 

1. Aufbau eines eigenen Projektteams

Das Kunden-Unternehmen sollte ein eigenes internes Projektteam aufstellen, das aus Experten für die outzusourcenden Services besteht. Sollte der Service schon outgesourct sein und es erfolgt ein Wechsel zu einem neuen Service Provider (2.-Generation-Outsourcing), so sind Mitarbeiter des bisherigen Service Providers einzubinden. Diese Experten übernehmen Zuarbeiten, stellen den notwendigen Wissenstransfer zum neuen Dienstleister sicher und führen erforderliche Abnahmen der vom neuen Dienstleister im Rahmen der Transition geschaffenen Ergebnisse durch. Hierfür benötigen sie auch ausreichend freie Ressourcen.

Darüber hinaus ist auch intern ein erfahrener Projektleiter bereitzustellen. Er agiert gemeinsam mit dem Projektleiter des Dienstleisters als Doppelspitze. Diese Rolle kann intern besetzt werden oder, wenn die Kompetenz und Erfahrung für die Leitung eines Transition-Projekts nicht vorhanden ist, durch einen ausreichend erfahrenen externen Berater. Wichtig ist, dass er über ausgeprägte Projektmanagement-Kompetenz, ausreichend technisches Verständnis sowie hervorragende Kommunikationsfähigkeiten verfügt – sowohl gegenüber dem Dienstleister als auch gegenüber internen Abteilungen und der Managementebene.

 

2. Etablierung eines Governance-Rahmens für die IT-Transition

Zu Beginn der Transition sollte gemeinsam mit dem Dienstleister ein angemessener Governance-Rahmen für das Projekt vereinbart und etabliert werden. Hierzu gehört insbesondere ein gemeinsam mit dem Dienstleister erstellter, realistischer Projektplan, der klare Meilensteine und Verantwortlichkeiten definiert.

Zudem ist ein Projektstatus-Reporting aufzusetzen, das für Transparenz bezüglich des Projektfortschritts sorgt und ein Risikomanagement zu etablieren, das die frühzeitige Erkennung und die Überwachung von Risiken in der Transition ermöglicht.

Darüber hinaus sollte ein Lenkungsausschuss eingerichtet werden, der den Projektfortschritt überwacht, Risiken bewertet und notwendige Entscheidungen trifft.

Ebenso wichtig ist eine kontinuierliche interne Kommunikation, um alle betroffenen Stakeholder im Unternehmen über den Stand der Transition zu informieren. Nur so kann die Basis für die erforderliche Akzeptanz der zukünftig extern erbrachten Services im Unternehmen geschaffen werden.

Ein funktionierendes Eskalationsmanagement sowie ein strukturiertes Claim Management sind zudem erforderlich, um Konflikte und Forderungen beider Seiten zeitnah zu klären.

 

3. Schaffung einer Kooperationskultur

Zu Beginn der Partnerschaft sollten sich beide Parteien darauf verständigen, sich nicht als Gegner, sondern als Partner zu betrachten. Der Grundstein für eine konstruktive Kooperationskultur sollte idealerweise schon im Vertrag mit dem Dienstleister durch entsprechende Formulierungen gelegt sein.

Eine gute Grundlage für eine Kooperationskultur ist die Win-Win-Strategie: grundsätzlich ist stets gemeinsam nach Lösungen zu suchen, die für beide Seiten vorteilhaft sind, d.h. den Interessen beider Parteien entgegenkommen. Eine derartige Kultur muss bereits in der Phase der IT-Transition aktiv etabliert werden. Sie sollte auch in der späteren Betriebsphase weitergepflegt werden.

 

4. Vorbereitung des Providermanagements

Die im Outsourcing-Vertrag vereinbarten Gremien sind im Rahmen der Transition im Detail zu planen. Dies betrifft Aufgaben und Zuständigkeiten sowie die konkrete Zusammenarbeit in diesen Gremien und die Organisation der regelmäßigen Meetings je Gremium. Die Ergebnisse sollten – wie alle anderen in der Transition erarbeiteten Ergebnisse – angemessen dokumentiert werden.

Darüber hinaus ist die Einführung einer toolgestützten Messung der vertraglich vereinbarten Service Levels notwendig, um die Einhaltung der Service Levels transparent zu überwachen.

Ein auf den Messergebnissen aufsetzendes Service-Level-Reporting ist zu planen und zu implementieren. Es sollte einen schnellen Überblick über die Gesamtqualität des Services und mögliche Service-Level-Unterschreitungen bieten. Drill-Down-Funktionen im Report helfen dabei, Details und Ursachen von Abweichungen schnell identifizieren zu können. Dies ermöglicht eine effiziente Vorbereitung der Serviceverantwortlichen auf beiden Seiten für Gremien-Meetings.

Zudem sollten die am Providermanagement beteiligten Mitarbeiter geschult werden. Die Schulungen oder Einweisungen betreffen erforderliche Kompetenzen für das Providermanagement (laterales Führen, Kommunikation, Konfliktmanagement usw.) sowie im eigenen Unternehmen geltende Outsourcing-Standards und bereitgestellte Tools.  Diese Tools sollten den Mitarbeitern alle relevanten Informationen für die Providersteuerung zugänglich machen.

 

Fazit – IT-Transition

Eine erfolgreiche Transition im Rahmen eines IT-Outsourcings erfordert mehr als die bloße Übergabe an den Dienstleister. Sie lebt von aktiver Mitwirkung, klarer Steuerung und einer partnerschaftlichen Zusammenarbeit. Zudem sind die Voraussetzungen für das Providermanagement angemessen vorzubereiten. Wer diese Punkte beherzigt, schafft die Basis für einen stabilen externen Betrieb und eine langfristig erfolgreiche Outsourcing-Beziehung.

Benötigen Sie Unterstützung bei der Transition Ihres IT-Outsourcing-Projekts? Kontaktieren Sie uns für eine individuelle Beratung.

Seit dem 12. September 2025 ist der EU Data Act offiziell in allen EU-Staaten gültig – ein Meilenstein für die digitale Transformation Europas und ein zentrales Element der EU-Datenstrategie. Die Verordnung über harmonisierte Vorschriften für einen fairen Datenzugang und eine faire Datennutzung (Verordnung (EU) 2023/2854) soll Daten als strategische Ressource besser nutzbar machen, ohne den Schutz von Personen und Geschäftsgeheimnissen aus den Augen zu verlieren. Der Data Act schafft verlässliche Regeln, die Verbraucherinnen und Verbraucher stärken, Unternehmen Planungssicherheit geben und Innovation in der europäischen Datenökonomie fördern.

 

Was regelt der EU Data Act – und für wen gilt er?

Der EU Data Act ist sektorübergreifend angelegt. Er adressiert Daten, die durch vernetzte Produkte und digitale Dienste entstehen – von IoT-Geräten in der Industrie über Fahrzeuge und Maschinen bis hin zu Smart-Home-Anwendungen und Wearables. Entscheidend ist nicht der Firmensitz, sondern ob Produkte oder Dienste in der EU angeboten werden. Damit gilt der Data Act auch für Anbieter außerhalb der EU, wenn sie den europäischen Markt bedienen.

 

Kernpunkte im Überblick, jeweils mit praktischer Wirkung:

Zugangsrechte für Nutzerinnen und Nutzer

Wer ein vernetztes Produkt nutzt, erhält das Recht auf Zugriff auf die dabei entstehenden Daten – leicht, sicher, in maschinenlesbaren Formaten und möglichst nahezu in Echtzeit. Diese Daten dürfen auf Wunsch auch an Dritte weitergegeben werden, etwa an Reparaturwerkstätten oder alternative Serviceanbieter. Ergebnis: mehr Wahlfreiheit und Wettbewerb.

Pflichten für Dateninhaber

Hersteller und Dienstleister müssen die Daten bereitstellen – einfach, sicher und für den Zugang selbst kostenfrei. Technisch setzt das interoperable Schnittstellen (APIs), dokumentierte Exporte und klare Berechtigungsprozesse voraus.

Cloud Switching ohne Lock-in

Anbieter von Datenverarbeitungsdiensten (z. B. Cloud-Plattformen) müssen Wechselprozesse zu anderen Anbietern erleichtern. Unfaire Vertragsklauseln – etwa überzogene Ausstiegsentgelte oder nicht exportierbare Formate – sind untersagt. Ziel ist Daten- und Workload-Portabilität und damit mehr Wettbewerb im Cloud-Ökosystem.

B2G-Datenzugang (Business-to-Government)

In Ausnahmesituationen wie Naturkatastrophen oder Pandemien dürfen öffentliche Stellen auf privat gehaltene Daten zugreifen, wenn das verhältnismäßig und gesetzlich abgesichert ist. So sollen Kriseninformationen schneller verfügbar werden.

Verbot unfairer Vertragsklauseln im B2B-Bereich

Der EU Data Act schützt insbesondere KMU vor missbräuchlichen Bedingungen, die Datenzugang oder Datennutzung unangemessen einschränken. Dadurch werden faire Verhandlungen in Datenpartnerschaften gefördert.

 

Data Act versus DSGVO: Ergänzung statt Konkurrenz

Oft wird gefragt, wie sich der EU Data Act zur Datenschutz-Grundverordnung (DSGVO) verhält. Die Antwort: Er ergänzt sie. Während die DSGVO den Schutz personenbezogener Daten regelt (Rechtsgrundlagen, Transparenz, Datensparsamkeit, Betroffenenrechte), schafft der Data Act die Rahmenbedingungen für Zugänglichkeit und Nutzung von – häufig technischen oder industriellen – Daten.

In der Praxis treffen beide Welten aufeinander, etwa bei IoT-Daten, die sowohl technische Messwerte als auch personenbezogene Informationen enthalten können. In solchen Fällen gilt: Die DSGVO hat Vorrang. Unternehmen müssen also weiterhin Rechtsgrundlagen sicherstellen, personenbezogene Daten minimieren, pseudonymisieren oder trennen und Zugriffsrechte sauber steuern. Der EU Data Act zwingt nicht zur Offenlegung personenbezogener Daten ohne DSGVO-Basis; er sorgt vielmehr dafür, dass Zugriff und Nutzung dort möglich werden, wo es rechtlich zulässig und technisch zumutbar ist.

 

Baustein der EU-Datenstrategie: Verknüpfung mit DGA, DSA/DMA und AI Act

Der Data Act ist Teil der EU-Datenstrategie (seit 2020), deren Ziel ein europäischer Binnenmarkt für Daten ist – mit mehr Innovation, offenen Standards und digitaler Souveränität. Dazu gehören weitere Rechtsakte:

• Data Governance Act (DGA): Schafft Vertrauen und Mechanismen für den Datenaustausch zwischen öffentlichen und privaten Akteuren.
• Digital Services Act (DSA) & Digital Markets Act (DMA): Regeln Plattformverantwortung und fairen Wettbewerb in digitalen Märkten.
• AI Act: Setzt Risikoklassen und Anforderungen für den Einsatz Künstlicher Intelligenz.

Der EU Data Act ergänzt diese Bausteine, indem er die technische und vertragliche Grundlage für fairen, transparenten Datenaustausch legt – besonders zugunsten von KMU, die so leichter Zugang zu wertvollen Datensätzen erhalten und neue Geschäftsmodelle entwickeln können.

 

Auswirkungen auf Unternehmen: Chancen, Pflichten, Wettbewerbsvorteile

Für Unternehmen eröffnet der EU Data Act konkrete Chancen: Mit Zugang zu Nutzungs- und Betriebsdaten lassen sich datengetriebene Services entwickeln – von vorausschauender Instandhaltung über Pay-per-Use-Modelle bis hin zu After-Sales-Ökosystemen mit Partnern. Gleichzeitig entstehen Pflichten: Verträge müssen überarbeitet, APIs bereitgestellt, Prozesse dokumentiert und Sicherheits- sowie Berechtigungskonzepte gestärkt werden. Wer frühzeitig investiert, kann sich strategisch positionieren – etwa durch kundenzentrierte Datenportale, transparente Service-Level-Agreements und klare Datenlizenzklauseln. Auch die Cloud-Strategie gehört auf den Prüfstand: Exit-Pläne, Interoperabilität und Multi-Cloud-Fähigkeit werden zum Wettbewerbsfaktor.

 

Vorteile für Verbraucherinnen und Verbraucher: Kontrolle, Transparenz, Wahlfreiheit

Für Nutzerinnen und Nutzer vernetzter Produkte bedeutet der EU Data Act mehr Kontrolle über die eigenen Daten und Transparenz über deren Verwendung. Praktischer Effekt: Wer sein Smart-Home-Gerät oder sein E-Bike wartet, kann Daten an den Dienstleister der Wahl freigeben, ohne an den Hersteller gebunden zu sein. Das stärkt Wettbewerb und Reparierbarkeit, reduziert Lock-in-Effekte und fördert vertrauenswürdige Innovation.

 

Fazit

Der EU Data Act markiert einen Wendepunkt: Er verschiebt den Fokus von isolierten Datensilos hin zu fairen Zugangs- und Nutzungsmodellen, die Innovation, Wettbewerb und Verbraucherschutz gleichermaßen berücksichtigen. Für Unternehmen bedeutet das Pflicht und Chance zugleich: Wer frühzeitig APIs, Portabilitätsprozesse und faire Verträge etabliert, schafft Vertrauen und Marktvorteile. Für Verbraucherinnen und Verbraucher bringt der Data Act Transparenz, Kontrolle und Wahlfreiheit. Zusammen mit DSGVO, DGA, DSA/DMA und dem AI Act ist er damit ein Schlüsselbaustein der digitalen Zukunft Europas – und ein deutliches Signal, dass die EU den Wert von Daten aktiv gestaltet.