Warum die Cloud-Sicherheit von Managed Service Providern über Nacht zusammenbrach
Die Cloud-Sicherheit von Managed Service Providern (MSPs) geriet ins Wanken, als Cloud-Plattformen nicht mehr nur einfache Anbieter waren, sondern sich zu Umgebungen mit geteilter Verantwortung entwickelten, die aktiv gesteuert werden müssen. ISO 27001 A.5.23 verdeutlicht diesen Wandel, indem sie von Ihnen erwartet, die Auswahl, Nutzung und Beendigung von Cloud-Diensten im Einklang mit Ihrem Informationssicherheitsmanagementsystem (ISMS) zu kontrollieren, anstatt sich allein auf Anbieterzertifikate zu verlassen. Diese Erwartung spiegelt die Formulierung von ISO 27001:2022 A.5.23 und gängigen Leitlinien zur Cloud-Sicherheit wider, die definierte Prozesse für die Beschaffung, Nutzung, Verwaltung und Beendigung von Cloud-Diensten betonen, anstatt sich allein auf Zusicherungen von Anbietern zu verlassen, wie in den Kommentaren zu ISO 27001 A.5.23 hervorgehoben wird.
Cloud-Dienste ermöglichen Ihrem Managed Service Provider (MSP) zwar ein schnelles Wachstum, legen aber auch Lücken in Bezug auf Verantwortlichkeiten, Governance und Nachweisführung offen, die im alten Anbietermodell nie relevant waren. Wenn Kunden und Auditoren heute fragen, wer in der Cloud wofür zuständig ist, reicht die Aussage „Der Anbieter macht das“ nicht mehr aus. A.5.23 verdeutlicht diese Problematik, indem es einen kontrollierten, dokumentierten Umgang mit der Cloud-Nutzung anstelle von willkürlichen Plattformentscheidungen fordert.
Die Cloud wird für Managed Service Provider (MSPs) nur dann zum Vorteil, wenn die Verantwortung bewusst geteilt und nicht einfach vorausgesetzt wird.
Die Cloud hat Ihr altes „Lieferanten“-Denken längst hinter sich gelassen.
Die Cloud hat die Vorstellung, dass man mit einem Vertrag und einem Zertifikat die Sicherheit beim Provider absichern kann, längst hinter sich gelassen. Für Managed Service Provider (MSPs) zwingt A.5.23 dazu, zu erkennen, dass Identitäten, Konfigurationen und der tägliche Betrieb jeder Plattform nun fest in ihrer Verantwortung liegen.
Viele Managed Service Provider (MSPs) behandeln Cloud-Anbieter immer noch wie traditionelle Lieferanten, und genau hier stößt A.5.23 an seine Grenzen. Jahrelang konnte man einen Vertrag abschließen, Zertifizierungen vertrauen, ein paar Überwachungsfunktionen hinzufügen und fertig. Das funktionierte, solange Cloud-Dienste nur E-Mail-Hosting oder ein paar virtuelle Maschinen umfassten.
Heutzutage laufen ganze Servicekataloge auf Hyperscale-Plattformen, wobei Ihre Techniker über weitreichende Administratorrechte verfügen und Automatisierungstools Dutzende von Mandanten gleichzeitig betreuen. In diesem Umfeld trifft die Aussage „Der Anbieter ist für die Sicherheit verantwortlich“ nicht mehr zu. Der Cloud-Anbieter sichert zwar seine Infrastruktur und Kerndienste, aber Sie entscheiden über Identitäten, Konfigurationen, Integrationen und einen Großteil der Betriebssicherheit. Kunden verstehen dies zunehmend und erwarten von Ihnen, dass Sie offenlegen, wie die geteilten Verantwortlichkeiten definiert sind und wie Ihr Team diese Kontrollen im täglichen Betrieb umsetzt.
Abschnitt A.5.23 der Norm fordert diesen Wandel explizit. Er erwartet von Ihnen, dass Sie von einer allgemeinen Lieferantensicherung zu einer aktiven Steuerung der Art und Weise übergehen, wie Cloud-Plattformen Ihre Dienste und Ihre Kunden unterstützen.
Die versteckte Komplexität Ihrer aktuellen Cloud-Architektur
Die verborgene Komplexität Ihrer Cloud-Infrastruktur wird erst deutlich, wenn Sie sie dokumentieren. Eine kurze, fokussierte Bestandsaufnahme deckt in der Regel weit mehr Dienste, Datenflüsse und Administratorrollen auf als erwartet – genau das, was A.5.23 Ihnen vorsieht und Sie dazu anregt, diese gezielt zu verwalten.
Die meisten Managed Service Provider (MSPs) stellen fest, dass sie weitaus mehr Dienstleistungen auf weitaus vielfältigere Weise anbieten, als irgendjemand ursprünglich angenommen hatte:
- Interne SaaS-Tools für Zusammenarbeit, Ticketing, CRM und Finanzen.
- Öffentliche Cloud-Plattformen als Grundlage für verwaltete Infrastruktur-, Backup-, Überwachungs- und Sicherheitsdienste.
- Nischen-Cloud-Tools, die von einzelnen Teams oder Ingenieuren zur Lösung spezifischer Probleme ausgewählt werden.
Zusammengenommen bilden diese Dienste ein komplexes Geflecht aus Datenspeicherorten, Administratorrollen, Protokollen und Fehlermodi. Ohne eine zentrale Übersicht häufen sich Risiken unbemerkt an: Ein einzelner Techniker hat die globale Administration für mehrere Mandanten, ein ursprünglich als „temporäres“ SaaS-Tool wird geschäftskritisch, und ein Backup-Dienst wurde nie auf reale Wiederherstellungsszenarien getestet. Eine ISMS-Plattform wie ISMS.online hilft Ihnen dabei, diese zentrale Übersicht zu wahren, sodass die Komplexität nicht verborgen bleibt.
Um den Wandel konkreter zu machen, ist es hilfreich, die alte Lieferantenmentalität mit der Cloud-Governance-Philosophie zu vergleichen, die A.5.23 vorsieht.
Ein kurzer Vergleich zeigt, wie sich Ihre Herangehensweise ändern muss:
| Aspekt | Altes Lieferantenmodell | A.5.23 Cloud-Governance für Managed Service Provider (MSPs) |
|---|---|---|
| Sicht des Anbieters | „Ein vertrauenswürdiger Anbieter kümmert sich um die Sicherheit.“ | „Partner in einem definierten Modell gemeinsamer Verantwortung.“ |
| Kontrollumfang | Vertrag plus grundlegende Überwachung | Vollständiger Lebenszyklus: Auswahl, Nutzung, Änderung, Beendigung |
| Beweise, die Sie besitzen | Zertifikate und Verträge | Register, Risikoaufzeichnungen, Matrizen, Lebenszyklusartefakte |
| Eigentumsverhältnisse innerhalb der MSP | Implizit, personenabhängig | Explizite Rollen, Runbooks und ISMS-Integration |
Wenn Sie Ihre Situation einmal aus dieser Perspektive betrachten, wird es einfacher zu entscheiden, wo Sie Struktur benötigen und nicht nur provisorische Lösungen.
Wo Kunden und Wirtschaftsprüfer die Schwachstellen aufdecken
Kunden und Auditoren decken Schwachstellen in Ihrer Cloud-Infrastruktur auf, indem sie gezielte Fragen zu Diensten, Daten und Verantwortlichkeiten stellen. Ihre Fragen verdeutlichen oft Lücken in Bezug auf Zuständigkeiten, Lebenszyklus und Nachweise, lange bevor es zu einem Sicherheitsvorfall oder Ausfall kommt. Das Management von Drittanbieterrisiken und die Überwachung der Lieferantenkonformität wurden von 41 % der Unternehmen in der ISMS.online-Umfrage 2025 als eine der größten Herausforderungen genannt.
Typische Fragen sind:
- Welche Cloud-Dienste nutzen Sie in unserem Auftrag, und wo werden unsere Daten gespeichert?
- Wer ist auf den jeweiligen Plattformen für Datensicherung, Identitätsmanagement, Protokollierung und Konfiguration verantwortlich?
- Wie prüft, überwacht und wechselt man gegebenenfalls zu Cloud-Anbietern?
- Wie werden Sie uns unterstützen, wenn wir einen anderen Dienst in Anspruch nehmen möchten?
Diese Fragen decken Unklarheiten in Ihrem aktuellen Vorgehen auf. Wenn Ihre Antworten davon abhängen, wer an der Besprechung teilnimmt oder eine Überprüfung erfordern, stellt A.5.23 bereits ein Problem dar. Die Kontrollvorgabe sieht vor, dass Sie Prozesse für die Beschaffung, Nutzung, Verwaltung und Deaktivierung von Cloud-Diensten gemäß definierten Sicherheitsanforderungen implementieren. Für einen Managed Service Provider (MSP) bedeutet dies den Übergang von einer improvisierten Cloud-Infrastruktur zu einer strukturierten, die von Auditoren und Kunden geprüft werden kann.
Hier wird ein Live-Register von Cloud-Diensten, verknüpft mit Risiken, Verantwortlichkeiten und Lebenszyklusdatensätzen, unerlässlich und nicht nur ein nettes Extra.
KontaktWas ISO 27001 A.5.23 wirklich von Ihnen verlangt
ISO 27001 A.5.23 fordert, die Cloud als regulierte Servicelandschaft mit klaren Regeln, Verantwortlichkeiten und Nachweisen zu behandeln und nicht als unstrukturierte Sammlung von Tools und Anbietern. Konkret bedeutet dies, nachweisen zu können, wie Cloud-Dienste gemäß Ihren Informationssicherheitsanforderungen ausgewählt, kontrolliert und außer Betrieb genommen werden.
Im Bericht „State of Information Security 2025“ wird darauf hingewiesen, dass Kunden am häufigsten erwarten, dass Lieferanten sich an formale Rahmenwerke wie ISO 27001, ISO 27701, DSGVO, Cyber Essentials, SOC 2 und aufkommende KI-Standards anpassen.
In der Ausgabe 2022, Abschnitt A.5.23, wird empfohlen, Prozesse für die Beschaffung, Nutzung, Verwaltung und Deaktivierung von Cloud-Diensten gemäß den Informationssicherheitsanforderungen einzurichten und zu implementieren. Diese Formulierung entspricht dem veröffentlichten Kontrolltext in ISO 27001:2022 A.5.23 sowie ergänzenden Cloud-Leitlinien wie ISO 27017 und ISO 27018, die allesamt die durchgängige Governance von Cloud-Diensten anstelle von einmaligen Lieferantenprüfungen betonen. Eine zentrale ISMS-Plattform wie ISMS.online kann diese Arbeit vereinfachen, indem sie Richtlinien, Risiken, Verantwortlichkeiten und Aufzeichnungen an einem Ort bündelt.
Prüfer achten in der Regel auf einen klaren Zusammenhang zwischen dem Kontrolltext und den tatsächlichen Richtlinien, Verfahren und Aufzeichnungen. Wenn Sie in Ihren eigenen Worten erklären können, was A.5.23 für Ihr Unternehmen bedeutet, sind Sie vielen Managed Service Providern (MSPs) bereits einen Schritt voraus, die sich ausschließlich auf den formalen Wortlaut verlassen.
Von einem Satz zu praktischen Zielen
Die Umsetzung von A.5.23 in praktische Ziele bedeutet, den formalen Wortlaut in wenige konkrete, überprüfbare Erwartungen zu unterteilen, auf deren Grundlage Sie Kontrollen und Nachweise entwickeln können. Diese Ziele bieten Ihnen einen Rahmen, um die Kontrolle Ihrem Team und den Auditoren zu erläutern. Interpretationen von auf Cloud-Technologien spezialisierten ISO-27001-Anwendern gruppieren die Anforderungen von A.5.23 häufig in Themenbereiche wie Cloud-Richtlinien, Risiken und Anforderungen, geteilte Verantwortung, Lebenszyklus und Nachweise – ein Ansatz, der auch hier verfolgt wird.
In der Praxis erwartet A.5.23, dass Sie fünf Dinge konsequent tun und dies nachweisen können. Eine hilfreiche Methode zur Interpretation der Kontrolle besteht darin, sie in fünf praktische Ziele zu unterteilen:
- Cloud-Richtlinie und -Geltungsbereich – Definieren Sie, was „Cloud“ für Ihre Organisation bedeutet, welche Dienste und Daten in den Geltungsbereich fallen und wer neue Dienste nutzen kann.
- Risiken und Anforderungen – Cloudspezifische Risiken wie Mandantenfähigkeit, Datenstandort und Konnektivität identifizieren und Mindestanforderungen an Sicherheit und Datenschutz festlegen.
- Geteilte Verantwortung – dokumentieren Sie, wer für die wichtigsten Kontrollmechanismen auf Anbieter-, MSP- und Kundenebene für jede wichtige Plattform und jeden wichtigen Dienst verantwortlich ist.
- Lebenszyklusverwaltung – Sicherheit sollte bei der Auswahl, dem Onboarding, der Änderung, der Überwachung und dem Ausstieg aus Cloud-Diensten berücksichtigt werden, nicht nur in den Verträgen.
- Nachweise und Verbesserungen – Führen Sie Aufzeichnungen, die belegen, dass diese Prozesse funktionieren, und überprüfen Sie diese regelmäßig, wenn sich Plattformen, Kunden und Vorschriften ändern.
Zusammengenommen verwandeln diese Ziele A.5.23 von einem einzelnen Satz in eine Reihe von Gewohnheiten. Sie bieten Ihnen außerdem eine Struktur, um die Kontrolle in Ihre Anwendbarkeitserklärung und Ihr umfassenderes ISMS zu integrieren. Die Erfassung der Ziele, Verantwortlichen und Belege in einem System wie ISMS.online hilft Ihnen, deren Konsistenz bei der Weiterentwicklung von Diensten und Standards zu gewährleisten.
Wie A.5.23 das ältere Lieferantenmodell erweitert
A.5.23 erweitert das ältere Lieferantenmodell, indem es anerkennt, dass die Cloud eine technische Grundlage und nicht nur ein weiterer Outsourcing-Vertrag ist. Wenn Ihre Dienste von gemeinsam genutzten Plattformen abhängen, haben Ihre Konfigurations-, Zugriffs- und Betriebsentscheidungen einen starken Einfluss auf die Sicherheitsergebnisse, selbst wenn die zugrunde liegende Infrastruktur einem anderen Unternehmen gehört.
Im Vergleich zu allgemeinen Lieferantenkontrollen in Bereichen wie Lieferantenmanagement und Betriebssicherheit, A.5.23:
- Der Schwerpunkt liegt auf dem Lebenszyklus von Cloud-Diensten, nicht nur auf der Auswahl des Anbieters.
- Erwartet eine explizite Berücksichtigung der gemeinsamen Verantwortung und der Möglichkeit mehrerer Mieter.
- Im Fokus steht die Frage, wie Sie Cloud-Dienste verlassen oder ersetzen können, ohne die Kontrolle über Ihre Daten zu verlieren.
Diese Schwerpunkte spiegeln sich in den Fachkommentaren zu A.5.23 und den Cloud-Kontrollmappings wider, die Lebenszyklus, geteilte Verantwortung und Exit-Planung im Gegensatz zur traditionellen Lieferantenüberwachung hervorheben. Für Managed Service Provider (MSPs) ergänzt A.5.23 zudem Zugriffskontrolle, Asset-Management, Incident-Management und andere Kontrollen gemäß Anhang A. Ziel ist es nicht, Arbeit zu duplizieren, sondern sicherzustellen, dass Ihre bestehenden Kontrollen die Cloud und Ihre Servicebereitstellung vollständig berücksichtigen.
Durch die klare Verknüpfung dieser Kontrollfunktion mit Ihrem ISMS erkennen die Prüfer, dass die Cloud-Governance integriert ist und nicht als separater Bereich behandelt wird.
Dokumentarten, die Prüfer erwarten
Die von Prüfern gemäß A.5.23 erwarteten Dokumenttypen belegen, dass Ihre Cloud-Richtlinien, -Prozesse und -Verantwortlichkeiten real, konsistent und angewendet werden. Sie erwarten eine kleine, zusammenhängende Sammlung von Artefakten anstelle einer Vielzahl lose verknüpfter Dokumente. Leitfäden zur Implementierung von Cloud-Governance gemäß A.5.23 nennen häufig eine Kombination aus Richtlinien, Serviceregistern, Risikobewertungen und Lebenszyklusdokumenten als zentrale Nachweise, die Prüfer erwarten.
Im Rahmen einer Prüfung werden Sie wahrscheinlich nach Nachweisen wie den folgenden gefragt:
- Eine Cloud-Nutzungs- oder Cloud-Sicherheitsrichtlinie.
- Ein Verzeichnis der intern und im Auftrag von Kunden genutzten Cloud-Dienste.
- Cloudspezifische Risikoanalysen und Behandlungspläne.
- Sorgfaltsprüfungsunterlagen für wichtige Cloud-Anbieter und Unterauftragnehmer.
- Matrizen zur gemeinsamen Verantwortung oder gleichwertige Rollendefinitionen.
- Verfahren oder Leitfäden für die Aufnahme und Beendigung von Diensten.
- Beispiele von Protokollen, Rezensionen oder Tickets, die zeigen, wie diese Prozesse ablaufen.
Wenn diese Informationen schnell gefunden werden können und ein schlüssiges Bild zeichnen, wirkt A.5.23 kontrolliert und angemessen. Sind sie hingegen nur in verstreuten Dokumenten oder im Gedächtnis der Mitarbeiter vorhanden, wird die Kontrolle zur Quelle von Nachforschungen und zusätzlicher Arbeit. Die Nutzung einer ISMS-Plattform wie ISMS.online, um diese Artefakte zentral zu speichern, erleichtert es erheblich, die praktische Cloud-Verwaltung zu veranschaulichen.
ISO 27001 leicht gemacht
Ein Vorsprung von 81 % vom ersten Tag an
Wir haben die harte Arbeit für Sie erledigt und Ihnen vom Moment Ihrer Anmeldung an einen Vorsprung von 81 % verschafft. Sie müssen nur noch die Lücken ausfüllen.
Das Doppelleben des Managed Service Providers: Cloud-Kunde und -Anbieter
Ihr Managed Service Provider (MSP) hat gemäß A.5.23 eine Doppelrolle: Sie sind sowohl ein anspruchsvoller Cloud-Kunde von Upstream-Anbietern als auch ein verantwortlicher Cloud-Anbieter für Ihre eigenen Kunden. Die Regelung verlangt von Ihnen, dass Sie beide Rollen verstehen, dokumentieren und steuern, einschließlich deren Wechselwirkungen entlang der gemeinsamen Verantwortungskette.
Als Cloud-Kunde verlassen Sie sich auf Hyperscale-Plattformen und SaaS-Tools, um Ihr Geschäft zu betreiben und Services bereitzustellen. Als Cloud-Anbieter sehen Ihre Kunden Sie als Verantwortlichen für Sicherheit, Kontinuität und Support, selbst wenn die zugrundeliegende Technologie einem anderen Anbieter gehört. A.5.23 führt diese beiden Perspektiven zusammen und fordert Sie auf, sie kohärent zu managen.
Ihre vorgelagerten und nachgelagerten Rollen verstehen
Das Verständnis Ihrer vorgelagerten und nachgelagerten Rollen bedeutet, zu erkennen, dass Sie Cloud-Dienste als interner Kunde nutzen und gleichzeitig als Anbieter cloudbasierte Dienste an Ihre eigenen Kunden verkaufen. A.5.23 erwartet von Ihnen, dass Sie beide Perspektiven im Blick behalten und sicherstellen, dass sie sich gegenseitig unterstützen und nicht widersprechen.
Als Cloud-KundeSie nutzen Dienste wie Produktivitätssuiten, Ticketsysteme, Überwachungsplattformen und öffentliche Cloud-Infrastruktur. Sie sind verantwortlich für die Konfiguration dieser Dienste, die Zugriffsrechte und deren Überwachung. Im Falle von Vorfällen oder behördlichen Anfragen hängt Ihre Fähigkeit, die Kontrolle nachzuweisen, davon ab, wie gut Sie diese Nutzung verwalten und wie klar sie in Ihre ISMS-Prozesse, wie z. B. Risikobewertung und Änderungsmanagement, eingebunden ist.
Als Cloud-Anbieter oder ManagerSie entwickeln, liefern und betreuen Services, die auf diesen Plattformen laufen. Möglicherweise verkaufen Sie Managed Infrastructure, Backup-Lösungen, SOC-Services, Anwendungshosting oder Sicherheitsdienste. Ihre Kunden sehen Sie als verantwortlichen Partner, selbst wenn Sie auf einer Cloud eines Drittanbieters aufbauen. Sie unterscheiden nicht zwischen Ihrem Service und dem Hyperscaler, auf dem er läuft; sie gehen davon aus, dass Sie sich um alle Details gekümmert haben.
Ein häufiges Problem entsteht, wenn Sie Kunden Zusagen zur Protokollaufbewahrung oder zum Backup-Verlauf machen, ein vorgelagertes Tool aber weiterhin mit seiner standardmäßigen, deutlich kürzeren Konfiguration läuft. In diesem Fall ist Ihre nachgelagerte Zusage Ihrer vorgelagerten Konfiguration voraus, und A.5.23 deckt diese Diskrepanz auf.
Aufbau einer Sichtweise auf Doppelrollenverantwortung
Die Schaffung eines Modells mit doppelter Verantwortlichkeit bedeutet, die Zuständigkeiten von Anbietern, Ihren MSP-Teams und Kunden in einem einheitlichen, konsistenten Modell abzubilden. Dadurch erhalten Ihr CISO, der Leiter der Servicebereitstellung und Ihre Account Manager ein gemeinsames Bild davon, wer in der gesamten Wertschöpfungskette wofür verantwortlich ist.
Eine praktische Methode hierfür ist die Erstellung einer Matrix mit doppelten Verantwortlichkeiten. Für die wichtigsten Kontrollbereiche – Identitäts- und Zugriffsmanagement, Konfiguration, Protokollierung, Datensicherung, Reaktion auf Sicherheitsvorfälle, Änderungskontrolle, Datenschutz – listen Sie Folgendes auf:
- Wozu sich Ihre vorgelagerten Lieferanten verpflichten.
- Was Sie als Managed Service Provider (MSP) gegenüber dem Upstream-Anbieter zusagen (z. B. die Aktivierung bestimmter Funktionen, das Management bestimmter Risiken).
- Was Sie in Ihren Kundenverträgen und SLAs zusichern.
- Was Sie von Ihren Kunden erwarten, dass sie selbst tun.
Diese Übung deckt häufig Diskrepanzen auf: Verpflichtungen gegenüber Kunden ohne entsprechende Unterstützung durch vorgelagerte Systeme oder Annahmen über Anbieter, die nicht vertraglich belegt sind. Sie zeigt auch, wo strengere Kontrollen, klarere Formulierungen oder andere Servicekonzepte erforderlich sind. Durch die Integration dieser Ansicht in eine ISMS-Plattform wie ISMS.online erhalten Teams eine zentrale Informationsquelle zu ihren gemeinsamen Verantwortlichkeiten.
Verantwortlichkeitskarten in die tägliche Praxis umsetzen
Die Umsetzung von Verantwortlichkeitslandkarten in die tägliche Praxis bedeutet, sicherzustellen, dass jeder, der mit Cloud-Diensten arbeitet, seine Zuständigkeiten kennt und schnell handeln kann. Die Karten sollten das Verhalten in Vertrieb, Entwicklung, Support und Kundenbetreuung prägen.
Verantwortungskarten in die Realität umzusetzen bedeutet:
- Sie werden genutzt, um Vertriebs- und Kundenbetreuungsteams zu briefen, damit diese keine übertriebenen Versprechungen machen oder Zusagen improvisieren.
- Die Abstimmung von Runbooks und Playbooks auf die von Ihnen definierten Verantwortlichkeiten sorgt für ein einheitliches Vorgehen der technischen Teams.
- Schulung von Ingenieuren hinsichtlich der Art und Weise und des Zeitpunkts der Ausübung ihrer Rechte gegenüber Kundenmietern, einschließlich zeitgebundener Erhöhungen und Genehmigungen.
- Vereinbarung darüber, wie Vorfälle mit Beteiligung von Anbietern gegenüber Kunden kommuniziert und gehandhabt werden, einschließlich Eskalationswege.
Wenn Ihre Sichtweise auf die Doppelrolle auf diese Weise eingebettet ist, hört A.5.23 auf, eine abstrakte Anforderung zu sein, und wird zu einer natürlichen Perspektive auf die Arbeitsweise Ihres MSP in der Cloud. Sie erhalten dadurch auch eine klare Darstellung für Vorstände und Kunden, die Ihren Platz in der gemeinsamen Verantwortungskette verstehen möchten.
Ein praktisches Modell der geteilten Verantwortung für MSP-Cloud-Plattformen
Ein praktisches Modell geteilter Verantwortung für MSP-Cloud-Plattformen besteht aus übersichtlichen Matrizen, die die Zuständigkeiten von Anbieter, MSP und Kunde für jeden Dienst klar definieren. Gemäß A.5.23 machen diese Matrizen das Konzept der geteilten Verantwortung praktikabel, verständlich und überprüfbar.
Die meisten Public-Cloud-Anbieter beschreiben eine einfache Aufteilung: Sie sichern die Infrastruktur, Sie sichern die darauf basierenden Anwendungen. Dieses Muster ist in den Erläuterungen zum Modell der geteilten Verantwortung großer Anbieter wie AWS, Azure und Google Cloud dokumentiert und hat sich als gängige Grundlage für die Gestaltung von Cloud-Kontrollen etabliert. Für Managed Service Provider (MSPs) ist dies jedoch nur der Ausgangspunkt. Sie benötigen Modelle, die die spezifischen Plattformen, die angebotenen Services und die Arbeitsweise Ihrer Teams widerspiegeln.
Über die allgemeine „gemeinsame Verantwortung“ hinausgehen
Über allgemeine Bezeichnungen wie „gemeinsame Verantwortung“ hinauszugehen bedeutet, vage Aussagen durch konkrete, benannte Aufgaben zu ersetzen, die Einzelpersonen und Teams verstehen. A.5.23 honoriert diese Klarheit, da Prüfer und Kunden erkennen können, wer für tatsächliche Handlungen und nicht nur für abstrakte Konzepte verantwortlich ist.
Allgemeine Bezeichnungen für „gemeinsame Verantwortung“ verschleiern reale Risiken. Um diese zu überwinden, müssen Sie Folgendes berücksichtigen:
- Die von Ihnen verwendeten spezifischen Plattformen (z. B. Infrastructure-as-a-Service, Software-as-a-Service, Managed Security Tools).
- Die konkreten Dienstleistungen, die Sie anbieten (z. B. Managed Backup, Managed SOC, Managed Modern Workplace).
- Die tatsächliche Arbeitsweise Ihres Teams (z. B. Einsatz von Automatisierung, zentralisierte Überwachung, Wartungsfenster).
Für jede Kombination aus Plattform und Dienst sollte eine Verantwortlichkeitsmatrix die Zuständigkeiten so detailliert definieren, dass die Beteiligten handeln können. Das bedeutet, festzulegen, wer die Protokollierung aktiviert, wer Wiederherstellungen testet, wer Auskunftsersuchen bearbeitet und wer die Kommunikation bei Vorfällen leitet, anstatt lediglich „gemeinsam“ anzugeben.
Dieser zusätzliche Schritt unterstützt auch verwandte Kontrollmechanismen wie das Incident-Management und die Betriebssicherheit, da jeder sehen kann, wo seine Rolle beginnt und endet.
Strukturierung Ihrer Verantwortlichkeitsmatrizen
Eine gut strukturierte Verantwortlichkeitsmatrix zeichnet sich durch ein einheitliches Layout aus, das die Denkweise Ihrer Ingenieure und Servicemanager widerspiegelt und gleichzeitig detailliert genug ist, um konkrete Maßnahmen zu steuern. Eine einfache, serviceübergreifende Struktur vereinfacht Schulungen und Überprüfungen erheblich.
Eine praktische Matrix für jeden Dienst könnte Bereiche wie die folgenden abdecken:
- Identitäts- und Zugriffsverwaltung: – der Benutzerkonten erstellt und löscht, Rollen verwaltet und Zugriffsrechte überprüft.
- Konfiguration und Härtung: – der die Baselines anwendet, Sicherheitsupdates durchführt und Konfigurationsabweichungen überprüft.
- Protokollierung und Überwachung: – der die Protokollierung aktiviert, speichert, Warnmeldungen prüft und auf Vorfälle reagiert.
- Sicherung und Wiederherstellung: – der die Datensicherung konfiguriert, die Wiederherstellung testet und die Wiederherstellungsziele überprüft.
- Datenschutz und Privatsphäre: – der Daten klassifiziert, Aufbewahrungsregeln anwendet und die Rechte der betroffenen Personen verwaltet.
- Kontinuität und Ausgang: – wer für Resilienzmuster, Failover und Datenexport oder -löschung am Ende eines Vertrags verantwortlich ist.
In jeder Zeile der Matrix sollten die Verantwortlichkeiten klar gekennzeichnet sein: Anbieter, Managed Service Provider (MSP), Kunde oder geteilte Verantwortlichkeiten mit zugewiesenen Aufgaben. Zudem sollte sichergestellt werden, dass jede Matrix versionskontrolliert und bei Änderungen an Diensten, Plattformen oder Verträgen überprüft wird, um ihre Aktualität zu gewährleisten.
Ein vereinfachtes Beispiel für verwaltete Datensicherung auf einer öffentlichen Cloud-Plattform könnte wie folgt aussehen:
| Domain | Verantwortlichkeiten des Anbieters / Managed Service Providers / Kunden |
|---|---|
| Sicherungskonfiguration | Der Anbieter bietet die Funktion an; der Managed Service Provider (MSP) konfiguriert die Richtlinien; der Kunde prüft den Umfang. |
| Wiederherstellungstests | Der Managed Service Provider (MSP) führt regelmäßige Testwiederherstellungen durch; der Kunde überprüft die Vollständigkeit der Daten. |
| Aufbewahrungseinstellungen | Der Anbieter setzt die Limits durch; der Managed Service Provider (MSP) legt die Aufbewahrungsfrist fest; der Kunde genehmigt die Richtlinie. |
Diese Matrizen können Sie dann für Kunden, die dasselbe Service-Muster nutzen, wiederverwenden und nur dort anpassen, wo dies wirklich notwendig ist.
Verknüpfung des Modells mit Ihrem ISMS und Ihren Kunden
Die Verknüpfung des Modells der geteilten Verantwortung mit Ihrem ISMS und Ihren Kunden stellt sicher, dass es Entscheidungen vom Vorverkauf bis zum Offboarding beeinflusst, anstatt isoliert zu bleiben. Je stärker die Vernetzung, desto nützlicher und glaubwürdiger wird es.
Sobald Sie diese Modelle definiert haben, verbinden Sie sie:
- Intern, indem in Richtlinien, Verfahrensanweisungen, Betriebshandbüchern und Schulungen darauf verwiesen wird.
- Im kommerziellen Bereich erreichen Sie dies, indem Sie Ihre Leistungsbeschreibungen, Angebote und SLAs an den von Ihnen festgelegten Verantwortlichkeiten ausrichten.
- Indem man Kunden während des Onboardings vereinfachte Ansichten oder Diagramme präsentiert, werden die Erwartungen vom ersten Tag an klar definiert.
Wenn ein Auditor fragt, wie Sie die geteilte Verantwortung gemäß A.5.23 handhaben, können Sie auf diese Matrizen, deren Verknüpfung mit Ihrem ISMS und Beispiele verweisen, wie sie konkrete Entscheidungen beeinflusst haben. Fragt ein Kunde wie ein CISO oder IT-Leiter: „Wer ist für diese Kontrolle verantwortlich?“, haben Sie eine unternehmensweit einheitliche Antwort parat. Eine zentrale Plattform wie ISMS.online kann diese Matrizen zusammen mit Risiken, Kontrollen und Verträgen verwalten, sodass sie einfach zu pflegen und nachzuweisen sind.
Befreien Sie sich von einem Berg an Tabellenkalkulationen
Integrieren, erweitern und skalieren Sie Ihre Compliance, ohne dass es zu Problemen kommt. IO gibt Ihnen die Widerstandsfähigkeit und das Vertrauen, um sicher zu wachsen.
Gestaltung von Cloud-Service-Lebenszyklusprozessen für A.5.23
Die Lebenszyklusprozesse von Cloud-Diensten beweisen, dass A.5.23 mehr als nur eine Grundsatzerklärung ist: Sie zeigen, dass Sie Cloud-Dienste kontrolliert und wiederholbar auswählen, betreiben und außer Betrieb nehmen. Für Managed Service Provider (MSPs) besteht das Ziel darin, die Schritte des Cloud-Lebenszyklus in die bestehenden ISMS-Prozesse zu integrieren und keine separate Bürokratie zu schaffen.
A.5.23 verlangt den Nachweis, dass Cloud-Dienste definierte Schritte von der Idee bis zur Beendigung durchlaufen, wobei Sicherheit und geteilte Verantwortung in jeder Phase berücksichtigt werden. Dies deckt sich weitgehend mit der Formulierung der Kontrollrichtlinie zur „Beschaffung, Nutzung, Verwaltung und Beendigung“ von Cloud-Diensten im Einklang mit den Informationssicherheitsanforderungen sowie mit gängigen Lebenszyklusmodellen aus ISO 27001 und Cloud-Standards wie dem Kommentar zu ISO 27001 A.5.23. Dies steht in direktem Einklang mit den ISO-27001-Klauseln zu Risikobehandlung, operativer Planung, Änderungsmanagement und Lieferantenmanagement.
Definition eines Cloud-Service-Lebenszyklus, dem die Nutzer folgen können
Die Definition eines nachvollziehbaren Cloud-Service-Lebenszyklus bedeutet, A.5.23 in wenige, wiederholbare Phasen zu unterteilen, die sich in Ihre bestehenden Arbeitsabläufe integrieren lassen. Der Lebenszyklus sollte so einfach sein, dass Produktverantwortliche, Entwickler und Einkaufsteams ihn ohne Spezialkenntnisse anwenden können. Zwei Drittel der Unternehmen in der ISMS.online-Studie „State of Information Security 2025“ geben an, dass die Geschwindigkeit und das Ausmaß regulatorischer Änderungen die Einhaltung der Vorschriften erschweren.
Ein typischer Lebenszyklus für bedeutende Cloud-Dienste könnte beispielsweise folgende Phasen umfassen:
- Idee und Bewertung – Jemand schlägt einen neuen Cloud-Dienst oder eine neue Nutzungsmöglichkeit für einen bestehenden Dienst vor. Sie prüfen diesen auf geschäftlichen Nutzen, Sicherheit und Compliance-Konformität.
- Auswahl und Sorgfaltsprüfung – Sie prüfen Zertifizierungen, Datenspeicherorte, Vertragsbedingungen und Supportmöglichkeiten und vergleichen die Optionen.
- Design und Onboarding – Sie entscheiden, wie der Dienst konfiguriert, integriert und überwacht wird und wem er gehört.
- Betrieb und Änderung – Sie betreiben den Dienst, überprüfen Protokolle und Metriken, bearbeiten Änderungen und Vorfälle und sorgen dafür, dass die Konfiguration Ihren Standards entspricht.
- Überprüfung und Erneuerung – Sie überprüfen regelmäßig, ob der Service noch den Bedürfnissen entspricht, ob die Risiken akzeptabel sind und ob Verbesserungen erforderlich sind.
- Ausstieg oder Ersatz – Wenn Sie den Dienst abschalten oder ersetzen, sind Sie für den Datenexport, die Datenlöschung und die Kundenkommunikation verantwortlich.
Diese Phasen ermöglichen wiederholbare statt ad-hoc-Entscheidungen für Cloud-Dienste. Definieren Sie für jede Phase die minimal erforderlichen Aktionen, Genehmigungen und Dokumentationen. Dazu gehören beispielsweise Risikobewertungen, Checklisten für die Sorgfaltsprüfung, Konfigurationsbaselines, Änderungsprotokolle und Bestätigungen für den Ausstieg – alles abgestimmt auf Ihr zentrales ISMS.
Um dies noch benutzerfreundlicher zu gestalten, können Sie den Lebenszyklus als eine einfache Abfolge von Schritten darstellen, die Teams befolgen können.
Schritt 1: Die Idee erfassen und visualisieren
Erfassen und prüfen Sie jede Idee für einen Cloud-Service, bevor sich jemand anmeldet oder ihn integriert, damit Sie Nutzen, Risiko und Übereinstimmung mit Ihrem ISMS abwägen können.
Dokumentieren Sie den vorgeschlagenen Cloud-Dienst, seinen Zweck und die anfänglichen Risiken, bevor sich jemand anmeldet oder ihn integriert.
Schritt 2: Sorgfältige Prüfung und Planung abschließen
Eine gründliche Due-Diligence-Prüfung und Planung vor der Einführung eines Cloud-Dienstes ist unerlässlich, damit Konfiguration, Überwachung und Verantwortlichkeiten klar definiert und nicht improvisiert werden.
Prüfen Sie Zusicherungen, Verträge und Datenverarbeitung, und definieren Sie anschließend Konfiguration, Überwachung und gemeinsame Verantwortlichkeiten.
Schritt 3: An Bord gehen, bedienen und Ausstieg planen
Einbindung, Betrieb und Ausstiegsplanung erfolgen strukturiert, sodass Sie nachweisen können, dass der Dienst während seiner gesamten Lebensdauer kontrolliert wird.
Integrieren Sie den Dienst gemäß Ihren Vorgaben, überwachen Sie ihn und dokumentieren Sie, wie Sie ihn sicher verlassen oder ersetzen werden.
Einbettung von Lebenszyklussteuerungen in Ihre Arbeitsweise
Die Integration von Lebenszykluskontrollen in Ihre Arbeitsabläufe bedeutet, sie in die Prozesse und Tools einzubinden, die Ihre Teams bereits nutzen. Wenn der Lebenszyklus der Standardweg ist, lässt sich die Einhaltung von A.5.23 deutlich einfacher gewährleisten.
Halten:
- Die Abstimmung erfolgt auf die Beschaffungsprozesse, sodass Verträge erst nach Prüfung der Sicherheits-, Datenschutz- und Betriebsanforderungen unterzeichnet werden können.
- Verknüpfen Sie es mit Ihrem Service-Einführungsprozess, sodass neue Angebote oder größere Änderungen die Phasen des Cloud-Lebenszyklus durchlaufen.
- Integrieren Sie Lebenszyklusaufgaben in Ihre Ticket- und Änderungssysteme, nicht nur in separate Cloud-Dokumente.
Durch die Verknüpfung der einzelnen Schritte des Lebenszyklus mit etablierten Prozessen wie Änderungsmanagement und Lieferantenmanagement werden Reibungsverluste reduziert und die Akzeptanz erhöht. Die Mitarbeiter folgen dem Lebenszyklus, weil er den Weg des geringsten Widerstands darstellt, nicht weil sie aufgefordert wurden, eine weitere Richtlinie zu lesen.
Aufbereitung von Nachweisen aus dem Lebenszyklus für Audits
Um die Nachweise über den Lebenszyklus für eine Auditierung vorzubereiten, müssen einige vollständige Beispiele vorgelegt werden können, die die Anwendung derselben Logik auf verschiedene Dienstleistungen veranschaulichen. Auditoren wollen Muster erkennen, keine Einzelfälle.
Versuchen Sie, für jedes Beispiel Folgendes zu demonstrieren:
- Warum dieser Service gewählt wurde, basierend auf Risiko und Anforderungen.
- Wie Verantwortlichkeiten anhand Ihres Modells der geteilten Verantwortung definiert wurden.
- Welche Kontrollmechanismen wurden beim Onboarding implementiert, einschließlich Baselines und Zugriffsmuster?
- Wie der Service überwacht und überprüft wird, mit Beispielen für Änderungen oder Verbesserungen.
- Wie Daten und Zugriffe beim Verlassen des Systems gehandhabt werden, auch wenn dieses Verlassen des Systems noch nicht stattgefunden hat.
Wenn Sie diese Nachweise ohne großen Aufwand erbringen können, wird sich A.5.23 wie ein integraler Bestandteil des Systems anfühlen und nicht wie ein nachträglich hinzugefügtes Element. Ein System wie ISMS.online kann dabei helfen, indem es Dienste, Risiken, Verantwortlichkeiten, Änderungen und Austrittsdatensätze zentral verknüpft, sodass Sie nicht jedes Mal alle Informationen von Grund auf neu zusammentragen müssen.
Technische Kontrollen für Mandantensysteme: Implementierung einheitlicher Schutzmaßnahmen
Multi-Tenant-fähige technische Kontrollen sind die praktische Umsetzung Ihrer A.5.23-Cloud-Governance-Entscheidungen im täglichen Entwicklungsalltag. Sie übersetzen Modelle geteilter Verantwortung und Lebenszyklusprozesse in konkrete Baselines, die viele Kunden gleichzeitig schützen.
Bei der Verwaltung mehrerer Mandanten auf gemeinsamen Plattformen erwartet A.5.23 einen proaktiven, standardisierten Ansatz für Identität, Konfiguration, Protokollierung, Datensicherung und Isolation. So können Sie nachweisen, dass Ihre technischen Sicherheitsvorkehrungen den übernommenen Verantwortlichkeiten und den gegenüber Ihren Kunden eingegangenen Verpflichtungen entsprechen.
Warum die Baselines für Mehrnutzerumgebungen wichtig sind
Multi-Tenant-Baselines sind wichtig, da kleine Schwachstellen schwerwiegende Folgen für viele Kunden gleichzeitig haben können. Eine zu freizügige Rolle, ein versäumtes Update oder ein ungetestetes Backup können Ihre gesamte Cloud-Sicherheitsarchitektur gefährden. Cloud-Sicherheitsframeworks und nationale Leitlinien, wie beispielsweise Risikoanalysen für Multi-Tenant-Umgebungen in Kontrollkatalogen und Cloud-Sicherheitssammlungen nationaler Cybersicherheitszentren, heben Identitätsmanagement, Patching und Backup immer wieder als systemische Risikobereiche hervor, die sich bei einem Ausfall schnell auf alle Mandanten ausweiten können. Die Mehrheit der Organisationen in der ISMS.online-Umfrage 2025 gab an, im vergangenen Jahr von mindestens einem Sicherheitsvorfall im Zusammenhang mit Drittanbietern oder Anbietern betroffen gewesen zu sein.
In einer MSP-Umgebung kann ein einziges überprivilegiertes Administratorkonto, eine nicht protokollierte kritische Aktion oder ein ungetesteter Backup-Prozess Dutzende von Kunden in einem einzigen Vorfall betreffen. Gemäß A.5.23 müssen Sie diese Risiken systematisch und nicht reaktiv managen und nachweisen können, wie Ihre Kontrollmaßnahmen für die von Ihnen genutzten und bereitgestellten Cloud-Dienste gelten. Einheitliche Baselines definieren die Mindestkontrollen für jeden Kunden, der eine bestimmte Plattform oder einen bestimmten Dienst nutzt, und geben Prüfern und Kunden die Gewissheit, dass Sie die Sicherheit nicht jedes Mal neu erfinden müssen.
Aus Sicht der Führungskräfte bieten diese Baselines auch eine Art Garantie: Sie können Vorständen und Kunden zeigen, dass die technischen Sicherheitsvorkehrungen mit den bereits getroffenen Governance- und Vertragsentscheidungen übereinstimmen.
Technische Kernthemen zur Standardisierung
Zu den zentralen technischen Themen, die standardisiert werden sollen, gehören die Bereiche, in denen einheitliche Sicherheitsvorkehrungen die Wahrscheinlichkeit von mandantenübergreifenden Problemen verringern und den Ingenieuren auf jeder Plattform einen klaren Ausgangspunkt bieten.
Die Details variieren zwar je nach Plattform, doch die meisten Managed Service Provider (MSPs) profitieren davon, zumindest die folgenden Aspekte zu standardisieren. Dadurch wird es für Ihre Sicherheitschefs, Betriebsleiter und Entwicklungsteams einfacher, an einem Strang zu ziehen.
- Identitäts- und Zugriffsverwaltung: – rollenbasierte Zugriffskontrolle, Prinzip der minimalen Berechtigungen, Funktionstrennung, zeitlich begrenzte Eskalation bei risikoreichen Aktionen und robustes Offboarding.
- Konfiguration und Härtung: – Basisvorlagen für Netzwerksegmentierung, Verschlüsselung, Endpunktschutz, Patching-Richtlinien und Ressourcenbenennung.
- Protokollierung und Überwachung: – konsistente Protokollierungskonfigurationen, zentrale Protokollaggregation, definierte Alarmregeln und dokumentierte Reaktions-Playbooks.
- Sicherung und Wiederherstellung: – Standardmäßige Backup-Zeitpläne, Aufbewahrung, Verschlüsselung, Wiederherstellungstestroutinen und Dokumentation der Wiederherstellungsziele des Kunden.
- Isolation und Mietverhältnisse: – Muster zur Trennung von Mandanten auf Netzwerk-, Identitäts- und Datenebene sowie Prüfungen zur Sicherstellung, dass die Isolation auch tatsächlich eingehalten wird.
Jede Baseline sollte klar darlegen, was der Anbieter liefert, was Sie konfigurieren und warten und welche Aufgaben Sie von den Kunden erwarten. Zusammen bilden diese Punkte das technische Fundament Ihrer A.5.23-Implementierung.
Nachdem Sie diese Themen definiert haben, besteht der nächste Schritt darin, sie dort einzubetten, wo die Ingenieure arbeiten: Vorlagen, Skripte, Infrastruktur als Code, zentrale Verwaltungstools und dokumentierte Playbooks.
Anbindung technischer Steuerungen an A.5.23 und darüber hinaus
Die Verknüpfung technischer Kontrollen mit A.5.23 und verwandten Kontrollen stellt sicher, dass Ihre Governance, rechtlichen Verpflichtungen und technischen Vorgehensweisen sich gegenseitig unterstützen, anstatt sich zu behindern. Diese Abstimmung erleichtert die Erklärung und Verteidigung Ihres Gesamtsystems.
Das bedeutet:
- Ordnen Sie jedes Basiselement Ihren Matrizen für die gemeinsame Verantwortung zu, sodass die technischen Kontrollen den von Ihnen zugewiesenen Verantwortlichkeiten entsprechen.
- Es ist wichtig, dass Baselines Teil des Lebenszyklus Ihres Cloud-Services sind, sodass sie beim Onboarding angewendet und bei Überprüfungen erneut überprüft werden.
- Verknüpfung von Themen wie Zugriff, Protokollierung und Datensicherung mit den in Anhang A geregelten Kontrollen zu Zugriffskontrolle, Betriebssicherheit, Vorfallmanagement und Geschäftskontinuität.
Diese Abstimmung sorgt für ein kohärentes Gesamtkontrollsystem. Das bedeutet auch, dass Sie bei Audits oder Kundenbesprechungen, in denen A.5.23 thematisiert wird, nicht nur Richtlinien, sondern auch funktionierende technische Schutzmaßnahmen vorweisen können, die Ihrem Governance-Modell entsprechen. Wenn Sie diese Baselines in einem zentralen System wie ISMS.online verwalten, können Sie die Verbindung von einem Cloud-Dienst über dessen Risikobewertung bis hin zu den technischen Kontrollen mit wenigen Klicks demonstrieren.
Verwalten Sie Ihre gesamte Compliance an einem Ort
ISMS.online unterstützt über 100 Standards und Vorschriften und bietet Ihnen eine einzige Plattform für alle Ihre Compliance-Anforderungen.
Verträge, SLAs und Unterauftragnehmerklauseln, die einer Prüfung standhalten
Verträge, SLAs und Unterauftragnehmerklauseln sind der Punkt, an dem Ihre Entscheidungen zur Cloud-Governance gemäß A.5.23 rechtsverbindlich werden. Die Kontrollbehörde erwartet, dass Ihre Vereinbarungen mit Anbietern, Unterauftragnehmern und Kunden die von Ihnen getroffenen Entscheidungen zur gemeinsamen Verantwortung, zum Lebenszyklus und zu den technischen Aspekten widerspiegeln und nicht im Widerspruch dazu stehen.
A.5.23 schreibt keine bestimmte Vertragsform vor, jedoch prüfen Prüfer und Kunden, ob Ihre rechtlichen Verpflichtungen mit der technischen Umsetzung übereinstimmen. Die prinzipienbasierte Leitlinie zu A.5.23 und verwandten Cloud-Kontrollen betont regelmäßig die Wichtigkeit der Abstimmung vertraglicher Zusagen mit tatsächlichen Kontrollen und Modellen geteilter Verantwortung, da Diskrepanzen häufig zu Beanstandungen und Streitigkeiten führen.
A.5.23 schreibt keine bestimmte Vertragsform vor, jedoch prüfen Wirtschaftsprüfer und Kunden, ob Ihre rechtlichen Verpflichtungen mit der technischen Realität übereinstimmen. Andernfalls wird die Kontrolle zu einem Risikofaktor und kann zu Beanstandungen führen.
Die explizite Festlegung von Verantwortlichkeiten und Erwartungen in Verträgen und Service-Level-Agreements (SLAs) bedeutet, Ihre internen Verantwortlichkeitsmatrizen in eine klare und eindeutige Sprache zu übersetzen, die von Rechtsabteilung, Vertrieb und Kunden gleichermaßen verstanden wird. A.5.23 lässt sich deutlich leichter nachweisen, wenn diese Dokumente Ihrer tatsächlichen Arbeitsweise entsprechen.
Verträge und SLAs sind häufig der Ort, an dem Missverständnisse zu Streitigkeiten führen, insbesondere bei Cloud-Diensten. Um A.5.23 zu unterstützen, sollten Ihre Vereinbarungen Folgendes beinhalten:
- Beschreiben Sie die Dienstleistungen klar und deutlich, einschließlich jeglicher Abhängigkeit von Cloud-Plattformen Dritter.
- Legen Sie die Verpflichtungen zum Schutz der Daten und Sicherheit so detailliert dar, dass sie sinnvoll sind, ohne dabei Versprechungen zu machen, die Sie nicht einhalten können.
- Erläutern Sie, wer für welche Aspekte der Vorfallserkennung, -reaktion und -kommunikation verantwortlich ist.
- Klären Sie, was am Ende des Vertrags geschieht, einschließlich Datenexport oder -löschung und jeglicher Unterstützung beim Übergang.
Richten Sie diese Formulierungen nach Möglichkeit direkt an den Bereichen Ihrer Verantwortlichkeitsmatrizen aus, um eine klare Verbindung zwischen Modell und Formulierung herzustellen. Dies trägt auch dazu bei, die entsprechenden Anforderungen der ISO 27001 hinsichtlich rechtlicher, regulatorischer und vertraglicher Verpflichtungen zu erfüllen.
Sobald die Verantwortlichkeiten sowohl in den Matrixstrukturen als auch in den Verträgen klar definiert sind, haben Ihre Teams weniger Spielraum für widersprüchliche Interpretationen, wenn es zu Zwischenfällen oder komplexen Kundenanforderungen kommt.
In Einklang mit den technischen Gegebenheiten und den rechtlichen Verpflichtungen
Die Abstimmung der technischen Gegebenheiten mit den rechtlichen Verpflichtungen bedeutet, zu prüfen, ob die vertraglichen Zusagen mit den vorhandenen Tools, Prozessen und Standards umsetzbar sind. Dadurch verringert sich das Risiko, dass Kunden oder Auditoren Diskrepanzen zwischen Vertrag und Praxis feststellen. Laut der ISMS.online-Umfrage von 2025 gaben nur etwa 29 % der Unternehmen an, keine Bußgelder wegen Datenschutzverstößen erhalten zu haben. Die Mehrheit berichtete von Bußgeldern, einige sahen sich sogar mit Strafen von über 250,000 £ konfrontiert.
Rechtliche Klauseln entfernen sich im Laufe der Zeit leicht von der technischen Realität. Eine Vorlage verspricht beispielsweise eine sehr schnelle Benachrichtigung bei Vorfällen, doch Ihre Überwachungs- und Eskalationsprozesse erschweren dies in der Praxis. Oder eine Service-Level-Vereinbarung (SLA) legt Wiederherstellungsziele fest, die nicht mit den Backup-Konzepten übereinstimmen.
Um dies zu vermeiden, sollten Sie Ihre Verträge und SLAs gemeinsam von den Abteilungen Recht, Sicherheit, Betrieb und Kundenbetreuung prüfen lassen. Fragen Sie:
- Können wir die von uns eingegangenen Verpflichtungen angesichts unserer derzeitigen Überwachungs-, Support- und technischen Rahmenbedingungen dauerhaft erfüllen?
- Gibt es Bereiche, in denen wir in bessere Kontrollmechanismen oder Werkzeuge investieren müssen, um diese einzuhalten?
- Gibt es Verpflichtungen, die stattdessen beim Kunden oder Anbieter liegen und als solche kommuniziert werden sollten?
Wenn Ihre rechtlichen Verpflichtungen und technischen Möglichkeiten übereinstimmen, lässt sich A.5.23 leichter nachweisen und ist im Alltag weniger risikoreich. Zudem verringern Sie das Risiko von Überraschungen für Kunden, Aufsichtsbehörden oder Wirtschaftsprüfer, die Ihre Zusagen genauer unter die Lupe nehmen.
Governance in Ihre Vereinbarungen einbeziehen
Die Integration von Governance-Prinzipien in Ihre Verträge bedeutet, die Vertragssprache so zu gestalten, dass sie das gewünschte Verhalten von Anbietern und Kunden unterstreicht und nicht nur Leistungen und Preise dokumentiert. Dadurch werden gemeinsame Verantwortung und die Berücksichtigung des gesamten Lebenszyklus zu einem festen Bestandteil der täglichen Geschäftsbeziehung.
Das könnte beinhalten:
- Recht auf Erhalt oder Einsicht in die Zusicherungen des Anbieters, wie z. B. aktualisierte Zertifizierungen oder unabhängige Berichte.
- Erwartungen hinsichtlich der Teilnahme an gemeinsamen Notfall- oder Kontinuitätsübungen.
- Pflichten zur Benachrichtigung über wesentliche Änderungen der Dienstleistungen oder des Standorts.
- Anforderungen zur Einhaltung vereinbarter Austrittsprozesse, einschließlich Zeitvorgaben und Kooperationspflichten.
Indem Sie diese Aspekte in Ihre Verträge integrieren, stellen Sie sicher, dass Governance nicht nur eine interne Angelegenheit ist. Sie wird vielmehr integraler Bestandteil der Zusammenarbeit zwischen Ihnen, Ihren Anbietern und Ihren Kunden während der gesamten Laufzeit der Dienstleistung. Bei der Prüfung von A.5.23 können Auditoren feststellen, dass Lebenszyklus und geteilte Verantwortung durchgängig in Ihren Vereinbarungen und nicht nur in Ihren Richtlinien abgebildet sind.
Buchen Sie noch heute eine Demo mit ISMS.online
Eine Demo bei ISMS.online ist eine praktische Möglichkeit, zu sehen, wie Ihr Managed Service Provider (MSP) die Cloud-Governance gemäß A.5.23 umsetzen kann, ohne Ihre Teams zusätzlich zu belasten. Sie erhalten einen umfassenden Überblick über die Zusammenhänge von Cloud-Services, Risiken, Verantwortlichkeiten, Lebenszyklusphasen und Nachweisen und sind somit optimal auf Audits, Kundenfragen und Aufsichtsratssitzungen vorbereitet.
Sie bringen die Cloud-Governance gemäß A.5.23 in den Griff, indem Sie verstreute Dokumente und Ad-hoc-Entscheidungen durch ein einziges, kohärentes System ersetzen, das Dienste, Risiken, Verantwortlichkeiten, Lebenszyklusphasen und Nachweise miteinander verknüpft. Für viele Managed Service Provider (MSPs) kann die Nutzung einer speziell entwickelten ISMS-Plattform wie ISMS.online ein praktischer Weg sein, diese Konsolidierung ohne zusätzliche Komplexität zu erreichen.
ISMS.online unterstützt Sie dabei, Ihre Cloud-Governance-Verantwortlichkeiten gemäß A.5.23 in ein einheitliches, integriertes System zu überführen, das Cloud-Inventare, Modelle geteilter Verantwortlichkeiten, Lebenszyklus-Workflows, Verträge und Nachweise miteinander verbindet. Anstatt Dokumente auf verschiedenen Laufwerken, Konsolen und in E-Mail-Postfächern zu suchen, erhalten Sie einen zentralen Überblick über die Verwaltung von Cloud-Diensten und Verantwortlichkeiten.
Für Managed Service Provider (MSPs) bedeutet dies, dass Sie Wirtschaftsprüfern, Aufsichtsräten und Kunden eine klarere und schlüssigere Darstellung bieten können: welche Cloud-Dienste Sie nutzen, wie die Verantwortlichkeiten verteilt sind, welche Kontrollmechanismen implementiert sind und wie sich diese im Laufe der Zeit verändern. Experten für Governance-, Risiko- und Compliance-Tools (GRC) stellen häufig fest, dass zentrale Plattformen die Erstellung und Konsistenz dieser Darstellung erleichtern, da sie Risiken, Kontrollen und Nachweise in einer Umgebung zusammenführen. Sie behalten die Kontrolle über Ihre Entscheidungen; die Plattform unterstützt Sie dabei, diese Kontrolle konsistent nachzuweisen, während Ihr Unternehmen wächst und sich Standards weiterentwickeln.
Sehen Sie Ihre Wolkengeschichte in einer Ansicht
Die Darstellung Ihrer Cloud-Architektur in einer einzigen Ansicht erleichtert es Ihrem CISO, dem Betriebsleiter und den kundennahen Teams, komplexe Fragen reibungslos zu beantworten. A.5.23 wird dadurch weniger zu einer reinen Compliance-Maßnahme und mehr zu einer einfachen Möglichkeit, Ihre tatsächliche Arbeitsweise zu beschreiben.
Wenn Sie Ihre Cloud-Governance in einer ISMS-Plattform zentralisieren, erhalten Sie und Ihr Team einen zentralen Bezugspunkt für A.5.23. Sie können:
- Führen Sie ein aktuelles Verzeichnis der internen und kundenorientierten Cloud-Dienste.
- Verknüpfen Sie jeden Service mit Risiken, Kontrollen, Verantwortlichkeitsmatrizen und Lebenszyklusphasen.
- Ordnen Sie Verträge, Due-Diligence-Prüfungen, Änderungsaufzeichnungen und Austrittsnachweise direkt den jeweiligen Dienstleistungen zu.
Zusammengenommen erleichtern diese Funktionen die Beantwortung von Fragen von Auditoren, Sicherheitsüberprüfungen durch Kunden und internen Entscheidungsträgern, die verstehen möchten, wie die Cloud verwaltet wird, erheblich. Sie sind nicht länger auf Ihr Gedächtnis oder unübersichtliche Tabellenkalkulationen angewiesen, um Ihre Cloud-Aktivitäten zu dokumentieren.
Machen Sie den nächsten Schritt mit Zuversicht
Wenn Sie die hier beschriebenen Herausforderungen Ihres Managed Service Providers (MSP) wiedererkennen – unklare Verantwortlichkeiten, verstreute Nachweise, zunehmender Druck von Kunden und Auditoren –, ist die Erkundung einer Plattform wie ISMS.online in einer kurzen, fokussierten Demonstration ein sinnvoller nächster Schritt. Trotz des steigenden Drucks geben fast alle Befragten der Studie „State of Information Security 2025“ an, dass das Erreichen oder Aufrechterhalten von Sicherheitszertifizierungen wie ISO 27001 oder SOC 2 höchste Priorität hat.
Sie können sehen, wie es Ihre bestehenden Werkzeuge und Arbeitsweisen unterstützt und Ihnen gleichzeitig die von A.5.23 erwartete Struktur bietet.
Entscheiden Sie sich für ISMS.online, wenn Sie Ihr Cloud-Service-Register, Ihre Verantwortlichkeiten, Risiken und Nachweise zentral verwalten möchten, um nicht nur zu behaupten, dass Sie die Anforderungen von A.5.23 erfüllen, sondern dies auch nachweisen können. Wenn Sie Wert auf klare Governance, reibungslosere Audits und eine überzeugende Darstellung gegenüber Kunden und Aufsichtsräten legen, unterstützt Sie unser Team gerne dabei, dies in Ihrer Umgebung umzusetzen.
KontaktHäufig gestellte Fragen (FAQ)
Was genau erwartet ISO 27001:2022 A.5.23 von einem Managed Service Provider (MSP), der Cloud-Dienste nutzt?
ISO 27001:2022 A.5.23 erwartet von Ihrem Managed Service Provider (MSP), dass den gesamten Lebenszyklus jedes Cloud-Dienstes, auf den Sie sich verlassen, aktiv steuernEs reicht nicht, einfach nur Anbieterzertifikate zu sammeln und auf das Beste zu hoffen. Sie sollten schnell und zuverlässig nachweisen können, was Sie verwenden, warum Sie es verwenden, was schiefgehen könnte, wem welche Kontrollen gehören und wie Sie den Vorgang beenden würden, ohne Daten oder Dienste zu verlieren.
Wie sehen „gute“ Nachweise gemäß A.5.23 für einen MSP aus?
Prüfer und informierte Kunden suchen in der Regel nach einem kleines, zusammenhängendes Bündel Es geht um Beweismaterial, nicht um ein riesiges Archiv. Für einen MSP umfasst der Kernsatz typischerweise Folgendes:
- Eine klare Cloud-Nutzung / Cloud-Sicherheitsrichtlinie
Hierin wird definiert, was in Ihrer Welt als „Cloud“ gilt (IaaS, SaaS, PaaS, Managed Security Services), wer neue Dienste genehmigen kann und welche Mindestanforderungen Sie an Konfiguration, Überwachung und Exit stellen.
- A Cloud-Dienst-Register das umfasst:
- interne Tools (RMM, PSA, Ticketing, Abrechnung, CRM, Monitoring, sicherer Dateitransfer); und
- Kundenorientierte Dienstleistungen (IaaS-Plattformen, Microsoft 365 und andere SaaS-Suiten, Backup/DR, SOC/XDR, verwaltete Firewalls und WAFs).
- Cloudspezifische Risikobewertungen und -behandlungen:
Diese sollten auf die Gefährdung durch mehrere Mandanten, weitreichende mandantenübergreifende Rollen, Datenresidenz, Anbieterabhängigkeit, API-Abhängigkeiten und Schlüsselverwaltung hinweisen. Die Risiken sollten mit konkreten Kontrollmaßnahmen und Verbesserungsvorschlägen verknüpft sein.
- Sorgfaltsprüfungsunterlagen: für wichtige Anbieter und Unterauftragnehmer
Typischerweise umfasst dies Sicherheitszusammenfassungen, Zertifizierungen (z. B. ISO 27001, SOC 2), Datenschutzvereinbarungen, Verfügbarkeitshistorie, Historie von Sicherheitsvorfällen und bekannte Einschränkungen oder Ausschlüsse, die Ihre Designs betreffen.
- Matrizen für geteilte Verantwortung:
Zeigen Sie für jede wichtige Dienstleistung auf, was der Anbieter und Ihr Managed Service Provider (MSP) leisten und was der Kunde selbst tun muss. Die Formulierungen sollten so konkret sein, dass ein Techniker oder Kunde seine Aufgaben ohne weiteres Gespräch nachvollziehen kann.
- Lebenszyklusdatensätze für Cloud-Dienste:
Nachweise dafür, dass Auswahl, Einarbeitung, Konfiguration, Änderung, regelmäßige Überprüfung und Austritt auf kontrollierte, wiederholbare Weise und nicht über Ad-hoc-Tickets abgewickelt werden.
Sind diese Elemente miteinander verknüpft und leicht zu navigieren, wirkt A.5.23 übersichtlich und glaubwürdig. Die Nutzung von ISMS.online zur Verwaltung von Richtlinien, Risikoeinträgen, Lieferantendatensätzen, Verantwortlichkeitsmatrizen und Nachweisen zum Lebenszyklus in einem zentralen ISMS-Arbeitsbereich bedeutet, dass Sie Ihre Cloud-Daten nicht jedes Mal neu zusammensetzen müssen, wenn ein Prüfer oder Kunde die betreffende Klausel anspricht. Dazu müssen Sie lediglich E-Mails durchsuchen und Screenshots der Konsole erstellen.
Wie sollte ein Managed Service Provider (MSP) ein nutzbares Modell der geteilten Verantwortung für die Cloud gemäß A.5.23 aufbauen?
Sie erfüllen die Intention von A.5.23, wenn „gemeinsame Verantwortung“ zu einer Dienstweise Übersicht realer AufgabenEs handelt sich nicht nur um eine Marketingfolie, die besagt: „Wir und der Anbieter legen beide Wert auf Sicherheit.“ Jeder, der sie liest – ob Ingenieur, Vertriebsmitarbeiter, Vertragsprüfer oder Kunde – sollte genau sehen können, was ihm gehört.
Wie lässt sich „gemeinsame Verantwortung“ in etwas Konkretes umsetzen?
Ein praktisches Vorgehen, das sich für Managed Service Provider (MSPs) bewährt hat, ist folgendes:
1. Katalogisieren Sie Ihre Cloud-Dienste nach Kategorien.
Beginnen Sie mit einer kurzen Liste von Kategorien:
- Workloads in der Public-Cloud (IaaS/PaaS).
- SaaS-Produktivitätssuiten (Microsoft 365, Google Workspace und ähnliche).
- Managed Backup- und Disaster-Recovery-Services.
- Managed SOC/XDR- und Bedrohungserkennungsdienste.
- Andere regelmäßig genutzte Cloud-basierte Tools, auf die Sie sich bei der Führung Ihres Unternehmens oder der Erbringung Ihrer Dienstleistungen verlassen.
Diese Liste spiegelt in der Regel die Einträge in Ihrem Cloud-Service-Register wider, was die Abstimmung erleichtert.
2. Wählen Sie einen gemeinsamen Satz von Sicherheitsdomänen.
Wählen Sie eine kleine Auswahl an Domänen, die auf die meisten Ihrer Dienstleistungen zutreffen, zum Beispiel:
- Identitäts- und Zugriffsverwaltung.
- Grundkonfiguration und Härtung.
- Protokollierung, Überwachung und Alarmierung.
- Backup-, Wiederherstellungs- und Testroutinen.
- Verschlüsselung und Schlüsselverwaltung.
- Vorfallerkennung, Priorisierung und Reaktion.
- Änderungsmanagement und Genehmigungen.
- Datenaufbewahrung, Speicherort und Löschung.
Die Einhaltung eines Standardsatzes macht das Modell leichter verständlich und ermöglicht die Wiederverwendung über verschiedene Dienste hinweg.
3. Zuweisung der Eigentumsrechte pro Domäne, pro Dienst
Entscheiden Sie für jeden Dienst und jede Sicherheitsdomäne, wer die Arbeit in der Praxis tatsächlich erledigt:
- Cloud-Anbieter: – Infrastrukturresilienz, physische Sicherheit, die meisten zugrunde liegenden Plattform-Patches, einige Protokollspeicheroptionen.
- Ihr Managed Service Provider (MSP): – Mandantenkonfigurations-Baselines, Alarmweiterleitung, Sicherungspläne, Wiederherstellungstests, Vorfall-Triage, Kundenberichterstattung.
- Kunde: – Nutzerverhalten, zulässige Nutzung, Datenklassifizierung, Zugriffsgenehmigung, Entscheidungen zum Inhaltslebenszyklus.
Wenn die Verantwortlichkeiten geteilt werden, notieren Sie die Aufteilung wie folgt: spezifische Aufgabenkeine vagen Bezeichnungen wie „gemeinsam“. Zum Beispiel:
- „Der Kunde genehmigt die Aufbewahrungsfrist; der Managed Service Provider implementiert und überprüft die Konfiguration vierteljährlich.“
- „MSP prüft Sicherheitswarnungen; Anbieter übernimmt die Reaktion auf Vorfälle auf Plattformebene.“
4. Das Modell in den täglichen Betrieb integrieren.
Eine Verantwortlichkeitsmatrix ist nur dann sinnvoll, wenn sie am Arbeitsplatz sichtbar ist. Stellen Sie sicher, dass Sie:
- Beziehe dich darauf in Runbooks und PlaybooksSo können die Ingenieure sehen, was bei Störungen und Änderungen zu tun ist.
- Ausrichten Standard-Leistungsbeschreibungen und SoWs Damit wird sichergestellt, dass Vertriebsmitarbeiter keine Leistungen versprechen, die sie nicht erbringen.
- Reflektiere es in Verträge und SLAsSo werden die rechtlichen Verpflichtungen mit den technischen Gegebenheiten und den Fähigkeiten der vorgelagerten Anbieter in Einklang gebracht.
- Nehmen Sie es mit auf Onboarding-PaketeSo verstehen neue Kunden, welche Aktionen ihnen und welche Ihnen gehören.
Die zentrale Pflege dieser Matrizen in ISMS.online – verknüpft mit Diensten in Ihrem Cloud-Register, Risikoeinträgen und Lieferantendatensätzen – ermöglicht es Ihnen, eine Matrix einmalig zu aktualisieren und die Änderung automatisch in Betriebshandbücher, Dokumentationen und Prüfnachweise zu übernehmen. Dadurch lässt sich die praktische Anwendbarkeit von A.5.23 deutlich einfacher nachweisen, nicht nur in einem Richtliniendokument.
Welche Cloud-spezifischen Risiken hebt A.5.23 für Managed Service Provider (MSPs) hervor, und wo treten diese Risiken häufig auf?
Für Managed Service Provider (MSPs) geht es bei A.5.23 weniger um allgemeine Berichte über „Cloud-Sicherheitsvorfälle“, sondern vielmehr um … Fehlende Erwartungen, Konfigurationsschwächen und mangelhafte Lebenszykluskontrolle in gemeinsam genutzten Umgebungen. Probleme treten häufig dort auf, wo Ihre Marketingversprechen, die Fähigkeiten des Anbieters und das Verhalten des Teams nicht übereinstimmen.
Wo tappen Managed Service Provider (MSPs) häufig in die Falle?
Zu den Mustern, die immer wieder Probleme verursachen, gehören:
Übermäßiges Vertrauen in die Sicherheitsannahmen der Anbieter
Es ist leicht, von „Secure by Design“ zu sprechen und dabei anzunehmen, dass Aufgaben wie Wiederherstellungstests, Protokollprüfung, Bedrohungsanalyse oder die Härtung auf Mandantenebene in einem Cloud-Abonnement enthalten sind. In Wirklichkeit sind viele dieser Aktivitäten jedoch nicht standardmäßig enthalten. Ihre Verantwortung als MSPund manchmal teilweise auch die Ihrer Kunden. Wenn sie nicht in Ihren Verantwortlichkeitsmatrizen und Betriebshandbüchern erfasst sind, werden sie selten konsequent umgesetzt.
Übermäßiger, schlecht kontrollierter privilegierter Zugriff
Managed Service Provider (MSPs) verfügen häufig über weitreichende Berechtigungen – globale Administratorkonten, Partnerportale, Notfallkonten –, die mehrere Mandanten betreffen. Fehlen für diese Berechtigungen strenge Genehmigungs-, Protokollierungs- und Überprüfungsmechanismen, kann ein einziger kompromittierter Zugang oder ein missbräuchlich verwendetes Konto zu einem schwerwiegenden Vorfall mit mehreren Mandanten führen. Gemäß A.5.23 sind Sie verpflichtet, dieses Risiko in Ihren Anlagen- und Risikoregistern zu berücksichtigen und klare Kontrollmechanismen zu implementieren.
Nicht registrierte oder „Schatten“-SaaS-Lösungen
Teams nutzen SaaS-Tools, die sensible Daten oder Kundendaten verarbeiten – für Support, Zusammenarbeit, Entwicklung, Vertrieb oder Automatisierung –, ohne diese jemals in Ihr ISMS, Lieferantenregister oder Ihre Risikoprozesse zu integrieren. Diese Dienste fallen somit nicht unter Ihre Überwachungs-, Incident-Response- und Exit-Pläne.
Schwache oder unerprobte Ausstiegspläne
Viele Managed Service Provider (MSPs) denken erst dann an den Ausstieg, wenn ein Anbieter die Einstellung eines Produkts, eine größere Preisänderung oder einen Ausfall ankündigt. Ohne einen dokumentierten Ausstiegsplan – inklusive Datenexport, Migration, Beweissicherung und Kundenkommunikation – improvisieren Sie genau dann, wenn Sie die Kontrolle am dringendsten benötigen.
SLAs, die zu viel versprechen
Verträge verpflichten Sie mitunter zu Wiederherstellungszielen, Aufbewahrungsfristen oder spezifischen Datenstandortvorgaben, die die zugrundeliegende Technologie nicht gewährleisten kann. Wenn Service-Design, Cloud-Anbieterfunktionen und Vertragstext nicht übereinstimmen, gehen Sie unnötige Risiken ein.
A.5.23 bietet Ihnen einen Rahmen, um diese Probleme systematisch anzugehen:
- Inventarisierung und Klassifizierung von Cloud-Diensten: Damit Sie wissen, wo sich das Risiko konzentriert.
- Ausführen Cloudspezifische Risikobewertungen die sich mit Problemen der Mandantenfähigkeit, privilegierten Zugriffen und Ausfallmodi von Anbietern befassen.
- Hilft dabei Verantwortungsmatrizen So werden Aufgaben zugewiesen, jemandem übertragen und überprüft.
- Beweisbar Lebenszyklusschritte – vom Onboarding bis zum Exit – damit die Menschen sehen, dass Veränderungen, Überprüfungen und Exits kontrollierte Ereignisse und keine Reaktionen sind.
Wenn Sie ein Risiko – beispielsweise übermäßigen Zugriff auf das Partnerportal – von Ihrem Register über Verantwortlichkeitsmatrizen bis hin zu Änderungsaufzeichnungen und Verbesserungsmaßnahmen zurückverfolgen können, erfüllen Sie nicht nur die Anforderungen von A.5.23, sondern präsentieren auch den Prüfern und Kunden eine wesentlich überzeugendere Darstellung der Cloud-Risiken.
Wie kann ein MSP die Dokumentation A.5.23 in sein ISMS integrieren, ohne alles neu zu gestalten?
A.5.23 lässt sich in der Regel wie folgt abdecken: Integration cloudspezifischer Governance in Ihr bestehendes ISMSAnstatt eine parallele Struktur aufzubauen, soll das Ziel darin bestehen, dass jeder, der mit ISO 27001 vertraut ist, die Auswahl, Steuerung und Außerbetriebnahme von Cloud-Diensten genauso einfach nachvollziehen kann wie die Auswahl, Steuerung und Außerbetriebnahme traditioneller Anlagen oder Lieferanten.
Wie lässt sich Cloud-Governance in Ihre bestehende Infrastruktur integrieren?
Ein einfaches, aber effektives Vorgehen besteht darin, mit drei verbundenen Komponenten zu beginnen und diese dann in Ihr bestehendes ISMS einzubinden:
1. Cloud-Nutzung / Cloud-Sicherheitsrichtlinie
Erweitern Sie Ihre bestehenden Richtlinien zur Informationssicherheit um ein zielgerichtetes Dokument, das Folgendes beinhaltet:
- Definiert, was in Ihrem Kontext als Cloud-Dienst gilt.
- Legt Genehmigungsschwellenwerte fest (z. B. wer einen neuen Anbieter autorisieren kann).
- Erwartungen der Staaten an Sorgfaltspflichten, Konfigurationsgrundlagen, Überwachung, Vorfallbearbeitung und Beendigung.
Diese Richtlinie bildet die Grundlage für alle damit verbundenen Verfahren und Aufzeichnungen.
2. Cloud-Dienstregister
Erstellen Sie ein Register – häufig eine Anlagen- oder Lieferantenliste von ISMS.online – das mindestens Folgendes erfasst:
- Name des Dienstes und Anbieter.
- Interner Eigentümer.
- Geschäftszweck.
- Verarbeitete Datentypen und Datenspeicherorte.
- Kritikalität und Auswirkungen des Verlusts.
- Links zu Verträgen, Datenschutzvereinbarungen, Zertifizierungen und Verantwortlichkeitsmatrizen.
Sie können dies in Ihr bestehendes Anlageninventar integrieren, sodass Cloud-Dienste nicht in einem separaten Universum existieren.
3. Matrizen der gemeinsamen Verantwortung
Für die wichtigsten Services erstellen und pflegen Sie Verantwortlichkeitsmatrizen wie zuvor beschrieben. Konzentrieren Sie sich zunächst auf Folgendes:
- Ihre primäre Public-Cloud-Plattform.
- Ihre zentrale SaaS-Suite für Produktivität und Zusammenarbeit.
- Ihr führendes Managed-Backup-/DR-Angebot.
- Ihre verwalteten SOC/XDR- oder ähnliche Security-as-a-Service-Lösungen.
Anschließend können Sie diese Komponenten in die bereits von Ihnen betriebenen ISMS-Elemente einbinden:
- Risikomanagement: – Verknüpfung von Cloud-Diensten mit Risikoeinträgen und -behandlungen, insbesondere bei Multi-Tenant- oder Provider-Ausfall-Szenarien.
- Lieferantenmanagement: – Verträge, Sicherheitsübersichten, Datenschutzvereinbarungen und Prüfberichte den jeweiligen Anbietern beifügen; regelmäßige Überprüfungen und Entscheidungen protokollieren.
- Bedienelemente: – Referenzieren Sie cloudspezifische Onboarding-, Änderungs-, Überprüfungs- und Exit-Schritte innerhalb Ihrer bestehenden Änderungsmanagement- und Vorfallbearbeitungsprozesse.
- Beweismittelverwaltung: – Verknüpfung von Vorfällen, Backup-Testergebnissen, Zugriffsüberprüfungen und Verbesserungsmaßnahmen mit den entsprechenden Cloud-Einträgen und Risiken.
Anhand von praktischen Beispielen – beispielsweise einer internen SaaS-Lösung, einer kundenorientierten Lösung in der Public Cloud und einer spezialisierten, aber kritischen Plattform – können Sie Prüfern zeigen, dass das Muster wiederholbar ist, ohne jeden noch so kleinen Dienst einzeln dokumentieren zu müssen. ISMS.online ist genau für diese Art der Modellierung konzipiert: Richtlinien, Register, Risiken, Lieferanten, Aufgaben und Nachweise sind übersichtlich angeordnet und durch Links leicht nachvollziehbar.
Welche Verträge und SLAs sollte ein MSP verwenden, um Kunden die Anforderungen von A.5.23 zu demonstrieren?
Um A.5.23 überzeugend zu demonstrieren, benötigen Sie sowohl Ihre Upstream- als auch Ihre Downstream-Vereinbarungen Die Vorgehensweise muss Ihrer tatsächlichen Vorgehensweise beim Cloud-Risikomanagement entsprechen. Das bedeutet, dass Ihre Verträge und SLAs mit Anbietern und Unterauftragnehmern sowie Ihre Geschäftsbedingungen mit Kunden dieselben Verantwortlichkeiten und Kompetenzen aufzeigen sollten, die Sie in Ihrem ISMS dokumentieren.
Worauf sollten Sie bei Verträgen mit vorgelagerten Anbietern und Unterauftragnehmern achten?
Prüfen Sie die Teile jedes Vertrags, die Ihre Leistungen und Ansprüche direkt betreffen:
- Sicherheits- und Verfügbarkeitszusagen: – sicherstellen, dass die RPO/RTO-Ziele, die Verfügbarkeits-SLAs und die Datenbeständigkeit mit der Gestaltung Ihrer Services und den Zusagen in Ihren eigenen SLAs übereinstimmen.
- Angaben zum Datenstandort und Wohnsitz: – Sie sollten die Frage „Wo befinden sich unsere Daten?“ mit Zuversicht beantworten können, einschließlich der Standorte für Backups und Ausweichregionen.
- Meldung und Eskalation von Vorfällen: – Prüfen Sie, wie und wann sich die Anbieter verpflichten, Sie über Vorfälle zu informieren, die Ihre Kunden betreffen könnten.
- Unterstützung für wichtige Steuerelemente: – Prüfen Sie, ob Funktionen wie detaillierte Protokollierung, vom Kunden verwaltete Verschlüsselungsschlüssel, unveränderliche Backups oder erweiterte Zugriffskontrollen, auf die Sie angewiesen sind, explizit verfügbar sind und unterstützt werden.
- Sicherungsmechanismen: – Identifizieren Sie Zertifizierungen, Prüfberichte, Zusammenfassungen von Penetrationstests oder vertragliche Prüfrechte, die Sie als Nachweise in Ihrem eigenen ISMS und in der Kundenberichterstattung verwenden können.
Möglicherweise müssen Sie nicht jeden Vertrag neu verhandeln, aber Sie sollten verstehen und dokumentieren, wo die Zusagen eines Anbieters nicht Ihren aktuellen Leistungsbeschreibungen entsprechen, und Ihre eigenen Angebote oder Architekturen entsprechend anpassen.
Wie sollten Kundenverträge und SLAs geändert werden, um A.5.23 Rechnung zu tragen?
Im weiteren Verlauf sollten Ihre kundenorientierten Dokumente Folgendes beinhalten:
- Klar identifizieren Welche Dienste sind auf welche Cloud-Plattformen angewiesen?insbesondere wenn dies Auswirkungen auf den Datenstandort, die Ausfallsicherheit oder die Unterstützung hat.
- Erklären Wer ist für welche Kontrollbereiche verantwortlich? – wie z. B. Benutzerzugriffsgenehmigungen, zulässige Nutzung, Klassifizierung, rechtliche Aufbewahrungspflichten und Inhaltslebenszyklus – im Einklang mit Ihren Matrizen zur gemeinsamen Verantwortung.
- Verpflichte dich zu Wiederherstellungsziele, Aufbewahrungsfristen und Zeitrahmen für die Vorfallskommunikation dass Ihre vorgelagerten Vereinbarungen und Entwürfe dies zuverlässig gewährleisten können.
- Verweis oder Link zu, Informationen zu Verantwortung und Abhängigkeit so, dass Kunden es verstehen können, ohne Ihr ISMS lesen zu müssen.
Wenn vorgelagerte Verträge, interne Verantwortlichkeitsmatrizen und nachgelagerte SLAs alle übereinstimmen, lässt sich einem Kunden oder Auditor viel leichter erläutern, wie Sie Cloud-Risiken gemäß A.5.23 managen. Die Verwaltung dieser Dokumente in ISMS.online zusammen mit Ihren Richtlinien und Risiken hilft Ihnen, die Darstellung einheitlich zu halten, während Anbieter ihre Bedingungen aktualisieren, sich Vorschriften weiterentwickeln und Kunden anspruchsvoller werden.
Wie kann ein Managed Service Provider (MSP) ISMS.online nutzen, um A.5.23 im Zuge von Änderungen an Cloud-Diensten unter Kontrolle zu halten?
ISMS.online hilft Ihnen dabei, A.5.23 unter Kontrolle zu halten, indem es Cloud-Governance in eine ständig aktualisiertes, vernetztes SystemAnstatt einer Sammlung statischer Dokumente, die mit den Änderungen Ihrer Systemarchitektur nicht mehr Schritt halten, bleibt Ihre ISMS-Sichtweise stets aktuell, nachvollziehbar und verständlich, wenn Sie Cloud-Dienste einführen, modifizieren oder außer Betrieb nehmen.
Wie sieht die tägliche Verwaltung von A.5.23 in ISMS.online aus?
In einer typischen Konfiguration würde Ihr Team ISMS.online für Folgendes verwenden:
Führen Sie ein Live-Cloud-Dienstregister
- Erfassen Sie jeden Cloud-Dienst mit Angabe des Eigentümers, des Zwecks, der Datentypen, der Datenspeicherorte und der Kritikalität.
- Tag-Dienste, die intern verwendet werden, im Gegensatz zu solchen, die zur Bereitstellung von Managed Services eingesetzt werden.
- Verknüpfen Sie jeden Eintrag mit den entsprechenden Richtlinien, Risiken, Lieferanten und Verantwortlichkeitsmatrizen.
Cloudspezifische Risiken und Behandlungsmaßnahmen erfassen und verfolgen
- Erstellen Sie Risikoeinträge für Multi-Tenant-Exposition, leistungsstarke Cross-Tenant-Konten, Datenresidenz, Provider-Lock-in und API-Abhängigkeiten.
- Behandlungen, Verantwortliche und Überprüfungstermine zuweisen.
- Nutzen Sie die verknüpften Arbeiten und Projekte der Plattform, um Maßnahmen zur Behebung und Verbesserung zu verfolgen.
Verträge, Zertifizierungen und Due-Diligence-Prüfungen an einem Ort speichern
- Laden Sie Anbieterverträge, Datenschutzvereinbarungen, Sicherheitszusammenfassungen und Prüfberichte direkt in die Lieferantenaufzeichnungen hoch.
- Dokumentieren Sie die Ergebnisse und Entscheidungen der Überprüfungen, um nachweisen zu können, dass das Anbieterrisiko im Laufe der Zeit gesteuert wird.
Zentralisierung der Matrizen für geteilte Verantwortung
- Pflegen Sie eine maßgebliche Matrix pro wichtigem Cloud-Dienst oder Dienstfamilie.
- Verknüpfungsmatrizen mit Richtlinien, Leistungsbeschreibungen, Risikoeinträgen und Lieferantendatensätzen.
- Nutzen Sie sie als Referenzpunkte beim Aktualisieren von Betriebshandbüchern, SLAs und Onboarding-Materialien.
Nachweise über Lebenszyklusaktivitäten
- Protokollauswahl, Onboarding, Genehmigungen der Konfigurationsbasislinie, Änderungsprüfungen, regelmäßige Neubewertungen und Ausstiegsschritte als Aufgaben oder verknüpfte Arbeitselemente.
- Ordnen Sie zugehörige Vorfälle, Backup-Tests, Zugriffsüberprüfungen und Verbesserungen den entsprechenden Diensten und Risiken zu.
Bei der Einführung einer neuen Plattform können Sie einen bestehenden Eintrag klonen, Konfiguration und Verantwortlichkeiten anpassen und ihn innerhalb weniger Minuten mit Risiken und Lieferanten verknüpfen. Wenn Sie einen Dienst außer Betrieb nehmen, können Sie die Entscheidungen zur Datenmigration, Datenbereinigung und Aufbewahrung von Nachweisen zentral erfassen.
Für Audits, Kundenbefragungen oder Vorstandssitzungen können Sie direkt aus ISMS.online ein fokussiertes A.5.23-Nachweispaket zusammenstellen: die Cloud-Richtlinie, das aktuelle Register, Beispiel-Verantwortlichkeitsmatrizen, wichtige Cloud-Risiken und deren Behandlung, Lieferantenprüfung sowie Beispiele für Lebenszyklus- und Vorfallsdokumentationen. Diese Fähigkeit, eine konsistente, durchgängige Darstellung zu liefern, lässt einen Managed Service Provider (MSP) die Cloud-Governance als handlungsfähig und nicht als reaktiv erscheinen. Wenn Sie von Kunden und Auditoren zu dieser ersten Gruppe gezählt werden möchten, ist die Investition in eine korrekte Strukturierung von A.5.23 in ISMS.online ein wirkungsvoller nächster Schritt.
