Matrix zur gemeinsamen Verantwortung in der Cloud für ISO, NIS2 und DORA

Ein Fintech-COO ruft den CISO an einem Montag um 07:15 Uhr an.

Ein europäischer Bankkunde verlangt einen Nachweis, dass die SaaS-Plattform des Unternehmens die Anforderungen von DORA an IKT-Drittparteienrisiken erfüllen kann. Das Vertriebsteam hat bereits das vertraute Paket zur Lieferantensicherheit versendet: ISO-Zertifikat, Zusammenfassung des Penetrationstests für das Management, Cyberversicherungszertifikat, Datenschutzhinweis und Assurance-Bericht des Cloud-Anbieters.

Die Bank kommt mit einer präziseren Frage zurück:

„Zeigen Sie uns, wer jede einzelne Kontrolle in Ihrer Cloud-Umgebung verantwortet: Sie, Ihr Cloud-Anbieter, Ihr Anbieter für verwaltete Datenbanken, Ihr Identitätsanbieter, Ihr Anbieter für Protokollierung und alle Unterauftragsverarbeiter. Und zeigen Sie anschließend die Nachweise.“

Später am selben Vormittag hat der CISO eine Sitzung mit dem Leitungsorgan. Der CEO wird dieselbe Frage in Geschäftssprache stellen: „Sind wir sicher, dass diese Plattform geschützt ist, und wer ist verantwortlich, wenn etwas schiefgeht?“

An genau diesem Punkt geraten viele Programme zur Cloud-Compliance ins Stocken.

Die Organisation verfügt möglicherweise über einen starken Cloud-Anbieter, gute Werkzeuge, angemessene Richtlinien und ein Risikoregister. Sobald jedoch Verantwortungsgrenzen nachgewiesen werden sollen, sind die Nachweise verstreut. Die Beschaffung hat die Verträge. Die Rechtsabteilung hat den Auftragsverarbeitungsvertrag. Das Engineering-Team hat Architekturdiagramme. Die Informationssicherheit hat Protokolle und Cloud-Konfigurationen. Die Datenschutzfunktion hat die Liste der Unterauftragsverarbeiter. Compliance hat die Anwendbarkeitserklärung. Niemand verfügt über eine gelenkte Aufzeichnung, die Kontrolle für Kontrolle festhält, was der Anbieter übernimmt, was der Kunde konfigurieren muss, welcher Unterauftragsverarbeiter beteiligt ist, welche Klausel die Verpflichtung durchsetzbar macht und welche Nachweise ein Auditor erwarten sollte.

Diese Aufzeichnung ist die Matrix zur gemeinsamen Verantwortung in der Cloud.

Nicht die generische Hyperscaler-Folie, die erklärt, dass der Anbieter die Cloud absichert und der Kunde absichert, was in der Cloud betrieben wird. Eine belastbare Matrix zur gemeinsamen Verantwortung in der Cloud für ISO/IEC 27001:2022, NIS2, DORA und GDPR ist eine Governance-Aufzeichnung. Sie hält einer Due-Diligence-Prüfung durch Kunden, einem ISO-Audit, einer DORA-Prüfung, einer Rechenschaftsanforderung nach GDPR und einer Vorfallsuntersuchung stand.

Warum gemeinsame Verantwortung in der Cloud zum Auditproblem wird

Das Modell der gemeinsamen Verantwortung wird meist als technische Abgrenzung vermittelt. Bei IaaS betreibt der Anbieter physische Einrichtungen, Hardware, Virtualisierung und zentrale Infrastruktur. Der Kunde verantwortet Identitäten, Daten, Workloads, Netzwerkregeln, Entscheidungen zur Verschlüsselung und Konfigurationen. Bei SaaS übernimmt der Anbieter mehr operative Verantwortung, dennoch verbleiben Benutzerzugriff, Governance-Modell für Daten, Rechtsgrundlage, Konfiguration, Erwartungen an die Überwachung und Vorfalleskalation beim Kunden.

Diese Erklärung ist nützlich, aber unvollständig.

Auditoren, Aufsichtsbehörden und Unternehmenskunden fragen nicht nur: „Wer betreibt die Kontrolle?“ Sie wollen wissen:

• Wer ist für das Risiko rechenschaftspflichtig?
• Welche Vertragsklausel macht diese Rechenschaftspflicht durchsetzbar?
• Welche Richtlinie verlangt die Kontrolle?
• Welcher Cloud-Dienst, welche SaaS-Plattform oder welcher Unterauftragsverarbeiter liegt im Geltungsbereich?
• Welche Nachweise belegen, dass die Kontrolle im Prüfzeitraum wirksam war?
• Welche Anforderung eines Rahmenwerks wird durch die Nachweise erfüllt?
• Was geschieht, wenn der Anbieter seinen Dienst, Standort, Unterauftragnehmer oder sein Kontrollprofil ändert?

ISO/IEC 27001:2022 ISO/IEC 27001:2022 macht daraus ein Thema des Managementsystems. Die Klauseln 4.1 bis 4.4 verlangen, dass die Organisation interne und externe Themen, interessierte Parteien, gesetzliche und vertragliche Verpflichtungen, den ISMS-Geltungsbereich, Schnittstellen und Abhängigkeiten versteht. Die Klauseln 6.1.1 bis 6.1.3 verlangen Risikobeurteilung, Risikobehandlung, Genehmigung durch den Risikoverantwortlichen, Restrisikoakzeptanz und eine Anwendbarkeitserklärung. Klausel 8.1 verlangt operative Planung und Steuerung, einschließlich der Steuerung extern bereitgestellter Prozesse, Produkte und Dienstleistungen, die für das ISMS relevant sind.

Einfach gesagt: Wenn ein Cloud-Anbieter, SaaS-Anbieter oder Unterauftragsverarbeiter einen im Geltungsbereich befindlichen Geschäftsprozess unterstützt, darf er nicht außerhalb des ISMS stehen. Er muss in Geltungsbereich, Risiko, Behandlung, vertraglicher Kontrolle und Nachweisen sichtbar sein.

NIS2 erhöht die Anforderungen. Article 21 verlangt von wesentlichen und wichtigen Einrichtungen die Umsetzung geeigneter und verhältnismäßiger technischer, operativer und organisatorischer Maßnahmen, einschließlich Risikoanalyse, Behandlung von Sicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sicherer Beschaffung, sicherer Entwicklung, Schwachstellenbehandlung, Wirksamkeitsbewertung, Cyberhygiene, Kryptografie, Personalsicherheit, Zugriffskontrolle, Asset-Management und, soweit angemessen, Multi-Faktor-Authentifizierung oder kontinuierlicher Authentifizierung. Article 20 weist Leitungsorganen Governance-Verantwortung zu.

DORA ist für Finanzunternehmen noch ausdrücklicher. DORA gilt ab dem 17. Januar 2025 und verpflichtet Finanzunternehmen, IKT-Risiken, die Meldung schwerwiegender IKT-bezogener Vorfälle, Tests der digitalen operationalen Resilienz und IKT-Drittparteienrisiken zu steuern. Articles 28 bis 30 verlangen das Management von IKT-Drittparteienrisiken, eine vorgelagerte Bewertung von Konzentrationsrisiken, vertragliche Sicherheitsmaßnahmen, Audit- und Zugriffsrechte, Transparenz über Unterauftragsvergabe, Kündigungsrechte und Exit-Strategien.

GDPR ergänzt den Rechenschaftstest. Article 5 verlangt, dass personenbezogene Daten mit Integrität und Vertraulichkeit verarbeitet werden, und Article 5(2) verlangt, dass der Verantwortliche die Einhaltung nachweisen kann. Article 28 regelt Verträge mit Auftragsverarbeitern und Unterauftragsverarbeitern. Article 32 verlangt Sicherheit der Verarbeitung. Articles 33 und 34 verlangen, soweit anwendbar, die Meldung von Verletzungen des Schutzes personenbezogener Daten.

Die Matrix zur gemeinsamen Verantwortung in der Cloud wird zur Brücke zwischen diesen Verpflichtungen.

Die Clarysec-Definition: ein Governance-Artefakt, kein Diagramm

In Clarysec-Mandaten ist eine Matrix zur gemeinsamen Verantwortung in der Cloud eine gelenkte ISMS-Aufzeichnung, die Cloud-Dienste, Lieferanten, Unterauftragsverarbeiter, Kontrollen, Richtlinien, vertragliche Verpflichtungen, Nachweise und Auditerwartungen miteinander verknüpft.

Die treffendste Erklärung findet sich in Zenith Blueprint Zenith Blueprint, in der Phase „Controls in Action“, Schritt 23:

„Cloud-Anbieter sichern die Infrastruktur, aber Sie bleiben rechenschaftspflichtig für Ihre Daten, Ihre Konfigurationen, Ihre Zugriffsrichtlinien und Ihre Incident-Response-Bereitschaft.“

Derselbe Schritt erläutert, dass die Nutzung von Cloud-Diensten als Teil des ISMS zu behandeln ist, einschließlich Klassifizierung von Cloud-Diensten, Verständnis der verarbeiteten oder gespeicherten Daten, Anbieterbewertung, Vertragsklauseln und Management von Serviceänderungen. Dadurch wird gemeinsame Verantwortung von einem Konzept in eine nachvollziehbare Kontrollstruktur überführt.

Zenith Controls Zenith Controls behandelt ISO/IEC 27001:2022 Annex A-Maßnahmen und die ISO/IEC 27002:2022-Leitlinien 5.20, 5.21 und 5.23 als zentrale Anker:

• 5.20, Informationssicherheit in Lieferantenvereinbarungen berücksichtigen.
• 5.21, Informationssicherheit in der IKT-Lieferkette steuern.
• 5.23, Informationssicherheit bei der Nutzung von Cloud-Diensten.

Dies sind keine isolierten Checklisteneinträge. Sie bilden das Rückgrat der Matrix.

Unterstützende Standards können die Matrix stärken. ISO/IEC 27017 hilft bei cloud-spezifischen Sicherheitspraktiken. ISO/IEC 27018 und ISO/IEC 27701 unterstützen personenbezogene Daten und Datenschutz-Governance. ISO/IEC 27005 unterstützt die Risikobeurteilung. ISO 22301 unterstützt Aufrechterhaltung des Geschäftsbetriebs und Resilienz. ISO/IEC 27035 unterstützt das Vorfallmanagement. ISO/IEC 20000-1 kann helfen, wenn Cloud-Dienste Teil der gesteuerten Leistungserbringung sind.

Die minimal tragfähige Matrix zur gemeinsamen Verantwortung

Eine reife Matrix beginnt nicht mit 200 Zeilen. Sie beginnt mit den Cloud-Diensten, die am wichtigsten sind.

Für ein SaaS-Unternehmen, ein Fintech oder ein reguliertes KMU beginnt Clarysec üblicherweise mit:

1. Kundenbezogene Produktiv-Cloud-Umgebung.
2. Identitätsanbieter.
3. Verwaltete Datenbank oder Speicherdienst.
4. Plattform für Protokollierung, Überwachung und SIEM.
5. Zahlungs-, KYC-, Analyse- oder Kundensupport-SaaS.
6. Dienst für Backup und Disaster Recovery.
7. Managed Service Provider oder Managed Security Service Provider.
8. Unterauftragsverarbeiter, die auf Kundendaten zugreifen, diese speichern oder verarbeiten.

Die erste Matrix sollte die folgenden Spalten enthalten.

Eine praxisnahe Protokollierungszeile könnte so aussehen.

Diese Zeile ist nicht nur Dokumentation. Sie sagt der Informationssicherheit, was zu konfigurieren ist, der Beschaffung, welche Vertragssprache zu prüfen ist, der Datenschutzfunktion, welchen Datenfluss sie erfassen muss, und Auditoren, welche Nachweise anzufordern sind.

Richtlinienbasis: die Matrix zur durchsetzbaren Anforderung machen

Eine Matrix zur gemeinsamen Verantwortung in der Cloud ohne Richtlinienunterstützung ist nur eine Tabelle. Clarysec-Richtlinien machen sie durchsetzbar.

Für KMU verlangt die Richtlinie zur Nutzung von Cloud-Diensten - KMU Richtlinie zur Nutzung von Cloud-Diensten - KMU, Abschnitt „Governance-Anforderungen“, Klausel 5.3:

„Ein Register für Cloud-Services muss durch den IT-Dienstleister oder den General Manager gepflegt werden. Es muss Folgendes erfassen:“

Dieselbe KMU-Richtlinie verknüpft in Klausel 5.2.3 Cloud-Governance mit Datenschutz- und Standort­risiken:

„Datenresidenz und Datenschutzpraktiken erfüllen die anwendbaren rechtlichen Anforderungen (z. B. GDPR)“

Für Enterprise-Umgebungen besagt die Richtlinie zur Nutzung von Cloud-Diensten Richtlinie zur Nutzung von Cloud-Diensten, Abschnitt „Governance-Anforderungen“, Klausel 5.1:

„Die Organisation muss ein zentrales Register für Cloud-Services führen, das vom CISO verantwortet wird und Folgendes enthält:“

Klausel 5.4 macht Cloud-Verantwortlichkeiten anschließend vertraglich durchsetzbar:

„Alle Verträge mit CSP (Cloud Service Provider) müssen durchsetzbare Bestimmungen enthalten für:“

Lieferanten-Governance erweitert die Matrix über den unmittelbaren Anbieter hinaus. Die Richtlinie zur Lieferanten- und Drittparteiensicherheit - KMU Richtlinie zur Lieferanten- und Drittparteiensicherheit - KMU, Abschnitt „Governance-Anforderungen“, Klausel 5.3.5 verlangt:

„Beschränkungen weiterer Unterauftragsvergabe ohne Genehmigung“

Dieselbe KMU-Lieferantenrichtlinie ergänzt in Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Klausel 6.3.1 eine regelmäßige Überprüfung:

„Kritische Lieferanten oder Lieferanten mit hohem Risiko müssen mindestens jährlich überprüft werden. Die Überprüfung muss verifizieren:“

Auf Enterprise-Ebene besagt die Richtlinie zur Lieferanten- und Drittparteiensicherheit Richtlinie zur Lieferanten- und Drittparteiensicherheit, Abschnitt „Governance-Anforderungen“, Klausel 5.3:

„Verträge mit Lieferanten müssen enthalten:“

Für personenbezogene Daten verlangt die Richtlinie zu Datenschutz und Privatsphäre Richtlinie zu Datenschutz und Privatsphäre, Abschnitt „Durchsetzung und Einhaltung“, Klausel 8.5.1:

„Verträge mit Auftragsverarbeitern müssen enthalten:“

Für Transparenz über Abhängigkeiten verlangt die Richtlinie zum Management von Risiken aus Lieferantenabhängigkeiten Richtlinie zum Management von Risiken aus Lieferantenabhängigkeiten, Klausel 6.5.4:

„Nutzung der Lieferantenbeziehung, um Aktualisierungen zu Unterauftragnehmern oder Lieferkettenabhängigkeiten eine Ebene nachgelagert zu erhalten, sofern diese uns betreffen können (wenn beispielsweise ein kritischer Softwarelieferant stark von einer Drittanbieterbibliothek abhängt, ist dies zu dokumentieren).“

Für Protokolle stellt die Richtlinie zur Protokollierung und Überwachung - KMU Richtlinie zur Protokollierung und Überwachung - KMU, Abschnitt „Governance-Anforderungen“, Klausel 5.5.1.3 eine konkrete vertragliche Anforderung bereit:

„Verträge müssen Anbieter verpflichten, Protokolle mindestens 12 Monate aufzubewahren und auf Anfrage Zugriff bereitzustellen“

Zusammen machen diese Richtlinien die Matrix zu einer erforderlichen Governance-Aufzeichnung, die Lieferantenfreigabe, Cloud-Onboarding, Datenschutz-Rechenschaftspflicht, jährliche Überprüfung und Auditnachweise unterstützt.

Zuordnung der Matrix über ISO/IEC 27001:2022, NIS2, DORA und GDPR hinweg

Der klassische Fehler besteht darin, vier getrennte Compliance-Arbeitsmappen zu erstellen. Eine Kontrolle kann mehrere Verpflichtungen erfüllen, wenn Verantwortung und Nachweise nachvollziehbar sind.

ISO/IEC 27001:2022 stellt den ISMS-Motor bereit: Kontext, interessierte Parteien, Geltungsbereich, Führung, Risikobehandlung, Ziele, operative Steuerung, Leistungsbewertung und Verbesserung. Annex A liefert die praktische Kontrollstruktur.

NIS2 Article 21 lässt sich über Sicherheit der Lieferkette, Behandlung von Sicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Zugriffskontrolle, Asset-Management und sichere Beschaffung natürlich derselben Matrix zuordnen. Article 20 macht die Matrix für das Leitungsorgan relevant, weil Leitungsorgane Maßnahmen zum Management von Cybersicherheitsrisiken genehmigen und beaufsichtigen müssen.

DORA macht die Matrix zu einem Werkzeug für IKT-Drittparteienrisiken. Articles 5, 6 und 8 verlangen Governance, dokumentiertes IKT-Risikomanagement und die Identifizierung von Assets, Funktionen und Abhängigkeiten. Articles 17 bis 19 verlangen Vorfallserkennung, Klassifizierung, Eskalation, Kommunikation und Berichterstattung. Articles 28 bis 30 verlangen Drittparteienrisikomanagement, Analyse von Konzentrationsrisiken, Vertragsklauseln, Kontrollen zur Unterauftragsvergabe, Auditrechte, Kündigungsrechte und Exit-Strategien.

GDPR ergänzt die Perspektive personenbezogener Daten. Jede Zeile zu einem Cloud-Dienst sollte ausweisen, ob personenbezogene Daten verarbeitet werden, ob der Anbieter Auftragsverarbeiter oder Unterauftragsverarbeiter ist, ob der Datenstandort relevant ist und welche Vertrags- oder Auftragsverarbeitungsvertragsnachweise vorliegen.

NIST CSF 2.0 hilft, dieselbe Matrix in Ergebnislogik zu kommunizieren. Die Funktion GOVERN adressiert Organisationskontext, gesetzliche und regulatorische Anforderungen, Abhängigkeiten, Risikomanagement, Rollen, Richtlinien und Aufsicht. GV.SC-Ergebnisse sind besonders nützlich für Cyberrisiken von Lieferanten, einschließlich Lieferantenrollen, Kritikalität, vertraglicher Anforderungen, gebotener Sorgfalt, Überwachung, Vorfallskoordination und Beendigungsplanung.

COBIT 2019 ergänzt eine Assurance- und Governance-Perspektive. Es fragt, ob Rechenschaftspflicht, Managementpraktiken, Eigentümerschaft, Überwachung und Behebung von Problemen wiederholbar und nachgewiesen sind.

Die Matrix vom Register bis zum Nachweis aufbauen

Stellen Sie sich ein SaaS-Unternehmen vor, das eine Hyperscale-IaaS-Plattform, eine verwaltete Datenbank, einen Identitätsanbieter eines Drittanbieters, eine SaaS-Plattform für Kundensupport und ein externes SIEM nutzt. Der Umsetzungsablauf ist klar.

Schritt 1: Mit dem Register für Cloud-Dienste beginnen

Nutzen Sie die Richtlinie zur Nutzung von Cloud-Diensten oder die Richtlinie zur Nutzung von Cloud-Diensten - KMU als Auslöser. Erfassen Sie jeden Cloud-Dienst, Verantwortlichen, Zweck, Datenkategorien, Standort, Geschäftsfunktion, Lieferantenstufe, Vertragsverantwortlichen und Überprüfungsdatum.

Wenn der Dienst Kundendatensätze, Authentifizierungsprotokolle oder Support-Tickets speichert, kennzeichnen Sie ihn als datenschutzrelevant. Wenn er die Produktivverfügbarkeit unterstützt, kennzeichnen Sie ihn als betriebskritisch. Wenn er eine kritische oder wichtige Funktion eines Finanzkunden unterstützt, kennzeichnen Sie ihn als DORA-relevant.

Schritt 2: Domänen der gemeinsamen Verantwortung ergänzen

Definieren Sie für jeden Dienst die Verantwortlichkeiten über die Kerndomänen hinweg.

Schritt 3: Kontrollen mit Risiko und Anwendbarkeitserklärung verknüpfen

Zenith Blueprint, Phase Risikomanagement, Schritt 13, erläutert die Anforderung an die Nachvollziehbarkeit:

„Regelwerke quermappen: Wenn bestimmte Kontrollen speziell umgesetzt werden, um GDPR, NIS2 oder DORA einzuhalten, können Sie dies entweder im Risikoregister (als Teil der Begründung der Risikoauswirkung) oder in den SoA-Hinweisen vermerken.“

Beispielsweise kann das Risiko „unbefugter Zugriff auf Kundendaten in der Produktion durch Cloud-Fehlkonfiguration“ Zugriffskontrolle, Cloud-Nutzung, Protokollierung, Kryptografie, Schwachstellenmanagement und Lieferantenvereinbarungen zugeordnet werden. Die Anwendbarkeitserklärung (SoA) kann ISO/IEC 27001:2022 Annex A 5.15, 5.16, 5.20, 5.23, 8.8, 8.15, 8.16 und 8.24 referenzieren, mit Hinweisen zu GDPR Article 32, NIS2 Article 21 und, soweit anwendbar, DORA-IKT-Risikomanagement.

Schritt 4: Nachweise vor der Auditsaison anhängen

Nachweise sollten in die Matrix eingebaut werden, statt in Panik gesammelt zu werden.

Die Nachweisliste macht Verantwortung beweisbar. Sie hilft auch kommerziellen Teams, Enterprise-Due-Diligence schneller zu beantworten, weil sie nicht nur Zertifizierungen, sondern auch Kontrollverantwortung und Betriebsnachweise zeigen können.

Unterauftragsverarbeiter: der blinde Fleck in den meisten Matrizen

Bei Unterauftragsverarbeitern wird gemeinsame Verantwortung zum realen Lieferkettenrisiko.

Ein SaaS-Anbieter kann unter GDPR Ihr Auftragsverarbeiter sein. Dieser Anbieter kann wiederum auf einen Cloud-Hosting-Anbieter, ein CDN, einen Analysedienst, eine Supportplattform, einen E-Mail-Zustelldienst, eine verwaltete Datenbank, einen Observability-Anbieter und einen Zahlungsabwickler zurückgreifen. Einige können auf personenbezogene Daten zugreifen. Einige unterstützen kritische Leistungserbringung, ohne Daten direkt einzusehen. Einige können außerhalb der EU sitzen. Einige sind ersetzbar. Andere erzeugen Konzentrationsrisiken.

DORA Article 29 verlangt eine Bewertung von Konzentrationsrisiken für kritische oder wichtige IKT-Dienste, einschließlich Ersetzbarkeit, Mehrfachvereinbarungen mit demselben oder verbundenen Anbietern, Unterauftragsketten, Unterauftragnehmern in Drittländern, Insolvenzrecht, Beschränkungen der Datenwiederherstellung und Durchsetzbarkeit des Datenschutzrechts der Union. DORA Article 30 verlangt vertragliche Bestimmungen zu Bedingungen der Unterauftragsvergabe, Standorten, Datenverarbeitung und -speicherung, Zugriff und Wiederherstellung, Unterstützung bei Vorfällen, Zusammenarbeit mit Behörden, Auditrechten, Beendigung und Exit.

NIS2 Article 21 verlangt ebenfalls Sicherheit der Lieferkette für direkte Lieferanten und Dienstleister, einschließlich der Berücksichtigung lieferantenspezifischer Schwachstellen, Cybersicherheitspraktiken von Lieferanten und Verfahren zur sicheren Entwicklung.

Deshalb behandelt Clarysec die Zuordnung von Unterauftragsverarbeitern als erforderliche Erweiterung der Lieferanten-Governance, nicht nur als Datenschutzliste. Das Register der Unterauftragsverarbeiter sollte ausweisen, welcher Lieferant den Unterauftragsverarbeiter nutzt, welcher Dienst davon abhängt, ob personenbezogene Daten verarbeitet werden, ob er eine kritische Funktion unterstützt, die Verarbeitungsregion, soweit relevant, weiterzugebende Verpflichtungen, Genehmigungs- oder Widerspruchsrechte, verfügbare Assurance, Überwachungsmethode und Exit-Option.

Zenith Blueprint, Phase „Controls in Action“, Schritt 23, besagt:

„Identifizieren Sie für jeden kritischen Lieferanten, ob er Unterauftragnehmer (Unterauftragsverarbeiter) einsetzt, die auf Ihre Daten oder Systeme zugreifen können. Dokumentieren Sie, wie Ihre Informationssicherheitsanforderungen an diese Parteien weitergegeben werden, entweder über die Vertragsbedingungen Ihres Lieferanten oder über Ihre eigenen direkten Klauseln.“

Das ist die Nachweistiefe, die Auditoren erwarten, wenn sie fragen, ob Cloud-Verantwortlichkeiten nachgelagert kontrolliert werden.

Wie Auditoren dieselbe Matrix prüfen

Eine starke Matrix zur gemeinsamen Verantwortung in der Cloud hält mehreren Auditansätzen stand, weil sie um Verantwortlichkeit, Durchsetzbarkeit und Nachweise herum aufgebaut ist.

Die Matrix ist nicht das Endziel. Sie ist die Karte, mit der Auditoren prüfen, ob das Governance-System tatsächlich funktioniert.

Ein ISO-Auditor kann ein Cloud-Zugriffsrisiko mit hoher Tragweite auswählen und es vom Risikoregister zur SoA sowie weiter zu Berechtigungsüberprüfungen, MFA-Nachweisen und Überwachungswarnmeldungen nachverfolgen. Ein DORA-Prüfer kann einen kritischen IKT-Anbieter auswählen und den Exit-Test, die Analyse der Unterauftragsvergabe und vertragliche Auditrechte anfordern. Ein GDPR-Prüfer kann sich auf Löschung, Datenresidenz, Meldung von Datenschutzverletzungen und Transparenz zu Unterauftragsverarbeitern konzentrieren.

Häufige Fehlermuster

Die häufigsten Fehler bei gemeinsamer Verantwortung sind nicht exotisch.

Erstens verlassen sich Organisationen auf Assurance-Berichte von Anbietern, ohne sie den Verantwortlichkeiten des Kunden zuzuordnen. Ein Cloud-Anbieter kann physische Sicherheit, Infrastrukturresilienz und Plattformkontrollen nachweisen, aber nicht, ob Ihr Storage Bucket privat war, IAM-Rollen dem Prinzip der minimalen Berechtigung entsprachen oder Protokolle aktiviert waren.

Zweitens enthalten Verträge generische Sicherheitssprache, aber keine Vorfallfristen, Zugriffsrechte auf Protokolle, Auditrechte, Beschränkungen der Unterauftragsvergabe, Bestimmungen zur Datenrückgabe oder Exit-Unterstützung. Zenith Blueprint, Phase „Controls in Action“, Schritt 23 hebt typische Bereiche von Lieferantenvereinbarungen hervor, etwa Vertraulichkeit, Zugriffskontrolle, technische und organisatorische Maßnahmen, Vorfallfristen, Auditrechte, Kontrollen für Unterauftragnehmer und Bestimmungen zum Vertragsende.

Drittens werden Unterauftragsverarbeiter für Datenschutz­zwecke gelistet, aber nicht mit Sicherheit, Kontinuität oder Konzentrationsrisiko verknüpft. Ein nachgelagerter Observability- oder Supportanbieter erscheint möglicherweise nie im Risikoregister, obwohl sein Ausfall oder seine Sicherheitsverletzung die Leistungserbringung gegenüber Kunden beeinträchtigen könnte.

Viertens sagt die SoA, dass eine Kontrolle anwendbar ist, aber niemand kann operative Nachweise liefern. Cloud-Protokollierung kann als umgesetzt markiert sein, aber die Organisation kann Einstellungen zur Aufbewahrung, Berechtigungsüberprüfungen, Behandlung von Warnmeldungen oder Zusagen des Anbieters zum Zugriff auf Protokolle nicht nachweisen.

Fünftens spiegeln Incident-Response-Pläne Anbieterabhängigkeiten nicht wider. Wenn der Anbieter einen Plattformvorfall meldet: Wer bewertet die Kundenauswirkung? Wer bestimmt, ob eine Meldung nach NIS2, DORA oder GDPR erforderlich ist? Wer kontaktiert betroffene Kunden? Was gilt, wenn die Ursache bei einem Unterauftragsverarbeiter liegt?

Rechenschaftspflicht des Managements: warum das Leitungsorgan betroffen ist

NIS2 Article 20 verpflichtet Leitungsorgane, Maßnahmen zum Management von Cybersicherheitsrisiken zu genehmigen, deren Umsetzung zu beaufsichtigen und Schulungen zu erhalten. DORA Article 5 verpflichtet das Leitungsorgan, Vorkehrungen für das IKT-Risikomanagement zu definieren, zu genehmigen, zu beaufsichtigen und zu verantworten, einschließlich IKT-Drittparteienrichtlinien, Kontinuitäts- und Wiederherstellungsplänen, Auditplänen, Schulungen und Meldekanälen.

Dadurch ändert sich der Zweck der Matrix. Sie ist nicht mehr nur ein Arbeitsblatt der Sicherheitsfunktion. Sie wird zum Nachweis, dass das Management weiß:

• Welche Cloud-Dienste kritische Betriebsabläufe unterstützen.
• Welche Drittparteien und Unterauftragsverarbeiter wesentlich sind.
• Welche Verpflichtungen aus Kundenverträgen, GDPR, NIS2 und DORA gelten.
• Welche Verantwortlichkeiten bei der Organisation verbleiben.
• Welche Anbieterzusagen vertraglich durchsetzbar sind.
• Welche Lücken Finanzierung, Abhilfemaßnahmen oder Risikoakzeptanz erfordern.

Für KMU ist Verhältnismäßigkeit entscheidend. Eine kleinere Einrichtung benötigt keine schwergewichtige Bürokratie, aber sie benötigt dennoch Dokumentation, Überwachung, resiliente Systeme, Erkennung von IKT-Risikoquellen, Identifizierung wesentlicher Drittparteienabhängigkeiten, Kontinuitätsmaßnahmen, Tests, Lessons Learned und regelmäßige Überprüfung, soweit sie im Geltungsbereich liegt.

Die Matrix ist eines der effizientesten verhältnismäßigen Werkzeuge, weil sie Verpflichtungen konsolidiert, statt sie zu vervielfachen.

Ein 30-Tage-Sprint, um Ihr Cloud-Modell auditbereit zu machen

Wenn Sie nicht beantworten können, wer jede Cloud-Kontrolle verantwortet, welcher Nachweis sie belegt und welcher Unterauftragsverarbeiter sie beeinflussen könnte, ist Ihr Modell der gemeinsamen Verantwortung weiterhin ein Diagramm, kein Governance-Artefakt.

Ein praxisnaher 30-Tage-Sprint sieht so aus:

1. Erstellen oder aktualisieren Sie das Register für Cloud-Dienste anhand der Richtlinie zur Nutzung von Cloud-Diensten oder der Richtlinie zur Nutzung von Cloud-Diensten - KMU.
2. Identifizieren Sie kritische Dienste, Verarbeitung personenbezogener Daten, kundenbezogene Systeme sowie DORA- oder NIS2-Relevanz.
3. Bauen Sie die erste Matrix rund um ISO/IEC 27001:2022 Annex A-Maßnahmen 5.20, 5.21 und 5.23 mit Zenith Controls auf.
4. Verknüpfen Sie jede Zeile anhand von Schritt 13 aus Zenith Blueprint mit dem Risikoregister und der Anwendbarkeitserklärung.
5. Validieren Sie Lieferanten- und Auftragsverarbeiterklauseln anhand der Richtlinie zur Lieferanten- und Drittparteiensicherheit, der Richtlinie zur Lieferanten- und Drittparteiensicherheit - KMU und der Richtlinie zu Datenschutz und Privatsphäre.
6. Ergänzen Sie Nachweise zu Protokollaufbewahrung, Vorfalleskalation, Genehmigung von Unterauftragsverarbeitern, Auditrechten und Exit.
7. Überprüfen Sie kritische Lieferanten jährlich sowie nach wesentlichen Änderungen, Vorfällen, neuen Unterauftragsverarbeitern oder Audit-Feststellungen.

Das Ziel ist einfach. Wenn Kunde, Auditor, Aufsichtsbehörde oder Leitungsorgan fragt: „Wer verantwortet diese Kontrolle?“, suchen Sie nicht in Verträgen, Tickets und Ordnern. Sie öffnen die Matrix, zeigen den Verantwortlichen, zeigen die Klausel, zeigen die Nachweise und zeigen den Prüfpfad nachgelagert.

Clarysec kann Sie dabei unterstützen, Assurance-Unterlagen von Cloud-Anbietern in eine integrierte Matrix zur gemeinsamen Verantwortung für ISO/IEC 27001:2022-Audits, NIS2-Umsetzungsreife, DORA-IKT-Drittparteienrisiken, GDPR-Rechenschaftspflicht und Enterprise-Kunden-Due-Diligence zu überführen.

Beginnen Sie mit dem Register. Bauen Sie die Matrix. Hängen Sie die Nachweise an. Nutzen Sie sie anschließend als leitungsorganfähigen Nachweis dafür, dass Cloud-Risiko nicht ausgelagert, sondern gesteuert wird.