MSP, Cloud- und DevOps-Dienstleister
Sie betreiben Systeme für Ihre Kunden: Private und Public Cloud,
Kubernetes-Cluster, CI/CD-Pipelines, Observability-Stacks,
Infrastructure-as-Code-Umgebungen, Security-Tooling und vieles mehr.
Sie liefern eine Mischung aus Betrieb, Standardwerkzeugen und eigenem
Code: Terraform-Module, Helm-Charts, Ansible-Playbooks, Custom
Operators, Glue-Code, Runbooks.
Managed Service Provider und Cloud-Dienstleister sind regulatorisch in
einer besonders exponierten Lage: Sie haben meist Betriebsverantwortung
plus Zugang zu den Systemen Ihrer Kunden plus eigenen Code in der
Umgebung. Die Kombination macht Sie zum idealen Ansatzpunkt für
Lieferantenprüfungen unter DORA und NIS2.
Typische Leistungen und ihre regulatorische Einordnung
Managed Cloud und Managed Kubernetes
Reiner Betrieb fällt nicht primär unter den CRA, aber unmittelbar unter
NIS2-Lieferantenbewertungen (Art. 21 Abs. 3 NIS2) und DORA-
Drittparteienrisiko (Art. 28 DORA). Ihr Kunde muss Sie in sein
DORA-Informationsregister aufnehmen, wenn er Finanzinstitut ist. Das
betrifft jeden MSP, der einen Banken-, Versicherungs- oder
Asset-Management-Kunden hat.
Infrastructure-as-Code und Automatisierung
Terraform-Module, Pulumi-Konfigurationen, Helm-Charts, Ansible-
Playbooks, Crossplane-Compositions - das ist Code, den Sie schreiben
und bei Kunden ausrollen. Fehler in IaC führen direkt zu
Betriebsstörungen oder Datenlecks. Art. 6 Abs. 1 lit. c der
Produkthaftungsrichtlinie trifft solche Fehler unmittelbar.
Wenn Sie Module als Produkte an mehrere Kunden ausliefern, werden diese
Module nach CRA zu Produkten mit digitalen Elementen.
Wenn Sie für Kunden Pipelines aufbauen, ist die Kette aus Runner,
Image-Registry, Secrets-Handling, Signierung und Deployment
sicherheitskritisch. Supply-Chain-Angriffe zielen genau hier an. NIS2
und DORA bewerten solche Prozesse besonders genau.
Observability-Stacks (Grafana, Prometheus, Loki, ELK) und
Security-Tooling (SIEM, SOAR) verarbeiten sensibelste Betriebsdaten.
Als Betreiber solcher Stacks sind Sie Datenverarbeiter und oft
Prozessor im DSGVO-Sinn - mit Haftung auch für Drittbibliotheken in
diesen Komponenten.
Custom Operators, Controller, Glue-Code
Selbstgeschriebener Code in Kubernetes-Operatoren, Lambda-Funktionen,
Cloud-Functions oder Glue-Skripten ist eigenständiger Produkt-Code
nach CRA. Er wird in die Systemlandschaft Ihres Kunden eingebracht
und ist damit Ihre Liefersoftware.
Pen-Tests, Hardening, Incident-Response
Wenn Sie Incident-Response oder Penetrationstests für Finanz- oder
NIS2-Kunden erbringen, können Sie in DORAs Threat-Led-Penetration-
Testing-Regime (Art. 26 DORA) einbezogen werden. Die Anforderungen
dort sind erheblich - mit formalisierten Rollen, Nachweisen und
behördlicher Einbindung.
Welche Gesetze greifen bei welchen Kunden
Zwei Gesetze greifen unabhängig vom Kundensektor:
- Produkthaftungsrichtlinie (RL 2024/2853) erfasst jeden Code, den Sie bei Kunden ausrollen - Terraform-Module, Helm-Charts, Operatoren, Lambda-Funktionen, Glue-Skripte. Als Entwickler sind Sie nach Art. 8 Hersteller, Datenverlust ist Haftungsgrund (Art. 6 Abs. 1 lit. c), und die Haftung ist nicht gedeckelt (Art. 12).
- Cyber Resilience Act (VO (EU) 2024/2847) erfasst Ihre wiederverwendbaren Module, Custom Operators und Tool-Bundles als "Produkte mit digitalen Elementen" (Art. 3 Nr. 1). Art. 13 Abs. 5 verlangt Sorgfalt bei der Integration von Open-Source-Komponenten - und davon stecken in Base-Images, Pipelines und Cloud-Tooling besonders viele.
MSP- und Cloud-Kunden sind zudem oft in regulierten Sektoren tätig -
die regulatorische Breite Ihres Portfolios ist entsprechend groß:
- Finanzsektor: DORA in voller Schärfe. Jeder MSP, der für einen DORA-pflichtigen Kunden arbeitet, ist IKT-Drittdienstleister. Je nach Funktion auch "kritisch" nach Art. 28 Abs. 5 DORA.
- Cloud-Hyperscaler-Reseller und -Integratoren: Sie sind Teil der Sub-Outsourcing-Kette. DORA Art. 28 und die ITS- Informationsregister-Verordnung beleuchten diese Kette genau.
- Energie, Versorgung: NIS2 als wesentliche Einrichtungen. Cloud- Betrieb für Stadtwerke ist sofort Lieferkette nach Art. 21 Abs. 3.
- Gesundheit, Kliniken: NIS2 plus besonders hohe Datenschutz- Anforderungen. Managed Cloud für ein Krankenhaus ist hoch reguliert.
- Öffentliche Verwaltung: NIS2 plus BSI-Vorgaben plus C5- Anforderungen bei Cloud-Leistungen. Besonders streng bei Bundes- und Landesbehörden.
- Digitale Infrastruktur selbst: NIS2-Sektor. Rechenzentren, Cloud-Anbieter und Hosting-Provider sind wesentliche Einrichtungen nach NIS2.
- Automotive, Industrie, Halbleiter: NIS2 als wichtige Einrichtungen. DevOps-Dienstleister in Produktionsnetzen sind Kern-Zulieferer.
Besonderheit: MSP sind oft die einzigen externen Dienstleister mit
direktem Produktiv-Zugriff. Entsprechend hart fallen Lieferantenaudits
aus.
Konkrete Konsequenzen
Rechtlich stehen auf dem Spiel:
- Unbegrenzte Haftung nach der Produkthaftungsrichtlinie für jeden ausgerollten Code - IaC-Module, Operatoren, Glue-Skripte, Images
- Bußgelder bis 15 Mio. Euro oder 2,5 % des Jahresumsatzes nach CRA (Art. 64) für wiederverwendbare Module und Custom Operators
- Direkte DORA-Aufsicht mit Bußgeldern bis 1 % des weltweiten Tagesumsatzes (Art. 50 DORA), wenn Sie als kritischer IKT-Drittdienstleister eines Finanzinstituts eingestuft werden - das betrifft insbesondere große MSP mit relevantem Finanz-Portfolio
- Verlust des Finanz- und KRITIS-Segments, wenn Sie die Lieferanten-Due-Diligence nicht bestehen. MSP sind wegen ihres Systemzugriffs besonders hart geprüft
- Verlust von Zertifizierungen (ISO/IEC 27001, SOC 2, C5, TISAX) bei dokumentierten Sicherheitsmängeln - und damit sofortiger Wegfall ganzer Kundengruppen
- 24-/72-Stunden-Meldepflichten nach Art. 14 CRA, Art. 23 NIS2, Art. 19 DORA - oft kombiniert in einem einzigen Vorfall
- Persönliche Haftung der Geschäftsleitung bei grober Sorgfaltsverletzung
Vertraglich werden Ihre Kunden verlangen:
- Dokumentierte Sicherheitsstrategie und ISMS (ISO/IEC 27001 wird Standardforderung)
- SBOM für eingesetzte Tools, Images, Charts und eigene Module
- Supply-Chain-Nachweise (signierte Images, SLSA, Provenance)
- Incident-Response mit 24/7-Bereitschaft bei DORA-Kunden
- Ausstiegsszenario nach Art. 28 Abs. 8 DORA
- Auditierbarkeit und Auditzugang für Kundenprüfer und Aufsicht
- Penetrationstests und regelmäßige Sicherheits-Reviews
Operativ müssen Sie etablieren:
- SBOM-Generierung für alle deployten Container-Images und Pipelines
- Monitoring aller eingesetzten Open-Source-Komponenten, einschließlich transitiver Abhängigkeiten in Base-Images und Helm-Charts
- Responsible-Disclosure-Kanal und Vulnerability-Handling nach Art. 14 CRA
- Patch-Strategie über alle Kundensysteme hinweg mit definierten Reaktionszeiten
- Change-Management, das Auditoren nachvollziehen können
- Kontinuierliche Überprüfung der eigenen Tool-Landschaft auf Schwachstellen
Finanziell kommt auf Sie zu:
- Laufende Zertifizierungen (ISO/IEC 27001, SOC 2, C5, TISAX je nach Sektor)
- Aufbau interner Security-Kapazität oder Einkauf als Service
- Versicherungsbedarf, der bei MSP besonders hoch ausfällt
- Unbegrenztes Haftungsrisiko unter der neuen Produkthaftungsrichtlinie für eigenen Code
Sicherheit ist auch ohne Pflicht ein Wettbewerbsvorteil
MSP und Cloud-Dienstleister konkurrieren hart um Vertrauen. Wer bei
Kunden in Produktivsystemen sitzt, wird gefragt, wie die eigene
Lieferkette gesichert ist - und das zunehmend auch dort, wo gar keine
Regulierung greift. Nachweisbare Sicherheit ist ein
Differenzierungsmerkmal, das im Verkaufsgespräch unmittelbar wirkt.
Konkret bringt das: höhere Chancen in Ausschreibungen mit
Sicherheitsanforderungen, leichtere Prüfungen nach ISO/IEC 27001,
SOC 2 oder C5, günstigere Versicherungsprämien, stärkere Kundenbindung
und eine klare Abgrenzung gegenüber Wettbewerbern, die
Sicherheitsfragen nur auf Nachfrage beantworten können. Was Sie für
Compliance investieren, wirkt gleichzeitig als Verkaufsargument.
Wie OTTRIA MSP und Cloud-Dienstleister unterstützt
Der Open-Source-Anteil in modernen Cloud-Stacks ist überwältigend:
Base-Images, Kubernetes, Helm-Charts, Operatoren, Observability-
Tools, CI/CD-Werkzeuge, Security-Tooling - fast alles ist Open
Source. Entsprechend groß ist die Sorgfaltslast. OTTRIA übernimmt
diesen Teil:
- SBOM-Analyse und -Pflege für Base-Images, Helm-Charts, CI/CD-Pipelines und eigene Module
- Vulnerability-Monitoring in Echtzeit über alle eingesetzten Komponenten, auch transitiv
- Silent-Fix-Detection in Cloud-Native-Projekten durch aktive Beobachtung von Commit-Historien und Sicherheitsprozessen
- Fehlerbehebung direkt im Open-Source-Projekt - etwa bei Container-Runtimes, Kubernetes-Operatoren, Observability-Stacks
- Frühwarnung durch OTTRIAs Steward-Rolle bei kritischen Open-Source-Projekten - Sie erfahren von Schwachstellen vor der CVE-Veröffentlichung
- Auditfähige Dokumentation pro Kunde, pro Umgebung, pro Pipeline - vorlegbar bei DORA-, NIS2- und C5-Prüfungen
- Steward-Unterstützung für Kunden, die OTTRIA als Steward für kritische Open-Source-Komponenten einsetzen möchten
- Responsible-Disclosure-Kanal für Ihre Kundenumgebungen und eigenen Module
Sie konzentrieren sich auf Betrieb, Automatisierung und Kundenberatung.
OTTRIA liefert den Open-Source-Sorgfaltsteil, den kein MSP intern
vollständig abdecken kann - und die prüffähigen Nachweise, die Ihre
Kunden unter DORA und NIS2 einfordern müssen.
Erstgespräch vereinbaren
Zurück zur Übersicht für Software-Dienstleister
Weiterlesen