9. März 2026
Cloud-Beschaffung: Warum sie immer auch ein Sicherheits- und Governanceprojekt ist
„Cloud“ wird häufig mit Flexibilität, Skalierbarkeit und modernem IT-Betrieb verbunden.
Aus vergaberechtlicher und sicherheitstechnischer Sicht bedeutet Cloud jedoch vor allem eines: Verantwortung.
Denn Cloud bedeutet stets auch:
fremde Infrastruktur,
fremde Dienste,
fremde Lieferketten.
Gerade bei der öffentlichen Beschaffung wird diese Dimension häufig unterschätzt. In großen IT-Vergaben zeigt sich immer wieder, dass Projekte, die später in Rechenzentren oder auf SaaS-Plattformen Dritter betrieben werden, nicht primär als Sicherheitsprojekt gedacht werden.
Dabei verschärfen aktuelle regulatorische Entwicklungen diese Perspektive erheblich. Sowohl die NIS-2-Richtlinie als auch der Cyber Resilience Act adressieren zentrale Aspekte der IT-Sicherheit entlang der gesamten digitalen Lieferkette.
Die Regelungslogik ist dabei klar verteilt:
NIS-2 richtet sich insbesondere an Betreiber digitaler Dienste, etwa Cloud- oder Plattformanbieter – unter Umständen aber auch an öffentliche Stellen selbst.
Der Cyber Resilience Act adressiert vor allem Hersteller digitaler Produkte und Komponenten, etwa Softwareentwickler, und enthält Anforderungen etwa an Schwachstellenmanagement oder Software Bill of Materials (SBOM).
Damit wird deutlich: IT-Beschaffung mit Cloud-Bezug ist immer auch Teil eines umfassenderen Sicherheits- und Governance-Kontexts.
Wer eine IT-Leistung beschafft, die nicht im eigenen Rechenzentrum betrieben wird – etwa als Software-as-a-Service – gibt technisch unmittelbar Kontrolle ab. Dies betrifft unter anderem:
- Cloud-Plattform und Rechenzentrumsstandorte
- Softwarearchitektur und Schnittstellen
- Rollen- und Rechtekonzepte (IAM, Zero-Trust-Modelle)
- Subdienstleister und Datenflüsse
- Speicher- und Löschkonzepte
- Logging, Audit-Trails und Compliance-Mechanismen
Gerade bei SaaS-Modellen liegt die operative Kontrolle über zentrale technische Funktionen – etwa Berechtigungslogik, Monitoring oder Logging – regelmäßig beim Anbieter. Auftraggeber können diese Aspekte daher nicht unmittelbar steuern, sondern nur über Anforderungen, Vertragsgestaltung und Audit-rechte.
Vor diesem Hintergrund sollten bei Cloud-bezogenen Beschaffungen insbesondere folgende Fragen geklärt werden:
- Wer trägt Verantwortung bei Ausfällen der Plattform?
- Wo werden Daten gespeichert, und bestehen Bindungen an EU- bzw. EWR-Standorte?
- Welche Subprozessoren sind beteiligt?
- Welche Service-Level gelten tatsächlich?
- Welche Exit- und Portabilitätsmechanismen bestehen?
- Welche Audit-, Logging- und Compliance-rechte sind erforderlich?
- Wird eine Software Bill of Materials (SBOM) bereitgestellt, wie es der Cyber Resilience Act vorsieht?
Eine hilfreiche Orientierung für viele dieser Aspekte bietet der BSI-Katalog C5:2020, der zentrale Anforderungen an Cloud-Sicherheitsarchitekturen strukturiert zusammenfasst.
Die Vielzahl der Aspekte kann auf den ersten Blick komplex wirken. Der zentrale Punkt lässt sich jedoch vergleichsweise einfach zusammenfassen:
Sobald Cloud- oder Rechenzentrumsleistungen Dritter Teil der Leistungserbringung sind, wird die Beschaffung automatisch zu einem IT-Sicherheits- und Governanceprojekt.
Beschaffung, IT-Sicherheit und organisatorische Steuerung lassen sich in solchen Projekten nicht sinnvoll voneinander trennen. Werden diese Dimensionen bereits im Vergabedesign gemeinsam gedacht, verändert dies häufig nicht nur einzelne Vertragsklauseln, sondern die gesamte Steuerungsfähigkeit eines Projekts im späteren Betrieb.
Spätestens mit NIS-2 und dem Cyber Resilience Act wird daher nicht mehr die Frage im Vordergrund stehen, ob IT-Sicherheit Teil eines Vergabeverfahrens ist, sondern mit welcher Tiefe sicherheitsbezogene Anforderungen in Vergabeunterlagen implementiert werden müssen.