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.

Seit Juli 2023 ist das Datenschutzabkommen „Data Privacy Framework” in Kraft. Nach Safe Harbor und EU-US-Privacy Shield nun also der dritte Versuch, ein rechtssicheres Abkommen für die Weitergabe von personenbezogenen Daten aus der EU in die USA zu etablieren. Im folgenden Artikel klären wir insbesondere folgende sich ergebende Fragen hierzu: Welche Grundprinzipien sind im neuen Datenschutzabkommen festgelegt? Hat das neue Abkommen das Zeug dazu, den schon geplanten Gegenklagen zu widerstehen? Und wie kam es überhaupt zu der Entstehung eines dritten Datenschutzabkommens zwischen der EU und den USA?

Erstes Datenschutzabkommen: Safe Harbor

Damit der Datenverkehr zwischen der Europäischen Union (EU) und den USA im immer schneller wachsenden Internet nicht zum Erliegen kam, wurde zwischen 1998 und 2000 ein besonderes Verfahren für die Weitergabe von Personen-bezogenen Daten entwickelt. US-Unternehmen konnten dem sogenannten Safe Harbor Datenschutzabkommen beitreten und sich auf einer entsprechenden Liste des US-Handelsministeriums eintragen lassen. Damit verpflichteten sie sich, die sogenannten „Safe Harbor Principles“, also die ‚Grundsätze eines sicheren Hafens‘ anzuerkennen. Diese Grundsätze umfassen etwa die der Transparenz und Zweckmäßigkeit der Informationsverarbeitung, der Datensicherheit sowie der Korrigierbarkeit der erfassten Informationen. Safe Harbor wurde notwendig, da die Datenschutzrichtlinie 95/46/EG aus dem Jahr 1995 es grundsätzlich verbot, personenbezogene Daten aus Mitgliedstaaten der Europäischen Union in Staaten zu übertragen, deren Datenschutz kein dem EU-Recht vergleichbares Schutzniveau aufwies. In der Safe-Harbor-Entscheidung hatte die EU im Juli 2000 anerkannt, dass bei den Unternehmen, die sich diesem Abkommen verpflichten, ein ausreichender Schutz für die personenbezogenen Daten von EU-Bürgern bestand.

Nur ein Jahr später erschütterten die Terroranschläge vom 11. September die Welt, und hatten langfristig auch Auswirkungen auf das Safe-Harbor- sowie die Folge-Abkommen.

Durch den im Oktober 2001 verabschiedeten US-Patriot Act erhielten die US-Geheimdienste weitreichende Möglichleiten, bei jedem US-Unternehmen im Verdachtsfall ohne richterliche Beschlüsse Daten abfragen zu können. In den folgenden Jahren fand dieser Umstand keine große Aufmerksamkeit. Doch mit dem Entstehen sowie dem immer mehr in den Fokus von europäischen Datenschutzaktivisten. Der NSA-Skandal von 2013 (Die Veröffentlichung von Geheimdienstdokumenten durch Edward Snowden) brachte schließlich das Fass zum Überlaufen. Er brachte umfangreiche Spionageaktivitäten ans Licht.

Als Folge wurde Klage gegen Safe Harbor vor dem europäischen Gerichtshof (EU-GH) eingereicht. Dieser erklärte dann im September 2015, dass die entsprechende Regelung nichtig ist.

Zweites Datenschutzabkommen: EU-US Privacy Shield

Es musste also ein Nachfolgeabkommen her, damit die Nutzung des von amerikanischen Firmen dominierten und inzwischen weiter enorm gewachsenen Cloud-Computing-Markts für europäische Unternehmen auf rechtlich sicheren Füßen steht. Nach Zugeständnissen der US-Regierung unter Präsident Obama, etwa einer Klagemöglichkeit für EU-Bürger in den USA im Fall einer Verletzung des Datenschutzes, wurde im Juli 2016 das Nachfolgeabkommen Privacy Shield von der EU-Kommission in Kraft gesetzt. Kritiker bemängelten von Anfang an, dass es bis auf wenige Details keine Unterschiede zu Safe Harbor gibt und mahnten Unsicherheiten im Falle eines Regierungswechsels in den USA an. Dieser Wechsel trat dann 2016 tatsächlich durch die Regierung Trump ein. Diese verabschiedete eine Reihe von Gesetzesänderungen, unter anderem das Non-US-Bürger von Klagemöglichkeiten in den USA wieder ausgeschlossen sind. Es wurde erneut vor dem EU-GH Klage einreicht und das Privacy Shield Abkommen im Juli 2020 für nichtig erklärt.

 

Drittes Datenschutzabkommen Data Privacy Framework

Erneut musste also ein Nachfolge-Abkommen vereinbart werden, um den EU-Unternehmen Rechtssicherheit bei der Nutzung von US-amerikanischen Cloud-Services zu bieten. Um eine Einigung zu erzielen musste zunächst eine sogenannte „Executive Order“ der neuen US-Regierung unter Biden erlassen werden, welche unter anderem die US-Geheimdienste anweist, ihre Datenzugriffe auf ein verhältnismäßiges Maß zu beschränken. Damit war der der Weg für die EU-Kommission frei, das Privacy Framework Abkommen mittels eines sogenannten Angemessenheitsbeschluss gemäß Art. 45 GDPR bzw. DSGVO zu verabschieden. Dieser Beschluss wurde ab Dezember 2022 entworfen und im Juli 2023 schließlich verabschiedet. Das Framework ist damit in Kraft getreten.

Es gelten folgende Grundprinzipien:

• Verbindliche Schutzmaßnahmen sollen den Zugriff der US-Nachrichtendienste beschränken. Es soll sichergestellt sein, dass ein Zugriff nur dann erfolgt, wenn er notwendig und verhältnismäßig ist, um die nationale Sicherheit der USA zu gewährleisten, ohne dass dadurch die Rechte und Freiheiten des Einzelnen unverhältnismäßig beeinträchtigt werden.
• Es werden Verfahren etabliert, die eine wirksame Überwachung der neuen Standards gewährleisten.
• Ein neues zweistufiges Rechtsbehelf-System soll sicherstellen, dass Beschwerden von EU-Bürgern über den Zugriff auf Daten durch US-Nachrichtendienste untersucht und behandelt werden. Für die gerichtliche Prüfung wurde in den USA ein neuer und unabhängiger „Data Protection Review Court“ ins Leben gerufen.
• Für US-Unternehmen, die aus der EU übermittelte Daten verarbeiten, gelten strenge Verpflichtungen. Dazu gehört insbesondere, die Einhaltung des Abkommens gegenüber dem US-Handelsministerium anhand einer Selbstzertifizierung zu bestätigen. Die Prinzipien für diese Selbstzertifizierung orientieren sich am europäischen Datenschutzrecht.

Für alle EU-Unternehmen, die US-Cloud-Dienste einsetzen und dadurch personenbezogene Daten in die USA übermitteln, ist mit dem Inkrafttreten des EU-US Data Privacy Framework eine deutliche Erleichterung eingetreten. Es besteht nämlich jetzt wieder Rechtssicherheit. Aus wirtschaftlicher Sicht ist diese Entwicklung durchaus zu begrüßen.

Doch Vorsicht! Der Angemessenheitsbeschluss für das EU-US Data Privacy Framework kommt nur zum Tragen, wenn das US-Unternehmen, an das personenbezogene Daten übermittelt werden sollen, über eine entsprechend gültige Zertifizierung verfügt. Es muss also auf der offiziellen Website für das neue Datenschutzabkommen in der Liste mit den US-Unternehmen eingetragen sein, die sich nach dem neuen Mechanismus zertifiziert haben lassen und an die somit ohne weitere Voraussetzungen personenbezogene Daten übermittelt werden dürfen.

Ist das nicht der Fall, ist als Alternative weiterhin der Abschluss von Standardvertragsklauseln und die Durchführung eines sogenannten Transfer Impact Assessments, also eine Risikobewertung für Datenübermittlungen in unsichere Drittländer, erforderlich. Bei Standardvertragsklauseln handelt es sich um von der Europäischen Kommission verabschiedete Vertragsmuster. Diese Muster vereinbaren europäische Datenschutzstandards vertraglich zwischen Firmen im Europäischen Wirtschaftsraum und Cloud-Anbietern in Drittstaaten. Angesichts der offenen Erfolgschancen des EU-US Data Privacy Frameworks empfiehlt es sich, bereits bestehende Vertragsklauseln nicht zu kündigen, sondern das Framework als eine Art „doppelten Boden“ zu nutzen.

 

Fazit – Datenschutzabkommen „Data Privacy Framework”

Grundsätzlich ist jedes Datenschutzabkommen, welches Rechtsicherheit für EU-Unternehmen bietet, zu begrüßen. Aus diesem Blickwinkel ist das Data Privacy Framework ein Schritt in die richtige Richtung. Allerdings ist auch hier das letzte Wort noch nicht gesprochen. Die Datenschutzaktivisten, die schon Safe Harbor und Privacy Shield zu Fall gebracht haben, haben eine entsprechende Klage gegen das Data Privacy Framework angekündigt. Gerade die wagen Formulierungen bezüglich des verhältnismäßigen Maßes bei Datenzugriffen durch US-Geheimdienste sowie die insgesamt nur geringen Unterschiede zum Privacy Shield sind ihnen ein Dorn im Auge. Solange es keine Änderung des US-Überwachungsrechts hinsichtlich das Patriot Acts gibt, steht jedes Datenschutzabkommen auf wackligen Beinen. Daher sollten EU-Unternehmen bei der Nutzung von Cloud Services von US-Anbietern weiterhin zusätzlich auf genau definierte Standardvertragsklauseln für die Datenverarbeitung in Nicht-EU-Rechenzentren und auf eine detaillierte Risikobewertung bei der Datenübermittlung achten.

Häufig hört man die Aussage, Service Level Agreements bzw. SLA-Vereinbarungen von Cloud Services – kurz Cloud-SLAs – seien zu „schwammig“. Konkret ist damit gemeint: aufgrund unklarer Regelungen kann die Erbringung der vom Kunden erwarteten Leistung und Qualität nicht sichergestellt werden. SLAs müssen jedoch eindeutig definiert und ihr Erreichungsgrad via Kennzahlen transparent gemacht werden, so dass Nichterfüllung oder Schlechtleistung nachgewiesen werden und Kundenrechte eingefordert werden können.

Sind diese in der Praxis nun zu unklar definiert, fehlen Kennzahlen oder sind sie nicht aussagekräftig? Werden Leistungen dadurch nicht ausreichend gut erbracht, ohne dass dies Folgen für den Cloud-Provider hat? Wir schauen uns an konkreten Beispielen bei Microsoft und Amazon Web Services (AWS) an, was wirklich in Standard-Verträgen / AGBs der Cloud Provider steht. Wir prüfen, ob Kunden auf dieser Basis in die Lage versetzt werden, Cloud Provider und ihre Services angemessen steuern können.

Regelungen in Standard-Verträgen / AGBs

Die SLA-Vereinbarungen sind Teil des Standard-Vertrags mit dem Cloud Provider. Microsoft Azure und Amazon AWS bieten je Cloud Service separate SLAs für ihre Infrastruktur-Dienste an.
An dieser Stelle werden beispielhaft die SLA für die virtuellen Server-Dienste Microsoft Azure Virtual Machines und Amazon AWS EC2 betrachtet.

In den SLAs für Azure Virtual Machines und AWS EC2 sind ausschließlich Service-Level für Verfügbarkeit spezifiziert. Diese Service-Level werden nach der Art der Server-Bereitstellung unterschieden: Einzelne oder mehrere Serverinstanzen, die in mehreren isolierten Verfügbarkeitszonen einer Region oder innerhalb einer Verfügbarkeitsgruppe in einem Rechenzentrum repliziert werden können.  Auf Basis verschieden hoher Ausfallsicherheit durch die Bereitstellungsart des Cloud Services ergeben sich bezogen auf die Kennzahl Verfügbarkeit folgende Service-Level:

Tabelle 1: Service-Level Verfügbarkeit

	Amazon AWS EC2	MS Azure Virtual Machines
Virtuelle Server in mehreren Verfügbarkeitszonen	99,99%	99,99%
Virtuelle Server in einer Verfügbarkeitsgruppe	–	99,95%
Einzelner virtueller Server	99,5%	99,9% (Premium SSD) 99,5% (SSD) 95,0% (HDD)

Die prozentuale Service-Verfügbarkeit bezieht sich hierbei auf die Service-Nutzung innerhalb eines monatlichen Abrechnungszeitraums, mindestens eine Serverinstanz muss hierfür lauffähig bleiben. Microsoft unterscheidet zudem bei der Verfügbarkeit einzelner virtueller Server nach der Art des genutzten virtualisierten Datenspeichers.

Der technische Support sowie Reaktions- und Antwortzeiten werden Service-unabhängig bei beiden Cloud Providern mit kostenlosen oder zusätzlichen kostenpflichtigen Support-Plänen spezifiziert. Diese unterscheiden sich maßgeblich bei Leistungsumfang, Servicezeiten, Reaktionszeiten. Somit kann der passende Support-Plan gemäß der Unternehmensanforderung an die eingesetzten Cloud Services gewählt werden.

Konsequenzen bei Schlecht- bzw. Nichterfüllung

Werden die in den AGBs spezifizierten Mindestwerte nicht erreicht, sind Servicegutschriften in den Cloud-SLAs als Kompensierung vereinbart. Sie entsprechen Malus-Regelungen in klassischen Outsourcing-Verträgen. Beide Cloud Provider bieten gleichermaßen Servicegutschriften, jedoch in geringfügig unterschiedlicher Höhe an.

Tabelle 2: MS Azure Virtual Machines Verfügbarkeit in Prozent

Virtuelle Server in mehreren Verfügbarkeitszonen	Virtuelle Server in einer Verfügbarkeitsgruppe	Servicegutschrift
< 99,99 %	< 99,95 %	10 %
< 99 %	< 99 %	25 %
< 95 %	< 95 %	100 %

 

Tabelle 3 MS Azure Virtual Machines Verfügbarkeit in Prozent

Einzelne virtuelle Server
Premium-SSD	Standard-SSD	Standard-HDD	Servicegutschrift
< 99,9 %	< 99,5 %	< 95 %	10 %
< 99 %	< 95 %	< 92 %	25 %
< 95 %	< 90 %	< 90 %	100 %

 

Tabelle 4: Amazon AWS EC2 Verfügbarkeit in Prozent

Virtuelle Server in mehreren Verfügbarkeitszonen	Einzelne virtuelle Server	Servicegutschrift
< 99,99%	< 99,5%	10%
< 99%	< 99%	30%
< 95%	< 95%	100%

In einigen Fällen sind die SLAs aufgehoben, wie es auch bei klassischem Outsourcing nicht ungewöhnlich ist: Bei höherer Gewalt, wie beispielsweise Naturkatastrophen, festgelegten Wartungsfenster, die zu geplanten Ausfallzeiten führen oder Nicht-Verfügbarkeit durch eigenes Verschulden auf Kundenseite.

Standard-Reporting

Um die Qualität der erbrachten Leistung prüfen und kontrollieren zu können, ist ein angemessenes Reporting notwendig. Dies muss den Grad der Einhaltung der vereinbarten Service-Level aufzeigen und Behebungszeiten von Störungen darstellen. Hierfür stehen dem Kunden bei beiden Cloud Providern Dashboards zur Verfügung, über die der Service-Status ersichtlich ist und Informationen zu Störungen und ihrer Behebung in sämtlichen Regionen bereitgestellt werden (MS Azure Health Status & Dashboard, Amazon AWS Health Dashboard).

Beurteilung der Cloud SLAs

Die Verträge der beiden Cloud Provider sind hinsichtlich der SLAs vergleichbar und bieten ähnliche Bereitstellungsoptionen für die virtuellen Server-Dienste an. Für diese Dienste wird neben den Festlegungen in den Supportplänen als wesentliche Kennzahl in den SLAs die Verfügbarkeit festgelegt.

Im klassischen Outsourcing werden üblicherweise neben der Service-Verfügbarkeit noch weitere Kennzahlen vereinbart, um die Service-Qualität sicherzustellen, z.B.:

• Bereitstellungszeit/Erstbereitstellungszeit eines Servers / einer virtuellen Maschine
• Maximale Ausfallzeit (in Kombination mit der Verfügbarkeit)
• Maximale Behebungszeit von Störungen

Die Bereitstellungszeit ist durch die vollständige Automatisierung des Bereitstellungsprozesses bei den angeführten Cloud Services im Regelfall sehr kurz. Maximale Ausfallzeit und maximale Störungsbehebungszeit werden durch den Verfügbarkeitszielwert nach oben begrenzt. In vielen Fällen werden die angebotenen Service Level und das Reporting ausreichen.

Bei Schlechtleistung oder Nichterfüllung des Services stellen Servicegutschriften die alleinige Entschädigung dar – der Kunde muss diese jedoch grundsätzlich selbst einfordern: Dies bedeutet zusätzlichen Aufwand für den Cloud Providermanager. Darüber hinaus sind keine weiteren Ansprüche vertraglich geregelt: Schäden aus entgangenem Gewinn, entgangenen Einnahmen, Betriebsunterbrechungen oder Verlust von geschäftlichen Informationen in Folge einer Nicht-Verfügbarkeit sind ausgeklammert.

Die AGB-Regelungen der Cloud Provider sind vom grundsätzlichen Ansatz her ähnlich wie Vertragsregelungen im klassischen Outsourcing.

Fazit

Die hier aufgezeigten, beispielhaft herangezogenen Cloud Services der Cloud Provider Microsoft und Amazon sind so ausgelegt, dass damit verschiedene Kundenanforderungen abgedeckt werden können. Die Cloud-SLAs spiegeln dies in den Verfügbarkeitskennzahlen und Qualitätsstufen der Cloud Services wider. Eine Kontrolle der vertraglich zugesagten und tatsächlich erbrachten Leistungen sind für die Kunden der Cloud Provider über deren Standard-Reporting möglich.

Im Einzelfall muss je nach Anwendungsszenario geprüft werden, welche spezifischen Anforderungen des eigenen Unternehmens mit einem Cloud Service erfüllt werden müssen und ob die AGBs des Cloud Providers und insbesondere die genutzten Kennzahlen und zugesagten Service-Level hierfür ausreichen. Eine höhere Service-Verfügbarkeit ist i.d.R.  auch mit erhöhten Kosten für den Cloud Service verbunden.

Sollten die Regelungen der AGB nicht zu den Anforderungen des eigenen Unternehmens passen, so gilt: Individualisierungsspielraum gibt es bei den Cloud-Standard-Verträgen in der Regel wenig. Deshalb muss bei Nutzung der Cloud Services eine genaue Prüfung der AGBs und der SLAs stattfinden und mögliche Risiken identifiziert und abgewogen werden. Bei nicht tolerablen Vertragsregelungen sollte zumindest eine Nachverhandlung versucht werden, wobei deren Erfolg üblicherweise von der Größe des Kundenunternehmens und seiner Marktmacht abhängig ist.

Auf dem Weg in die Cloud kann für Unternehmen die Einhaltung von Compliance-Vorgaben nicht nur technisch, sondern auch organisatorisch eine Herausforderung sein. Der Einsatz geeigneter Tools und Werkzeuge kann hierbei die Komplexität bei der Sicherstellung von Compliance in der Cloud reduzieren und die Einhaltung gesetzlicher Vorgaben und deren Anforderungen maßgeblich unterstützen. Im Folgenden zeigen wir am Beispiel Microsoft 365 auf, wie insbesondere Tools von Cloud Service Providern beim Compliance Management helfen können.

Cloud Service Provider stellen bereits Bordmittel für die IT-Compliance zur Verfügung. In diesem Artikel betrachten wir beispielhaft Microsofts Lösung, die einen ersten Ansatz zum strukturierten Vorgehen bietet, um den Unternehmensanforderungen hinsichtlich Konformität und Einhaltung von branchenspezifischen und regionalen Standards, Gesetzen und Vorschriften gerecht zu werden.

Compliance in der Cloud – typische Fragen

Befindet man sich nun in einer Phase, in der eine Applikation outgesourct werden soll, ergeben sich daraus zwangsläufig Fragen und daraus resultierende Aktivitäten für die IT-Compliance:

• Welche neuen Compliance-Vorgaben ergeben sich im Rahmen des Outsourcings der Applikation?
• Welche technischen Einstellungen sind vorzunehmen, um die eingesetzte Applikation gesetzeskonform und sicher nutzen zu können?
• Stimmen die getroffenen Sicherheitsmaßnahmen sowie das Identitäts- und Berechtigungsmanagement?
• Welche Prozesse und Dokumentationen sind aktuell und welche müssen angepasst werden? Wo muss gegebenenfalls nachgesteuert und aktualisiert werden?

Compliance-Toolbeispiel: Microsoft Cloud

Microsoft bietet im Rahmen von Microsoft 365 und seinem Cloud-Portfolio den sogenannten „Compliance Manager“ an. Dieser Service ist Microsofts Antwort auf die Frage, wie IT-Sicherheit und Compliance für Cloud-basierte Applikationen in Angriff genommen werden können. Er versteht sich als Bordmittel und Hilfestellung zur Einhaltung der IT-Compliance in der Microsoft-365-Umgebung.

Dieses Tool, das sich in das administrative Backend der Microsoft-Umgebung einbettet, biete eine Möglichkeit, die eigenen Compliance-Prozesse und -Einstellungen auf den Prüfstand stellen.
Mit den sogenannten „Bewertungsvorlagen“ bietet Microsoft den Ausgangspunkt für Prüf-Aktivitäten. Diese umfassen separate Bewertungskataloge mit Fokus auf verschiedene Zertifizierungen, (nationale) Vorschriften und Gesetze.

Dabei können einzelne Einstellungen und Maßnahmen vorgenommen werden, um bestimmte Compliance-Anforderungen zu erfüllen. Diese Einzelelemente werden mit verschieden starker Punktegewichtung gruppiert dargestellt. Daraus ergibt sich ein konsolidierter Compliance-Score-Wert.
Microsofts Maßnahmenvorschläge bzw. Handlungsempfehlungen orientieren sich an Best Practices. Es werden zudem erweiterte Sicherheitsfunktionen aufgezeigt, um etwaige Risiken zu minimieren, die durch das Outsourcing entstanden sind.

So ist zum Beispiel der BSI Cloud Computing Compliance Criteria Catalogue (BSI C5) bei den Bewertungskatalogen enthalten. Dieser beschreibt als Kriterienkatalog die Mindestanforderungen an die Informationssicherheit für Cloud-Services. Der BSI C5 ist zudem ein relevanter Bestandteil des Compliance-Nachweises für KRITIS-Unternehmen.

Im Finanzsektor stellt die BaFin mit der Bankaufsichtlichen Anforderungen an die IT (BAIT) die konkretisierten Rahmenbedingungen für eine sichere Informationsverarbeitung und Informationstechnik dar. Die BAIT ist ebenfalls als Bewertungsvorlage vorhanden und kann damit als Grundlage dienen, die Vorgaben der BaFin abzudecken.

Sicherheit und Compliance in der Cloud stellen prinzipiell eine Teilung der Verantwortlichkeiten zwischen Cloud Service Provider und dem Kunden dar. Während hierbei der Cloud Service Provider beispielsweise Vorgaben hinsichtlich physischer Rechenzentrumssicherheit einzuhalten hat, ist der Kunde, der die Cloud-basierten Services in Anspruch nimmt, für Konfiguration und das Sicherstellen geeigneter Zugriffsschutzmaßnahmen und daraus resultierender Dokumentationspflichten verantwortlich. Entsprechend sind bei Microsoft im Compliance-Score-Wert Punkte, für deren Erfüllung der Kunde verantwortlich ist und Punkte, für deren Erfüllung der Provider verantwortlich ist, getrennt dargestellt.

Über den Compliance Manager ist eine Nachverfolgung von Aktionen und die Zuweisung von Aktivitäten an bestimmte Personen möglich. Nach erfolgter Prüfung können einzelne Verbesserungsaktionen mit einem Teststatus und einer Notiz versehen, oder relevante Dokumente angehängt werden, wie etwa Prüfergebnisse oder Nachweise.
Der Compliance Manager zielt zwar grundsätzlich auf die eigenen Services von Microsoft ab, muss aber nicht zwangsläufig nur dafür genutzt werden. Auch für Drittanbieter-Applikationen ist eine Nutzung möglich.

Compliance-Tools anderer Cloud Service Provider

Andere Cloud Service Provider verfolgen einen ähnlichen Ansatz: zum Beispiel unterstützt Amazon in seinen Amazon Web Services (AWS) seine Kunden mit Tools und Werkzeugen für die Sicherstellung von Sicherheit und Compliance in der Cloud: durch Nutzung von verschiedenen AWS-Services und Verwaltungskonsolen wird die (teils automatisierte) Prüfung auf Einhaltung branchenspezifischer Vorgaben durchgeführt, damit Sicherheits- und Compliance-Anforderungen sichergestellt werden können.

Fazit

Vor und während der Nutzung von Cloud Services kann Tool-Unterstützung in Form von – durch den Cloud Service Provider gestellte – Compliance Services den Aufwand im Compliance Management mindern und helfen, die Compliance-Vorgaben des eigenen Unternehmens sicherzustellen. Insbesondere können sie auch dabei helfen, Maßnahmen auf regelmäßiger Basis zu prüfen und erforderliche Aktualisierungen durchzuführen.

Cloud Services nutzende Unternehmen sind allerdings selbst dafür verantwortlich, dass bei ihnen geltende Compliance-Gesetze und Vorschriften eingehalten werden. Das heißt, dass sie selbst ein angemessenes Compliance Management etablieren müssen, in dem die Compliance-Tools der Cloud Service Provider nur ein Baustein sein können, der zudem noch auf die eigenen Anforderungen anzupassen ist. In diesem Sinne ist ein Tool wie der Microsoft Compliance Manager keine absolute „Checkliste“, jedoch ein gutes Basiswerkzeug für den Einstieg und ein strukturelles Vorgehen.

Public Cloud Services gelten als Extremvariante von IT-Outsourcing: Die sehr hohe Standardisierung ihrer Services ermöglicht den Cloud Service Providern, diese zu sehr attraktiven Preisen anzubieten. Unternehmen, die komplette IT-Services outsourcen (sogenannte Managed Services), haben allerdings eine geringere IT-Fertigungstiefe als Unternehmen, die nur Public Cloud Services beziehen. Letztere erbringen die nicht vom Cloud Service Provider übernommenen Aufgaben selbst. Im Folgenden betrachten wir die Gegenüberstellung “Cloud Services versus Managed Services”, d.h. ob und wann es vorteilhaft sein kann, einen zusätzlichen Service Provider für diese intern verbleibenden Aufgaben einzubinden und so auf Managed Service Niveau zu kommen.

Zunächst betrachten wir jedoch die Public Cloud Services und die mit dem jeweils gewählten Cloud-Servicemodell verbundenen Restaufgaben, die beim Kunden verbleiben. Als ausführlicheres Beispiel dient anschließend das Servicemodell „Infrastructure as a Service (IaaS)“.

Leistungsinhalte bei Public Cloud Services

Cloud Service Provider bieten Kunden mit ihren Public Cloud Services geteilte Computer-Ressourcen als Dienstleistung, in Form von Servern, Datenspeicher oder Applikationen an. Der Kunde kann den Service entsprechend seinem tatsächlichen Bedarf skalieren, der Service wird nach tatsächlicher Nutzung abgerechnet. Der Service ist für alle Kunden jeweils identisch und kann in der Regel über ein Serviceportal vom Kunden eingerichtet, abgerufen und überwacht werden.

Verbleibende Kundenaufgaben

Hier beginnt die Arbeitsteilung: Für alle Kunden gleiche Servicebestandteile werden vollständig vom Cloud Service Provider übernommen, alles Kundenspezifische ist vom Kunden selbst zu „administrieren“. Das ist – abhängig vom Servicemodell und konkreten Service – wenig oder mehr Aufwand für den Kunden und die erforderlichen Arbeiten erfordern wenig oder mehr Expertise. Bei den drei klassischen Cloud Servicemodellen sieht die Arbeitsteilung grob wie folgt aus:

Bei Infrastructure as a Service (IaaS) wird die IT-Infrastruktur wie Computer (virtuelle oder dedizierte Hardware), Netzwerke und Speicher über das Internet bereitgestellt und vom Service Provider betrieben. Der Kunde übernimmt die Einrichtung „seiner“ Server und Storage-Bereiche und betreibt die darauf installierte Software.

Bei Platform as a Service (PaaS) stellt der Service Provider das Infrastruktur- und Software-Framework bereit und betreibt es. Der Kunde entwickelt darauf seine Anwendungen, lässt sie hier ausführen und betreibt diese.

Bei Software as a Service (SaaS) wird die Anwendung vom Service Provider auf seiner eigenen Infrastruktur bereitgestellt und verwaltet. Der Kunde richtet User-Accounts, Berechtigungen und Schnittstellen zu anderen Anwendungen ein.

In der folgenden Abbildung werden die Verantwortlichkeiten von Service Provider und Kunde bei den verschiedenen Cloud Servicemodellen dargestellt. Bei allen Servicemodellen muss der Kunde neben seinen eben skizzierten „Restaufgaben“ zusätzlich die Aufgaben des Providermanagements übernehmen.

 

 

Kundenaufgaben am Beispiel IaaS

Am Beispiel IaaS schauen wir uns die verbleibenden Kundenaufgaben einmal genauer an. Die betriebsbezogenen „Restaufgaben“ umfassen insbesondere:

• Verwaltung des Gastbetriebssystems (einschließlich Updates und Sicherheitspatches) und jeglicher Anwendungssoftware oder Dienstprogramme, die vom Kunden installiert werden
• Konfiguration der vom Provider bereitgestellten Firewall
• Datenverwaltung und Verschlüsselung
• Datensicherung und Recovery-Maßnahmen
• Benutzer- und Zugriffsverwaltung
• Risikomanagement

Neben dem Ansatz, Public Cloud Services mit eigenem Restaufgabenanteil einzusetzen gibt es jedoch auch noch die Möglichkeit, alle mit einem Cloud-Service anfallenden Aufgaben nach außen zu vergeben (Managed Services). Dies würde bedeuten, dass ein weiterer Service Provider die Restaufgaben für den Kunden erbringt und letzterer nur noch das Providermanagement übernimmt. Diese beiden Optionen stellen wir im folgenden Abschnitt am Beispiel IaaS gegenüber (Cloud Services versus Managed Services).

Vergleich Cloud Services versus Managed Services (IaaS + Restaufgaben und IaaS + ergänzende Services)

Zunächst werfen wir einen Blick auf die Gesamtkosten der beiden Optionen: Die Gesamtkosten bei der Option „IaaS + Restaufgaben“ teilen sich in drei Teile:

• externe Servicekosten für IaaS,
• interne Kosten für Kunden-seitige Restaufgaben und
• interne Kosten des Providermanagements.

Die internen Aufgaben erfordern ein angemessenes Fachwissen, das bei vielen Unternehmen zunächst nicht vorhanden ist. Zwar gestaltet es sich relativ einfach, mit einigen wenigen Diensten zügig loszulegen. Ein optimaler Einsatz von Cloud Services aber, der auch innovative Services, Best Practices, Sicherheit, Compliance und das Kosten-Management berücksichtigt, ist für viele IT-Organisationen eine große Herausforderung: Intern müssen hierfür erst einmal Kompetenzen und Ressourcen aufgebaut werden.

Der Aufwand im Providermanagement ist deutlich niedriger als bei klassischem Outsourcing, denn es gibt kaum einen persönlichen Kontakt zum Provider. Dies ist auch nicht erforderlich, da IaaS ein für alle Kunden gleicher Standardservice ist und keine Kunden-individuellen Leistungen erbracht werden. Providermanagement-Aufgaben konzentrieren sich deswegen im Wesentlichen auf Vertragsmanagement, Security und Compliance Management, Performance Management und Finanzmanagement.

Bei der Option „IaaS + ergänzende Services“ übernimmt ein ergänzender Service Provider die Kunden-seitigen Restaufgaben. Er kann zudem die operative Steuerung des IaaS-Providers übernehmen. Dadurch entstehen insgesamt höhere externe Servicekosten. Der Aufwand und damit die Kosten im Providermanagement steigen ebenfalls, da der externe Gesamtservice jetzt „kundenspezifisch“ wird und damit besser mit dem internen Servicemanagement zusammenspielen muss.

 

 

Vorteile der Option „IaaS + ergänzender Service“:

+ geringe Fertigungstiefe (vergleichbar mit anderen Managed Services)

+ kein internes Betriebs-Know-how mehr erforderlich

+ Nutzung der Kernkompetenz und Erfahrung eines spezialisierten Service Providers

+ höhere Kostentransparenz durch externe Abrechnungsstrukturen

 

Nachteile der Option „IaaS + ergänzender Service“

– zwei Provider erhöhen gegebenenfalls die Komplexität

– Abhängigkeit vom ergänzenden Service Provider, da das Betriebs-Know-how intern nicht mehr vorhanden ist

– anspruchsvolleres und aufwändigeres Providermanagement

 

Gesamtbewertung

Bei Outsourcing ist die Option „IaaS + ergänzende Services“ gegenüber der Lösung „IaaS + interne Restaufgaben“ die einheitlichere, wenn Unternehmen die Strategie verfolgen, IT-Services komplett outzusourcen und nicht nur Teilaufgaben eines IT-Services extern erbringen lassen: So wird eine einheitliche (und geringe) Fertigungstiefe sichergestellt. Ob diese Alternative wirtschaftlicher ist, hängt von den Rahmenbedingungen im Unternehmen und insbesondere vom Reifegrad des Providermanagements ab.