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.

Abbildung 1: Worauf kommt es an?

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.

Wir zeigen in diesem Artikel an einem Beispiel auf, wie man durch Automation und Einsatz künstlicher Intelligenz (KI) die Arbeit im Providermanagement optimieren und Aufwand reduzieren kann. Verträge bilden die Grundlage für die Beziehung zu externen Dienstleistern – insbesondere im Providermanagement. Die manuelle Verwaltung von Service Level Agreements (SLAs) ist ein Beispiel, das sich durch KI optimieren lässt: SLA-Management ist zeitaufwendig, fehleranfällig und oft wenig skalierbar. Hier kommt die KI ins Spiel. Sie bietet dabei neue Möglichkeiten, repetitive Aufgaben zu automatisieren und damit die Qualität der Vertragsverwaltung zu verbessern.

 

Herausforderungen im SLA-Management

Die Herausforderung liegt vor allem in der manuellen Erfassung und Auswertung von SLA-Daten in Verträgen. Typische Kennzahlen, wie Vertragsbeginn, Vertragsende, Reaktionszeiten oder Verfügbarkeitsgarantien müssen überprüft und dokumentiert werden. KI kann hier als unterstützendes Werkzeug agieren, das nicht nur Daten aus Verträgen extrahiert, sondern auch Prozesse intelligent steuert.

Dadurch verändert sich auch die Rolle der Mitarbeitenden: Weg von operativer Verwaltung, hin zu strategischer Steuerung. KI übernimmt repetitive Aufgaben, während Menschen sich auf kreative Problemlösung, Kommunikation und strategische Entscheidungen konzentrieren können.

Doch wie genau unterstützt KI im SLA-Management? Und welche konkreten Einsatzszenarien sind bereits heute realisierbar?

 

Wobei KI im SLA-Management unterstützt

Die Einsatzbereiche von KI im Vertragsmanagement sind vielfältig und reichen weit über die reine Texterkennung hinaus. Moderne KI-Systeme können nicht nur Inhalte analysieren, sondern auch strukturieren und Inhalte in bestehende Systeme integriert werden.

• Automatisierte Erkennung und Extraktion von SLA-relevanten Daten:
  KI kann Verträge analysieren und gezielt Kennzahlen wie Reaktionszeit, Verfügbarkeitsgarantie, Vertragsbeginn und -ende extrahieren.
• Datenaufbereitung:
  Extrahierte Informationen werden strukturiert und für weitere Verarbeitung vorbereitet.
• Monitoring und Analyse:
  SLA-Kennzahlen können kontinuierlich überwacht und analysiert werden – etwa zur Erkennung von SLA-Verletzungen.
• Integration in bestehende Tools:
  Über Power Automate lassen sich KI-gestützte Prozesse nahtlos in SharePoint, Teams oder Power BI integrieren.

Dadurch können Einsparpotenziale erschlossen werden: die Automatisierung reduziert den manuellen Aufwand und spart Zeit und Kosten.

Jedoch hängt die Qualität der Ergebnisse stark davon ab, wie Verträge strukturiert sind und von der Qualität der KI-Prompts. Nicht jeder Vertrag ist gleich aufgebaut – und nicht jede KI erkennt komplexe Formulierungen zuverlässig.

Trotz der Herausforderungen bei der Qualität bietet der Einsatz von KI im SLA-Management klare Vorteile: Er ermöglicht eine effizientere und skalierbare Verwaltung von Verträgen. Repetitive Aufgaben wie die Datenerfassung und -pflege werden automatisiert, wodurch Mitarbeitende entlastet werden. Sie gewinnen Zeit für kreative, kommunikative und strategische Tätigkeiten. Ein zentraler Mehrwert liegt dabei in der deutlichen Zeitersparnis.

 

Zeitersparnis durch KI

Ein zentraler Vorteil von KI im Vertragsmanagement ist die deutliche Zeitersparnis – insbesondere bei wiederkehrenden Aufgaben, die bislang manuell durchgeführt wurden.

• Automatisierter SLA-Abgleich:
  Repetitive Aufgaben wie der manuelle Vergleich von tatsächlichen Service-Level-Werten mit den im Vertrag definierten Zielwerten entfallen.
• Schnellere Reaktion auf SLA-Verletzungen:
  Durch automatisiertes Monitoring können Verstöße frühzeitig erkannt und Maßnahmen eingeleitet werden.
• Reduktion typischer Fehlerquellen:

KI kann bei klar strukturierten Daten konsistent arbeiten und typische menschliche Fehler bei der manuellen Datenerfassung vermeiden. Bei komplexen oder unstrukturierten Vertragsinhalten sind manuelle Nachkontrollen weiterhin sinnvoll.

Hieraus ergibt es sich eine deutliche Zeitersparnis und Produktivitätssteigerung – vorausgesetzt die Prozesse sind sauber aufgesetzt und die Datenqualität passt. Die Effizienzgewinne entstehen durch die Integration von KI in automatisierte Workflows, die beispielsweise mit Power Automate umgesetzt werden. So lässt sich der gesamte Ablauf – vom Hochladen eines Vertrags bis zur automatisierten Auswertung – nachvollziehbar und skalierbar gestalten.

 

Prozessskizze: KI-gestützter SLA-Prüfungs-Workflow

Ein beispielhafter KI-gestützter Workflow im SLA-Management mit Power Automate könnte wie folgt aussehen:

1. Vertragsablage:
   Ein neuer Vertrag wird in SharePoint abgelegt.
2. KI-Analyse:
   Über Power Automate wird ein Prompt an ein Large Language Model (LLM) gesendet
3. Datenerkennung:
   Die SLA-relevanten Kennzahlen werden aus dem Vertrag extrahiert.
4. Datenablage:
   Die extrahierten SLA-Daten werden automatisch in einer SharePoint-Liste gespeichert.
5. Anschließend folgt die Weiterverarbeitung, wie z.B.:
   • Benachrichtigung: Bei SLA-Verletzungen erfolgt eine automatische Benachrichtigung via Teams oder E-Mail.
   • Analyse & Reporting: SLA-Daten können in Power BI visualisiert und in Form von Dashboards oder automatisierten Berichten aufbereitet und verteilt werden.

Die Abbildung zeigt den strukturierten Ablauf dieses KI-gestützten Prozesses innerhalb der Microsoft-Cloud-Umgebung (Microsoft 365). Als Basis dienen integrierte Microsoft-Werkzeuge wie das Workflow- und Automatisierungstool Power Automate, das Collaboration-Tool SharePoint, sowie die Kommunikationslösung Microsoft Teams. Die Abfragen (Prompts), die im 2. Schritt an die KI bzw. das Large Language Model (LLM) gestellt werden, sind strukturiert aufgebaut. KI-Chats hingegen sind dialogorientiert und in natürlicher Sprache verfasst.

Doch wie unterschneidet sich dieser Workflow-Ansatz im Vergleich zu alternativen Prozessansätzen?

 

Alternative Prozess-Lösungen im Vergleich

Natürlich gibt es auch andere Ansätze für das SLA-Management – mit jeweils eigenen Vor- und Nachteilen:

• Manuelle Prozesse: Sie sind flexibel, aber zeitintensiv und fehleranfällig.
• Klassische Workflows: Sie bieten gewisse Automatisierung, stoßen aber bei komplexen Vertragsstrukturen schnell an ihre Grenzen.
• KI-Einzelabfragen: Sie zeichnen sich durch folgende Eigenschaften aus:
  • Dialogorientierte Prompt-Abfragen in natürlicher Sprache
  • Keine technische Formatierung notwendig
  • Kontextsensitive Antworten, die sich flexibel an unterschiedliche Vertragsstrukturen anpassen

Diese Einzelabfragen sind besonders hilfreich für ad-hoc-Analysen, während KI-gestützte Workflow, wie oben aufgezeigt, ideal für skalierbare Prozesse sind.

Die Wahl der richtigen Lösung hängt stark vom Anwendungsfall ab – und davon, wie viel Automatisierung tatsächlich gewünscht oder möglich ist.

 

Fazit

Ein vollautomatisierter, intelligenter SLA-Management-Prozess ist heute keine Zukunftsvision mehr. Dank KI müssen SLA-Kennzahlen nicht mehr an festen Stellen im Dokument stehen – die KI erkennt sie kontextbasiert. Damit entfällt die Notwendigkeit statischer Masken oder einheitlicher Dokumentenformate.

KI steht für Effizienz: Sie ermöglicht nicht nur Automatisierung, sondern auch Prognosen, Empfehlungen und kontinuierliche Verbesserung. Im Providermanagement bedeutet das eine Transformation – weg von operativer Verwaltung, hin zu direkter Dienstleistersteuerung und Beziehungsmanagement. Lesen Sie hierzu auch unseren Blogartikel KI-Unterstützung im Providermanagement nutzen.

Der Einsatz von Copilot und Power Automate im oben dargestellten Beispiel zeigt: KI kann mehr als nur unterstützen – sie kann Prozesse grundlegend verändern.