ISO 27001 Scope richtig formulieren

„Unser Produkt XYZ ist nach ISO 27001 zertifiziert!“

Nein.

Das Produkt ist nicht zertifiziert. Zertifiziert ist das Informationssicherheitsmanagementsystem einer Organisation – und zwar für einen festgelegten Anwendungsbereich. Das klingt zunächst nach Wortklauberei. Es ist aber ein ziemlich wichtiger Unterschied. Eine Managementsystemzertifizierung bestätigt nicht, dass ein bestimmtes Produkt jede Sicherheitsanforderung erfüllt, fehlerfrei programmiert wurde oder gegen jeden Angriff immun ist.

Die Formulierung des Scopes entscheidet deshalb nicht nur darüber, was im Audit betrachtet wird. Sie entscheidet auch darüber, was Kunden aus dem Zertifikat vernünftigerweise herauslesen dürfen. Und weil der Text später gut sichtbar auf dem Zertifikat steht, sollte er weder Marketinglyrik noch eine Inventarliste Ihrer heutigen IT-Landschaft sein.

Die kurze Antwort

Ein guter ISO 27001 Scope beschreibt kurz, eindeutig und dauerhaft, welche an den Markt gerichteten Tätigkeiten der Organisation vom zertifizierten ISMS erfasst werden.

Typische Formulierungen lauten beispielsweise:

• Entwicklung und Bereitstellung von Standardsoftware für das Projektmanagement;
• Entwicklung, Betrieb und Support cloudbasierter Unternehmenssoftware;
• Erbringung von Managed IT Services für mittelständische Unternehmen;
• Konzeption, Entwicklung und Wartung kundenspezifischer Softwarelösungen;
• Betrieb eines Rechenzentrums und Erbringung zugehöriger Infrastrukturservices.

Ein guter Scope nennt dagegen möglichst keine Produktnamen, keine momentan eingesetzten Cloudanbieter und keinen Katalog interner Unterstützungsabteilungen. Er beschreibt das stabile Geschäft – nicht dessen aktuelle Verpackung.

Scope ist nicht gleich Scope

In ISO 27001-Projekten werden unter dem Wort „Scope“ gerne mehrere Dinge gleichzeitig verstanden. Das führt zu unnötiger Verwirrung. Praktisch sollten Sie drei Ebenen auseinanderhalten.

Der interne ISMS-Anwendungsbereich

Abschnitt 4.3 der ISO 27001 verlangt, die Grenzen und die Anwendbarkeit des ISMS festzulegen. Dafür müssen Sie unter anderem den Kontext der Organisation, relevante Anforderungen und die Schnittstellen sowie Abhängigkeiten zu anderen Organisationen berücksichtigen.

Diese interne Abgrenzung darf und muss häufig genauer sein. Sie kann beschreiben, welche Gesellschaften, Organisationseinheiten, Standorte, Teams, Prozesse und Schnittstellen dazugehören. Sie erklärt auch, wie mit externen Dienstleistern oder nicht einbezogenen Unternehmensteilen umgegangen wird. Der Anwendungsbereich muss als dokumentierte Information verfügbar sein. Er gehört damit zu den wirklich notwendigen dokumentierten Informationen eines ISMS.

Der Zertifikats-Scope

Auf dem Zertifikat steht evtl. eine deutlich kürzere Formulierung. Sie soll für einen Leser erkennbar machen, welche Tätigkeiten, Produkte oder Dienstleistungen von der Managementsystemzertifizierung erfasst werden. ISO/IEC 17021-1 verlangt in Abschnitt 8.2.2, dass diese Beschreibung nicht irreführend oder mehrdeutig ist.

Das Zertifikat ist deshalb nicht der richtige Ort für ein seitenlanges Grenzprotokoll. Es ist aber auch nicht der Ort für eine wohlklingende Formulierung, unter der sich fast alles oder gar nichts verstehen lässt.

Die Außendarstellung

Und dann gibt es noch das, was Vertrieb und Marketing aus dem Zertifikat machen. Genau hier entsteht schnell die inkorrekte Behauptung vom „ISO 27001-zertifizierten Produkt“.

ISO/IEC 17021-1 ist dazu ziemlich eindeutig: Zertifizierungszeichen und Aussagen dürfen nicht den Eindruck erwecken, ein Produkt, ein Prozess oder eine Dienstleistung sei durch die Managementsystemzertifizierung selbst zertifiziert worden. Sie dürfen also sagen, dass Ihr Unternehmen für einen bestimmten Anwendungsbereich ein zertifiziertes ISMS betreibt. Sie sollten nicht behaupten, Ihre Software sei deshalb ein nach ISO 27001 zertifiziertes Produkt.

Formulieren Sie den Scope von außen nach innen

Der beste Ausgangspunkt ist nicht das Organigramm und auch nicht die Assetliste. Fragen Sie zunächst:

Was tun wir für unsere Kunden?

Genau dort liegen die an den Markt gerichteten Tätigkeiten. Ein Softwareunternehmen entwickelt, betreibt und unterstützt Software. Ein Managed Service Provider erbringt IT Services. Ein Beratungsunternehmen konzipiert und begleitet bestimmte Leistungen. Ein Rechenzentrumsbetreiber stellt Infrastrukturservices bereit.

Diese Tätigkeiten sind meistens deutlich stabiler als Produktnamen, Teambezeichnungen oder technische Lösungen. Wer den richtigen Zuschnitt noch nicht gefunden hat, sollte zuerst klären, wie groß der Anwendungsbereich sinnvollerweise sein soll. Erst danach lohnt sich die Arbeit am schönen Satz für das Zertifikat.

Warum Produktnamen im Scope meistens keine gute Idee sind

Ein Produktname wirkt zunächst konkret. Genau deshalb landet er schnell in einem ersten Scope-Entwurf. Praktisch bringt er aber zwei Probleme mit.

Problem 1: Er klingt nach Produktzertifizierung

„Entwicklung und Betrieb des Produkts XYZ“ kann beim Leser den Eindruck erzeugen, XYZ sei der zertifizierte Gegenstand. Tatsächlich wurde aber das Managementsystem auditiert, mit dem die Organisation unter anderem Entwicklung und Betrieb steuert.

Manche Zertifizierungsstellen akzeptieren Produktnamen deshalb nur sehr ungern. Sie müssen sicherstellen, dass das Zertifikat weder mehrdeutig noch irreführend ist. Die einfachste Lösung ist meistens, nicht die Marke zu nennen, sondern die Tätigkeit und die Art der Marktleistung.

Problem 2: Produktnamen ändern sich

Heute heißt die Software „CloudDesk“, nach dem nächsten Markenworkshop plötzlich „Nimbly Workspace“. Vielleicht wurde das Unternehmen übernommen. Vielleicht werden zwei Produktlinien zusammengeführt. Vielleicht hat irgendjemand festgestellt, dass der alte Name in einem wichtigen Zielmarkt etwas Unappetitliches bedeutet.

Die Menschen entwickeln und betreiben weiterhin dieselbe Art von Software. Das ISMS hat sich möglicherweise überhaupt nicht wesentlich verändert. Steht der Produktname aber auf dem Zertifikat, dürfen Sie trotzdem mit der Zertifizierungsstelle klären, ob und wie das Zertifikat neu ausgestellt werden muss.

Schreiben Sie nichts in den Scope, was Ihre Marketingabteilung nächste Woche auf links krempeln könnte.

Warum Technik und Dienstleister meistens ebenfalls nicht hineingehören

Ähnlich kurzlebig ist die technische Umsetzung. Heute läuft eine Anwendung bei einem bestimmten Cloudanbieter. Morgen wird sie in eine andere Cloud verschoben. Übermorgen holt das Unternehmen einen Teil wieder selbst herein, weil die monatliche Rechnung inzwischen aussieht wie die Wirtschaftsleistung eines kleineren Inselstaates.

Solange sich die an den Markt gerichtete Tätigkeit nicht ändert, sollte der Zertifikats-Scope möglichst nicht an dieser technischen Bewegung hängen. Formulierungen wie „Betrieb der Software auf der Plattform ABC unter Nutzung der Dienste DEF und GHI“ altern daher schlecht.

Natürlich sind Cloudanbieter, externe IT-Dienstleister und andere Lieferanten intern hochrelevant. Sie tauchen in Schnittstellen, Risiken, Verträgen, Assets, der Lieferantensteuerung und der Anwendbarkeitserklärung auf. Das ist aber etwas anderes, als jeden Dienstleister auf dem Zertifikat zu verewigen. Wie rechtliche und vertragliche Vorgaben systematisch berücksichtigt werden, erläutern wir im Artikel zu rechtlichen und vertraglichen Anforderungen.

Müssen Unterstützungsprozesse in den Zertifikats-Scope?

Die Formulierung „einschließlich aller Unterstützungsprozesse“ ist in einem Zertifikats-Scope weder besonders üblich noch besonders hilfreich. Dass ein Unternehmen seine Marktleistung nicht ohne Personal und Dach überm Kopf erbringen kann, ist keine revolutionäre Entdeckung.

Das bedeutet aber nicht, dass man die unterstützenden Funktionen intern aus dem ISMS herauszaubern kann.

Wenn Ihre Softwareentwicklung im Scope liegt, verwaltet die IT deren Geräte, Konten und Berechtigungen. HR stellt Beschäftigte ein, verändert Rollen und organisiert Austritte. Office- oder Facility-Management beeinflusst Zutritt, Besuchersteuerung und physische Sicherheit. Über die Anforderungen und Controls aus Anhang A kommen diese Funktionen sehr schnell ins Spiel.

Sie müssen deshalb nicht alle auf das Zertifikat schreiben. Sie müssen sie aber dort in das ISMS einbeziehen, wo sie für die in-scope Tätigkeiten sicherheitsrelevant sind. Dabei helfen klar geregelte Rollen, Verantwortlichkeiten und Befugnisse.

Der Scope ist kein Werkzeug zum Wegdefinieren unbequemer Controls

Manchmal wird versucht, die Scope-Formulierung gleich ganz stromlinienförmig als Risikobehandlung zu benutzen. Dann heißt es beispielsweise sinngemäß, die physische Sicherheit, die Personalverwaltung oder die zentrale IT lägen außerhalb des Anwendungsbereichs. Damit soll das Thema möglichst aus dem Audit verschwinden.

So funktioniert die Logik nicht. Der Anwendungsbereich kann auf einen sinnvollen Teil der Organisation begrenzt werden. Innerhalb dieses Bereichs müssen aber die relevanten Abhängigkeiten betrachtet werden. Wenn die zentrale IT Benutzerkonten für das in-scope Entwicklungsteam verwaltet, bleibt diese Tätigkeit sicherheitsrelevant – ganz gleich, in welchem Kästchen des Organigramms die Administratoren sitzen.

Auch die Controls aus Anhang A werden nicht dadurch unanwendbar, dass man sie im Scope-Satz nicht erwähnt. Ihre Auswahl und Begründung erfolgen über Risikobewertung, Risikobehandlung und Anwendbarkeitserklärung. Der Zertifikats-Scope soll das Geschäft verständlich beschreiben. Er ist kein Radiergummi für alles, worauf das Unternehmen gerade keine Lust hat.

Gute und schlechte Scope-Formulierungen

Zu unbestimmt

„Alle sicherheitsrelevanten Tätigkeiten des Unternehmens.“

Welche sind das? Was bietet das Unternehmen überhaupt an? Ein Kunde kann daraus nicht erkennen, ob die für ihn relevante Leistung erfasst ist.

Auch zu unbestimmt

„Die interne IT sowie die Etagen 2 und 4 in der Beispielstraße 17, Niederäpfelbach“

Welche an den Markt gerichteten Tätigkeiten erbringt das Unternehmen, für die das ISMS Sicherheit voranbringt? Arbeiten die Mitarbeiter auf Etage 3 ohne Computer?

Am Thema vorbei

„Betrieb eines Informationssicherheitsmanagementsystems.“

Das ISMS ist das Managementsystem, nicht die Marktleistung. Diese Formulierung beantwortet nicht, wofür das ISMS gilt.

Zu produktnah

„Entwicklung und Betrieb des Produkts XYZ.“

Die Formulierung ist abhängig von einer Marke und kann Produktzertifizierung suggerieren.

Zu technisch und zu vergänglich

„Entwicklung und Betrieb unserer Software auf AWS mit Microsoft 365, GitHub und dem externen Supportdienstleister Müller IT.“

Das ist eher ein Ausschnitt aus der Asset- und Lieferantenlandschaft als ein dauerhaft brauchbarer Zertifikats-Scope.

Brauchbar für einen Softwareanbieter

„Entwicklung, Bereitstellung, Betrieb und Support cloudbasierter Unternehmenssoftware.“

Die marktgerichteten Tätigkeiten sind erkennbar. Die Formulierung bleibt auch bei einem Rebranding oder Cloudwechsel grundsätzlich tragfähig.

Brauchbar für einen IT-Dienstleister

„Erbringung von Managed IT Services und IT-Support für mittelständische Unternehmen.“

Der Leser erkennt Leistung und Zielrichtung, ohne dass der Scope jede interne Abteilung oder jedes eingesetzte Werkzeug aufzählt.

Was ist mit Standorten und mehreren Gesellschaften?

Standorte werden in den Zertifizierungsunterlagen gesondert ausgewiesen. Bei einer sog. Multi-Site-Zertifizierung muss nachvollziehbar sein, welche Standorte und gegebenenfalls welche Tätigkeiten je Standort erfasst sind. IAF MD 1 beschreibt dazu unter anderem zentrale Funktion, Standorte und Sub-Scopes.

Das ist mehr als Adresspflege. Ein einzelner Standort kann nur dann unter einer gemeinsamen Multi-Site-Zertifizierung laufen, wenn er tatsächlich vom gemeinsamen Managementsystem erfasst und gesteuert wird. Man kann auch nicht während des Zertifizierungsverfahrens einen Standort mit schwerwiegender Nichtkonformität kurzerhand aus dem Scope werfen, damit der Rest sein Zertifikat bekommt. IAF MD 1 schiebt genau diesem Manöver einen Riegel vor.

Für Organisationen ohne definierten physischen Tätigkeitsort enthält ISO/IEC 27006-1 noch einen besonderen Punkt: Wenn wirklich alle Tätigkeiten remote durchgeführt werden, soll dies aus den Zertifizierungsdokumenten hervorgehen.

Wie kommen Sie praktisch zu einer guten Formulierung?

Gehen Sie in dieser Reihenfolge vor:

1. Zertifizierungszweck klären: Für welche Leistungen erwarten Kunden, Ausschreibungen oder Verträge den Nachweis?
2. Marktleistungen benennen: Welche stabilen Tätigkeiten erbringen Sie gegenüber Ihren Kunden?
3. Interne Grenze bestimmen: Welche Gesellschaften, Bereiche, Standorte und Prozesse sind erforderlich, damit diese Tätigkeiten sicher erbracht werden?
4. Schnittstellen prüfen: Welche nicht einbezogenen Bereiche und externen Organisationen besitzen relevante Abhängigkeiten?
5. Zertifikatssatz kürzen: Reduzieren Sie die ausführliche interne Abgrenzung auf eine eindeutige Beschreibung der Marktleistungen.
6. Auf Zukunftsfestigkeit prüfen: Würde der Satz nach einem Rebranding, Cloudwechsel oder internen Umbau weiterhin stimmen?
7. Mit der Zertifizierungsstelle abstimmen: Klären Sie die endgültige Formulierung frühzeitig und nicht erst beim Korrekturlesen des Zertifikats.

Der Scope ist eine der frühen Entscheidungen auf dem Weg zum ISO 27001-Zertifikat. Trotzdem muss das Unternehmen ihn nicht ohne Unterstützung im stillen Kämmerlein erfinden. Ein guter Berater kann aus Leistungen, Kundenanforderungen und Organisationsstruktur einen Vorschlag ableiten. Das Unternehmen muss allerdings erklären können, was es tatsächlich tut und wofür seine Kunden den Nachweis benötigen.

Was will der Auditor sehen?

Der Auditor wird nicht nur prüfen, ob der Scope-Satz hübsch klingt. Er wird schauen, ob er zur Realität passt.

Dazu gehören Fragen wie:

• Sind die genannten Tätigkeiten tatsächlich diejenigen, die im betrachteten Bereich erbracht werden?
• Passen interne Scope-Dokumentation und gewünschter Zertifikats-Scope zusammen?
• Sind relevante Standorte, Menschen, Systeme und unterstützende Funktionen berücksichtigt?
• Werden Schnittstellen zu externen Dienstleistern und nicht einbezogenen Bereichen beherrscht?
• Ist der Scope für Kunden verständlich und frei von irreführenden Aussagen?
• Versucht das Unternehmen, unbequeme Risiken oder organisatorische Abhängigkeiten sprachlich verschwinden zu lassen?

Ein knapp formulierter Zertifikats-Scope darf auf einer detaillierten internen Abgrenzung beruhen. Problematisch wird es erst, wenn die Kürze zur Tarnkappe wird.

Der eigentliche Punkt

Ein guter Scope ist kein Werbeslogan. Er ist eine belastbare Beschreibung dessen, wofür das zertifizierte Managementsystem gilt.

Formulieren Sie deshalb stabil, marktbezogen und verständlich. Benennen Sie Tätigkeiten statt Produktmarken. Halten Sie technische Momentaufnahmen aus dem Zertifikat heraus. Und vergessen Sie intern trotzdem nicht die Funktionen, Systeme und Dienstleister, ohne die Ihre Marktleistung nicht sicher funktionieren würde.

Der beste Prüfsatz lautet:

Würde diese Formulierung noch stimmen, wenn morgen das Produkt umbenannt, der Cloudanbieter gewechselt oder die interne Organisation umgebaut wird?

Wenn ja, ist der Scope wahrscheinlich robust. Wenn nein, beschreibt er vermutlich zu viele vergängliche Details.

Interesse geweckt?

Wenn Sie Ihren ISO 27001-Anwendungsbereich sauber zuschneiden und eine Zertifikatsformulierung entwickeln möchten, die zu Geschäft, Kundenanforderungen und Organisation passt, Sprechen Sie mit uns.