Cloud-Services unter ISO 27001: Auswahlkriterien und Controls zur Integration ins ISMS

Viele Unternehmen stehen heute vor derselben Spannung: Cloud-Services versprechen Geschwindigkeit und Skalierung, das ISMS verlangt Nachweisbarkeit, kontrollierten Betrieb und klare Verantwortlichkeiten. Genau hier wird das Fokus-Thema Cloud-Services unter ISO 27001 praktisch relevant. Nicht, weil die Norm „Cloud“ grundsätzlich erschwert, sondern weil sie von Ihnen verlangt, Risiken systematisch zu erkennen, Controls wirksam umzusetzen und das Ganze auditfähig zu dokumentieren. Das klingt nach Papier – wird aber in der Cloud schnell zu harten Betriebsfragen: Wer darf was? Wo liegen Daten? Wie wird geloggt? Wie reagieren wir auf Vorfälle? Und wie kommen wir wieder raus, wenn es nötig ist?

Dieser Beitrag liefert eine belastbare Auswahl- und Integrationslogik: Entscheidungskriterien für die Beschaffung, konkrete Controls für die Integration ins ISMS, typische Audit-Perspektiven und Umsetzungshinweise aus Betriebssicht. Der Fokus liegt auf IaaS/PaaS/SaaS, also Infrastruktur-, Plattform- und Anwendungsdienste aus der Cloud – jeweils mit Konsequenzen für Governance, Administration und Sicherheit.

Cloud-Services unter ISO 27001 in der Praxis

In Audits und internen Reviews tauchen wiederkehrende Muster auf, die nicht an einzelnen Konfigurationen hängen, sondern an unklaren Schnittstellen zwischen Provider und Kunde:

• Unklare Verantwortlichkeiten: Das Shared Responsibility Model (geteilte Verantwortung zwischen Provider und Kunde) wird im Alltag nicht in Aufgaben, Rollen und Nachweise übersetzt.
• Zu grober Scope: „Wir nutzen Cloud“ ersetzt keine Scope-Abgrenzung. Ohne Service-Landkarte, Datenflüsse und Abhängigkeiten ist Risikoarbeit zufällig.
• Vendor-Auswahl ohne Sicherheitsanhang: Einkauf und Fachbereich priorisieren Funktionen, IT/Security kommen zu spät. Ergebnis: SLA ohne Sicherheitskennzahlen, fehlende Audit-Rechte, unklare Unterauftragnehmer.
• Fehlendes Logging-Design: Logs existieren, aber nicht zentral, nicht korreliert, keine Aufbewahrungsregeln, keine Zuständigkeit. Im Incident ist dann „nichts beweisbar“.
• Kein Exit-Plan: In der Cloud ist Lock-in selten „nur Preis“. Es sind Datenformate, IAM-Kopplungen, proprietäre Services und fehlende Migrationspfade.

ISO 27001 zwingt nicht zu maximaler Kontrolle, sondern zu angemessener, begründeter Kontrolle. Der entscheidende Schritt ist daher, Cloud-Services als Lieferantenbeziehung plus kritische Betriebsplattform zu behandeln – mit technischen Controls, die sich prüfen lassen.

Einordnung: ISO 27001, Annex A und was „Cloud“ daran ändert

ISO 27001 fordert ein Informationssicherheitsmanagementsystem (ISMS) mit risikobasiertem Ansatz, messbarer Wirksamkeit und kontinuierlicher Verbesserung. Der Annex A (Kontrollziele/Controls, in ISO/IEC 27001:2022 neu strukturiert) ist dabei ein Werkzeugkasten, kein Pflichtkatalog „alles immer“. In der Cloud verschiebt sich die Umsetzung:

• Kontrollen werden stärker vertraglich und prozessual (z. B. Lieferantensteuerung, Audit-Nachweise, Unterauftragnehmer-Transparenz).
• Kontrollen werden stärker konfigurationsgetrieben (z. B. IAM, Verschlüsselung, Netzsegmentierung), weil Sie weniger „physisch“ kontrollieren.
• Nachweise werden stärker datengetrieben (z. B. Log-Auszüge, Konfigurations-Exports, Change-Records), weil klassische Server-Checklisten nicht mehr passen.

Für die Praxis hilfreich ist die Zuordnung nach Dienstmodell: Bei SaaS kontrollieren Sie vor allem Identitäten, Berechtigungen, Daten, Integrationen und Supplier Management. Bei PaaS kommen Plattform-Settings, Netz- und Laufzeitkontrollen dazu. Bei IaaS tragen Sie deutlich mehr Verantwortung für Betriebssysteme, Hardening, Patchen und Netzarchitektur.

Auswahlkriterien: So prüfen Sie Cloud-Services vor dem Einkauf

Aus ISMS-Sicht ist die Auswahlphase der günstigste Zeitpunkt, Sicherheit und Auditfähigkeit „einzubauen“. Später wird jede Lücke teuer: Vertragsnachträge, Workarounds, Schatten-IT oder zusätzliche Tools.

1) Scope-Fit und Datenflüsse: Was genau soll in die Cloud?

Starten Sie nicht mit Features, sondern mit Informationswerten: Welche Datenarten verarbeitet der Service (personenbezogen, vertraulich, kritisch für Betrieb)? Welche Systeme sind angebunden (ERP, IAM, E-Mail, Tickets)? Ein Service, der Daten exportiert und verteilt, braucht andere Controls als ein isoliertes Tool.

Praktischer Mindestnachweis: Service-Steckbrief mit Zweck, Datenkategorien, Schnittstellen, Nutzergruppen, kritischen Abhängigkeiten und Betriebsfenstern. Das ist später die Brücke zu Risikobewertung, Statement of Applicability (SoA) und internen Audits.

2) Shared Responsibility Model in Aufgaben übersetzen

Viele Provider dokumentieren die geteilte Verantwortung. Für Ihr ISMS reicht das nicht, solange es nicht in konkrete Aufgaben überführt ist: Wer konfiguriert MFA? Wer prüft Logs? Wer verantwortet Schlüssel? Wer patcht (bei IaaS)?

Bewährt hat sich eine RACI-Matrix (Responsible, Accountable, Consulted, Informed) pro Control-Bereich. Entscheidend ist „Accountable“: eine interne Rolle, die im Zweifel gegenüber Auditoren und Management die Verantwortung trägt.

3) Lieferantenfähigkeit: Nachweise, Audit-Rechte, Unterauftragnehmer

ISO 27001 adressiert Lieferantensteuerung explizit. Für Cloud heißt das: Sie benötigen belastbare Informationen zu Sicherheitsmaßnahmen, Subprozessoren/Unterauftragnehmern, Standort-/Regionsthemen und zu Meldungen bei Sicherheitsereignissen. Prüfen Sie insbesondere:

• Audit- und Nachweisstrategie: Erhalten Sie geeignete Berichte/Nachweise (z. B. unabhängige Prüfberichte), und sind diese für Ihren Scope ausreichend?
• Transparenz zu Unterauftragnehmern: Werden Subdienstleister benannt, Änderungen angekündigt, und gibt es ein Widerspruchsrecht?
• Meldewege und Fristen: Security Incident Notification, Ansprechpartner, 24/7-Kontakt, Mindestinhalte der Meldung.
• Service Continuity: Verfügbarkeit, Wartungsfenster, Notfallprozesse, Backup/Restore (bei SaaS oft der Knackpunkt).

Wenn Sie Lieferantenrisiken vertiefen möchten: Planen Sie intern eine Verlinkung zu Ihrem Lieferantenmanagement-Beitrag ein (Vertragsklauseln, technische Prüfkriterien, Onboarding-Prozess).

4) Technische Integrationsfähigkeit: IAM, Logging, Netzwerk, Schlüssel

Ein Cloud-Service ist nicht „ein Tool“, sondern Teil Ihrer Sicherheitsarchitektur. Prüfen Sie deshalb vorab die Integrationspunkte:

• IAM-Integration: SSO (Single Sign-On), SCIM (automatisiertes Provisioning/Deprovisioning), Rollenmodell, Unterstützung für MFA und Conditional Access.
• Logging: Export in Ihr zentrales Logging/SIEM, Log-Details (Admin-Aktionen, Authentifizierung, Datenzugriffe), Aufbewahrung, Zeitstempel-Konsistenz.
• Netzwerk und Zugriff: Private Endpoints, IP-Restriktionen, Mandantentrennung, API-Zugriff, Rate Limits.
• Verschlüsselung/Key Management: Verschlüsselung at rest/in transit, Kunden-Schlüssel (BYOK/CMK), Rotation, HSM-Optionen, Schlüsselzugriff durch Provider.

Diese Punkte sind nicht „nice to have“. Sie entscheiden darüber, ob Controls im Betrieb bezahlbar und prüfbar sind oder ob Sie dauerhaft manuell nacharbeiten.

5) Kosten- und Betriebsfolgen: Security ist auch laufender Aufwand

Cloud-Kosten werden oft als Nutzungsgebühren verstanden. Für ISO 27001 relevante Zusatzkosten liegen aber regelmäßig in:

• Identitätsbetrieb (SSO, Rollenpflege, Rezertifizierung von Berechtigungen)
• Logging/Monitoring (Datenvolumen, SIEM-Lizenzen, Aufbewahrung)
• Schlüssel- und Zertifikatsmanagement (HSM/Key Vault, Rotation, Prozesse)
• Audit- und Nachweisaufwand (Lieferantenreviews, jährliche Assessments, interne Audits)
• Exit-Readiness (Datenexport, Migrationsproben, Parallelbetrieb)

Eine saubere Entscheidungsvorlage benennt diese Folgekosten explizit, damit Sicherheitsmaßnahmen nicht „unterfinanziert“ starten.

Controls zur Integration ins ISMS: pragmatische Kontrollfamilien

Statt einzelne Annex-A-Nummern auswendig zu lernen, ist es für die Umsetzung hilfreicher, Cloud-Controls in Kontrollfamilien zu strukturieren. Jede Familie sollte drei Dinge liefern: (1) Regel/Policy, (2) technische Umsetzung, (3) prüfbaren Nachweis.

Cloud-Governance: Policies, Rollen, Entscheidungswege

Ohne Governance wird Cloud-Security zu Einzelfallentscheidungen. Mindestens sollten Sie definieren:

• Cloud-Service-Onboarding-Prozess (wer genehmigt, welche Prüfschritte, welche Mindestanforderungen)
• Rollenmodell (Service Owner, Information Owner, ISMS-Verantwortliche, Betrieb/Plattform-Team, Datenschutz)
• Änderungsmanagement (Konfigurationsänderungen, Berechtigungen, Integrationen; Freigaben und Dokumentation)
• Ausnahmenmanagement (Risikoakzeptanz mit Frist, Kompensationsmaßnahmen, Review-Termin)

Audit-Perspektive: Auditoren suchen weniger „die perfekte Policy“, sondern Nachweise, dass Entscheidungen konsistent, risikobasiert und wiederholbar getroffen werden.

Asset- und Datenmanagement: Klassifizierung, Datenresidenz, Lebenszyklus

In der Cloud ist Datenklassifizierung der Anker: Sie bestimmt, welche Controls zwingend sind (z. B. Verschlüsselung, Zugriffsbeschränkungen, DLP). Legen Sie fest:

• Datenklassen (z. B. öffentlich, intern, vertraulich, streng vertraulich) und klare Beispiele.
• Zulässige Cloud-Nutzung je Klasse (welche Service-Kategorien sind erlaubt, welche Regionen/Standorte).
• Aufbewahrung und Löschung inklusive Nachweis (Deletion Requests, Retention Policies, E-Discovery-Anforderungen).

Wichtig für die Praxis: Bei SaaS ist „Löschen“ oft ein Prozess (Soft Delete, Retention, Backups). Ihr ISMS muss diese Realität abbilden und bewerten, nicht idealisieren.

Identitäts- und Zugriffsmanagement (IAM): der häufigste Cloud-Audit-Fund

IAM ist in Cloud-Projekten der Bereich mit den meisten Findings, weil er schnell wächst und fachbereichsnah ist. Mindest-Controls:

• SSO und MFA für alle privilegierten Accounts, möglichst für alle Nutzer.
• Least Privilege (minimal nötige Rechte) und Rollen statt individueller Sonderrechte.
• Joiner/Mover/Leaver: Automatisierte Provisionierung/Deprovisionierung, ideal mit SCIM.
• Regelmäßige Rezertifizierung von Berechtigungen (wer prüft, wie dokumentiert, welche Frequenz nach Risiko).
• Break-Glass-Accounts: Notfallzugänge mit starker Absicherung, separater Überwachung und dokumentiertem Einsatz.

Nachweise, die Auditoren akzeptieren: Rollen-Export, MFA-Status, Protokolle über Rezertifizierungen, Tickets/Changes für Rollenänderungen, Protokollierung von Admin-Aktionen.

Verschlüsselung und Schlüsselmanagement: von „Häkchen“ zu kontrollierter Praxis

„Verschlüsselung aktiv“ ist kein Control, solange Schlüsselzugriffe, Rotation und Verantwortlichkeiten unklar sind. Für Cloud-Services sollten Sie festlegen:

• Verschlüsselung in Transit: TLS-Standards, Zertifikatsmanagement, keine unsicheren Protokolle.
• Verschlüsselung at Rest: Standard-Encryption, ggf. kundenverwaltete Schlüssel (Customer Managed Keys).
• Key Lifecycle: Rotation, Zugriff (wer darf Keys verwalten), Trennung von Aufgaben (Separation of Duties).
• Backups und Exporte: Verschlüsselung auch außerhalb der Plattform, insbesondere bei Datenexporten.

Praktische Konsequenz: Wenn Sie BYOK/CMK wählen, müssen Sie den Betrieb dafür können (Prozesse, Monitoring, Notfallzugriff). Ohne diese Fähigkeit ist „eigene Schlüssel“ oft nur scheinbare Kontrolle.

Logging, Monitoring und Detection: auditfähig statt „wir könnten“

ISO 27001 verlangt keine bestimmte SIEM-Lösung, aber die Fähigkeit, Ereignisse zu erkennen, zu untersuchen und nachzuweisen. In der Cloud müssen Sie daher klären:

• Welche Ereignisse werden geloggt? Authentifizierung, Admin-Aktionen, Policy-Änderungen, Datenexporte, API-Calls, Fehler/Anomalien.
• Wo landen die Logs? Zentral, manipulationsgeschützt (Write Once/immutables Speichern, soweit möglich), mit definierter Aufbewahrung.
• Wer reagiert? Zuständigkeiten, Alarmwege, Bereitschaft/Vertretung, Runbooks.

Ein häufiger Praxisfehler ist „zu viel Logging ohne Plan“. Besser ist ein risikobasiertes Logging-Profil pro Service-Klasse plus ein Minimalset, das immer aktiv ist (insbesondere Admin- und IAM-Events).

Beispiel: Minimaler Audit-Nachweis-Ordner je Cloud-Service (Strukturvorschlag)
01_Service-Steckbrief.pdf
02_Risikoanalyse_und_Risikobehandlung.pdf
03_SoA_Zuordnung_Controls.pdf
04_Vertrag_und_Sicherheitsanhang.pdf
05_RACI_und_Betriebsmodell.pdf
06_IAM_Rollenexport_MFA_Nachweise/
07_Logging_Forwarding_Nachweise/
08_Change_Records_und_Ausnahmen/
09_Incident_Runbooks_und_Tests/
10_Exit_Plan_und_Exporttests/

Vulnerability- und Patch-Management: je nach Service-Modell unterschiedlich

Hier trennt sich SaaS von IaaS deutlich:

• SaaS: Provider patcht Plattform und Anwendung. Ihre Controls liegen bei Konfiguration, IAM, Integrationen, Endpoints und bei der Bewertung von Release-/Change-Informationen des Providers.
• PaaS: Provider patcht Basisdienste, Sie patchen ggf. Runtimes/Dependencies in Ihrer Anwendung. Wichtig sind Policies zu unterstützten Versionen und Deployments.
• IaaS: Sie patchen Betriebssysteme und Applikationen. Das ist klassisches Patch- und Hardening-Programm, nur mit Cloud-Tooling.

Audit-Perspektive: Es wird geprüft, ob Verantwortlichkeiten klar sind, ob Schwachstellenbewertung stattfindet und ob es ein Verfahren gibt, kritische Updates zeitnah umzusetzen oder zu kompensieren.

Backup, Restore und Business Continuity: RTO/RPO und reale Wiederherstellung

In Cloud-Projekten wird Verfügbarkeit oft mit „der Provider ist hochverfügbar“ verwechselt. Für Ihr ISMS zählen aber Ihre Geschäftsanforderungen. Definieren Sie:

• RTO/RPO (Recovery Time Objective/Recovery Point Objective): Wie schnell und mit welchem Datenverlust dürfen wir zurückkommen?
• Backup-Umfang: Konfigurationen (IAM, Policies), Daten, Schlüsselmaterial (wo zulässig), Integrationskonfigurationen.
• Restore-Tests: Häufigkeit, Erfolgskriterien, Protokolle. Ohne Tests ist Backup im Audit schwach.

Bei SaaS ist der kritische Punkt oft: Welche Exportmöglichkeiten gibt es? Wie schnell bekommen Sie Daten im Notfall heraus? Welche Abhängigkeiten zu Identity oder E-Mail verhindern Zugriff?

Incident Management und Forensik: was in der Cloud anders ist

Incident Response in der Cloud ist vor allem ein Thema von Zugriff auf Beweisdaten und Koordination. Legen Sie pro Service fest:

• Kontaktwege zum Provider (Security Hotline, Ticket-Priorität, Eskalation).
• Beweissicherung: Welche Logs, Snapshots oder Exporte sind möglich? Welche Aufbewahrung ist aktiv?
• Rollen: Wer führt, wer entscheidet über Abschaltung/Isolierung, wer kommuniziert intern/extern?

Ein prüfbarer Nachweis ist ein getestetes Runbook (Tabletop-Übung reicht als Start), inklusive Lessons Learned und Maßnahmen-Tracking.

Change- und Konfigurationsmanagement: Cloud-konform, nicht serverzentriert

ISO 27001 erwartet kontrollierte Änderungen. In der Cloud heißt das: Änderungen passieren häufig in Konfigurationen, Policies und Rollen. Gute Controls sind:

• Baseline-Konfigurationen je Service-Klasse (z. B. MFA an, Logging an, Admin-Rollen eingeschränkt).
• Change-Records für sicherheitsrelevante Änderungen (Berechtigungen, Netzwerk, Schlüssel, Logging).
• Regelmäßige Konfigurationsreviews und Abweichungsbehandlung.

Wenn Sie Infrastructure as Code (IaC) nutzen: Es unterstützt Nachvollziehbarkeit, ist aber kein Selbstläufer. Entscheidend ist der Prozess: Review, Freigabe, Rollback, und dass auch manuelle Änderungen erkannt werden.

Exit-Strategie und Portabilität: Control gegen Lock-in und Betriebsrisiko

Ein Exit-Plan ist unter ISO 27001 ein sehr starkes Argument in der Risikobehandlung, weil er Abhängigkeiten reduziert und die Handlungsfähigkeit im Krisenfall erhöht. Ein praxisnaher Exit-Plan umfasst:

• Datenexport: Formate, Vollständigkeit, Frequenz, Verschlüsselung, Integrität (Checksums), Verantwortliche.
• Konfigurations-Export: Rollen, Policies, Integrationen, Automatisierungen.
• Migrationspfad: Zielplattform-Optionen, kritische Abhängigkeiten, Mindesttest (z. B. jährlicher Export-/Restore-Test).
• Vertragsregelungen: Fristen, Unterstützung, Löschung, Herausgabe, Kosten.

Wichtig: Exit ist kein „Projekt am Ende“, sondern eine Fähigkeit. Kleine, regelmäßige Tests sind günstiger als eine große Migration unter Zeitdruck.

Audit-Perspektive: Welche Nachweise in Cloud-Setups wirklich zählen

Viele Teams dokumentieren zu viel an der falschen Stelle (lange Texte) und zu wenig an der richtigen (prüfbare Artefakte). In Cloud-Audits zählen typischerweise:

• Scope und Inventar: Welche Cloud-Services sind im ISMS-Scope, mit Ownern und Zweck.
• Risikobewertung: nachvollziehbare Risiken pro Service bzw. Service-Klasse, inklusive Risikobehandlung.
• SoA: begründete Auswahl der Controls, inkl. Umsetzung/Status.
• Lieferantenakte: Vertrag, Sicherheitsanhang, Nachweise/Reports, Subdienstleister-Infos, Reviews.
• Betriebsnachweise: IAM-Exports, Rezertifizierungsprotokolle, Logging-Forwarding, Incident-Übungen, Restore-Tests.

Wenn Sie sich audit-ready strukturieren wollen, planen Sie intern eine Verlinkung auf eine „Audit-Ready“-Checkliste ein. Das verbessert sowohl Vorbereitung als auch tägliche Ablagequalität.

Praktische Checkliste: Cloud-Service in 10 Schritten ISMS-konform onboarden

1. Service-Steckbrief erstellen (Zweck, Daten, Schnittstellen, Nutzer, Owner).
2. Datenklassifizierung und zulässige Regionen/Residenz festlegen.
3. Shared Responsibility als RACI pro Control-Familie dokumentieren.
4. Lieferantenprüfung inkl. Unterauftragnehmer, Incident-Meldung, Nachweise.
5. Risikobewertung durchführen, Risikobehandlung planen (inkl. Kompensationsmaßnahmen).
6. Vertrag/Sicherheitsanhang finalisieren (SLA, Logging, Support, Exit, Audit-Infos).
7. IAM integrieren (SSO, MFA, Rollen, SCIM, Break-Glass).
8. Logging/Monitoring anbinden, Aufbewahrung und Alarmierung definieren.
9. BCM/Backup/Restore klären und mindestens einen Test planen.
10. Exit-Minimaltest definieren (Export + Validierung) und in den Jahresplan aufnehmen.

Diese Reihenfolge ist bewusst so gewählt, dass Governance und Nachweise nicht „nachgezogen“ werden, sondern Beschaffung und Betrieb von Anfang an tragfähig sind.

Verantwortlichkeiten und Governance im Alltag: Wer muss was entscheiden?

Cloud-Integration ins ISMS scheitert oft an impliziten Annahmen: „Security macht das“ oder „der Provider ist zuständig“. Für belastbare Entscheidungen braucht es klare Rollen:

• Service Owner: fachliche Verantwortung, Budget, akzeptiert Restrisiken im Rahmen der Governance.
• Information Owner: verantwortet Schutzbedarf/Klassifizierung der Daten (häufig Fachbereich, unterstützt durch IT/Compliance).
• Cloud Platform/Operations: technische Baselines, Logging, Accounts, Automatisierung, Betrieb.
• ISMS/Compliance: Methode, Risikobewertung, SoA, Nachweisführung, Audit-Kommunikation.
• Security: Controls, Monitoring, Incident Response, Ausnahmebewertungen.
• Datenschutz (falls relevant): Rechtsgrundlagen, Auftragsverarbeitung, internationale Transfers.

Die Geschäftsführung ist nicht „Detailverantwortliche“, aber sie muss Governance unterstützen: durch klare Mandate, Ressourcen für Controls und eine definierte Risikobereitschaft.

Schlussfazit: Cloud-Services ISO-27001-konform nutzen heißt kontrolliert entscheiden

Cloud-Services unter ISO 27001 sind kein Widerspruch – aber nur dann beherrschbar, wenn Auswahl, Vertrag, Konfiguration und Betrieb als zusammenhängendes Kontrollsystem verstanden werden. Die zentrale Stellschraube ist nicht ein einzelnes Tool, sondern Ihre Fähigkeit, Verantwortlichkeiten eindeutig zuzuweisen, Datenflüsse und Risiken zu dokumentieren und technische Controls so umzusetzen, dass sie im Alltag und im Audit standhalten.

Wenn Sie pragmatisch starten wollen: Etablieren Sie einen Service-Steckbrief, ein Standardpaket aus IAM- und Logging-Mindestanforderungen, einen Lieferanten-Sicherheitsanhang und einen Exit-Minimaltest. Damit reduzieren Sie die typischen Cloud-Risiken (Unklarheit, fehlende Beweise, Lock-in) deutlich – ohne Ihr ISMS mit Papier zu überladen.

Für dieses Thema sind auch Isms Cloud Integration und Cloud Governance wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.