Cloud-Auditnachweise für ISO 27001, NIS2 und DORA

Maria, CISO eines schnell wachsenden Unternehmens für Finanzanalysen, hatte noch sechs Wochen, bevor drei Fristen zusammenliefen. Ihr ISO 27001:2022-Überwachungsaudit war bereits terminiert. NIS2 hatte das Unternehmen als wichtige Einrichtung auf eine neue Stufe der Managementverantwortung gehoben. DORA würde in Kürze prüfen, ob ihre Fintech-Abläufe digitale operationale Resilienz nachweisen können. Gleichzeitig hielt ein großer Unternehmenskunde einen Vertrag zurück, bis ihr Team eine detaillierte Sicherheitsbewertung bestanden hatte.

Das Unternehmen war nicht unsicher. Es betrieb produktive Workloads in AWS und Azure, nutzte Microsoft 365 und mehrere kritische SaaS-Plattformen, setzte MFA durch, sicherte Daten, führte Schwachstellenscans durch und sammelte Cloud-Protokolle. Das Problem war der Nachweis.

Nachweise waren über Slack-Screenshots, Entwickler-Wiki-Seiten, Exporte aus Cloud-Konsolen, Beschaffungsordner, Rechtsverträge und mündliche Zusicherungen von Plattformverantwortlichen verteilt. Wenn ein Auditor fragte: „Zeigen Sie mir, wie Sie Ihre Cloud-Umgebung kontrollieren“, reichte ein Link auf die Compliance-Seite eines Cloud-Anbieters nicht aus. Die Zertifikate des Anbieters belegten die Kontrollen des Anbieters. Sie belegten nicht Marias Seite des Modells der geteilten Verantwortung.

An dieser Stelle scheitern viele Programme für Auditnachweise zur Cloud-Sicherheit. Nicht weil Kontrollen fehlen, sondern weil die Organisation nicht strukturiert und nachvollziehbar belegen kann, welche Verantwortlichkeiten beim Anbieter liegen, welche beim Kunden, wie SaaS- und IaaS-Kontrollen konfiguriert sind, wie Lieferantenverpflichtungen durchgesetzt werden und wie Nachweise für Auditoren, Aufsichtsbehörden und Kunden aufbewahrt werden.

Cloud-Compliance ist kein technischer Anhang mehr. Für einen SaaS-Anbieter unter NIS2, ein Finanzunternehmen unter DORA oder jede ISO 27001:2022-Organisation, die IaaS, PaaS und SaaS nutzt, ist Cloud-Governance Teil des ISMS-Geltungsbereichs, des Risikobehandlungsplans, des Lieferantenlebenszyklus, des Vorfallsprozesses, der Datenschutz-Rechenschaftspflicht und der Managementbewertung.

Das praktische Ziel ist einfach: Aufbau einer belastbaren Cloud-Nachweisarchitektur, die Fragen zu ISO 27001:2022, NIS2, DORA, GDPR, Kundenvertrauen und internem Audit beantwortet, ohne Nachweise für jedes Rahmenwerk neu aufzubauen.

Cloud ist immer im Geltungsbereich, auch wenn Infrastruktur ausgelagert ist

Die erste Auditfalle ist die Annahme, ausgelagerte Infrastruktur liege außerhalb des ISMS. Das ist nicht der Fall. Outsourcing verändert die Kontrollgrenze, beseitigt aber nicht die Rechenschaftspflicht.

ISO/IEC 27001:2022 verlangt, dass die Organisation ihren Kontext, interessierte Parteien, den ISMS-Geltungsbereich, Schnittstellen, Abhängigkeiten und Prozesse definiert. In einem Cloud-first-Unternehmen sind der Identitätsanbieter, das Cloud-Hosting-Konto, CRM, E-Mail-Plattform, Data Warehouse, CI/CD-Pipeline, Ticketsystem und Backup-Service häufig zentrale Geschäftsinfrastruktur.

Clarysecs Zenith Blueprint: 30-Schritte-Roadmap für Auditoren Zenith Blueprint stellt diesen Punkt in der Phase „ISMS Foundation & Leadership“, Schritt 2, „Stakeholder Needs and ISMS Scope“, heraus:

„Wenn Sie Ihre IT-Infrastruktur an einen Cloud-Anbieter auslagern, schließt das diese nicht vom Geltungsbereich aus; vielmehr beziehen Sie das Management dieser Beziehung und die Cloud-Assets in den Geltungsbereich ein (weil die Sicherheit Ihrer Daten in der Cloud Ihre Verantwortung ist).“

Diese Aussage ist ein Audit-Anker. Ihr Geltungsbereich sollte nicht lauten: „AWS ist ausgeschlossen, weil Amazon es verwaltet.“ Er sollte festlegen, dass Informationswerte und Prozesse im Zusammenhang mit auf AWS gehosteten Services im Geltungsbereich liegen, einschließlich Management von Cloud-Sicherheitskontrollen, Identität, Protokollierung, Verschlüsselung, Backup, Nachweisen zur Lieferantensicherheit und Incident Response.

Für ISO 27001:2022 unterstützt dies die Klauseln 4.1 bis 4.4 zu Kontext, interessierten Parteien, Geltungsbereich und ISMS-Prozessen. Für NIS2 unterstützt es die Erwartungen aus Article 21 an Risikoanalyse, Verfahren zum Umgang mit Sicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sichere Beschaffung und Wartung, Zugriffskontrolle, Asset-Management, Kryptografie, Kontrollwirksamkeit und MFA, soweit angemessen. Für DORA unterstützt es den Grundsatz, dass Finanzunternehmen für IKT-Risiken verantwortlich bleiben, auch wenn IKT-Services ausgelagert werden.

Die Frage ist nicht, ob Ihr Cloud-Anbieter sicher ist. Die Frage ist, ob Sie Ihre Nutzung des Anbieters steuern, Ihre Seite korrekt konfigurieren, den Service überwachen, Lieferantenverpflichtungen managen und Nachweise aufbewahren.

Aus geteilter Verantwortung müssen geteilte Nachweise werden

Cloud-Anbieter erläutern geteilte Verantwortung. Auditoren prüfen, ob Sie sie operationalisiert haben.

Bei IaaS sichert der Anbieter üblicherweise physische Einrichtungen, Kerninfrastruktur und Hypervisor. Der Kunde kontrolliert Identität, Workload-Konfiguration, Härtung des Betriebssystems, Anwendungssicherheit, Datenklassifizierung, Verschlüsselungseinstellungen, Netzwerkregeln, Protokollierung, Backups, Patching und Incident Response.

Bei SaaS kontrolliert der Anbieter den Großteil des Plattformbetriebs, der Kunde kontrolliert jedoch weiterhin Tenant-Konfiguration, Benutzer, Admin-Rollen, Integrationen, Datenfreigaben, Aufbewahrung, Protokollierungsoptionen und Eskalationsverfahren.

Clarysecs Zenith Controls: Der Cross-Compliance-Leitfaden Zenith Controls behandelt ISO/IEC 27002:2022 Maßnahme 5.23, Informationssicherheit bei der Nutzung von Cloud-Services, als zentrale Cloud-Governance-Kontrolle mit präventivem Zweck über Vertraulichkeit, Integrität und Verfügbarkeit hinweg. Er verknüpft Cloud-Services mit Lieferantenbeziehungen, sicherer Informationsübertragung, Asset-Inventar, Verhinderung von Datenabfluss, Endpoint- und Netzwerksicherheit sowie sicheren Entwicklungspraktiken.

Eine zentrale Auslegung aus Zenith Controls lautet:

„Cloud-Service-Provider (CSPs) fungieren als kritische Lieferanten; daher gelten alle Kontrollen zur Lieferantenauswahl, Vertragsgestaltung und zum Risikomanagement nach 5.19. 5.23 geht jedoch weiter, indem cloud-spezifische Risiken wie Multi-Tenancy, Transparenz zum Datenstandort und Modelle geteilter Verantwortung adressiert werden.“

Diese Unterscheidung ist kritisch. Lieferantenzertifikate allein erfüllen Annex A.5.23 nicht. Sie benötigen kundenseitige Nachweise, die belegen, dass der Cloud-Service gesteuert, konfiguriert, überwacht und überprüft wird.

Das ist der Unterschied zwischen vorhandenen Cloud-Kontrollen und auditbereiten Cloud-Kontrollen.

Beginnen Sie mit einem Register für Cloud-Services, das Auditoren nutzen können

Der schnellste Weg zu besserer Cloud-Auditbereitschaft ist ein vollständiges Register für Cloud-Services. Es darf keine reine Beschaffungsliste und kein Export aus der Finanzabteilung sein. Es muss Cloud-Services mit Daten, Verantwortlichen, Regionen, Zugriff, Verträgen, Kritikalität, regulatorischer Relevanz und Nachweisen verknüpfen.

Clarysecs SME Richtlinie zur Nutzung von Cloud-Diensten-sme Richtlinie zur Nutzung von Cloud-Diensten-sme bietet in Klausel 5.3 eine kompakte und auditfreundliche Grundlage:

„Ein Cloud-Service-Register muss vom IT-Dienstleister oder GM geführt werden. Es muss Folgendes erfassen: 5.3.1 Name und Zweck jedes genehmigten Cloud-Services 5.3.2 die verantwortliche Person oder das verantwortliche Team (Anwendungsverantwortlicher) 5.3.3 die Arten der gespeicherten oder verarbeiteten Daten 5.3.4 das Land oder die Region, in dem bzw. der Daten gespeichert werden 5.3.5 Benutzerzugriffsberechtigungen und administrative Konten 5.3.6 Vertragsdetails, Verlängerungstermine und Supportkontakte“

Für Unternehmensumgebungen legt Clarysecs Richtlinie zur Nutzung von Cloud-Diensten Richtlinie zur Nutzung von Cloud-Diensten das umfassendere Mandat fest:

„Diese Richtlinie legt die verbindlichen Anforderungen der Organisation an die sichere, konforme und verantwortungsvolle Nutzung von Cloud-Computing-Services über Infrastructure-as-a-Service (IaaS)-, Platform-as-a-Service (PaaS)- und Software-as-a-Service (SaaS)-Bereitstellungsmodelle hinweg fest.“

Die Richtlinie zur Nutzung von Cloud-Diensten verlangt ein zentrales Register unter Verantwortung des CISO sowie genehmigte Baseline-Konfigurationen für Cloud-Umgebungen. Dieses Register wird zur Nachweisgrundlage für mehrere Verpflichtungen zugleich.

Für ISO 27001:2022 unterstützt es Asset-Inventar, Governance der Cloud-Nutzung, Lieferantenbeziehungen, Zugriffskontrolle, gesetzliche und vertragliche Anforderungen, Risikobehandlung und dokumentierte Information. Für NIS2 unterstützt es Sicherheit der Lieferkette, Asset-Management, Risikoanalyse, Verfahren zum Umgang mit Sicherheitsvorfällen und Kontinuität. Für DORA unterstützt es die Kartierung von IKT-Assets und Abhängigkeiten, das Register für IKT-Drittparteien, die Zuordnung kritischer oder wichtiger Funktionen und die Analyse von Konzentrationsrisiken. Für GDPR identifiziert es, ob personenbezogene Daten verarbeitet werden, wo sie liegen, welcher Anbieter als Auftragsverarbeiter handelt und welche Übermittlungs- oder Datenverarbeitungsbedingungen gelten.

Wenn das Register Datenkategorien und Regionen nicht ausweist, bleiben Datenschutz- und Resilienznachweise unvollständig. Wenn es keine Anwendungsverantwortlichen benennt, bleiben Berechtigungsüberprüfungen verwaist. Wenn es Verträge und Verlängerungstermine nicht ausweist, können Sicherheitsklauseln von Lieferanten nicht geprüft werden.

ISO 27001:2022 als Rückgrat für Cloud-Nachweise nutzen

ISO 27001:2022 ist das beste Rückgrat für Cloud-Nachweise, weil sie Geschäftskontext, Risiken, Kontrollen, operative Nachweise, Überwachung und Verbesserung miteinander verbindet.

Zu den wichtigsten cloud-relevanten Anforderungen aus ISO 27001:2022 gehören:

• Klauseln 4.1 bis 4.4 zu Kontext, interessierten Parteien, ISMS-Geltungsbereich, Schnittstellen, Abhängigkeiten und Prozessen.
• Klauseln 5.1 bis 5.3 zu Führung, Richtlinie, Rollen, Verantwortlichkeiten und Rechenschaftspflicht.
• Klauseln 6.1.1 bis 6.1.3 zu Risikobeurteilung, Risikobehandlung, Annex-A-Abgleich, Anwendbarkeitserklärung und Restrisikoakzeptanz.
• Klausel 7.5 zu gelenkter dokumentierter Information.
• Klauseln 8.1 bis 8.3 zu operativer Planung, Durchführung der Risikobeurteilung und Durchführung der Risikobehandlung.
• Klauseln 9.1 bis 9.3 zu Überwachung, Messung, internem Audit und Managementbewertung.
• Klausel 10 zu Nichtkonformität, Korrekturmaßnahmen und kontinuierlicher Verbesserung.

Die Annex-A-Kontrollen mit dem größten Gewicht für Cloud-Nachweise umfassen A.5.19 Informationssicherheit in Lieferantenbeziehungen, A.5.20 Adressierung von Informationssicherheit in Lieferantenvereinbarungen, A.5.21 Management der Informationssicherheit in der IKT-Lieferkette, A.5.22 Überwachung, Überprüfung und Änderungsmanagement von Lieferantendiensten, A.5.23 Informationssicherheit bei der Nutzung von Cloud-Services, A.5.24 bis A.5.27 Vorfallmanagement, A.5.29 Informationssicherheit während Störungen, A.5.30 IKT-Bereitschaft für Aufrechterhaltung des Geschäftsbetriebs, A.5.31 gesetzliche, satzungsmäßige, regulatorische und vertragliche Anforderungen, A.5.34 Datenschutz und Schutz personenbezogener Daten, A.5.36 Einhaltung von Richtlinien, Regeln und Standards für Informationssicherheit, A.8.8 Management technischer Schwachstellen, A.8.9 Konfigurationsmanagement, A.8.13 Informationssicherung, A.8.15 Protokollierung, A.8.16 Überwachungstätigkeiten, A.8.24 Nutzung von Kryptografie, A.8.25 sicherer Entwicklungslebenszyklus, A.8.29 Sicherheitstests in Entwicklung und Abnahme sowie A.8.32 Änderungsmanagement.

In Zenith Blueprint erläutert die Phase „Controls in Action“, Schritt 23, Cloud-Services in einer Sprache, die bei Auditoren anschlussfähig ist:

„Die Verlagerung zu Cloud-Services führt zu tiefgreifenden Änderungen des Vertrauensmodells. Sie kontrollieren den Server, den Netzwerkperimeter oder den Hypervisor nicht mehr. Oft wissen Sie nicht einmal, wo sich die Daten physisch befinden. Was Sie kontrollieren, und was diese Kontrolle durchsetzt, ist die Governance dieser Beziehung, die Transparenz darüber, was Sie nutzen, und die Sicherheitserwartungen, die Sie an Ihre Anbieter stellen.“

Ein belastbarer Eintrag in der Anwendbarkeitserklärung zu A.5.23 sollte nicht nur lauten: „Anwendbar, Cloud-Anbieter zertifiziert.“ Er sollte erläutern, warum die Kontrolle anwendbar ist, welche Risiken sie behandelt, wie sie umgesetzt ist und wo Nachweise gespeichert werden.

Fügen Sie der SoA oder dem Kontroll-Tracker eine Spalte für den Nachweisort hinzu. Auditoren sollten nicht E-Mails, Ticketsysteme und gemeinsame Laufwerke durchsuchen müssen, um Nachweise zu finden.

Ein Nachweismodell für ISO 27001:2022, NIS2 und DORA nutzen

NIS2 und DORA verlangen beide dokumentierte, risikobasierte und durch das Management gesteuerte Cybersicherheit. Die Überschneidung ist erheblich, der aufsichtsrechtliche Druck jedoch unterschiedlich.

NIS2 gilt für viele wesentliche und wichtige Einrichtungen in der EU, darunter Anbieter digitaler Infrastruktur, Managed Service Provider, Managed Security Service Provider, Banken, Finanzmarktinfrastrukturen und digitale Anbieter. Article 21 verlangt angemessene und verhältnismäßige technische, operative und organisatorische Maßnahmen, einschließlich Risikoanalyse, Verfahren zum Umgang mit Sicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sichere Beschaffung und Wartung, Umgang mit Schwachstellen, Bewertung der Kontrollwirksamkeit, Cyberhygiene, Schulung, Kryptografie, Zugriffskontrolle, Asset-Management und MFA oder sichere Kommunikation, soweit angemessen.

Für Auditnachweise zur Cloud-Sicherheit fragt NIS2, ob Cloud- und Lieferantenrisiken als Teil des Risikos der Leistungserbringung gesteuert werden. Hinzu kommt eine strukturierte Meldung erheblicher Vorfälle, einschließlich Frühwarnung innerhalb von 24 Stunden, Vorfallmeldung innerhalb von 72 Stunden und Abschlussbericht innerhalb eines Monats.

DORA gilt seit dem 17. Januar 2025 für viele EU-Finanzunternehmen und schafft einheitliche Anforderungen an IKT-Risikomanagement, Meldung schwerwiegender IKT-Vorfälle, Tests der digitalen operationalen Resilienz, Informationsaustausch und IKT-Drittparteienrisiken. Für Finanzunternehmen, die zugleich unter NIS2 fallen, gilt DORA für überschneidende operative Verpflichtungen als sektorspezifischer Rechtsakt der Union.

Für Cloud ist DORA unmittelbar relevant. Finanzunternehmen bleiben für IKT-Risiken verantwortlich, wenn Services ausgelagert werden. Sie benötigen IKT-Drittparteienstrategien, Vertragsregister, vorvertragliche Bewertungen, Due Diligence, Audit- und Zugriffsrechte, Kündigungsauslöser, Analysen von Konzentrationsrisiken, Kontrollen für Unterbeauftragungen und getestete Exit-Strategien.

Zenith Controls ordnet ISO/IEC 27002:2022 Maßnahme 5.23 EU NIS2 Article 21 und DORA Articles 28 to 31 zu. Außerdem verweist es auf unterstützende Standards wie ISO/IEC 27017 für Cloud-Sicherheitsrollen und Überwachung, ISO/IEC 27018 für den Schutz personenbezogener Daten in der Public Cloud, ISO/IEC 27701 für Datenschutzmanagement in Beziehungen mit Cloud-Auftragsverarbeitern, ISO/IEC 27036-4 für Cloud-Service-Überwachung und Lieferantenvereinbarungen sowie ISO/IEC 27005 für Cloud-Risikobeurteilung.

Die praktische Konsequenz ist einfach. Erstellen Sie keine getrennten Nachweispakete für ISO 27001:2022, NIS2, DORA und GDPR. Bauen Sie eine Cloud-Nachweisarchitektur mit rahmenwerkspezifischen Zuordnungen.

Lieferantenverträge sind Kontrollnachweise, keine Rechtsarchive

Cloud-Auditnachweise brechen häufig auf Vertragsebene zusammen. Security hat einen Lieferantenfragebogen. Legal hat das MSA. Die Beschaffung kennt den Verlängerungstermin. Der DPO hat den DPA. Niemand hat eine einheitliche Sicht darauf, ob die Vereinbarung die Sicherheitsklauseln enthält, die ISO 27001:2022, NIS2, DORA und GDPR verlangen.

Clarysecs SME Richtlinie zur Lieferanten- und Drittparteiensicherheit-sme Richtlinie zur Lieferanten- und Drittparteiensicherheit-sme legt in Klausel 5.3 fest:

„Verträge müssen verbindliche Klauseln enthalten zu: 5.3.1 Vertraulichkeit und Geheimhaltung 5.3.2 Verpflichtungen zur Informationssicherheit 5.3.3 Fristen zur Meldung von Datenschutzverletzungen (z. B. innerhalb von 24–72 Stunden) 5.3.4 Auditrechte oder Verfügbarkeit von Nachweisen der Einhaltung 5.3.5 Beschränkungen weiterer Unterbeauftragungen ohne Genehmigung 5.3.6 Beendigungsbedingungen, einschließlich sicherer Datenrückgabe oder Vernichtung“

Für Auditkonsistenz sollten diese Klauseln in eine Vertragsprüfmatrix überführt werden. ISO 27001:2022 Annex A.5.20 erwartet, dass Sicherheitsanforderungen mit Lieferanten vereinbart werden. GDPR Article 28 verlangt Auftragsverarbeiterbedingungen zu Vertraulichkeit, Sicherheitsmaßnahmen, Unterstützung, Unterauftragsverarbeitern, Löschung oder Rückgabe von Daten und Auditunterstützung. DORA Article 30 verlangt detaillierte vertragliche Regelungen für IKT-Drittdienstleister, einschließlich Servicebeschreibungen, Datenstandort, Sicherheit, Unterstützung bei Vorfällen, Zusammenarbeit mit Behörden, Auditrechten, Zugriffsrechten, Kündigung und Übergangsregelungen. Die NIS2-Sicherheit der Lieferkette benötigt ebenfalls durchsetzbare Lieferantenkooperation.

Zenith Controls ordnet ISO/IEC 27002:2022 Maßnahme 5.20 Lieferantenvereinbarungen zu und verweist auf Verbindungen zu 5.19 Lieferantenbeziehungen, 5.14 Informationsübertragung, 5.22 Lieferantenüberwachung, 5.11 Rückgabe von Vermögenswerten und 5.36 Einhaltung.

Der zentrale Punkt ist die Operationalisierung. Wenn ein Cloud-Vertrag Zugriff auf SOC 2-Berichte gewährt, können Auditoren fragen, ob Sie den Bericht eingeholt, Ausnahmen überprüft, Abhilfemaßnahmen nachverfolgt und das Risiko neu bewertet haben. Wenn der Vertrag eine Meldung von Verstößen zusagt, können sie fragen, ob Ihr Incident-Playbook den Kontaktpfad zum Lieferanten und regulatorische Entscheidungspunkte enthält. Wenn Änderungen bei Unterauftragnehmern Genehmigung oder Benachrichtigung erfordern, können sie fragen, ob Benachrichtigungen zu Unterauftragsverarbeitern vor der Annahme geprüft werden.

Ein Vertrag ohne Überprüfungsnachweise ist ein Archiv. Ein Vertrag, der mit Lieferantenrisiko, Überwachungsaufzeichnungen und Vorfalls-Workflows verknüpft ist, ist eine Kontrolle.

SaaS-Protokollierung und -Konfiguration sind häufige Audit-Blindspots

Cloud-Feststellungen entstehen häufig bei SaaS, nicht bei IaaS. Infrastrukturteams verfügen meist über technische Verantwortliche, Protokollierungspipelines, Baseline-Kontrollen und Änderungsaufzeichnungen. SaaS-Plattformen sind über Vertrieb, HR, Finanzen, Customer Success, Marketing und Betrieb verteilt. Jede davon kann sensitive oder regulierte Daten verarbeiten.

Clarysecs Richtlinie zur Protokollierung und Überwachung-sme Richtlinie zur Protokollierung und Überwachung-sme adressiert dies direkt in Klausel 5.5:

„5.5 Cloud-Services und Protokollierung durch Dritte 5.5.1 Für Plattformen, bei denen die Protokollierung nicht unter direkter IT-Kontrolle steht (z. B. SaaS-E-Mail), gelten folgende Anforderungen: 5.5.1.1 Protokollierung muss aktiviert und konfiguriert werden, sofern verfügbar 5.5.1.2 Warnmeldungen müssen an den IT-Support-Dienstleister weitergeleitet werden 5.5.1.3 Verträge müssen Anbieter verpflichten, Protokolle mindestens 12 Monate aufzubewahren und auf Anfrage Zugriff bereitzustellen“

Für Unternehmen ergänzt die Richtlinie zur Nutzung von Cloud-Diensten:

„Cloud-Services müssen zur kontinuierlichen Überwachung in das SIEM der Organisation integriert werden.“

Diese Anforderung macht aus SaaS ein „überwachtes Informationssystem“ statt nur ein „Geschäftswerkzeug“. Nachweise sollten Exporte von Protokollierungseinstellungen, Nachweise zu SIEM-Konnektoren, Alarmregeln, Triage-Tickets, Aufbewahrungseinstellungen und Überprüfungen administrativer Zugriffe umfassen.

Für kritische SaaS sollten Nachweise zur Erstellung von Admin-Konten, verdächtigen Anmeldungen, Massendownloads, öffentlichen Freigaben, Deaktivierung von MFA, Erstellung von API-Token, Aktivität externer Gäste und Rechteerweiterung vorbereitet werden. Für IaaS sollten CloudTrail oder äquivalente Protokollierung der Kontrollebene, Speicherzugriffsprotokolle, IAM-Änderungen, Flow Logs soweit angemessen, CSPM-Feststellungen, Schwachstellenscans, Patch-Nachweise, Verschlüsselungseinstellungen, Backup-Status, Überprüfungen von Netzwerksicherheitsgruppen und Änderungstickets vorbereitet werden.

Die Auditmethodik von Zenith Controls zu Maßnahme 5.23 weist darauf hin, dass ein Audit im Stil von ISO/IEC 27007 AWS-S3-Bucket-Berechtigungen, Verschlüsselung, IAM-Richtlinien und CloudTrail-Protokollierung prüfen kann. Ein COBIT-orientierter Auditor kann Alarmkonfigurationen, DLP-Kontrollen, die Nutzung von Microsoft 365 Secure Score und Änderungsmanagementprotokolle überprüfen. Eine NIST SP 800-53A-Perspektive kann Kontenmanagement und Überwachung testen, einschließlich der Frage, ob Cloud-Workloads mit derselben Strenge wie interne Systeme gepatcht, gescannt und überwacht werden.

Verschiedene Auditoren sprechen verschiedene Dialekte. Ihre Nachweise sollten dieselben sein.

Ein belastbares Nachweispaket für einen SaaS- und einen IaaS-Service erstellen

Ein praktischer Workflow beginnt mit einer kritischen SaaS-Plattform und einer kritischen IaaS-Umgebung. Zum Beispiel Microsoft 365 für Zusammenarbeit und AWS für Produktionshosting.

Schritt 1: Register für Cloud-Services aktualisieren

Für Microsoft 365 erfassen Sie Zweck, Verantwortlichen, Datentypen, Region, Admin-Konten, Vertrag, DPA, Supportkontakt, Verlängerungstermin und Kritikalität. Für AWS erfassen Sie das Produktionskonto, Regionen, Datenkategorien, Workloads, Kontoverantwortlichen, Root-Kontostatus, Supportplan, Vertragsbedingungen und verknüpfte Geschäftsservices.

Nutzen Sie die Felder der Richtlinie zur Nutzung von Cloud-Diensten-sme als Mindestdatensatz. Ergänzen Sie Kritikalität, regulatorische Relevanz und Nachweisort.

Schritt 2: Geteilte Verantwortung dokumentieren

Für Microsoft 365 umfassen Kundenverantwortlichkeiten Benutzerlebenszyklus, MFA, Conditional Access, Gastfreigaben, Aufbewahrungskennzeichnungen, DLP soweit genutzt, Protokollierung und Vorfalleskalation. Für AWS umfassen Kundenverantwortlichkeiten IAM, Netzwerkregeln, Workload-Härtung, Verschlüsselungskonfiguration, Backup, Protokollierung, Patching und Anwendungssicherheit.

Fügen Sie die Dokumentation des Anbieters zur geteilten Verantwortung bei und ordnen Sie anschließend jede Kundenverantwortung einem Kontrollverantwortlichen und einer Nachweisquelle zu.

Schritt 3: Konfigurationsnachweise erfassen

Für Microsoft 365 exportieren oder dokumentieren Sie per Screenshot MFA- und Conditional-Access-Richtlinien, Admin-Rollen, Einstellungen zur externen Freigabe, Audit-Protokollierung, Aufbewahrungskonfiguration und Security-Score-Maßnahmen. Für AWS exportieren Sie IAM-Passwortrichtlinie, privilegierten MFA-Status, CloudTrail-Konfiguration, S3 Public Access Block, Verschlüsselungsstatus, Sicherheitsgruppenprüfung, Backup-Jobs und Status von Schwachstellenscans.

Die Richtlinie zur Nutzung von Cloud-Diensten verlangt, dass Cloud-Umgebungen einer dokumentierten, vom Cloud-Sicherheitsarchitekten genehmigten Baseline-Konfiguration entsprechen. Ihr Nachweispaket sollte sowohl die Baseline als auch den Nachweis der Übereinstimmung enthalten.

Schritt 4: Lieferanten- und Datenschutznachweise verknüpfen

Fügen Sie Vertrag, DPA, Liste der Unterauftragsverarbeiter, Bedingungen zur Meldung von Verstößen, Audit-Assurance-Berichte und Nachweise zum Datenstandort bei. Wenn personenbezogene Daten verarbeitet werden, erfassen Sie, ob der Anbieter als Auftragsverarbeiter handelt, wie Löschung gehandhabt wird, wie die Unterstützung bei Betroffenenanfragen funktioniert und welche Übermittlungsschutzmaßnahmen gelten.

Für DORA identifizieren Sie, ob der Cloud-Service eine kritische oder wichtige Funktion unterstützt. Falls ja, verknüpfen Sie die Nachweise mit dem IKT-Drittparteienregister, der Due-Diligence-Akte, den Auditrechten, dem Exit-Plan und der Bewertung des Konzentrationsrisikos.

Schritt 5: Protokollierung mit Incident Response verbinden

Zeigen Sie, dass Protokolle aktiviert, weitergeleitet, überprüft und genutzt werden. Fügen Sie SIEM-Dashboards, Alarmregeln und mindestens ein geschlossenes Alarmticket bei. Ordnen Sie den Workflow anschließend den Meldeentscheidungspunkten aus NIS2 und DORA zu.

Für NIS2 muss der Vorfallsprozess eine 24-Stunden-Frühwarnung, eine 72-Stunden-Vorfallmeldung und einen Abschlussbericht innerhalb eines Monats für erhebliche Vorfälle unterstützen. Für DORA sollte der IKT-Vorfallsprozess Vorfälle nach betroffenen Kunden, Transaktionen, Dauer, Ausfallzeit, geografischer Ausbreitung, Datenauswirkung, Servicekritikalität und wirtschaftlichen Auswirkungen klassifizieren.

Schritt 6: Nachweise diszipliniert speichern

Clarysecs P33 – Richtlinie zur Audit- und Compliance-Überwachung-sme P33 – Richtlinie zur Audit- und Compliance-Überwachung-sme definiert in Klausel 6.2 praktische Nachweisdisziplin:

„6.2 Nachweiserhebung und Dokumentation 6.2.1 Alle Nachweise müssen in einem zentralen Auditordner gespeichert werden. 6.2.2 Dateinamen müssen das Auditthema und das Datum eindeutig referenzieren. 6.2.3 Metadaten (z. B. wer den Nachweis erhoben hat, wann und aus welchem System) müssen dokumentiert werden. 6.2.4 Nachweise müssen mindestens zwei Jahre aufbewahrt werden oder länger, wenn dies durch Zertifizierungs- oder Kundenvereinbarungen erforderlich ist.“

Die Enterprise-P33 – Richtlinie zur Audit- und Compliance-Überwachung P33 – Richtlinie zur Audit- und Compliance-Überwachung formuliert das Ziel:

„Belastbare Nachweise und einen Prüfpfad zur Unterstützung von Anfragen von Aufsichtsbehörden, Gerichtsverfahren oder Kundenanfragen zur Vertrauensbildung zu erzeugen.“

Ein Screenshot mit dem Namen „screenshot1.png“ ist ein schwacher Nachweis. Eine Datei mit dem Namen „AWS-Prod-CloudTrail-Enabled-2026-05-10-CollectedBy-JSmith.png“ ist stärker, weil sie System, Kontrolle, Datum und erhebende Person beschreibt. Metadaten sind wichtig, weil Auditoren nachvollziehen müssen, wann ein Nachweis erhoben wurde, wer ihn erhoben hat und aus welchem System er stammt.

Wie Auditoren dieselbe Cloud-Kontrolle prüfen

Die stärksten Cloud-Nachweispakete sind für mehrere Auditperspektiven ausgelegt. ISO 27001:2022-Auditoren prüfen, ob die Kontrolle im ISMS, in der Risikobeurteilung, in der Risikobehandlung und in der SoA enthalten ist. NIST-orientierte Assessoren prüfen die technische Umsetzung. COBIT 2019-Auditoren prüfen Governance, Lieferantenleistung und Prozessintegration. Datenschutzauditoren konzentrieren sich auf Auftragsverarbeiterpflichten, Datenresidenz, Bereitschaft bei Verstößen und Rechte betroffener Personen. DORA-Aufsichtsprüfungen konzentrieren sich auf IKT-Drittparteienrisiko und Resilienz.

Zenith Controls enthält diese Unterschiede der Auditmethodik für Cloud-Services, Lieferantenvereinbarungen und Lieferantenüberwachung. Für 5.22, Überwachung, Überprüfung und Änderungsmanagement von Lieferantendiensten, hebt es hervor, dass Auditoren quartalsweise Protokolle von Lieferantenüberprüfungen, KPI-Berichte, SOC-Berichtsbewertungen, Änderungsprotokolle, Risikobeurteilungen, Lieferantenvorfälle und Maßnahmenverfolgung prüfen können. Für 5.20, Adressierung von Informationssicherheit in Lieferantenvereinbarungen, hebt es Vertragsstichproben zu Vertraulichkeit, Sicherheitsverpflichtungen, Meldung von Verstößen, Auditrechten, Genehmigung von Unterauftragnehmern und Beendigungsbedingungen hervor.

Cross-Compliance-Kontrollen, die die Cloud-Auditlast tragen

Ein belastbares Cloud-Nachweismodell basiert auf wenigen besonders wirksamen Kontrollen. Diese Kontrollen tragen einen großen Teil der Compliance-Last über ISO 27001:2022, NIS2, DORA, GDPR, NIST und COBIT 2019 hinweg.

NIST SP 800-53 Rev.5 ergänzt technische Tiefe durch Kontenmanagement, externe Systemdienste, kontinuierliche Überwachung, Systemüberwachung und Schutz von Netzgrenzen. COBIT 2019 ergänzt Governance-Tiefe durch Management von Lieferantenbeziehungen, Lieferantenrisiko, Datenaustausch, Netzwerksicherheit und Änderungsbereitschaft.

Unterstützende ISO-Standards schärfen das Nachweismodell. ISO/IEC 27017 bietet cloud-spezifische Leitlinien zu geteilten Rollen, Konfiguration virtueller Maschinen und Überwachung von Kundenaktivitäten. ISO/IEC 27018 konzentriert sich auf den Schutz personenbezogener Daten in der Public Cloud. ISO/IEC 27701 erweitert Datenschutzpflichten in Verarbeiter- und Verantwortlichenprozesse. ISO/IEC 27036-4 unterstützt Cloud-Lieferantenvereinbarungen und Überwachung. ISO/IEC 27005 unterstützt die Cloud-Risikobeurteilung.

Die Managementbewertung muss Cloud-Risiken sehen, nicht nur Cloud-Verfügbarkeit

Eines der am häufigsten übersehenen Audit-Artefakte ist die Managementbewertung. ISO 27001:2022 erwartet, dass die Managementbewertung Änderungen, Bedürfnisse interessierter Parteien, Leistungstrends, Auditergebnisse, Status der Risikobehandlung und Verbesserungsmöglichkeiten berücksichtigt. NIS2 verlangt, dass Leitungsorgane Maßnahmen zum Cybersicherheitsrisikomanagement genehmigen und deren Umsetzung beaufsichtigen. DORA verlangt, dass das Leitungsorgan das IKT-Risikomanagement definiert, genehmigt, überwacht und dafür rechenschaftspflichtig bleibt.

Ein quartalsweises Dashboard zu Cloud-Sicherheit und Lieferanten sollte Folgendes zeigen:

• Anzahl genehmigter Cloud-Services.
• Kritische Cloud-Services und Verantwortliche.
• Services, die personenbezogene Daten verarbeiten.
• Services, die kritische oder wichtige Funktionen unterstützen.
• Offene risikobehaftete Cloud-Fehlkonfigurationen.
• Status von MFA und Überprüfung privilegierter Zugriffe.
• Protokollierungsabdeckung für kritische SaaS- und IaaS-Plattformen.
• Erhaltene und überprüfte Berichte zur Lieferantensicherheit.
• Vertragsausnahmen und akzeptierte Risiken.
• Cloud-Vorfälle, Beinahe-Vorfälle und Lessons Learned.
• Ergebnisse von Backup- und Wiederherstellungstests.
• Status von Konzentrationsrisiko und Exit-Plan.

Dieses Dashboard wird zum Nachweis für Führung und Leistungsbewertung nach ISO 27001:2022, NIS2-Governance und DORA-Managementverantwortung.

Zenith Blueprint empfiehlt in der Risikomanagementphase, Schritt 14, regulatorische Anforderungen bei der Umsetzung von Risikobehandlungen und Richtlinien querzuverweisen. Es stellt fest, dass die Zuordnung wesentlicher regulatorischer Anforderungen zu ISMS-Kontrollen eine nützliche interne Übung ist und „Auditoren/Assessoren außerdem beeindruckt, weil Sie Sicherheit nicht im luftleeren Raum managen, sondern den rechtlichen Kontext kennen.“

Das ist der Reifegrad, den Aufsichtsbehörden und Unternehmenskunden erwarten.

Häufige Cloud-Auditfeststellungen und wie sie vermieden werden

In Projekten zur Cloud-Auditbereitschaft sind wiederkehrende Feststellungen vorhersehbar:

1. Das Register für Cloud-Services existiert, aber SaaS-Werkzeuge fehlen.
2. Der Datenstandort ist nicht erfasst oder wird aus Marketingseiten statt aus Vertragsnachweisen übernommen.
3. MFA wird für Beschäftigte durchgesetzt, aber nicht für alle administrativen oder Break-Glass-Konten.
4. Cloud-Protokolle sind aktiviert, werden aber nicht überprüft, aufbewahrt oder mit Incident Response verknüpft.
5. SOC-Berichte von Lieferanten werden archiviert, aber nicht bewertet.
6. Vertragsklauseln bestehen für neue Lieferanten, aber nicht für kritische Legacy-Services.
7. Benachrichtigungen zu Unterauftragsverarbeitern gehen per E-Mail ein, werden aber nicht risikobewertet.
8. Backup-Jobs laufen erfolgreich, aber Wiederherstellungstests sind nicht nachgewiesen.
9. Geteilte Verantwortung wird von Engineers verstanden, aber nicht für Auditoren dokumentiert.
10. Die SoA markiert Cloud-Kontrollen als anwendbar, verknüpft sie jedoch nicht mit Risikoeinträgen, Nachweisen oder Verantwortlichen.

Das sind Nachvollziehbarkeitsprobleme. Die Lösung besteht darin, Richtlinie, Risiko, Kontrolle, Verantwortlichen, Nachweis und Überprüfung zu verbinden.

Als Maria am Audittag angekommen war, verließ sie sich nicht mehr auf verstreute Screenshots. Sie öffnete ein zentrales Dashboard mit dem Register für Cloud-Services, Risikobeurteilungen, SoA-Einträgen, Nachweisen zur Baseline-Konfiguration, Lieferantenprüfdateien, Protokollierungsnachweisen und der DORA-Bewertung des Konzentrationsrisikos. Als der Auditor fragte, wie Cloud-Risiken gesteuert werden, zeigte sie das ISMS. Als der Auditor fragte, wie Services sicher konfiguriert werden, zeigte sie die Baseline und CSPM-Nachweise. Als der Auditor nach IKT-Drittparteienrisiko fragte, zeigte sie Vertragsprüfung, Lieferantenüberwachung und Exit-Planung.

Das Ergebnis war keine perfekte Umgebung. Keine Cloud-Umgebung ist perfekt. Der Unterschied war, dass Risikoentscheidungen dokumentiert, Nachweise belastbar und Rechenschaftspflicht sichtbar waren.

Erstellen Sie Ihr Cloud-Nachweispaket, bevor der Auditor fragt

Wenn Ihre Organisation auf SaaS, IaaS oder PaaS angewiesen ist, wird Ihr nächstes Audit „der Anbieter kümmert sich darum“ nicht als ausreichende Antwort akzeptieren. Sie müssen geteilte Verantwortung, kundenseitige Konfiguration, Lieferantenklauseln, Protokollierung, Vorfallsbereitschaft, Resilienz und Managementaufsicht belegen.

Beginnen Sie diese Woche mit drei praktischen Maßnahmen:

1. Erstellen oder aktualisieren Sie Ihr Register für Cloud-Services mit Clarysecs Richtlinie zur Nutzung von Cloud-Diensten Richtlinie zur Nutzung von Cloud-Diensten oder Richtlinie zur Nutzung von Cloud-Diensten-sme Richtlinie zur Nutzung von Cloud-Diensten-sme.
2. Ordnen Sie Ihre fünf wichtigsten Cloud-Services den ISO 27001:2022 Annex-A-Kontrollen, NIS2 Article 21, den DORA-Verpflichtungen zu IKT-Drittparteien soweit anwendbar und den GDPR-Anforderungen an Auftragsverarbeiter zu.
3. Erstellen Sie einen zentralen Nachweisordner unter Nutzung der Aufbewahrungs- und Metadatendisziplin aus P33 – Richtlinie zur Audit- und Compliance-Überwachung P33 – Richtlinie zur Audit- und Compliance-Überwachung oder P33 – Richtlinie zur Audit- und Compliance-Überwachung-sme P33 – Richtlinie zur Audit- und Compliance-Überwachung-sme.

Nutzen Sie anschließend Zenith Blueprint Zenith Blueprint, um die Arbeit in die 30-Schritte-ISMS-Audit-Roadmap einzuordnen, und Zenith Controls Zenith Controls, um Cross-Compliance-Zuordnungen, unterstützende ISO-Standards und Erwartungen an die Auditmethodik zu validieren.

Clarysec kann Ihnen helfen, verstreute Cloud-Screenshots, Lieferantendateien und SaaS-Einstellungen in ein belastbares Nachweispaket zu überführen, das ISO 27001:2022-Zertifizierungsaudits, NIS2-Aufsichtsfragen, DORA-IKT-Drittparteienprüfungen und Anforderungen von Unternehmenskunden an Sicherheitsnachweise standhält.