Wie Managed Service Provider (MSPs) mithilfe öffentlicher Cloud-Plattformen die ISO 27001-Konformität gewährleisten

Die Multi-Cloud- und Multi-Tenant-Problematik für ISO 27001-Managed-Service-Provider

Multi-Cloud- und Multi-Tenant-Public-Cloud-Umgebungen erschweren die Einhaltung der ISO 27001, da gemeinsam genutzte Schichten und virtuelle Grenzen die Auswirkungen von Fehlern deutlich vergrößern. Sie betreiben Kundenworkloads über AWS, Azure und Google Cloud hinweg und nutzen dabei Teams, Tools und Managementebenen wieder. Ein einziger Fehler kann daher viele Mandanten gleichzeitig betreffen. Um die Konformität zu gewährleisten, muss Ihr ISMS diese Realität beschreiben, gemeinsam genutzte Schichten als Risiken erster Klasse behandeln und aufzeigen, wie Sie Kundenumgebungen trennen. Diese Erwartung entspricht den Anforderungen der ISO 27001:2022, den organisatorischen Kontext zu verstehen, den Umfang zu definieren und die Risikobehandlung und -kontrolle so zu planen, dass sie Ihre tatsächliche Leistungserbringung gemäß der Norm widerspiegeln.

Die Public Cloud kann Ihre Services skalierbarer und profitabler machen, verändert aber auch Ihr Risikoprofil gemäß ISO 27001 auf oft unterschätzte Weise. Wenn Sie Dutzende von Kundenumgebungen auf verschiedenen Plattformen verwalten, schaffen Mandantenfähigkeit, gemeinsam genutzte Tools und komplexe Datenflüsse potenzielle Fehlerquellen, die Ihr älteres, lokales ISMS möglicherweise nie berücksichtigt hat. Geht Ihr Managementsystem weiterhin von physischer Trennung und kundenspezifischen Infrastrukturen aus, kann es Ihre heutigen Betriebsabläufe nur schwer abbilden.

Fast alle Befragten der ISMS.online-Umfrage 2025 nennen das Erreichen oder Aufrechterhalten von Sicherheitszertifizierungen wie ISO 27001 oder SOC 2 als oberste Priorität.

Für Managed Service Provider (MSPs) ist „Multi-Tenant“ nicht nur ein Softwarebegriff. Er beschreibt Ihr gesamtes Betriebsmodell: Viele Kunden nutzen dieselben Cloud-Plattformen, Support-Teams, Monitoring-Systeme und oft auch dieselbe Managementebene. ISO 27001:2022 erwartet von Ihnen, dass Sie diese gemeinsamen Ebenen verstehen, die damit verbundenen Risiken explizit behandeln und nachweisen, wie Sie verhindern, dass sich Probleme eines Kunden auf andere auswirken. Dies ergibt sich direkt aus dem Schwerpunkt der Norm auf die Identifizierung von Informationssicherheitsrisiken, die sich aus Ihrem Kontext und Ihren Verarbeitungstätigkeiten ergeben, sowie auf die Auswahl und den Betrieb von Kontrollen, um diese Risiken nachweislich und normkonform zu behandeln.

Eine starke Cloud-Sicherheit beginnt damit, dass Sie die Realität so beschreiben, wie sie ist, und nicht so, wie Sie sie gerne hätten.

Warum Mehrfamilienhäuser Ihr Risikoprofil verändern

Multi-Tenancy verändert Ihr Risikoprofil, da die Isolation nun logisch statt physisch erfolgt und gemeinsam genutzte Komponenten weitreichende Ausfälle verursachen können. Anstatt auf separate Hardware pro Kunde zu setzen, basieren Ihre Maßnahmen auf Konfigurationen, Identitäten und zentralen Plattformen. Ein einziger Fehler kann daher Ihre Annahmen zur Mandantentrennung zunichtemachen. ISO 27001 erwartet, dass diese Änderung in Ihren Risikobewertungen, Kontrollen und Nachweisen klar abgebildet wird. Dies entspricht dem risikobasierten Ansatz der ISO 27001:2022, der die Analyse der Auswirkungen von Technologie- und Serviceänderungen auf die Risiken sowie die Dokumentation der daraus resultierenden Kontrollen und Nachweise in Ihrem Risikobehandlungsplan und Ihrer Anwendbarkeitserklärung vorschreibt.

In On-Premise-Umgebungen gab es typischerweise separate Hardware, Netzwerke und mitunter auch separate Tool-Stacks pro Kunde. Die Isolation war hauptsächlich physisch. In der Public Cloud ist die Isolation logisch und hängt stark von der Konfiguration sowie dem Identitäts- und Zugriffsmanagement (IAM) ab. Dies führt zu drei wesentlichen Änderungen für ISO 27001:

Mietergrenzen sind größtenteils virtuell.
Eine falsch konfigurierte Rolle, Sicherheitsgruppe oder Speicherrichtlinie kann plötzlich mehrere Kunden betreffen. ISO 27001 verlangt, dass Sie dies in Ihrer Risikobewertung analysieren und Kontrollen entwickeln, die die Wahrscheinlichkeit dafür verringern und die Erkennung ermöglichen.
Gemeinsam genutzte Komponenten werden zu wirkungsvollen Assets.
Protokollierungspipelines, Backup-Ziele, Managementnetzwerke, Überwachungstools und Identitätsanbieter dienen heute mehreren Kunden. Wird eine dieser Komponenten kompromittiert, können die Auswirkungen weitreichend sein. Daher müssen diese Assets in Ihrem Inventar, Risikoregister und Ihrer Anwendbarkeitserklärung aufgeführt werden.
Die Verantwortung ist dreigeteilt.
Für jede Kontrollmaßnahme müssen Sie festlegen, welche Aufgaben vom Cloud-Anbieter, welche von Ihnen als Managed Service Provider (MSP) und welche von Ihrem Kunden übernommen werden. Ist diese Aufteilung unklar, ist Ihr Risikobild unvollständig und Ihre Nachweise werden von Wirtschaftsprüfern infrage gestellt. Branchenleitlinien zu Modellen geteilter Verantwortung in der Cloud, einschließlich Ressourcen wie der OWASP-Dokumentation zur geteilten Verantwortung in der Cloud, unterstreichen die Notwendigkeit, die Verantwortlichkeiten für jede Aktivität zwischen Anbieter, MSP und Kunde klar zuzuordnen und zu dokumentieren, um Lücken zu vermeiden.

Wenn Sie diese Veränderungen innerhalb Ihres ISMS nicht erkennen, bestehen Sie vielleicht noch ein- oder zweimal ein Audit, aber es wird Ihnen schwerer fallen, Entscheidungen zu rechtfertigen, wenn in einer gemeinsam genutzten Umgebung etwas schiefgeht.

Typische Schwachstellen, die MSPs übersehen

Typische Schwachstellen in Public-Cloud-MSP-Umgebungen sind die übermäßige Abhängigkeit von Providerzertifizierungen, das Vergessen gemeinsam genutzter Plattformen in der Anlagenliste und die Tatsache, dass kritisches Wissen im Kopf der Mitarbeiter statt im ISMS verankert ist. Diese Lücken untergraben ansonsten überzeugende ISO-27001-Nachweise und treten oft erst im Rahmen von Audits oder bei Störungen zutage.

Beim Umzug von Managed Service Providern (MSPs) in die Public Cloud und dem Versuch, die Anforderungen von ISO 27001 zu erfüllen, treten immer wieder dieselben Muster auf:

Vorausgesetzt, die Cloud ist zertifiziert, ist alles in Ordnung.

Cloud-Zertifizierungen decken den Anbieter ab; Sie müssen jedoch weiterhin jede Kundenumgebung sicher konfigurieren und betreiben.

Gemeinsam genutzte Plattformen werden nicht als Vermögenswerte aufgeführt.

Die Behandlung zentraler Protokollierungs-, Verwaltungs- oder Bastion-Plattformen als generische Infrastruktur führt dazu, dass Risiken und Kontrollmechanismen für Mehrmandantensysteme nicht dokumentiert werden.

Uneinheitliche Mieterisolierungsmuster:

Die Vermischung von dedizierten und gepoolten Modellen ohne Standardmuster oder Begründung macht Isolationsentscheidungen schwer zu erklären und zu verteidigen.

Undokumentiertes Heldenwissen:

Sich auf einige wenige erfahrene Ingenieure anstatt auf dokumentierte Rollen, Prozesse und Diagramme zu verlassen, entfremdet das ISMS der Realität.

Sie müssen nicht alles auf einmal beheben. Ein sinnvolles Ziel für das erste Quartal ist es, die Risiken von Multi-Tenant-Umgebungen in Ihre Risikobewertung einzubeziehen, gemeinsam genutzte Plattformen als kritische Assets zu identifizieren und die wichtigsten Tenant-Muster, die Sie heute verwenden, zu dokumentieren.

Kontakt

Neudefinition der Cloud als Erweiterung Ihres ISMS-Bereichs

Wenn Sie die Cloud als Erweiterung Ihres ISMS-Geltungsbereichs betrachten, sehen Sie AWS, Azure und Google Cloud nicht länger als generische Anbieter, sondern als Kernbestandteile Ihrer IT-Umgebung. Die Abschnitte der ISO 27001:2022 zu Kontext, Geltungsbereich, Risiko und beteiligten Parteien machen es selbstverständlich, die wichtigsten Cloud-Plattformen als Teil Ihrer Systemgrenzen und nicht nur als Randbereiche zu betrachten. Sobald Ihr Geltungsbereich diese Realität widerspiegelt, lässt sich alles Weitere leichter erklären und verteidigen.

Wenn Ihr ISMS noch immer so aussieht, als würden Sie nur ein oder zwei Rechenzentren mit einigen wenigen SaaS-Tools betreiben, entspricht es wahrscheinlich nicht mehr Ihrer aktuellen Public-Cloud-Realität. Ein klar definierter, Cloud-orientierter Geltungsbereich schafft klare Erwartungen bei Auditoren, Kunden und internen Teams und beugt späteren Streitigkeiten darüber vor, ob ein bestimmter Dienst, eine Region oder ein Konto „im Geltungsbereich“ liegt. Ohne diese Klarheit riskieren Sie versteckte Lücken, in denen Kunden-Workloads oder unterstützende Plattformen außerhalb Ihres dokumentierten Systems liegen.

Sobald Sie die Public Cloud als Teil Ihres Unternehmensnetzwerks betrachten, wird jedes Konto, jedes Abonnement und jedes Projekt, das verwaltete Workloads hostet, zu einer weiteren Einrichtung, die Sie verstehen, dokumentieren und kontrollieren müssen. Diese Umstellung mag zunächst administrativ erscheinen, hat aber sehr praktische Konsequenzen für die Erstellung von Richtlinien, die Nachverfolgung von Assets, das Lieferantenmanagement und die Kommunikation Ihrer Garantieversprechen an Kunden.

Aktualisieren Sie Ihre Scope-Definition für die öffentliche Cloud

Die Aktualisierung Ihrer Geltungsbereichsbeschreibung für die Public Cloud bedeutet, in verständlicher Sprache zu erläutern, welche Dienste, Umgebungen und Beteiligten von Ihrem ISMS abgedeckt werden. Anstatt nur Rechenzentren aufzulisten, müssen Sie Cloud-Konten benennen und beschreiben, wie neue Umgebungen in den Geltungsbereich fallen. Dies gibt Auditoren und Kunden ein klares Bild davon, wo Ihre Verantwortlichkeiten beginnen und enden.

Ihre Zielbeschreibung sollte drei Fragen beantworten:

Welche Leistungen sind abgedeckt?

Für einen Managed Service Provider (MSP) umfasst dies typischerweise Managed Hosting, Monitoring, Backup, Sicherheitsbetrieb, Service Desk und alle von Ihnen gehosteten oder betriebenen Kundenportale.

Welche Umgebungen werden abgedeckt?

Anstatt nur namentlich genannte Rechenzentren zu nennen, sollten Sie Cloud-Konten, Abonnements und Projekte erwähnen. Beschreiben Sie nach Möglichkeit, wie neue Umgebungen standardmäßig in den Geltungsbereich fallen, sobald sie bestimmte Kriterien erfüllen, z. B. das Hosting von Produktionskundendaten.

Welche Parteien und Orte sind relevant?

Dies umfasst Ihre eigene Organisation, Kundenumgebungen unter Ihrer Verwaltung, wichtige Lieferanten (große Cloud-Anbieter, zentrale SaaS-Tools) und gegebenenfalls geografische Aspekte wie den Datenstandort.

Eine einfache Möglichkeit zur Aktualisierung Ihres Geltungsbereichs besteht darin, jedes Cloud-Konto, Abonnement oder Projekt, das verwaltete Kundenworkloads hostet, als „Informationsverarbeitungseinrichtung“ gemäß ISO 27001 zu behandeln. Diese Formulierung trägt dazu bei, den Geltungsbereich an den Standard anzupassen und erleichtert die Begründung, warum bestimmte Kontrollen gelten.

Anpassung des Risikomanagements, der Vermögenswerte und der Lieferanten

Die Anpassung von Risikomanagement, Anlagen und Lieferanten an die Cloud erfordert, dass Ihre bestehenden ISO-27001-Prozesse die Sprache von Konten, Regionen und Managed Services sprechen. Anstatt die Cloud unter allgemeinen Outsourcing-Risiken zu verstecken, ordnen Sie sie explizit Ihrer Methodik, Ihrem Inventar und Ihren Lieferantenebenen zu, sodass die Abschnitte 4, 5 und 6 Ihre tatsächliche Arbeitsweise widerspiegeln.

Eine deutliche Mehrheit der Organisationen in der ISMS.online-Umfrage „State of Information Security 2025“ gibt an, dass die Geschwindigkeit und das Ausmaß der regulatorischen Änderungen die Aufrechterhaltung der Compliance erschweren.

Sobald Cloud-Computing explizit in den Geltungsbereich fällt, müssen mehrere unterstützende Teile des ISMS aktualisiert werden:

Risikomethodik:

Cloudspezifische Risiken wie regionale Ausfälle, Änderungen bei Managed Services, Probleme mit der Identitätsföderation und Konzentrationsrisiken auf einen einzelnen Anbieter sollten als namentlich genannte Punkte und nicht als allgemeine Outsourcing-Risiken aufgeführt werden.

Anlageninventar:

Cloud-Dienste, gemeinsam genutzte Managementebenen, Landezonen und Konfigurationsbaselines sollten als Assets mit Eigentümern, Klassifizierung und Lebenszyklusstatus aufgelistet werden.

Lieferantenmanagement:

Große Cloud-Anbieter gehören in eine Kategorie mit hoher Kritikalität, die eine intensivere Due-Diligence-Prüfung und kontinuierliche Überwachung erfordert, während SaaS-Tools mit geringerem Risiko in niedrigeren Kategorien angesiedelt sind.

Erklärung zur Anwendbarkeit:

Kontrollen mit Cloud-Bezug, einschließlich Anhang A 5.23 zur Nutzung von Cloud-Diensten, erfordern explizite Hinweise zu ihrer Anwendung auf Cloud-Dienste und -Konfigurationen. Organisationen, die Zuordnungen zwischen Anhang-A-Kontrollen und Cloud-Plattform-Konfigurationen veröffentlichen, wie beispielsweise Fachartikel zur Cloud-Kontrollzuordnung von unabhängigen Stellen wie MITRE, unterstreichen den Wert einer detaillierten Beschreibung, wie Ziele wie A.5.23 in spezifischen Diensten und Einstellungen erreicht werden. Da die genauen Zuordnungen stets von Ihrer Architektur abhängen, sollten Beispiele eher als Muster denn als starre Vorgaben verstanden werden.

Im nächsten Quartal sollten Sie Ihre Leistungsbeschreibung, Ihre Risikomethodik, Ihr Anlagenverzeichnis und Ihre Lieferantenstufen aktualisieren, damit diese die von Ihnen genutzten Cloud-Plattformen explizit widerspiegeln.

ISMS.online verschafft Ihnen einen Vorsprung von 81 % ab dem Moment Ihrer Anmeldung

ISO 27001 leicht gemacht

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.

Los geht´s

Entwurf von ISO 27001-konformen Multi-Tenant-Architekturen (AWS, Azure, GCP)

Die Entwicklung von ISO 27001-konformen Multi-Tenant-Architekturen erfordert die Auswahl einiger weniger Muster, die Sicherheit, Kosten und Komplexität in Einklang bringen, und deren konsequente Anwendung. Anstatt jedem Team die Entwicklung eines eigenen Tenant-Modells zu überlassen, standardisieren Sie auf gepoolte, isolierte und hybride Ansätze, die Sie in ISO-Begriffen beschreiben, dokumentieren und mit den Risiken und Kontrollen Ihres ISMS verknüpfen können.

Nachdem Umfang und Risiken geklärt sind, geht es im nächsten Schritt darum, sich auf wenige Mandantenarchitekturen festzulegen, die technisch und gegenüber einem Auditor nachvollziehbar sind. Der Versuch, jede mögliche Struktur zu unterstützen, führt zu Ausnahmen, technischer Verschuldung und Problemen bei Audits. Wenn Sie eine kurze Liste von Architekturen präsentieren, deren Anwendungsbereiche erläutern und deren Bezug zu Ihren Risikobewertungen aufzeigen können, lassen sich Ihre Cloud-Architekturen deutlich leichter begründen.

In der Public Cloud besteht die Mandantenfähigkeit üblicherweise aus der Wahl zwischen drei übergeordneten Modellen: Pooled Cloud, Silo-Cloud und Hybrid Cloud. Der Standard schreibt kein bestimmtes Muster vor, erwartet aber, dass Sie bewusste Entscheidungen treffen, diese dokumentieren und die verbleibenden Risiken managen. Dies entspricht dem technologieunabhängigen Ansatz der ISO 27001:2022, der jedoch die Auswahl und Begründung von Kontrollen und Maßnahmen auf Basis dokumentierter Risiken und Ihres gewählten Betriebsmodells erfordert, wie im Standard beschrieben.

Vergleich von gepoolten, isolierten und hybriden Modellen

Der Vergleich von gepoolten, isolierten und hybriden Modellen hilft Ihnen bei der Entscheidung, welche Muster zu welchen Diensten und Risikostufen passen. Gepoolte Designs bevorzugen Effizienz und logische Isolation, isolierte Designs klarere Abgrenzungen und hybride Designs kombinieren gemeinsam genutzte Tools mit getrennten Datenebenen. ISO 27001 schreibt kein bestimmtes Modell vor, erwartet aber, dass Sie Ihre Wahl begründen und die damit verbundenen Risiken managen.

Hier eine vereinfachte Darstellung der Abwägungen, vor denen Sie stehen:

Modell	Sicherheit und Gewährleistung	Kosten und operativer Aufwand
Gepoolt	Hängt stark von logischer Isolation und Tests ab; ist bei Hochrisikodaten schwerer zu rechtfertigen.	Effiziente Ressourcennutzung; einfacherer Betrieb in kleinerem Maßstab.
Isoliert	Klarere Isolationsgrenzen; oft leichter gegenüber Prüfern und Aufsichtsbehörden zu erklären.	Höhere Kosten pro Mieter; mehr zu verwaltende Umgebungen.
Hybrid	Schafft ein Gleichgewicht zwischen der Isolation kritischer Elemente und der gemeinsamen Nutzung von Komponenten zur Steigerung der Effizienz.	Die Komplexität von Design und Governance nimmt zu; es bedarf klarer Vorgaben.

Gepooltes Modell:

Viele Kunden nutzen dieselbe Infrastruktur, Anwendung und Datenbank, wobei die Trennung durch Mandanten-IDs, Zeilenebenensicherheit, Schemas oder Namensräume gewährleistet wird. Sie müssen aufzeigen, wie Zugriffskontrolle, Tests und Überwachung das Risiko mandantenübergreifender Sicherheitslücken verringern.

Silomodell:

Jeder Kunde verfügt über ein eigenes Konto, Abonnement oder Projekt, oft mit eigener Datenbank und manchmal eigener Instanz der Kerndienste. Dies ist insbesondere für risikoreichere Branchen attraktiv, da die Trennung leichter nachvollziehbar ist. Sie müssen dennoch nachweisen, wie Sie konsistente Baselines gewährleisten und Konfigurationsabweichungen vermeiden.

Hybridmodell:

Gemeinsam genutzte Steuerungsebenen und Tools speisen getrennte Datenebenen, wie z. B. Mandantenkonten, Netzwerke oder Datenbanken. Sie müssen darlegen, wie Sie gemeinsam genutzte Komponenten schützen und überwachen und die Auswirkungen von Ausfällen begrenzen.

Die meisten Managed Service Provider (MSPs) nutzen letztendlich einen Mix: eher gepoolte Modelle für risikoarme, hochvolumige Services und isolierte oder hybride Modelle für Angebote mit hohem Sicherheitsbedarf. Wichtig für ISO 27001 ist, dass Sie definieren, welche Services welches Muster verwenden und warum, die Risiken und Kontrollen für jedes Muster dokumentieren und die Muster konsequent anwenden.

Verwendung von Cloud-Bausteinen auf ISO-konforme Weise

Die Verwendung von Cloud-Bausteinen im Sinne der ISO-Norm bedeutet, die Strukturen von AWS, Azure und Google Cloud an den Kontrollthemen von Anhang A auszurichten, wie z. B. Zugriffskontrolle, Datentrennung, Protokollierung und Lieferantenmanagement. Wenn Sie Konten, Abonnements, Projekte und Managementgruppen in dieser Sprache erklären können, verwandeln Sie potenziell verwirrende Cloud-Terminologie in ein schlüssiges Qualitätssicherungskonzept.

Jede große Cloud-Plattform hat ihre eigene Terminologie und ihre eigenen Merkmale, aber die ISO-konformen Prinzipien sind ähnlich:

On AWSMehrere Accounts innerhalb einer Organisation mit zentralen Schutzmechanismen ermöglichen die Isolation der Mandanten, während gemeinsam genutzte Tools in separaten Management-Accounts verwaltet werden.

On AzureEntra-Mandanten, Managementgruppen und Abonnements schaffen eine Hierarchie; viele MSPs nutzen ein Abonnement-pro-Kunde-Modell mit gemeinsam genutzten Managementdiensten.

On CumolocityOrganisationen, Ordner und Projekte erzeugen Ebenen; ein Projekt-pro-Mandant-Modell mit zentraler Protokollierung und gemeinsam genutztem Netzwerk ist üblich.

In jedem Fall sollten Sie Ihre gewählten Muster in Architekturdokumenten, Diagrammen und Infrastructure-as-Code-Vorlagen festhalten. So können Sie den Prüfern nachweisen, dass Ihre Entwürfe bewusst erstellt, überprüft, mit Risikobewertungen verknüpft und konsistent implementiert wurden.

Einbettung von Sicherheit in Pipelines und Dokumentation

Durch die Integration von Sicherheitsfunktionen in Pipelines und Dokumentation werden Ihre Mandantenfähigkeitsmuster zu wiederholbaren und nachvollziehbaren Vorgehensweisen. Anstatt sich auf einmalige Konfigurationen zu verlassen, erzwingen Sie Isolation, Protokollierung und Kennzeichnung im Code und schaffen so eine klare Historie darüber, wer was warum geändert hat. Dies unterstützt direkt die Anforderungen der ISO 27001 hinsichtlich Änderungsmanagement, Betriebsplanung und Leistungsbewertung.

Schritt 1 – Schutzmechanismen in den Infrastrukturcode einbauen

Verwenden Sie Vorlagen, Richtlinien und Konfigurationsregeln, um bei der Erstellung einer neuen Umgebung Baselines für Isolation, Verschlüsselung, Protokollierung und Kennzeichnung durchzusetzen.

Schritt 2 – Sicherheitsprüfungen in CI/CD integrieren

Automatisches Scannen von Infrastrukturcode und Cloud-Konfigurationen auf Probleme, die die Mandantentrennung oder andere wichtige Kontrollmechanismen beeinträchtigen könnten, bevor Änderungen in die Produktion gelangen.

Schritt 3 – Entscheidungen und Bedrohungen in der Dokumentation erfassen

Halten Sie in prägnanten Entscheidungsprotokollen und Bedrohungsmodellen fest, warum Sie sich für jedes Muster entschieden haben, welche Bedrohungen Sie berücksichtigt haben und auf welche Kontrollmechanismen Sie sich verlassen.

Als realistisches Ziel für das nächste Quartal sollten Sie zwei oder drei Mietermuster standardisieren, diese in Code und Diagrammen erfassen und mit Ihren Risikobewertungen und den Kontrollen gemäß Anhang A verknüpfen.

Zuordnung von ISO 27001:2022 Anhang A zu Cloud-Diensten und -Mustern

Die Zuordnung von ISO 27001:2022 Anhang A zu Cloud-Diensten und -Mustern schafft eine gemeinsame Sprache zwischen Auditoren und Ingenieuren. Anstatt darüber zu streiten, ob eine Kontrolle „anwendbar“ ist, verweist man auf eine einfache Matrix, die aufzeigt, welche AWS-, Azure- und Google-Cloud-Dienste, Baselines und Berichte die jeweiligen Ziele erfüllen. Dies reduziert den Aufwand bei Audits und macht das Änderungsmanagement planbarer.

ISO 27001:2022 schreibt weder vor, welchen Cloud-Dienst Sie nutzen, noch wie Sie eine Firewall-Regel konfigurieren. Sie definiert Kontrollziele und überlässt Ihnen die Wahl der technischen Mittel. Dies ist beabsichtigt: ISO 27001:2022 konzentriert sich auf das „Was“ der Informationssicherheit (Risikomanagement, Kontrollziele und kontinuierliche Verbesserung) und bleibt technologieneutral, sodass Sie selbst entscheiden können, „Wie“ Sie diese Ziele auf Ihren gewählten Plattformen umsetzen, wie es die Norm vorsieht. In einer komplexen MSP-Umgebung ist die einzige praktikable Möglichkeit, dies überschaubar zu halten, die Erstellung einer einfachen Zuordnung von Kontrollen zu Diensten, der Techniker vertrauen und die Auditoren nachvollziehen können.

Diese Zuordnungstabelle dient als Brücke zwischen der Sprache der Auditoren (Anhang-A-Kontrollen) und der Sprache Ihrer Entwickler (Cloud-Dienste, APIs, Konfigurationsgrundlagen). Durch ihre Pflege gewinnen Sie zudem einen Vorsprung bei der Zuordnung zu anderen Rahmenwerken wie SOC 2 oder branchenspezifischen Standards.

Aufbau einer Kontroll-zu-Service-Matrix

Die Erstellung einer Kontroll-Service-Matrix bedeutet, diejenigen Kontrollen gemäß Anhang A zu identifizieren, die eine starke Cloud-Komponente aufweisen, und anschließend die Services, Konfigurationen und Prozesse aufzulisten, die Sie zur Erfüllung dieser Kontrollen benötigen. Wenn Sie dies einmalig durchführen und pflegen, reduzieren Sie den Aufwand für jedes zukünftige Audit und jede Framework-Mapping-Übung erheblich.

Ein sinnvoller Ausgangspunkt ist es, sich auf die Themen in Anhang A zu konzentrieren, die sich beim Wechsel zur Public Cloud am stärksten verändern, wie zum Beispiel:

Zugriffskontrolle und Identität:

Die Kontrollmechanismen für Benutzerzugriff, privilegierten Zugriff und Authentifizierung werden Identitätsanbietern, rollenbasierter Zugriffskontrolle, Multi-Faktor-Authentifizierung und Zugriffsüberprüfungen in Ihren Cloud-Plattformen zugeordnet.

Protokollierung und Überwachung:

Die Steuerung von Ereignisprotokollierung, Überwachung und Anomalieerkennung ist Cloud-Protokollierungsdiensten, zentralem SIEM, Alarmierungsfunktionen und Runbooks für die Vorfallbearbeitung zugeordnet.

Datensicherung, -wiederherstellung und Datenlöschung:

Die Kontrollen für Datensicherung, Wiederherstellungstests, Aufbewahrung und sichere Löschung sind auf Snapshot-Richtlinien, Backup-Tools, Lebenszyklusregeln und Datenbereinigungsverfahren abgestimmt.

Lieferanten- und Cloud-Nutzung:

Die Kontrollen im Zusammenhang mit der Nutzung von Cloud-Diensten, einschließlich Anhang A 5.23, entsprechen Ihrem Prozess zur Auswahl von Cloud-Diensten, zur Bewertung der gemeinsamen Verantwortung und zur Überwachung der Anbieterzusicherung.

Anschließend listen Sie für jedes Steuerelement die Cloud-Dienste und Konfigurationen auf, auf die Sie angewiesen sind.

Schritt 1 – Wählen Sie die Cloud-lastigen Steuerungsthemen aus

Identifizieren Sie die Kontrollthemen aus Anhang A, die sich in der Cloud am stärksten verändern, wie z. B. Zugriffskontrolle, Protokollierung, Datensicherung und Cloud-Nutzung, und priorisieren Sie diese in Ihrer Matrix.

Schritt 2 – Verknüpfen Sie jede Steuerung mit konkreten Diensten

Für jede Prioritätssteuerung sollten die Identität, die Protokollierung, die Sicherungs- oder Verwaltungsdienste sowie die wichtigsten Konfigurationen erfasst werden, die für deren Wirksamkeit in AWS, Azure oder Google Cloud erforderlich sind.

Schritt 3 – Entscheiden Sie, was als Beweis gilt.

Definieren Sie die Screenshots, Konfigurationsexporte, Protokolle, Berichte oder ISMS-Einträge, die Sie verwenden, um nachzuweisen, dass jede Kontrollmaßnahme implementiert ist und funktioniert. Die genauen Zuordnungen variieren je nach MSP; verwenden Sie dies daher als Leitfaden und passen Sie es an Ihre Architekturen an.

Ziel ist es nicht, eine riesige Tabelle zu erstellen. Vielmehr geht es darum, den Zusammenhang zwischen Kontrollmechanismen und der Realität in der Cloud explizit darzustellen, damit Sie Lücken erkennen und den Prüfern das Design erläutern können.

Angleichung von Ausgangswerten, Rahmenwerken und Belegen

Indem Sie Baselines, Frameworks und Nachweise an Ihrer Matrix ausrichten, wird diese zu einem alltäglichen Werkzeug anstatt zu einer einmaligen Übung. Wenn Sie eine Standardkonfiguration ändern, ein neues Framework einführen oder sich auf interne Audits und Managementbewertungen vorbereiten, konsultieren Sie dieselbe Matrix, anstatt von Grund auf neu zu beginnen.

Sobald Sie über eine grundlegende Matrix verfügen, ergeben sich drei praktische Vorteile:

Technische Baselines lassen sich leichter begründen.
Wenn Sie einen Standard-Build aktualisieren – beispielsweise um die Verschlüsselung überall zu erzwingen – können Sie schnell erkennen, welche Steuerelemente betroffen sind, und Ihre Dokumentation entsprechend aktualisieren.
Externe Frameworks überschneiden sich sauberer.
Die Zuordnung von ISO-Kontrollen zu Cloud-Baselines bedeutet, dass ein Satz technischer Standards mehrere Frameworks erfüllen kann, wodurch Doppelarbeit reduziert wird.
Die Beweislage wird vorhersehbar.
Für jede Kontrollmaßnahme in der Matrix können Sie festlegen, welche Nachweise Sie verwenden werden: Konfigurationsexporte, Screenshots, Protokolle, Richtliniendokumente, Berichte von Überwachungstools oder Ausgaben Ihrer ISMS-Plattform.

Eine dedizierte ISMS-Plattform wie ISMS.online kann hier Abhilfe schaffen, indem sie Ihnen eine zentrale Anlaufstelle bietet, um Kontrollen, Cloud-Ressourcen und Nachweise zu verknüpfen, anstatt diese Informationen über Tabellenkalkulationen, Diagramme und Issue-Tracker zu verteilen. Erstellen Sie in den kommenden Monaten eine erste Matrix für Ihre wichtigsten Services und optimieren Sie diese im Zuge der Weiterentwicklung Ihrer Architekturen.

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.

Buchen Sie Ihre Demo

Operationalisierung des Modells der geteilten Verantwortung über Clouds hinweg

Die Umsetzung des Modells der geteilten Verantwortung in Cloud-Umgebungen bedeutet, dass die Anbieterdiagramme in konkrete Verantwortlichkeiten für Sie und Ihre Kunden umgewandelt werden. Anstelle vager Aussagen zur „Sicherheit der Cloud“ pflegen Sie klare Matrizen, die zeigen, wer für welchen Dienst welche Aufgaben übernimmt, und richten Ihre Verträge, Verfahren und Risikobewertungen an diesen Aufteilungen aus.

Alle großen Cloud-Anbieter veröffentlichen ein Modell der geteilten Verantwortung. Große Anbieter wie AWS, Microsoft Azure und Google Cloud veröffentlichen jeweils eigene Modelle, und Branchenverbände wie die Cloud Security Alliance diskutieren in Ressourcen wie ihrem Blog zur Kommunikation geteilter Cloud-Verantwortlichkeit, wie diese Modelle kommuniziert und in der Praxis umgesetzt werden können. Im Kern sagen sie alle dasselbe aus: Der Anbieter sichert die Cloud, Sie sichern die Daten, die Sie in der Cloud speichern. Sobald Managed Service Provider (MSPs) und Kundenpflichten hinzukommen, wird die Aufteilung komplexer – und für ISO 27001 wichtiger.

ISO 27017, die Erweiterung der ISO 27001 um Cloud-Sicherheit, dient im Wesentlichen dazu, diese Unterschiede zu verdeutlichen. Leitlinien zur Cloud-Sicherheit und Referenzen zur geteilten Verantwortung, darunter auch Community-Projekte wie die OWASP-Materialien zur geteilten Verantwortung in der Cloud, unterstreichen die Rolle der ISO 27017 bei der Klärung der Verantwortlichkeiten von Anbietern und Kunden für Cloud-Dienste und unterstützen Organisationen bei der Anwendung der ISO-27001-Prinzipien in gehosteten Umgebungen. Selbst wenn Sie nicht formell zertifiziert sind, sind die Konzepte nützlich für Ihr ISMS und können Ihnen helfen, Ihr Modell gegenüber Auditoren, Kunden sowie Rechts- und Datenschutzbeauftragten, denen eine nachvollziehbare Verantwortlichkeit wichtig ist, verständlicher zu machen.

Die Umwandlung von Verantwortlichkeitsdiagrammen in konkrete Zuständigkeiten bedeutet, für jeden Managed Service festzuhalten, welche Aufgaben dem Anbieter, Ihnen und dem Kunden obliegen. Sind diese Zuordnungen schriftlich festgehalten und mit Ihrem ISMS synchronisiert, lassen sich Fragen von Auditoren zur Verantwortlichkeit für die einzelnen Kontrollmaßnahmen deutlich einfacher beantworten.

Rund 41 % der Organisationen gaben in der ISMS.online-Umfrage 2025 an, dass das Management von Drittparteirisiken und die Überwachung der Lieferantenkonformität zu ihren größten Herausforderungen im Bereich der Informationssicherheit gehören.

Für jede Ihrer Hauptdienstleistungen – Managed Hosting, Sicherheitsüberwachung, Datensicherung, Identitätsmanagement, Endpunktverwaltung – sollten Sie drei Fragen beantworten können:

Wofür ist der Cloud-Anbieter verantwortlich?
Wofür sind Sie als MSP verantwortlich?
Wofür ist der Kunde verantwortlich?

Am einfachsten lässt sich dies mithilfe einer einfachen Verantwortlichkeitsmatrix (oft RACI-Matrix genannt: verantwortlich, rechenschaftspflichtig, konsultiert, informiert) für jede Dienstleistung oder Dienstleistungskategorie erfassen. Diese Matrix sollte folgenden Kriterien entsprechen:

Ihre Verträge und Leistungsbeschreibungen.
Ihre internen Richtlinien und Verfahren.
Ihre Risikobewertungen und Behandlungspläne.
Ihr Kontrollkartierungs- und Evidenzmodell.

Wenn die Prüfer ein klares und konsistentes Set von Matrizen sehen, die Ihren realen Geschäftsabläufen und Dokumenten entsprechen, gewinnen sie das Vertrauen, dass Sie die gemeinsame Verantwortung verstehen und managen.

Einbettung gemeinsamer Verantwortung in Verträge und die tägliche Arbeit

Die Einbettung geteilter Verantwortung in Verträge und den Arbeitsalltag verleiht RACI-Matrizen ihre Bedeutung. Anstatt nur in einer isolierten Tabelle zu existieren, fließen die Aufteilungen in Rechtsdokumente, operative Handbücher und Schulungsmaterialien ein, sodass die Mitarbeiter im Einklang mit den Zusagen gegenüber Kunden und Wirtschaftsprüfern handeln.

Die gemeinsame Verantwortung muss an zwei Stellen sichtbar sein:

Kundenorientierte Verpflichtungen.
Verträge, Leistungsbeschreibungen, Dienstleistungsbeschreibungen und Anhänge zur Informationssicherheit sollten klarstellen, wer welche Aufgaben unter welchen Bedingungen übernimmt.
Interne Handlungsanweisungen und Schulungen.
Betriebshandbücher, Vorfallverfahren, Einarbeitungsunterlagen und Teambesprechungen müssen auf die gleichen Aufteilungen verweisen, damit die Ingenieure und Supportteams wissen, welche Aktionen in ihren Zuständigkeitsbereich fallen und welche eskaliert werden.

Ihr ISMS ist das Bindeglied, das diese beiden Sichtweisen aufeinander abstimmt. Ändert sich das Verantwortlichkeitsmodell – beispielsweise, wenn Sie mehr Sicherheitskonfigurationen des Kunden verwalten –, sollten sich auch Ihr Umfang, Ihre Risiken, Ihre Verfahren und Ihre Verträge entsprechend anpassen.

Im nächsten Quartal ist es ein realistisches Ziel, RACI-Matrizen für Ihre drei wichtigsten Cloud-Dienste zu erstellen, die entsprechenden Vertragsklauseln zu aktualisieren und Ihre Teams über die neue Aufteilung zu informieren. Für Datenschutzbeauftragte und Rechtsverantwortliche stärkt diese Angleichung zudem Ihre Position, falls eine Aufsichtsbehörde später prüft, wer für eine bestimmte Kontrollmaßnahme verantwortlich war.

Kontinuierliche Einhaltung: Governance, Monitoring und Nachweis

Kontinuierliche Compliance in der Public Cloud bedeutet, die ISO-27001-Governance in die bestehenden Überwachungs-, Berichts- und Automatisierungssysteme zu integrieren, die Sie bereits für den Betrieb Ihrer Dienste nutzen. Anstatt sich einmal jährlich auf Audits vorzubereiten, gestalten Sie Ihre Dashboards, Warnmeldungen und Überprüfungen so, dass sie die Wirksamkeit der Kontrollen nachweisen, interne Audits unterstützen und die Managementbewertung unterstützen.

Öffentliche Cloud-Umgebungen verändern sich ständig. Neue Dienste entstehen, bestehende werden um Funktionen erweitert, Kunden-Workloads verlagern sich und regulatorische Vorgaben entwickeln sich weiter. Ein ISO-27001-Programm, das erst kurz vor einem Audit aktiv wird, kann mit diesem Tempo nicht mithalten. Für Managed Service Provider (MSPs) liegt die Lösung darin, die ISO-27001-Governance in die gleichen Überwachungs-, Berichts- und Automatisierungsprozesse zu integrieren, die auch für den Betrieb der Dienste genutzt werden. So wird die Qualitätssicherung zu einem routinemäßigen Nebenprodukt eines reibungslosen Betriebs.

Die kontinuierliche Einhaltung der Vorschriften ist einfacher, wenn sie auf Systemen basiert, denen Sie bereits im operativen Geschäft vertrauen.

Entwicklung eines Überwachungssystems, das gleichzeitig als Beweismittel dient

Die Entwicklung eines Monitoringsystems, das gleichzeitig als Nachweis dient, erfordert die Planung von Kennzahlen und Warnmeldungen, die sowohl den Kontrollbetrieb als auch die Funktionsfähigkeit der Dienste aufzeigen. Wenn Ihre Dashboards bereits anzeigen, ob Backups durchgeführt, Zugriffe überprüft und Vorfälle planmäßig behandelt wurden, reduziert sich Ihr Aufwand für die Leistungsbewertung nach ISO 27001 erheblich.

Die meisten Organisationen, die an der ISMS.online-Umfrage „State of Information Security 2025“ teilnahmen, gaben an, im vergangenen Jahr bereits von mindestens einem Sicherheitsvorfall im Zusammenhang mit Drittanbietern oder Lieferanten betroffen gewesen zu sein.

Bei der Definition der Überwachungsanforderungen sollten Sie sowohl betriebliche als auch ISO-Ziele berücksichtigen:

Ordnen Sie Warnmeldungen den Steuerelementen zu.

Für jede wichtige Kontrollmaßnahme sollte eine entsprechende Kennzahl oder Warnung vorhanden sein; häufige Warnungen können bedeuten, dass die Kontrollmaßnahme nicht wirksam ist.

Zentralisieren Sie die mandantenübergreifende Sichtbarkeit sorgfältig.

Nutzen Sie die zentrale Protokollierung und Überwachung, um die Aktivitäten aller Kunden einzusehen, beschränken Sie den Zugriff jedoch rollenbasiert, um Isolation und Privatsphäre zu wahren.

Kontext mit Ereignissen erfassen.

Ergänzen Sie die Protokolle um Informationen, die für Audits wichtig sind, z. B. welche Richtlinie eine Behebung ausgelöst hat oder welche Änderungsanforderung eine Konfigurationsänderung genehmigt hat.

Schritt 1 – Entscheiden Sie, welche Kontrollmechanismen eine direkte Überwachung erfordern.

Identifizieren Sie Zugriffs-, Änderungs-, Sicherungs- und ereignisbezogene Kontrollen, bei denen Kennzahlen oder Warnmeldungen die Wirksamkeit im Laufe der Zeit am besten belegen.

Schritt 2 – Dashboards und Warnmeldungen für diese Steuerelemente entwerfen

Konfigurieren Sie Dashboards und Warnmeldungen so, dass sie den Kontrollstatus, Trends und Ausreißer in einer Sprache anzeigen, die Ihre Führungskräfte und Prüfer verstehen.

Schritt 3 – Überwachungsergebnisse in der internen Revision und Überprüfung wiederverwenden

Die Überwachungsberichte sollten in interne Audits und Managementbewertungen einfließen, damit die Leistungsbewertung gemäß Klausel 9 auf realen Daten und nicht auf Meinungen basiert.

Wenn Sie einem Auditor zeigen können, dass Ihre Dashboards und Berichte bereits seine Fragen zur Kontrollfunktion beantworten, verschwimmt die Grenze zwischen Betrieb und Compliance erfreulicherweise.

Automatisierung, Berichterstattung und Auslöser für Veränderungen

Automatisierung, Reporting und Auslöser für Änderungen gewährleisten die kontinuierliche Einhaltung der Compliance-Vorgaben über viele Mandanten hinweg. Anstatt jede Umgebung manuell zu prüfen, werden Baselines im Code festgelegt, der Kontrollstatus für die Führungsebene zusammengefasst und klare Bedingungen für die erneute Überprüfung von Risiken und Kontrollen definiert.

Um sicherzustellen, dass viele Mieter Ihre ISO 27001-Verpflichtungen einhalten, reicht eine manuelle Überprüfung nicht aus. Sie benötigen Folgendes:

Automatisierung zur Durchsetzung von Baselines.

Richtlinien als Code, Konfigurationsmanagement- und Behebungswerkzeuge sorgen dafür, dass Umgebungen mit Ihren Standards übereinstimmen und protokollieren, wann Abweichungen korrigiert werden.

Regelmäßige Berichte zur Unternehmensführung.

Die Dashboards und Zusammenfassungen für die Führungsebene umfassen den Kontrollstatus, Ausnahmen, Trends und ausstehende Risikobehandlungen, die in Klausel 9 und die Managementbewertung einfließen.

Klare Auslöser, um die Steuerelemente erneut zu überprüfen:

Neue Cloud-Dienste, größere Architekturänderungen, wiederkehrende Warnmeldungen oder regulatorische Änderungen sollten allesamt Anlass für eine Überprüfung Ihrer Risikobewertungen und Kontrollmaßnahmen sein.

Eine Plattform wie ISMS.online unterstützt Sie dabei, diese operativen Signale mit dem ISMS selbst zu verknüpfen – Risiken, Kontrollen, Maßnahmen und Nachweise zu verbinden –, sodass das Managementsystem die Vorgänge in der Cloud präzise widerspiegelt. Konzentrieren Sie sich in den kommenden Monaten darauf, einige wenige, aber wirkungsvolle Kontrollen zu identifizieren, diese in Ihre Überwachungs- und Automatisierungsprozesse zu integrieren und sicherzustellen, dass die resultierenden Berichte in Ihre internen Audit- und Managementbewertungszyklen einfließen. Für IT- und Sicherheitsexperten reduziert dies aufwendige manuelle Prüfungen und führt zu sichtbaren Compliance-Ergebnissen.

ISMS.online unterstützt über 100 Standards und Vorschriften und bietet Ihnen eine einzige Plattform für alle Ihre Compliance-Anforderungen.

Buchen Sie Ihre Demo

„ISO in der Cloud“ in einen kommerziellen Vorteil verwandeln

Um „ISO in der Cloud“ in einen Wettbewerbsvorteil zu verwandeln, sollten Sie Ihr Cloud-fähiges ISMS als integralen Bestandteil Ihres Angebots betrachten und nicht nur als reines Konformitätszertifikat. Anstatt Ihre Vorgehensweise hinter einem Zertifikat zu verbergen, bieten Sie Isolationsoptionen, Nachweise und eine flexible Governance als Funktionen an, die den Aufwand für Ihre Kunden reduzieren und Vertrauen schaffen.

Viele Managed Service Provider (MSPs) betrachten ISO 27001 als notwendiges Gütesiegel für Ausschreibungen. In der modernen Public-Cloud-Praxis kann es jedoch weit mehr leisten: Es kann dazu beitragen, Ihre Services zu differenzieren, Vertriebshürden zu reduzieren und langfristiges Vertrauen aufzubauen. Brancheninformationen zur Verwendung von ISO 27001 und Cloud-Sicherheit in Ausschreibungen und im Marketing, einschließlich Leitfäden großer Anbieter wie IBM zur Positionierung von Zertifizierungen in Enterprise-Kaufprozessen, gehen oft von dieser „Ausschreibungsvoraussetzung“ aus und zeigen dann, wie man darüber hinausgehen kann, beispielsweise in IBMs Leitfaden zu Sicherheitsbescheinigungen in Ausschreibungen. Wenn Ihr Informationssicherheitsmanagementsystem (ISMS) die Realität von Multi-Tenant-Umgebungen klar beschreibt, können Sie diese Arbeit wiederverwenden, um Fragen potenzieller Kunden schneller und glaubwürdiger zu beantworten.

Kunden, insbesondere in regulierten Branchen, möchten zunehmend wissen, wie Sie ihre Workloads in der Cloud sichern, und nicht nur, ob Sie über ein Zertifikat verfügen. Dies deckt sich mit den Erkenntnissen vieler Leitfäden zu Cloud-Sicherheit und -Marketing: Käufer, vor allem in regulierten Branchen, erwarten immer häufiger detaillierte Erläuterungen zur Sicherung von Workloads und nicht nur eine Liste von Zertifikaten. Dies spiegelt sich auch in den Empfehlungen von Anbietern zu Best Practices im Cloud-Sicherheitsmarketing wider, beispielsweise in den Best Practices von Oracle. Wenn Sie Ihre ISO-konformen Cloud-Praktiken in klare Serviceoptionen und wiederverwendbare Nachweise umwandeln können, erleichtern Sie es Ihren Kunden, sich für Sie zu entscheiden und diese Entscheidung intern zu begründen.

Verpackungssicherung als Merkmale, nicht nur als Zertifikate

Verpackungssicherung als Merkmale bedeutet, zu erklären wie Sie sichern Workloads in der Cloud und verfügen nicht nur über eine ISO 27001-Zertifizierung. Wenn Sie Isolationsstufen, Nachweispakete und eine klare Aufteilung der Verantwortlichkeiten als Teil Ihrer Dienstleistungen anbieten, erleichtern Sie Ihren Vertriebs- und Kundenerfolgsteams die Arbeit.

Laut der ISMS.online-Umfrage 2025 erwarten Kunden zunehmend von ihren Lieferanten, dass sie sich an formale Rahmenwerke wie ISO 27001, ISO 27701, DSGVO, Cyber Essentials, SOC 2 und neue KI-Standards anpassen.

Sie können Ihre ISO-konformen Cloud-Praktiken nutzen, um:

Bieten Sie klare Service-Stufen an, die die Isolations- und Sicherheitsniveaus der Mieter mit dokumentierten, ISO-konformen Kontrollen verknüpfen.

Bereitstellung standardisierter Nachweispakete, die Kunden in ihren eigenen Audits wiederverwenden können, einschließlich Matrizen, Zuordnungen, Protokollen und zusammenfassenden Risikoansichten.

Verkürzen Sie die Beschaffungszyklen, indem Sie eine kohärente, vorgefertigte Geschichte darüber präsentieren, wie Ihr ISMS die Public Cloud abdeckt – in einer Sprache, die Sicherheitsteams verstehen.

Für Gründer und Führungskräfte verwandeln diese Elemente Sicherheit von einem Einwand in einen Kaufgrund. Für CISOs und Datenschutzbeauftragte auf Kundenseite bieten sie genügend Transparenz, um Ihren Ansätzen zu vertrauen, ohne diese analysieren zu müssen. Für Ihre eigenen Anwender bestätigen sie den Entwicklungsaufwand, der in Ihre Architekturen und Kontrollen geflossen ist.

Die von Ihnen geleistete Arbeit zur Dokumentation von Umfang, Mustern, Kontrollzuordnungen und Überwachung kann selektiv in Vertriebsmaterialien und der Kundenkommunikation wiederverwendet werden, solange Sie die Genauigkeit wahren und darauf ausgerichtet sind, den Kunden bei der Erfüllung ihrer eigenen Sicherungsverpflichtungen zu helfen.

Messung und Kommunikation der kommerziellen Auswirkungen

Die Messung und Kommunikation der wirtschaftlichen Auswirkungen Ihrer ISO-konformen Cloud-Praxis trägt dazu bei, Compliance als Umsatztreiber neu zu positionieren. Wenn Sie auf schnellere Fragebögen, höhere Abschlussquoten und Vertragsverlängerungen verweisen können, bei denen Sicherheit als Grund für die Beibehaltung genannt wird, lässt sich Ihre Investition in das ISMS deutlich leichter rechtfertigen.

Wenn ISO 27001 als Umsatztreiber und nicht als Kostenfaktor wahrgenommen werden soll, ist es hilfreich, einige einfache Kennzahlen zu erfassen:

Erfolgsquote in regulierten oder sicherheitssensiblen Sektoren.

Zeitspanne vom Sicherheitsfragebogen bis zur Vertragsunterzeichnung.

Geschäfte scheiterten aus Sicherheits- oder Compliance-Gründen.

Beibehaltung der Geschäftsbeziehung, wenn Sicherheit und Compliance die wichtigsten Gründe für eine Verlängerung sind.

Schritt 1 – Wählen Sie eine kleine Anzahl von KPIs für die kommerzielle Sicherheit aus

Wählen Sie zwei oder drei Kennzahlen aus, wie z. B. die Bearbeitungszeit von Fragebögen oder die Erfolgsquote in regulierten Sektoren, die eindeutig von Ihrer Prüfungsgeschichte beeinflusst werden.

Schritt 2 – Erfassen und überprüfen Sie diese Kennzahlen regelmäßig.

Erstellen Sie einfache Berichte, die Trends im Zeitverlauf aufzeigen, und diskutieren Sie diese zusammen mit traditionellen Vertriebskennzahlen in Geschäfts- und Führungsmeetings.

Schritt 3 – Erkenntnisse in Ihr ISMS und Ihre Angebote einfließen lassen

Wenn Sie durch die Bereitstellung umfangreicherer Sicherheitspakete oder stärkerer Isolationsoptionen bessere Ergebnisse erzielen, sollten Sie dies in Ihren Dienstleistungen und in Ihrer ISMS-Dokumentation widerspiegeln.

Sie können Ihre Account- und Customer-Success-Teams auch darin schulen, den kontinuierlichen Sicherheitsnutzen zu kommunizieren: regelmäßige Kontrollüberprüfungen, Nachweisdokumentationen, Roadmap-Briefings und Reaktionen auf neue Bedrohungen oder regulatorische Änderungen. Dadurch bleibt ISO 27001 in den Erneuerungsgesprächen präsent, ohne dass diese in reine Audit-Meetings ausarten.

Buchen Sie noch heute eine Demo mit ISMS.online

ISMS.online unterstützt Sie beim Betrieb eines einheitlichen, Cloud-fähigen ISO 27001-Managementsystems, das sich nahtlos in die tatsächliche Nutzung von AWS, Azure und Google Cloud durch Ihren Managed Service Provider (MSP) einfügt. Anstatt mit Tabellenkalkulationen, Diagrammen und unstrukturierten Dokumentationsordnern zu jonglieren, können Sie Risiken, Kontrollen, Verantwortlichkeitsmatrizen und Cloud-spezifische Dokumentationen zentral verwalten und mit der täglichen Arbeit Ihrer Teams verknüpfen.

Für Gründer und Führungskräfte von Managed Service Providern (MSPs) bedeutet dies einen besseren Überblick darüber, wie ihre AWS-, Azure- und Google Cloud-Praktiken mit ISO 27001:2022 zusammenhängen, und mehr Sicherheit, dass ihre Zertifizierung die tatsächlichen Gegebenheiten in ihren Umgebungen widerspiegelt. Compliance-Managern bietet sie strukturierte Unterstützung bei der Aktualisierung von Geltungsbereich, Risikobewertungen, Annex-A-Zuordnungen und Nachweisen im Zuge des Wachstums ihrer Cloud-Infrastruktur, einschließlich cloudspezifischer Kontrollen, beispielsweise zur Nutzung von Cloud-Diensten. Serviceleitern, Architekten und Sicherheitsexperten bietet sie praktische Möglichkeiten, Referenzarchitekturen, Änderungsworkflows und Überwachungsergebnisse in das ISMS zu integrieren, ohne zusätzlichen Dokumentationsaufwand zu verursachen.

Wenn Sie Public-Cloud-Plattformen ernsthaft nutzen und gleichzeitig die Anforderungen der ISO 27001 erfüllen möchten – und diesen Vorteil Ihren Kunden spürbar machen wollen –, ist die Buchung einer kurzen Demo von ISMS.online der nächste logische Schritt. Sie sehen, wie Ihre bestehenden Cloud-Architekturen und -Prozesse in ein dynamisches, auditbereites ISMS überführt werden können, das mit Ihrem Managed-Services-Geschäft skaliert und Ihr Team entlastet.

Diese Informationen sind allgemeiner Natur und stellen keine Rechts-, Zertifizierungs- oder Prüfungsberatung dar; Sie sollten sich bei Entscheidungen, die Ihre Verpflichtungen betreffen, stets an einen qualifizierten Fachmann oder eine Zertifizierungsstelle wenden.

Häufig gestellte Fragen (FAQ)

Wie wirkt sich die Migration von MSP-Kunden in die Public Cloud konkret auf Ihre ISO 27001-Konformität aus?

Die Migration von Kunden zu AWS, Azure oder Google Cloud verändert Ihre ISO 27001-Konformität, da sich Ihr Geltungsbereich, Ihre Risiken und Kontrollen von physischer Ausrüstung auf Cloud-Plattformen, Konten und Automatisierung verlagern, und Ihr ISMS muss diese Verlagerung erfassen, sonst spiegelt es nicht mehr wider, wie Sie Ihre Dienstleistungen tatsächlich erbringen.

Welche ISMS-Elemente sollten Sie für die Public Cloud zuerst aktualisieren?

Es gibt drei Bereiche, die die meisten nach ISO 27001 zertifizierten Managed Service Provider (MSPs) als Erstes erneut überprüfen sollten:

Umfang und Kontext:

In Ihrer Geltungsbereichsbeschreibung sollten die Cloud-Anbieter, Kernkonten/Abonnements, Regionen und gemeinsam genutzten Managementebenen (z. B. zentrale Protokollierung, Sicherheitstools, CI/CD, Identitätsmanagement) explizit genannt werden. Dadurch wird dem Auditor genau verdeutlicht, wo Ihre ISO-27001-Grenzen liegen und welche Plattformen Ihre Managed Services unterstützen.

Anlageninventar und -klassifizierung:

Physische Server werden zu Cloud-Konten, Projekte, Dienste, Pipelines und KonfigurationenLanding Zones, Tenant-Baselines, Management-Abonnements, gemeinsam genutzte Monitoring-Stacks und Automatisierungen sollten als Informationsressourcen behandelt werden, deren verarbeitete Daten klar klassifiziert sind. So lässt sich genau nachvollziehen, wo Kundeninformationen in AWS, Azure oder Google Cloud gespeichert sind.

Risikobewertung und Behandlung:

Physische Bedrohungen verlieren an Bedeutung; Cloud-bezogene Risiken nehmen zu. Fehlkonfigurationen, zu weit gefasste Rollen, ungeschützte Verwaltungsschnittstellen, schwache API-Kontrollen, unsichere Automatisierung und regionale Ausfälle des Anbieters sollten in Ihrem Risikoregister erfasst sein, wobei die entsprechenden Maßnahmen den Kontrollen gemäß Anhang A zugeordnet werden sollten. A.5.23 (Nutzung von Cloud-Diensten) und die Netzwerksteuerung in A.8.20–A.8.22.

Wenn Ihr ISMS immer noch wie ein On-Premises-Betrieb wirkt, während Ihre Kunden in der Public Cloud arbeiten, wird ein Auditor hinterfragen, ob Ihr Risikobild und Ihr Kontrollsystem noch gültig sind.

Wie verändert die Public Cloud das Verständnis von „Kontrolle“ in der Praxis?

In der öffentlichen Cloud wird viel Kontrolle ausgedrückt durch Muster und Automatisierung, nicht nur Dokumente:

Zugriffskontrolle findet sich in Identitätsanbietern, Rollen, Richtlinien, bedingtem Zugriff und Workflows für privilegierten Zugriff.
Netzwerksegmentierung zeigt sich in VPCs/VNets, Sicherheitsgruppen, NSGs, Firewalls, privaten Endpunkten und Peering-Regeln.
Datensicherung, Überwachung und Störungsbehebung basieren auf nativen Diensten, die über Infrastructure-as-Code, serverlose Funktionen und Runbooks miteinander verbunden sind.

Für einen nach ISO 27001 zertifizierten Managed Service Provider (MSP) besteht der Test darin, ob diese Hebel folgende Eigenschaften aufweisen:

Standardisiert: in Muster und Ausgangswerte, anstatt für jedes Projekt individuell zu sein.
Besitz: durch klare Verantwortlichkeiten zwischen Anbieter, Ihnen und dem Kunden.
Regiert: durch Ihr ISMS (Änderung, Test, Überprüfung), nicht dem Motto „Was auch immer das Cloud-Team bevorzugt“ überlassen.

Wenn diese Cloud-Realitäten in einer strukturierten ISMS-Plattform wie ISMS.online abgebildet werden – mit aktualisiertem Geltungsbereich, Risiken, Kontrollen und Nachweisen –, können Sie den Auditoren versichern, dass Ihre Zertifizierung immer noch Ihrer tatsächlichen Arbeitsweise entspricht.

Wie sollte ein Managed Service Provider (MSP) Multi-Tenant-Cloud-Architekturen entwerfen, die dennoch den Anforderungen von ISO 27001 entsprechen?

Sie halten ISO 27001 auf Ihrer Seite, indem Sie sich auf Folgendes beschränken: geringe Anzahl von Mehrmietermusternindem jedes Risiko mit den Kontrollmaßnahmen gemäß Anhang A verknüpft und diese konsequent angewendet werden, anstatt für jeden neuen Kunden oder jede neue Arbeitslast ein maßgeschneidertes Design zu entwickeln.

Welche Mandantenfähigkeitsmodelle eignen sich tendenziell gut für ISO 27001 in AWS, Azure und Google Cloud?

Die meisten Managed Service Provider (MSPs) einigen sich auf zwei oder drei Standardmodelle und behandeln alles andere als Ausnahme, die einer stärkeren Begründung bedarf:

Gemeinsame Mietverhältnisse für Dienstleistungen mit geringerem Risiko:

Mehrere Kunden teilen sich die zugrundeliegende Infrastruktur (z. B. gemeinsam genutzte Kubernetes-Cluster oder mandantenfähige SaaS-Lösungen), wobei die Isolation durch IDs, Schemas, Namensräume und Autorisierung gewährleistet wird. Um die ISO-Konformität zu gewährleisten, sollten Sie Folgendes explizit angeben:

Wie Mandantendaten getrennt werden (Netzwerksegmentierung, Datenbanksteuerung, mandantenspezifische Schlüssel).
Wie die Isolation getestet und überwacht wird (automatisierte Prüfungen, simulierte Angriffe, Protokollierung).
Wie Sie einen lärmenden oder problematischen Mieter im Zaum halten (Gebührenbegrenzung, Drosselung, sichere Sperrung).

Eigenes Konto/Abonnement/Projekt pro Mandant für höherwertige Dienste:

Jeder Kunde verfügt über ein eigenes Konto, Abonnement oder Projekt, die mit gemeinsamen Landing Zones und Management-Tools verbunden sind. Dies entspricht den Anforderungen von Anhang A hinsichtlich der Trennung von Daten, erhöht aber die Anzahl der Umgebungen, die Sie an Ihre Baselines anpassen müssen.

Gemeinsame Steuerungsebene mit getrennten Datenebenen:

Eine zentrale Steuerungsebene (CI/CD, Protokollierung, Sicherheitstools) dient separate Datenebenen Dort, wo Kunden-Workloads und -Daten gespeichert sind. Dies ermöglicht operative Effizienz bei gleichzeitiger Wahrung klarer Datenisolationsgrenzen.

Am wichtigsten ist, dass Sie Folgendes nachweisen können:

A dokumentierte Referenzarchitektur für jedes Muster, mit Diagrammen und Infrastruktur-als-Code-Beispielen.
Eine Spur von jedem Muster in Ihre Gefahrenregister und Anhang A-Kontrollen (zum Beispiel A.8.20–A.8.22 für Netzwerksicherheit und -trennung).
Ändern und testen Sie Prozesse, die sicherstellen, dass jeder neue Mieter einem bekannten Muster folgt und nicht „irgendetwas, was ein Techniker unter Druck gemacht hat“.

Wenn diese Architekturen und Kontrollen in Ihrem ISMS integriert sind und Ihre Teams mit denselben Entwürfen arbeiten, können Sie die Mandantenfähigkeit gegenüber Prüfern und Käufern erklären, ohne die unstrukturierten Cloud-Konsolen per Bildschirmfreigabe präsentieren zu müssen.

Wie erklären Sie Ihr Mandantenmodell so, dass Prüfer und Kunden ihm vertrauen?

Beide Zielgruppen wünschen sich eine reibungslose Route von Risiko → Design → Konfiguration → NachweisEine einfache Erzählung funktioniert gut:

Risiko: „Mandantenübergreifender Datenzugriff auf einer gemeinsamen Plattform.“
Design: „Cluster-Pool-Muster mit mandantenspezifischen Namensräumen, Netzwerkrichtlinien und mandantenbezogenen Verschlüsselungsschlüsseln.“
Konfiguration: „Basisvorlagen und Leitplanken, die wir über Terraform oder Bereitstellungspipelines anwenden.“
Beweis: „Testergebnisse, Isolationsprüfungen, Protokolle und Vorfälle, die zeigen, dass die Kontrollmechanismen über einen längeren Zeitraum funktionieren.“

Durch die Integration dieser Kette in Ihr ISMS, ergänzt durch Diagramme und Baselines, können Sie Auditoren oder Interessenten Ihr Modell ruhig und nachvollziehbar präsentieren. ISMS.online hilft Ihnen, Risiken, Architekturen und Kontrollen zentral zu verwalten, sodass jede neue Umgebung Ihre bestehende Struktur stärkt, anstatt Verwirrung zu stiften.

Wie kann ein Managed Service Provider (MSP) die Kontrollen des Anhangs A der ISO 27001:2022 den Diensten von AWS, Azure und Google Cloud zuordnen?

Sie machen Anhang A in AWS, Azure und Google Cloud nutzbar, indem Sie jedes Steuerelement-Design übersetzen in spezifische Dienste, Basiskonfigurationen und unterstützende Prozesseund dies in einer Steuerungs-zu-Dienstleistungs-Zuordnung festzuhalten, der sowohl Ihre Ingenieure als auch Ihre Auditoren folgen können.

Wie sieht eine praktische Zuordnung von Steuerung zu Dienst aus?

Eine einfache, erweiterbare Matrix könnte folgendermaßen aussehen:

Schwerpunktbereich Anhang A	Cloud-Dienste im Geltungsbereich	Basiskonfiguration und Prozesse
Zugangskontrolle (A.5, A.8.x-Familie)	IAM, Azure AD, Cloud IAM, PIM/PAM	Standardrollen, MFA, Just-in-Time-Erhöhung
Protokollierung und Überwachung (A.8.15–A.8.16)	CloudTrail, Defender, Cloud-Protokollierung, SIEM	Zentralisierung, Alarmweiterleitung, Rufbereitschaft
Datensicherung und -wiederherstellung (A.8.13–A.8.14)	Snapshots, Backup-Tresore, regionsübergreifende Kopien	Zeitpläne, Aufbewahrung, Wiederherstellungstests
Nutzung von Cloud-Diensten (A.5.23)	Anbieterkataloge, Service-Onboarding-Prozess	Lieferantenbewertung, Risikofreigabe, Ausstiegsplanung

Für jede von Ihnen definierte Zeile:

Welche Dienste: Sie verwenden dieses Thema auf jeder Plattform.
Die Grundeinstellungen Sie erwarten (Verschlüsselung, Aufbewahrung, privater Zugriff, Protokollierung, MFA).
Die Beweis Sie können (IaC, Berichte, Tickets, Protokolle, Screenshots, falls erforderlich) erstellen.

Anschließend ordnen Sie jede Zeile den entsprechenden Steuerelementen in Anhang A zu und markieren, ob ein Steuerelement Folgendes ist:

Wird vom Anbieter bearbeitet: (physische Sicherheit des Rechenzentrums, Kerninfrastruktur).
Von Ihnen implementiert und überwacht: (Konfiguration, Überwachung, Reaktion).
Abhängig vom Kunden: (Sicherheit auf Anwendungsebene, einige Entscheidungen zur Datenverarbeitung).

Diese Zuordnung dient als gemeinsame Referenz für Sicherheits-, Entwicklungs- und Prüfungsteams und als Grundlage, auf der Sie aufbauen können, wenn Ihre Cloud-Infrastruktur wächst.

Warum ist diese Zuordnung auch über die ISO 27001-Zertifizierung hinaus nützlich?

Sobald Sie eine gute Zuordnung von Steuerung zu Dienst erstellt haben, können Sie diese auf verschiedene Weise wiederverwenden:

Erweitern Sie es, um Folgendes abzudecken SOC 2, NIS 2, DORA oder ISO 27701, anstatt neue Matrizen von Grund auf zu entwerfen.
Beschleunigen Sie die Beantwortung von Sicherheitsfragebögen und Angebotsanfragen, da Sie bereits wissen, welche Muster und Dienstleistungen gängige Anforderungen erfüllen.
Geben Sie Ihren Teams ein einzige Quelle der Wahrheit wie AWS, Azure und Google Cloud konfiguriert und betrieben werden müssen, um innerhalb Ihres ISMS zu bleiben.

Die Speicherung dieser Abbildung in einer integrierten ISMS-Plattform wie ISMS.online – zusammen mit Risiken, Richtlinien, SoAs und internen Audits – bedeutet, dass jede Änderung an Cloud-Diensten oder -Mustern automatisch in Ihre Assurance-Historie einfließt, anstatt in einer vergessenen Tabellenkalkulation zu verschwinden.

Was bedeutet geteilte Verantwortung konkret für einen nach ISO 27001 zertifizierten Managed Service Provider (MSP) in der Public Cloud?

Für einen nach ISO 27001 zertifizierten Managed Service Provider (MSP) bedeutet geteilte Verantwortung in der Public Cloud, dass Sie explizit festgelegt, dokumentiert und vereinbart, wer was tut für jeden wichtigen Kontrollbereich, und dieses Bild ist in Ihrem ISMS, Ihren Verträgen, Leistungsbeschreibungen und Betriebshandbüchern einheitlich.

Wie lässt sich geteilte Verantwortung von einer bloßen Abfolge in etwas Überprüfbares umwandeln?

Eine einfache Methode besteht darin, ein/eine Verantwortungsmatrix pro Dienst, üblicherweise mithilfe von RACI:

Verantwortlich: derjenige, der die Arbeiten ausführt (z. B. Mandanten konfigurieren, Backups durchführen, Warnmeldungen anpassen).
Verantwortlich: Wer trägt das Risiko und das Ergebnis (Sie, der Kunde oder manchmal beide)?
Konsultiert: Wer liefert Input (Kundensicherheit, Rechtsabteilung, Dateneigentümer)?
Informiert: Wer benötigt Aktualisierungen (Account Manager, Kundenbeteiligte)?

Wenden Sie diese Matrix auf verschiedene Kontrollthemen an, wie zum Beispiel:

Mandanten-, Plattform- und Netzwerksicherheit.
Identitäts- und Zugriffsverwaltung.
Backup-, Wiederherstellungs- und Ausfallsicherheitstests.
Protokollierung, Überwachung und Alarmbearbeitung.
Compliance-Berichterstattung und kundenorientierte Qualitätssicherung.

Jede Matrix sollte mit Folgendem übereinstimmen:

Verträge und Leistungsbeschreibungen: So sind Umfang und Annahmen explizit festgelegt.
Intern Betriebshandbücher und DiagrammeDaher folgen auch die Ingenieure der gleichen Arbeitsteilung.
Risiken und Kontrollmaßnahmen: in Ihrem ISMS, insbesondere dort, wo Sie auf das Handeln Ihrer Kunden angewiesen sind.

Wenn Sie einen Service anpassen – beispielsweise die Sicherheit auf Anwendungsebene erhöhen oder der Kunde mehr operative Kontrolle übernimmt –, aktualisieren Sie die Matrix, überarbeiten Sie Ihre Dokumentation und lassen Sie diese Änderung intern prüfen. Diese Historie bietet Ihnen im Falle eines Vorfalls oder einer Streitigkeit eine fundierte Position.

Wie kann ISO 27017 Ihr Modell der gemeinsamen Verantwortung stärken?

ISO 27017 bietet cloudspezifische Sicherheitsrichtlinien, die ISO 27001 und ISO 27002 ergänzen. Wenn Sie diese zur Gestaltung Ihres Modells der gemeinsamen Verantwortung nutzen, können Sie Folgendes erreichen:

Zeigen Sie Prüfern und Kunden, dass Ihre Aufgabenteilung folgendermaßen aussieht: veröffentlichte bewährte Verfahren, nicht nur ein Blick aufs Haus.
Klärung von Unklarheiten, beispielsweise wer virtuelle Firewalls konfiguriert, wer Verschlüsselungsschlüssel verwaltet und wer virtuelle Maschinen, Container oder serverlose Funktionen absichert.
Reduzieren Sie Reibungsverluste beim Onboarding, indem Sie ein standardisiertes Verantwortungsmodell das den ISO-Richtlinien entspricht.

Die Einbeziehung von ISO 27017 in Ihr ISMS und Ihre Kundenkommunikation macht die geteilte Verantwortung von einem Marketing-Diagramm zu einem Instrument, das auch ISO 27001-Audits und Gesprächen mit Aufsichtsbehörden standhält. ISMS.online unterstützt Sie dabei, Ihre Verantwortungsmodelle, Risikoregister und Kontrollzuordnungen mit der Weiterentwicklung Ihrer Cloud-Dienste zu synchronisieren.

Wie können Managed Service Provider (MSPs) überzeugende Nachweise für ISO 27001-Audits generieren, wenn Workloads in der Public Cloud ausgeführt werden?

Sie generieren überzeugende ISO 27001-Nachweise in der Public Cloud, indem Sie zeigen, dass Ihre Das Managementsystem integriert die Cloud vollständig. und dass dein Cloud-Plattformen werden konsistent betrieben mit diesem System über Mieter, Regionen und Dienste hinweg.

Welche ISMS-Artefakte sollten Ihre Nutzung von AWS, Azure und Google Cloud klar aufzeigen?

Auf der Seite der Managementsysteme werden die Prüfer darauf achten, ob der Begriff „Cloud“ explizit erscheint in:

Ihr Umfangsanweisung und Kontext, einschließlich der Abhängigkeit von bestimmten Anbietern und gemeinsam genutzten Managementplattformen.
Risikobewertungen: und Behandlungspläne, die cloudspezifische Probleme wie Fehlkonfigurationen, Identitätswucherung, Regionsausfälle und Lieferkettenabhängigkeiten hervorheben.
Die Erklärung zur Anwendbarkeitinsbesondere dort, wo Kontrollen von Anbietern implementiert oder mit Kunden geteilt werden.
Interne Prüfungspläne und -berichte: die Cloud-Governance-Aktivitäten wie Landing-Zone-Reviews, Zugriffsüberprüfungen und Konfigurationsabweichungsprüfungen umfassen.
Input und Output der Managementbewertung: Hier werden Cloud-Vorfälle, Änderungen und Leistungskennzahlen besprochen und Entscheidungen festgehalten.

Diese Artefakte belegen, dass Cloud-Lösungen Teil Ihres normalen Plan-Do-Check-Act-Zyklus sind und nicht etwas, das informell außerhalb des ISMS behandelt wird.

Welche Nachweise auf Cloud-Ebene beruhigen ISO 27001-Auditoren in der Regel?

Auf technischer Ebene benötigen Wirtschaftsprüfer in der Regel eine Mischung aus Konfigurations-, Überwachungs- und Betriebsaufzeichnungen, die sich auf Ihre Kontrollmechanismen beziehen, zum Beispiel:

Zugriffsprüfungsprotokolle: für Landing Zones, Mandantenumgebungen und Management-Tools, einschließlich der Frage, wie privilegierte Zugriffe genehmigt und entfernt werden.
Konfigurationsbaselines und Driftberichte: (z. B. IaC-Vorlagen, Richtlinienpakete, Dashboards zur Konfigurationskonformität), die zeigen, wie Sie Fehlkonfigurationen erkennen und korrigieren.
Nachweise zur Datensicherung und -wiederherstellung: wie z. B. Sicherungspläne, Auftragsberichte, Wiederherstellungstestprotokolle und die Behandlung fehlgeschlagener Aufträge.
Protokollierung und Überwachung der Ausgaben: einschließlich SIEM-Dashboards, Beispielwarnungen, Tuning-Protokollen und beispielhaften Vorfallzeitplänen.
Änderungs- und Störungstickets: die zeigen, wie reale Ereignisse Ihre Änderungs- und Vorfallmanagement-Workflows durchlaufen haben.

Indem Sie diese Materialien in einer strukturierten Umgebung zusammenführen – anstatt Screenshots auf verschiedenen Systemen zu suchen – sparen Sie Zeit und sorgen für eine konsistentere Dokumentation. ISMS.online hilft Ihnen, jedes Beweisstück mit dem entsprechenden Risiko, der Kontrolle und dem Service zu verknüpfen, sodass Sie es sowohl für Audits als auch für Kundendokumentationen wiederverwenden können, ohne alles von Grund auf neu erstellen zu müssen.

Wie kann ein Managed Service Provider (MSP) die Cloud-orientierte ISO 27001-Konformität in einen kommerziellen Vorteil verwandeln?

Sie machen aus der Cloud-fähigen ISO 27001-Konformität einen Wettbewerbsvorteil, indem Sie Ihre Managed Services so gestalten und beschreiben, dass Kunden das Gefühl haben, dass Sie verringern Sie ihren Arbeitsaufwand im Bereich Sicherheit und Compliance in der öffentlichen Cloud, anstatt sie alles selbst zusammensetzen zu lassen.

Wie können Sie Public-Cloud-Dienste so bündeln, dass Ihre Stärken gemäß ISO 27001 deutlich erkennbar sind?

Ein praktischer Ansatz besteht darin, einige wenige zu definieren. benannte Serviceebenen die Architektur, Sicherheit und Preis miteinander verbinden:

Jede Stufe kombiniert ein Mieterisolationsmodell (gepoolt, hybrid, dediziert) mit:

Definierte Überwachungs- und Berichtstiefe.
Vereinbarte Häufigkeit von Zugriffsüberprüfungen und Wiederherstellungstests.
Klare Verpflichtungen und Kommunikationsmuster für die Reaktion auf Vorfälle.

Sie unterstützen dann jede Stufe mit:

Ein Standard Verantwortungsmatrix für diese Stufe, damit die Kunden genau sehen, was Sie abdecken und was ihnen erhalten bleibt.
Ein Matching Kontroll- und Beweismittelpaket, in der Sie auflisten, welche Themen gemäß Anhang A Sie bearbeiten und welche Artefakte Kunden im Rahmen der Due-Diligence-Prüfung erwarten können.
Mehrweg Inhalt der Ausschreibung und des FragebogensSo müssen Ihre Teams nicht für jeden potenziellen Kunden die Sicherheitsantworten neu schreiben.

Von dort aus können Sie Folgendes verfolgen:

Erfolgsquoten bei Aufträgen, bei denen Käufer explizit nach ISO 27001 oder Public-Cloud-Sicherheit fragten.
Zeitspanne vom ersten Sicherheitsfragebogen bis zur Vertragsunterzeichnung.
Gründe für Erneuerung und Erweiterung, die Sicherheit, Compliance oder ein beruhigendes Gefühl betreffen.

Anhand dieser Datenpunkte können Sie intern beweisen, dass ein Cloud-fähiges ISMS nicht nur ein Kostenfaktor ist, sondern aktiv das Wachstum mit den richtigen Kunden unterstützt.

Wie kann eine ISMS-Plattform dazu beitragen, diese kommerzielle Geschichte leichter verständlich zu machen?

Wenn Risiken, Kontrollen, Verantwortlichkeiten und Nachweise über verschiedene Teams und Tools verteilt sind, lassen sich einfache Fragen von Käufern wie „Wie schützen Sie meine Daten in AWS oder Azure?“ nur schwer sicher beantworten. Eine spezialisierte ISMS-Plattform wie ISMS.online hilft Ihnen dabei:

Integrieren Sie Ihre ISO 27001-Kontrollen, Multi-Cloud-Architekturen und die Anforderungen von Anhang A 5.23 in ein strukturiertes System, das Ihre tatsächliche Arbeitsweise widerspiegelt.
Halten Sie die Matrizen zur gemeinsamen Verantwortung, die Risikobehandlungen und die Kontrollzuordnungen auf dem neuesten Stand, wenn sich Ihre Dienste, Regionen und Cloud-Funktionen ändern.
Generieren Sie konsistente, prüferfreundliche Ergebnisse – Scope Statements, Statements of Appropriation, Audit Reports und Customer Assurance Packs – ohne diese jedes Mal neu erstellen zu müssen, wenn sich eine neue Gelegenheit ergibt.

Wenn Sie möchten, dass potenzielle und bestehende Kunden Sie als den Managed Service Provider (MSP) erleben, der nimmt ihnen die Einhaltung der Vorschriften für öffentliche Cloud-Plattformen ab.Es lohnt sich zu untersuchen, wie eine integrierte ISMS-Plattform Ihre AWS-, Azure- und Google Cloud-Designs mit Ihren ISO 27001-Verpflichtungen und den Zusicherungen, die Käufer heute standardmäßig erwarten, verbinden kann.

Wir sind führend auf unserem Gebiet

Regionalleiter – Winter 2026 (Großbritannien)

Regionalleiter – Winter 2026, Mittelstand EU

Regionalleiter – Winter 2026, Mittelstand EMEA

„ISMS.Online, herausragendes Tool zur Einhaltung gesetzlicher Vorschriften“
— Jim M.

„Macht externe Audits zum Kinderspiel und verknüpft alle Aspekte Ihres ISMS nahtlos miteinander“
— Karen C.

„Innovative Lösung zur Verwaltung von ISO- und anderen Akkreditierungen“
— Ben H.

Wie MSPS öffentliche Cloud-Plattformen nutzen und gleichzeitig die ISO 27001-Konformität gewährleisten können