Die Scope-Frage wird in ISMS-Projekten meistens zu spät gestellt und zu breit beantwortet. Das Projekt ist beschlossen, der Auditor hat einen Termin, und irgendwann sitzt die Runde vor der Zeile, in der der Anwendungsbereich steht. Jemand sagt: nehmen wir das ganze Unternehmen, dann haben wir keine Lücken. Alle nicken, weil es nach Sorgfalt klingt.
Aus diesem einen Satz wird ein deutlich grösseres Projekt, ohne dass ein Kunde, ein Auditor oder ein Angreifer etwas davon merkt. Der ISMS-Scope ist keine Formalie in der Kopfzeile eines Dokuments. Er legt fest, welche Teile des Unternehmens ab jetzt nach Regeln arbeiten, die vorher nicht galten. Das ist eine Budget- und Personalentscheidung, und die gehört nicht in die IT.
Der ISMS-Scope bestimmt, was dein ISMS kostet und wie glaubwürdig es nach aussen wirkt. Der häufigere Fehler im KMU ist nicht ein zu kleiner, sondern ein zu grosser Anwendungsbereich: Er zieht Standorte, Tochterfirmen und Fachbereiche hinein, von denen kein Kunde etwas wissen will, und erzeugt Regeln, die niemand lebt. Tragfähig wird die Grenze, wenn sie der Leistung folgt, die deine Kunden kaufen, plus der IT, die diese Leistung trägt. Freigeben muss die Geschäftsleitung.
Der Scope entscheidet über den Aufwand, nicht über die Sicherheit
Der Anwendungsbereich steuert abzählbare Dinge: wie viele Prozesse du beschreibst, wie viele Leute du schulst, wie viele Systeme im Asset- und Risikoregister landen, wie viele Gespräche der Auditor führt, wie viele Nachweise du jedes Jahr wieder einsammelst. Das ist die Rechnung.
Dazu kommt, dass diese Rechnung jedes Jahr wieder gestellt wird. Ein Zertifikat ist kein Projektabschluss, sondern ein Abonnement: Überwachungsaudits kommen in festen Abständen, und jedes fragt nach denselben Nachweisen, nur ein Jahr aktueller. Wer den Anwendungsbereich im Juni grosszügig zieht, bezahlt diese Grosszügigkeit nicht einmal, sondern in jedem Audit und bei jedem Personalwechsel in den betroffenen Abteilungen erneut. Das ist der Grund, warum wir diese Entscheidung vor den Festpreis stellen und nicht danach.
Das Schutzniveau steuert der Scope nicht. Sicherheitsmassnahmen und Zertifikatsgrenze sind zwei verschiedene Dinge. Du darfst Mehrfaktor-Anmeldung im ganzen Haus einschalten und trotzdem nur einen Teil zertifizieren. Du darfst Backups für alle Standorte prüfen, auch wenn nur einer im Scope liegt. In den meisten KMU laufen die wirksamen Massnahmen ohnehin über dieselben zwei oder drei Plattformen, und die kennen keine Organigrammgrenze.
Ein breiter Scope macht ein KMU nicht sicherer. Er macht das ISMS teurer und träger. Es ist dieselbe Logik wie bei den Tools: Mehr Schutz entsteht durch richtige Dimensionierung, nicht durch Masse. Dein Betrieb trägt am Ende nur die Regeln, die er im Alltag auch ausführt. Alles darüber ist Dokumentation.
Woran erkennst du einen zu breiten ISMS-Scope?
Daran, dass du Richtlinien für Abteilungen schreibst, mit denen vor dem Projekt niemand gesprochen hat. Oder dass im Risikoregister Anwendungen stehen, die im Raum keiner erklären kann. Ein Scope ist zu breit, wenn du Verantwortliche benennen musst, die von ihrer Rolle nichts wissen.
Die Anzeichen zeigen sich früh, lange bevor der Auditor kommt:
- Bei Fachprozessen steht die IT als Owner, weil sich sonst niemand gemeldet hat.
- Im Inventar stehen Systeme, die nur dort existieren und sonst nirgends auftauchen.
- Eine Tochtergesellschaft soll Awareness-Schulungen absolvieren, obwohl ihr Geschäft mit dem Auslöser des Projekts nichts zu tun hat.
- Das Einsammeln der Nachweise dauert länger als die Massnahme, die sie belegen sollen.
- Niemand kann in zwei Sätzen sagen, was drin ist und was nicht.
Ein Anwendungsbereich, den die Geschäftsleitung ohne Organigramm nicht erklären kann, hält im Kundengespräch auch nicht.
Wer entscheidet über den ISMS-Scope?
Die Geschäftsleitung. Der Scope verteilt Arbeit auf Abteilungen, die nicht der IT berichten, und er legt fest, wofür das Unternehmen nach aussen geradesteht. Beides kann eine IT-Leitung nicht beschliessen, sie kann rechnen, vorbereiten und empfehlen. Unterschreiben muss jemand mit Budget- und Weisungsbefugnis.
In der Praxis scheitert das an der Vorlage, nicht am Willen. Wer der Geschäftsleitung ein fertiges Scope-Dokument zur Kenntnisnahme hinlegt, bekommt eine Kenntnisnahme. Entscheidbar wird die Sache erst, wenn für jede Variante auf dem Tisch liegt, welche Kundenanforderung sie beantwortet, wen sie im Haus betrifft und was sie an Zeit kostet. Diese Vorarbeit ist der Unterschied zwischen einem Entscheid, der hält, und einem, der im dritten Monat wieder aufgemacht wird.
Das ist auch der Grund, warum sich ein Festpreis für ein ISMS-Programm erst nach dem Scoping nennen lässt. Bei unseren Festpreis-Paketen steht der Preis für den ISMS-Aufbau deshalb auf Anfrage: Vor der Scope-Entscheidung ist jede Zahl geraten. Was Aufwand, Dauer und Kosten im KMU sonst treibt, haben wir in ISO 27001 im KMU aufgeschrieben.
Wie Kunden und Regulatoren den Scope vorgeben
Die Antwort steht meistens in der Anforderung, die das Projekt ausgelöst hat. Irgendwer von aussen will etwas sehen, und dieser Wunsch hat fast immer eine Grenze: ein Vertrag über eine bestimmte Lieferung, ein Fragebogen zu einem bestimmten Dienst, eine Auflage für einen bestimmten Betriebsteil.
Bei regulierten Branchen steht die Grenze teilweise im Gesetz. Der IKT-Minimalstandard des BACS ist für die Strombranche seit dem 1. Juli 2024 und für Gasversorger seit dem 1. Juli 2025 verpflichtend, für die übrigen Sektoren eine Empfehlung. Betreiber kritischer Infrastrukturen müssen Cyberangriffe zudem innerhalb von 24 Stunden dem BACS melden, seit dem 1. April 2025. Wer solche Unternehmen beliefert, bekommt diese Pflichten über den Vertrag weitergereicht, und zwar für den Teil der Lieferkette, der sie betrifft.
Die Reihenfolge ist unspektakulär und wird trotzdem oft gedreht. Ein Anwendungsbereich, der vor der Anforderung festgelegt wird, beantwortet am Ende selten die Frage, die jemand gestellt hat. Und wenn von aussen gar niemand fragt, braucht das Unternehmen kein Zertifikat, sondern ein ISMS, das im Alltag gelebt wird. Das ist billiger und wirkt schneller.
Ein Beispiel aus der Praxis
Ein Maschinenbauzulieferer mit 340 Mitarbeitenden, zwei Werken und einer Vertriebsgesellschaft im Ausland. Auslöser war ein Grosskunde aus der Energiebranche, der im Rahmenvertrag ein ISO-27001-Zertifikat verlangte, mit Frist. Der erste Entwurf des Anwendungsbereichs umfasste die Gruppe: beide Werke, Vertrieb, Entwicklung, Finanzen, Personal, die gesamte IT.
Ein Blick in die Anforderung zeigte etwas anderes. Der Kunde kaufte Komponenten aus einem Werk und bezog Konstruktionsdaten über ein Portal. Er wollte wissen, wie diese Daten geschützt sind und wer darauf zugreift. Das zweite Werk produzierte für andere Märkte, die Vertriebsgesellschaft verkaufte Ersatzteile, das Personalwesen kam in der Lieferung nicht vor.
Am Ende lag der Scope auf dem liefernden Werk, der Konstruktion und der gemeinsamen IT, inklusive Identitäten, Microsoft 365 und dem Portal. Die herausgefallenen Teile blieben nicht ungeschützt: Mehrfaktor-Anmeldung, Patchstand und Backup liefen weiter für alle, weil sie über dieselben Plattformen konfiguriert sind. Weggefallen sind die Nachweispflicht, die Schulungspflicht nach ISMS und die Auditinterviews für drei Bereiche.
Übrig blieb die unangenehme Stelle, und die bleibt in jedem KMU übrig: die gemeinsame IT. Sie trägt die gekaufte Leistung, also liegt sie im Scope, und im Audit prüft der Auditor sie auch so. Wer hofft, die IT durch eine geschickte Grenzziehung aus dem Zertifikat zu halten, verschiebt das Gespräch nur um ein Jahr.
Wann lohnt sich ein breiter Scope?
Wenn die Grenze mehr Arbeit macht als die Einbindung. In einem Unternehmen mit einem Standort, einer IT und einem Geschäftsmodell ist das meistens so. Zwei Regelwerke für vierzig Leute zu pflegen kostet mehr, als alle vierzig gleich zu behandeln, und am Ende weiss niemand, welche Regel für ihn gilt.
Dasselbe gilt, wenn die Nachfrage aus mehreren Geschäftsbereichen kommt. Ein Zertifikat, das der Verkauf in jedem zweiten Gespräch erklären muss, nützt dort wenig. Und ein Ausschluss, der nur auf Papier existiert, weil dieselben Leute auf beiden Seiten der Grenze arbeiten, fällt im Audit auf. Dann ist breit die ehrlichere und am Ende günstigere Variante.
Die Entscheidung läuft damit auf eine andere Frage hinaus: Wo existiert im Betrieb überhaupt eine Grenze? Wo keine existiert, hilft auch keine erfundene. Wo eine existiert, kostet es Geld, sie zu ignorieren.
Woran du einen tragfähigen Scope erkennst
Aus unseren Mandaten sind es vier Merkmale, und keines davon steht in der Norm:
- Er ist in zwei Sätzen erklärbar, ohne Organigramm und ohne Einschränkungen in Klammern.
- Jede Grenze folgt einer Verantwortung, nicht einer Kostenstelle. Wo die Zuständigkeit endet, endet der Scope.
- Die Schnittstellen nach draussen sind benannt, inklusive der Dienstleister, die etwas im Scope betreiben.
- Die Leute im Scope wissen, dass sie drin sind. Das ist der härteste Test, und er lässt sich in einer Kaffeepause durchführen.
Wer vor dieser Entscheidung steht, hat meistens schon eine Frist und einen Kunden im Rücken. Die nützlichste Stunde ist dann nicht die, in der jemand ein Scope-Dokument formuliert, sondern die, in der jemand die Anforderung mit euch liest und sagt, was sie verlangt und was nicht.
Häufige Fragen
Steht der Anwendungsbereich auf dem Zertifikat?
Ja. Er ist Teil des Zertifikats und damit die erste Stelle, auf die ein professioneller Einkauf schaut. Ein Zertifikat, dessen Scope die gekaufte Leistung nicht abdeckt, löst im Beschaffungsprozess mehr Rückfragen aus als gar keines. Deshalb ist die Formulierung dieser zwei Zeilen kein Dokumentationsthema, sondern Vertriebsarbeit.
Können wir den Scope später erweitern?
Ja, und das ist der üblichere Weg. Eine Erweiterung behandelt die Zertifizierungsstelle als Änderung am Zertifikat und prüft sie in einem Audit. Das kostet Vorbereitung, aber deutlich weniger als ein Erstaufbau über alles. Teuer wird nur der umgekehrte Fall: ein erster Scope, der so eng gezogen wurde, dass er die Hauptleistung nicht abdeckt und darum nachträglich geflickt werden muss.
Gilt unser Scope auch für den IT-Dienstleister?
Dein Dienstleister wird durch deinen Scope nicht zertifiziert. Was im Anwendungsbereich liegt, bleibt in deiner Verantwortung, auch wenn ein Externer es betreibt. Im Audit heisst das: Verträge, Berechtigungen und Nachweise für fremdbetriebene Systeme musst du liefern, nicht er. Ein Zertifikat des Dienstleisters hilft, ersetzt deine Nachweise aber nicht.