ISO 27017 und 27018,
die Cloud-Erweiterungen

ISO/IEC 27017 und ISO/IEC 27018 sind beide Verhaltensregeln: Control-Leitlinien, keine für sich zertifizierbaren Standards. Jede nimmt das bekannte Control-Set aus ISO/IEC 27002 und erweitert es auf die Realität des Cloud Computing, wo die Grenze zwischen dem, der einen Control betreibt, und dem, der sich auf ihn verlässt, nicht mehr offensichtlich ist.

ISO/IEC 27017 deckt Cloud-Sicherheit ab: wie die generischen ISO/IEC 27002-Controls umzusetzen sind, wenn der betreffende Dienst in der Cloud läuft, plus einige wenige Controls, die nur im Cloud-Kontext existieren. ISO/IEC 27018 deckt speziell den Datenschutz in der Cloud ab: wie ein Anbieter, der eine Public Cloud betreibt, die personenbezogenen Daten (PII) schützen sollte, die ihm seine Kunden anvertrauen.

Entscheidend ist von Anfang an: Sie zertifizieren sich nicht gegen 27017 oder 27018 für sich allein. Sie werden als Erweiterung einer ISO/IEC 27001-Zertifizierung umgesetzt und geprüft: Sie ziehen ihre Controls in Ihr Managementsystem, und eine akkreditierte Zertifizierungsstelle prüft sie zusammen mit dem Rest Ihres ISMS. Wenn Sie ohnehin in ISO 27001 denken, behandeln Sie diese beiden als Ergänzungen zu diesem Geltungsbereich, nicht als separate Projekte.

ISO/IEC 27017, erstmals 2015 veröffentlicht und im Juli 2026 als zweite Ausgabe überarbeitet, ist die Verhaltensregel für Informationssicherheits-Controls für Cloud-Dienste. Das meiste davon ist Umsetzungsleitlinie: Für die bereits in ISO/IEC 27002 aufgeführten relevanten Controls erklärt sie, was "den Control umzusetzen" tatsächlich bedeutet, sobald das System in der Cloud eines anderen liegt statt in einem Serverraum, der Ihnen gehört.

Über diese Leitlinien hinaus ergänzt 27017 eine kleine Reihe von Controls, die nur im Cloud-Kontext Sinn ergeben. Die Ausgabe 2026 enthält vier davon: geteilte Rollen und Verantwortlichkeiten zwischen dem Cloud-Service-Provider und dem Cloud-Service-Kunden, die Vereinbarung der Rollen von Cloud-Service-Partnern wie Brokern und Integratoren, die Trennung in virtuellen Rechenumgebungen sowie das Erkennen und Verhindern unautorisierter Nutzung von Cloud-Diensten.

Sie ist für beide Seiten der Beziehung geschrieben. Ein Cloud-Service-Provider liest sie, um zu verstehen, was er seinen Kunden schuldet; ein Cloud-Service-Kunde liest sie, um zu verstehen, was er weiterhin selbst tun muss und was er vernünftigerweise vom Anbieter erwarten darf. Genau wegen dieser doppelten Zielgruppe steht das Modell der geteilten Verantwortung im Zentrum des Standards.

ISO/IEC 27018, erstmals 2014 veröffentlicht und seit 2025 in der dritten Ausgabe, ist die Verhaltensregel zum Schutz personenbezogener Daten in Public Clouds, die als PII-Auftragsverarbeiter handeln. Wo es bei 27017 um Sicherheit in der Cloud im Allgemeinen geht, geht es bei 27018 eng um Datenschutz: was ein Public-Cloud-Anbieter tun muss, wenn die Daten, die er hält, seinen Kunden gehören und reale Personen identifizieren.

Sie ergänzt datenschutzorientierte Controls und Leitlinien über der ISO/IEC 27002-Grundlinie. Die Themen sind jedem vertraut, der mit modernem Datenschutzrecht gearbeitet hat: Einwilligung und Wahlmöglichkeit über die Nutzung von PII, Zweckbindung, Transparenz über Unterauftragsverarbeiter und den Speicherort der Daten, die Möglichkeit, PII zurückzugeben oder zu löschen, und, als prägende Bestimmung, Kunden-PII nicht für eigene Zwecke des Anbieters wie Werbung zu nutzen.

Wegen dieses Fokus verbindet sich 27018 natürlich mit Datenschutzregulierung. Sie ersetzt weder die DSGVO noch das Schweizer revDSG, und sie zu halten ist nicht dasselbe wie mit einem der beiden Gesetze konform zu sein. Aber die geforderten Controls decken sich eng mit dem, was diese Gesetze von einem Auftragsverarbeiter erwarten, weshalb sie in Datenschutzprüfungen europäischer und Schweizer Kunden häufig verlangt wird.

Der wichtigste Punkt zu beiden Standards ist struktureller Natur: Sie leben innerhalb einer ISO/IEC 27001-Zertifizierung, nicht daneben. Es gibt kein eigenständiges "ISO 27017-Zertifikat" oder "ISO 27018-Zertifikat", wie es ein ISO 27001-Zertifikat gibt. Stattdessen entscheiden Sie, dass die 27017- und/oder 27018-Controls im Geltungsbereich Ihres Informationssicherheits-Managementsystems liegen, setzen sie um und lassen sie von Ihrer Zertifizierungsstelle im selben Audit prüfen.

Für ein Team, das ISO 27001 bereits hält oder aktiv anstrebt, ist das wirklich eine gute Nachricht. Sie stellen kein zweites Managementsystem auf, wiederholen keine frische Risikobewertung von Grund auf und buchen keinen separaten Audit-Zyklus. Sie erweitern den Geltungsbereich des ISMS, das Sie bereits betreiben, und fügen der Statement of Applicability, die Sie bereits pflegen, eine definierte Reihe von Cloud- und Datenschutz-Controls hinzu.

Praktisch heisst das: Die Reihenfolge zählt. ISO 27001 kommt zuerst; 27017 und 27018 werden aufgesetzt, sobald dieses Fundament besteht. Den Cloud-Erweiterungen ohne das darunterliegende Managementsystem hinterherzulaufen heisst, das Dach vor den Wänden zu errichten.

Beide Standards beruhen auf derselben Idee: In der Cloud kontrolliert keine einzelne Partei alles, also werden Sicherheit und Datenschutz zwischen dem Cloud-Service-Provider und dem Cloud-Service-Kunden geteilt. Der Anbieter sichert die Teile, die er betreibt; der Kunde sichert die Teile, die er konfiguriert, und die Daten, die er einspielt. Ein Control, der in einem Aufbau ganz Sache des Anbieters ist, kann in einem anderen teilweise oder ganz Sache des Kunden sein.

Die meisten Cloud-Vorfälle, die Schlagzeilen machen, sind nicht der Anbieter, der seine Hälfte verfehlt. Es ist ein Kunde, der annimmt, der Anbieter habe einen Control abgedeckt, während die Verantwortung dafür eigentlich bei ihm lag. ISO/IEC 27017 investiert echte Mühe, diese Aufteilung explizit zu machen, gerade weil die Unklarheit der Ort ist, an dem Dinge schiefgehen.

Für Ihr eigenes ISMS bedeutet das: Jeder Control im Geltungsbereich braucht einen Eigentümer, schriftlich festgehalten: unser, der des Anbieters oder geteilt mit klarer Grenze. Diese Zuordnung ehrlich zu machen ist der grösste Teil der Arbeit bei der Einführung von 27017 und 27018, und genau der Teil, den Teams überspringen, wenn sie die Standards als Checkliste statt als Arbeitsteilung behandeln.

Diese Standards werden meist von Cloud-Service-Providern und SaaS-Anbietern verfolgt, also Teams, deren Produkt in der Cloud läuft und deren Kunden ihre Daten hindurchleiten. Der Auslöser ist fast immer extern: Die Sicherheits- oder Datenschutzprüfung eines Interessenten verlangt zusätzlich zu ISO 27001 cloud-spezifische Sicherheitszusicherung (27017) oder Cloud-PII-Schutz (27018), und der Deal stockt, bis Sie darauf verweisen können.

ISO 27017 kommt meist auf, wenn ein Kunde Wert darauf legt, wie seine Workloads in Ihrer Cloud gesichert sind: die Härtung, der Administratorzugang, die saubere Rückgabe seiner Werte beim Austritt. ISO 27018 kommt auf, wenn der Kunde selbst für personenbezogene Daten verantwortlich ist und seinen eigenen Regulierern zeigen muss, dass sein Auftragsverarbeiter PII verantwortungsvoll behandelt. Für einen europäischen oder Schweizer Käufer, der die DSGVO oder das Schweizer revDSG abwägt, ist diese 27018-Zeile im Geltungsbereich Ihres Zertifikats eine Abkürzung durch einen langen Fragebogen.

Wenn Sie kein Cloud-Anbieter sind oder Ihre Kunden nie cloud- oder PII-spezifische Bedenken geäussert haben, lohnt sich der zusätzliche Geltungsbereich vielleicht noch nicht. Der ehrliche Test ist derselbe wie bei jedem Framework: Kosten oder verzögern diese Fragen Deals? Wenn ja, ist es meist günstiger, Ihren ISO 27001-Geltungsbereich zu erweitern, um sie sauber zu beantworten, als sie für immer ad hoc zu beantworten.

Weil 27017 und 27018 auf einer ISO 27001-Zertifizierung aufsetzen, folgt die Mechanik dem 27001-Audit, das Sie bereits kennen. Sie fügen die Cloud- und Datenschutz-Controls Ihrer Statement of Applicability hinzu, setzen sie um, sammeln die Nachweise, dass sie funktionieren, und die akkreditierte Zertifizierungsstelle prüft sie in denselben Stage-1- und Stage-2-Audits sowie im selben jährlichen Überwachungs- und dreijährigen Rezertifizierungszyklus wie den Rest Ihres ISMS.

Es gibt kein separates Zertifikat zum Aufhängen. Was sich ändert, ist die Geltungsbereichsangabe auf Ihrem ISO 27001-Zertifikat: Sie hält fest, dass die 27017- und/oder 27018-Controls einbezogen und geprüft wurden. Genau nach dieser einen Zeile sucht der Prüfer eines Kunden, daher lohnt es sich, die Formulierung des Geltungsbereichs richtig zu treffen, statt die Cloud-Erweiterungen implizit zu lassen.

Was die Reihenfolge angeht, ist der günstigste Weg, die Erweiterungen in eine Rezertifizierung oder ein geplantes Überwachungsaudit zu falten, statt mitten im Zyklus zusätzliche Auditzeit zu buchen. Aber wenn ein Deal darauf wartet, können Zertifizierungsstellen einen zusätzlichen Geltungsbereich früher prüfen. So oder so liegt die eigentliche Arbeit bei den Controls, nicht bei der Audit-Logistik.

Cloud-Landschaften ändern sich schneller als fast alles andere in einem ISMS. Neue Dienste werden eingeführt, Unterauftragsverarbeiter kommen und gehen, Daten wandern zwischen Regionen, und Administratorzugang wird wöchentlich erteilt und entzogen. Die 27017- und 27018-Controls sind nur so gut, wie aktuell dieses Bild ist. Eine vor achtzehn Monaten dokumentierte Aufteilung der geteilten Verantwortung wird gegen eine seither weiterentwickelte Architektur ein Überwachungsaudit nicht überstehen.

Dieselbe Pflegedisziplin, die ISO 27001 am Leben hält, hält auch diese aktuell: die Verantwortungszuordnung korrekt, die Aufzeichnungen zu Unterauftragsverarbeitern und Datenstandort auf dem neuesten Stand, die Nachweise fliessend statt vor jedem Audit rekonstruiert. Weil die Cloud-Erweiterungen im selben Managementsystem sitzen, ist die Pflege geteilte Arbeit, einmal über den gesamten Geltungsbereich erledigt, statt eines zweiten Ordners, der für sich am Leben gehalten werden muss.