Geltungsbereich (Scope) definieren: Was gehört ins ISMS und was nicht?

Warum der Geltungsbereich der wichtigste erste Schritt ist

Wenn du ein Informationssicherheitsmanagementsystem (ISMS) aufbaust, steht ganz am Anfang eine Frage, die unscheinbar klingt, aber über Erfolg oder Scheitern des gesamten Projekts entscheidet: Was genau soll dein ISMS eigentlich abdecken?

Die ISO 27001 nennt das den Geltungsbereich oder englisch Scope. In Kapitel 4.3 der Norm wird verlangt, dass du die Grenzen und die Anwendbarkeit deines ISMS festlegst, um seinen Geltungsbereich zu bestimmen. Das klingt nach einem formalen Pflichtpunkt, ist aber in Wahrheit die strategischste Entscheidung, die du in der gesamten ISMS-Einführung triffst.

Denn der Scope bestimmt alles, was danach kommt. Jede Risikoanalyse, jede Richtlinie, jede Maßnahme, jedes interne Audit und jede Managementbewertung bezieht sich auf den definierten Geltungsbereich. Definierst du ihn zu weit, erstickst du in Aufwand. Definierst du ihn zu eng, fehlen kritische Bereiche, und dein ISMS schützt genau die Stellen nicht, an denen es darauf ankommt.

Außerdem prüft jeder Auditor bei einer ISO-27001-Zertifizierung als Erstes den Scope. Ist er nicht plausibel, nicht vollständig oder nicht nachvollziehbar begründet, wird der Auditor schon in den ersten Minuten skeptisch. Und dieses Misstrauen begleitet dann die gesamte Prüfung.

Was gehört in den Geltungsbereich?

Der Scope beschreibt konkret, welche Teile deiner Organisation und Infrastruktur vom ISMS erfasst werden. Das umfasst typischerweise fünf Dimensionen:

1. Standorte

Welche physischen Standorte sind Teil des ISMS? Das betrifft Bürogebäude, Rechenzentren, Lagerräume mit Servern, Home-Office-Arbeitsplätze und Produktionsstätten, soweit sie informationsverarbeitende Prozesse beinhalten.

Wichtig ist hier die Präzision. Wenn du drei Bürostandorte hast, aber nur den Hauptsitz ins ISMS aufnimmst, muss das explizit dokumentiert sein. Die beiden anderen Standorte sind dann Ausschlüsse, und du musst begründen können, warum sie (noch) nicht im Scope liegen.

Seit der Pandemie ist auch das Thema Home Office relevant. Wenn Mitarbeitende regelmäßig von zu Hause arbeiten und dabei auf Unternehmensdaten zugreifen, gehört das Home Office in den Scope, zumindest als definierter Arbeitskontext mit entsprechenden Regelungen.

2. Organisationseinheiten und Abteilungen

Welche Abteilungen sind betroffen? In einem kleinen Unternehmen mit 30 Mitarbeitenden ist die Antwort oft einfach: alle. In einem größeren Unternehmen kann es sinnvoll sein, den Scope zunächst auf bestimmte Bereiche zu begrenzen, etwa die IT-Abteilung, die Entwicklung und die Geschäftsführung.

Typische Abteilungen im ISMS-Scope:

• IT / Systemadministration: Betrieb und Wartung der IT-Infrastruktur
• Softwareentwicklung: Wenn du selbst Software entwickelst, die Kundendaten verarbeitet
• Geschäftsführung: Trägt die Gesamtverantwortung für Informationssicherheit
• Personal / HR: Verwaltet sensible Mitarbeiterdaten und regelt Onboarding/Offboarding
• Vertrieb / Kundenservice: Hat Zugriff auf Kundendaten und kommuniziert nach außen
• Finanzbuchhaltung: Verarbeitet geschäftskritische Finanzdaten

Abteilungen, die keinen direkten Bezug zu informationsverarbeitenden Prozessen haben, kannst du begründet ausschließen. Aber Vorsicht: Die Begründung muss stichhaltig sein. Ein Auditor wird nachfragen.

3. Geschäftsprozesse

Hier wird es konkret. Welche Geschäftsprozesse sind für dein ISMS relevant? Die ISO 27001 verlangt, dass du den Scope im Kontext der Geschäftstätigkeit definierst. Das bedeutet: Du musst verstehen, welche Prozesse auf schützenswerte Informationen zugreifen oder solche erzeugen.

Beispiele für typische Prozesse im Scope:

• Kundenauftragsabwicklung
• Softwareentwicklung und Deployment
• IT-Betrieb (Server, Netzwerk, Backup, Monitoring)
• Personalverwaltung
• Finanzbuchhaltung und Rechnungsstellung
• Kommunikation mit Kunden und Partnern
• Beschaffung und Lieferantenmanagement

Du musst nicht jeden Mikroprozess aufzählen. Aber die Kernprozesse, die geschäftskritisch sind oder sensible Daten verarbeiten, gehören in den Scope.

4. Informationssysteme und Anwendungen

Welche IT-Systeme unterstützen die Prozesse im Scope? Hier kommt ein sauberes IT-Asset-Management ins Spiel. Du listest die relevanten Systeme, Anwendungen und Plattformen auf:

• Server und Infrastruktur: Physische Server, virtuelle Maschinen, Container-Umgebungen
• Cloud-Dienste: Microsoft 365, AWS, Azure, Google Workspace und jede SaaS-Anwendung, die Unternehmensdaten verarbeitet
• Geschäftsanwendungen: ERP, CRM, Buchhaltungssoftware, Projektmanagement-Tools
• Kommunikationssysteme: E-Mail, Messenger, Videokonferenz-Plattformen
• Entwicklungsumgebungen: Code-Repositories, CI/CD-Pipelines, Testumgebungen
• Endgeräte: Laptops, Smartphones, Tablets der Mitarbeitenden

Diese Auflistung muss nicht bis ins letzte Detail gehen, aber sie muss vollständig genug sein, dass ein Auditor nachvollziehen kann, welche Systeme du im Blick hast und welche bewusst ausgeschlossen sind.

5. Netzwerke und Netzwerksegmente

Welche Netzwerkbereiche gehören zum Scope? Dazu zählen das interne LAN, WLAN, VPN-Zugänge, DMZ-Segmente und die Anbindung an externe Netze. Wenn du Netzwerksegmentierung betreibst, beschreibst du, welche Segmente im Scope liegen.

Auch das Thema Netzwerkgrenzen ist relevant: Wo endet dein Netzwerk, wo beginnt das des Internet-Providers oder Cloud-Anbieters? Diese Übergabepunkte sind Schnittstellen, die du explizit dokumentieren musst.

Schnittstellen nach außen dokumentieren

Ein Bereich, der bei der Scope-Definition oft unterschätzt wird, sind die externen Schnittstellen. Dein ISMS existiert nicht in einem Vakuum. Es gibt Stellen, an denen Informationen dein Unternehmen verlassen oder von außen hereinkommen. Diese Schnittstellen musst du kennen und dokumentieren.

Cloud-Dienste und SaaS-Anbieter

Wenn du Microsoft 365 für E-Mail und Dokumentenmanagement nutzt, liegt ein Teil deiner Informationsverarbeitung bei Microsoft. Das bedeutet nicht, dass Microsofts Rechenzentren in deinem Scope liegen. Aber die Schnittstelle zu Microsoft, also wie du den Dienst nutzt, wie du Zugänge verwaltest, welche Daten dort gespeichert werden, das gehört sehr wohl in deinen Geltungsbereich.

Gleiches gilt für jede SaaS-Anwendung: Dein CRM in der Cloud, dein Projektmanagement-Tool, deine Buchhaltungssoftware. Du musst dokumentieren, dass du diese Dienste nutzt und wie du die Informationssicherheit an diesen Schnittstellen sicherstellst. In ISMS Lite lassen sich externe Schnittstellen und Cloud-Dienste als Assets erfassen und direkt mit der Scope-Definition verknüpfen. Das passiert typischerweise über Lieferantenbewertungen und vertragliche Vereinbarungen.

Dienstleister und Partner

Externe IT-Dienstleister, die Zugriff auf deine Systeme haben, sind eine kritische Schnittstelle. Ein Managed-Service-Provider, der deine Server wartet, ein Entwicklungspartner mit Zugang zum Code-Repository, eine Agentur mit Zugriff auf dein CMS: All das sind Punkte, die im Scope-Dokument auftauchen müssen.

Du brauchst für diese Schnittstellen keine eigene Risikoanalyse des Dienstleisters, aber du musst dokumentieren, dass die Schnittstelle existiert, welche Daten oder Systeme betroffen sind und wie du die Risiken steuerst (Verträge, Auftragsverarbeitungsvereinbarungen, regelmäßige Überprüfungen).

Kunden und Auftraggeber

Wenn du Kundendaten verarbeitest, etwa als IT-Dienstleister oder Softwareanbieter, ist die Schnittstelle zum Kunden relevant. Welche Daten erhältst du vom Kunden? Wie werden sie übertragen? Wo werden sie gespeichert? Wer hat Zugriff?

Manche Kunden stellen auch eigene Anforderungen an dein ISMS. Gerade im B2B-Umfeld verlangen Auftraggeber zunehmend eine ISO-27001-Zertifizierung oder zumindest nachweisbare Informationssicherheitsmaßnahmen. Diese Anforderungen fließen in deinen Kontext der Organisation (ISO 27001, Kapitel 4.2) ein und beeinflussen den Scope.

Häufiger Fehler: Scope zu groß oder zu klein

Die beiden häufigsten Fehler bei der Scope-Definition sind Extreme in beide Richtungen. Beide können das ISMS-Projekt erheblich gefährden.

Fehler 1: Der Scope ist zu groß

Du nimmst alles rein: jeden Standort, jede Abteilung, jeden Prozess, jedes System. Das klingt gewissenhaft, führt aber in der Praxis zu massiven Problemen:

• Ressourcenüberlastung: Du musst für jeden Bereich Risikoanalysen durchführen, Maßnahmen umsetzen und deren Wirksamkeit prüfen. Bei einem Unternehmen mit 100 Mitarbeitenden und einem Standort ist das machbar. Wenn du aber drei Standorte, zehn Abteilungen und fünfzig Systeme im Scope hast, wird das Projekt schnell unbeherrschbar.
• Endlose Einführungsphase: Statt nach 6-9 Monaten ein funktionierendes ISMS zu haben, ziehst du das Projekt über Jahre. Die Motivation aller Beteiligten sinkt, und irgendwann fragt die Geschäftsleitung, warum es immer noch nicht fertig ist.
• Oberflächliche Umsetzung: Wenn der Scope zu groß ist, neigst du dazu, überall nur die Oberfläche zu kratzen. Lieber weniger Bereiche, die dafür gründlich umgesetzt sind, als ein riesiger Scope mit halbherzigen Maßnahmen.

Fehler 2: Der Scope ist zu klein

Das andere Extrem: Du beschränkst den Scope auf die IT-Abteilung und ihre Server. Alles andere ist draußen. Das kann funktionieren, birgt aber erhebliche Risiken:

• Sicherheitslücken durch Ausschlüsse: Wenn die Buchhaltung außerhalb des Scope liegt, aber Finanzdaten auf denselben Servern verarbeitet werden, die im Scope liegen, hast du ein logisches Problem. Der Auditor wird fragen, wie du die Daten der Buchhaltung schützt, wenn deren Prozesse nicht im Scope sind.
• Fehlende Akzeptanz: Wenn nur die IT im Scope ist, fühlen sich andere Abteilungen nicht betroffen. Informationssicherheit wird dann als reines IT-Thema wahrgenommen, nicht als organisationsweite Aufgabe. Das untergräbt die gesamte Sicherheitskultur.
• Auditor-Skepsis: Ein Auditor wird bei einem auffällig kleinen Scope genau hinschauen, ob du versuchst, problematische Bereiche auszuklammern. Ausschlüsse, die nicht plausibel begründet sind, können zur Beanstandung führen.

Der goldene Mittelweg

Die beste Strategie ist ein pragmatischer Scope, der alle geschäftskritischen Bereiche abdeckt, aber bewusst Grenzen zieht, wo es sinnvoll ist. Faustregel: Alles, was direkt mit der Erbringung deiner Kerndienstleistung zu tun hat, gehört rein. Bereiche, die nur indirekt betroffen sind, kannst du begründet ausschließen und in einer späteren Phase integrieren.

Praxisbeispiel: Scope für ein 100-Mitarbeiter-Unternehmen

Schauen wir uns an, wie ein konkretes Scope-Dokument aussehen kann. Unser Beispiel ist die fiktive SecureData Solutions GmbH, ein IT-Dienstleister mit 100 Mitarbeitenden und einem Standort in München.

Unternehmensprofil

• Branche: IT-Dienstleistung (Managed Services, Softwareentwicklung)
• Mitarbeitende: 100
• Standorte: 1 (Hauptsitz München, Ridlerstraße 42)
• Kunden: Mittelständische Unternehmen in der DACH-Region
• Rechenzentrum: Eigener Serverraum am Standort + Cloud-Dienste (AWS, Microsoft 365)

Das Scope-Dokument

Geltungsbereich des ISMS der SecureData Solutions GmbH

Version: 1.0 | Datum: 2026-03-01 | Freigabe: Geschäftsführung

Das ISMS der SecureData Solutions GmbH umfasst alle Prozesse, Systeme und Informationswerte, die für die Erbringung von Managed IT-Services und Softwareentwicklungsleistungen am Standort München erforderlich sind.

Einbezogene Standorte:

• Hauptsitz München, Ridlerstraße 42 (Büroräume, Serverraum, Besprechungsräume)
• Home-Office-Arbeitsplätze der Mitarbeitenden (als definierter Arbeitskontext)

Einbezogene Organisationseinheiten:

• Geschäftsführung
• IT-Betrieb / Systemadministration
• Softwareentwicklung
• Projektmanagement
• Vertrieb und Kundenbetreuung
• Personal / HR
• Finanzbuchhaltung

Einbezogene Kernprozesse:

• Erbringung von Managed IT-Services für Kunden
• Softwareentwicklung und -bereitstellung
• IT-Betrieb (Server, Netzwerk, Backup, Monitoring, Patch-Management)
• Kunden-Onboarding und Vertragsmanagement
• Incident Management und Support
• Personalverwaltung und Zugangsmanagement

Einbezogene Informationssysteme:

• Interne Serverinfrastruktur (VMware-Cluster, Backup-Systeme)
• AWS-Umgebung (Hosting von Kundenlösungen)
• Microsoft 365 (E-Mail, SharePoint, Teams)
• Jira / Confluence (Projektmanagement, Dokumentation)
• GitLab (Code-Repository, CI/CD)
• DATEV (Finanzbuchhaltung)
• Zammad (Ticketsystem / Kundensupport)

Einbezogene Netzwerke:

• Internes LAN und WLAN am Standort München
• VPN-Zugang für Remote-Arbeit
• DMZ für extern erreichbare Dienste
• Anbindung an AWS (Site-to-Site VPN)

Externe Schnittstellen:

• AWS (Cloud-Hosting): Steuerung über Lieferantenbewertung und AWS-Sicherheitszertifizierungen
• Microsoft (M365): Konfiguration nach CIS Benchmarks, Zugangssteuerung über Conditional Access
• Kunden: Datenübertragung via verschlüsselte Kanäle, geregelt durch Auftragsverarbeitungsvereinbarungen
• Externer Steuerberater: Zugang zu DATEV, geregelt durch Vertraulichkeitsvereinbarung

Ausschlüsse:

• Marketingabteilung (3 Mitarbeitende): Kein direkter Zugriff auf Kunden- oder Produktionssysteme. Nutzung beschränkt auf Website-CMS und Social-Media-Tools. Integration in Phase 2 geplant.
• Gebäudereinigung und Facility Management (extern): Kein Zugang zu IT-Systemen, physischer Zugang durch Besucherregelung gesteuert.

Was an diesem Beispiel gut ist

• Konkret und nachvollziehbar: Jeder Punkt ist spezifisch genug, dass ein Auditor versteht, was gemeint ist.
• Ausschlüsse sind begründet: Die Marketingabteilung ist nicht einfach weggelassen, sondern explizit ausgeschlossen mit Begründung und dem Hinweis auf eine geplante Integration.
• Externe Schnittstellen sind benannt: Für jeden externen Dienst ist dokumentiert, wie die Sicherheit gesteuert wird.
• Versioniert und freigegeben: Das Dokument hat eine Versionsnummer und ist durch die Geschäftsführung freigegeben.

Wie der Scope versioniert und genehmigt wird

Das Scope-Dokument ist ein gesteuertes Dokument im Sinne der ISO 27001. Das bedeutet, es unterliegt deiner Dokumentenlenkung und muss bestimmte Anforderungen erfüllen.

Versionierung

Jede Änderung am Scope führt zu einer neuen Version. Das Dokument enthält mindestens:

• Versionsnummer: Fortlaufend (1.0, 1.1, 2.0). Größere Änderungen wie neue Standorte oder wesentliche Erweiterungen bekommen eine neue Hauptversion. Kleinere Anpassungen wie die Aufnahme eines neuen IT-Systems eine Unterversion.
• Datum: Wann wurde diese Version erstellt?
• Autor: Wer hat die Änderung vorgenommen? Typischerweise der Informationssicherheitsbeauftragte (ISB).
• Änderungshistorie: Was wurde gegenüber der letzten Version geändert und warum?

Genehmigung durch die Geschäftsleitung

Die ISO 27001 verlangt in Kapitel 5.1, dass die oberste Leitung die Informationssicherheitspolitik festlegt und sicherstellt, dass das ISMS die Anforderungen erfüllt. Dazu gehört auch die Genehmigung des Geltungsbereichs.

Konkret bedeutet das: Die Geschäftsführung muss den Scope formell freigeben. Das kann als Unterschrift auf dem Dokument geschehen, als dokumentierter Beschluss im Management-Meeting oder als digitale Freigabe in einem Dokumentenmanagementsystem. Entscheidend ist, dass die Freigabe nachweisbar ist.

Diese Freigabe ist nicht nur eine Formalität. Sie stellt sicher, dass die Geschäftsleitung die Grenzen des ISMS kennt und akzeptiert. Wenn der Scope Bereiche ausschließt, muss die Geschäftsleitung wissen, dass diese Bereiche nicht durch das ISMS geschützt werden, und diese Entscheidung bewusst mittragen.

Kommunikation und Verfügbarkeit

Der Scope muss den relevanten Parteien bekannt sein. Deine Mitarbeitenden sollten wissen, ob sie im Geltungsbereich des ISMS arbeiten oder nicht. Externe Auditoren müssen das Dokument einsehen können. Und interessierte Parteien, etwa Kunden, die nach deiner Zertifizierung fragen, sollten eine Zusammenfassung des Scope erhalten können.

Am besten veröffentlichst du das Scope-Dokument in deinem internen Wiki oder Dokumentenmanagementsystem und verweist in der Informationssicherheitsleitlinie darauf.

Wann und warum der Scope angepasst werden muss

Der Scope ist kein Dokument, das du einmal schreibst und dann in der Schublade vergisst. Die ISO 27001 verlangt, dass du den Geltungsbereich aktuell hältst. Es gibt konkrete Anlässe, bei denen eine Überprüfung und gegebenenfalls Anpassung notwendig ist.

Organisatorische Veränderungen

Wenn dein Unternehmen wächst, eine neue Abteilung gründet oder seine Organisationsstruktur umstellt, musst du prüfen, ob der Scope noch passt. Ein typisches Beispiel: Du gründest ein neues Entwicklungsteam, das eigenständig ein neues Produkt entwickelt. Dieses Team und seine Systeme müssen in den Scope aufgenommen werden.

Neue Standorte

Die Eröffnung eines zweiten Büros oder die Anmietung eines Co-Working-Spaces als dauerhafter Arbeitsort erfordert eine Scope-Erweiterung. Auch die verstärkte Nutzung von Home Office kann eine Anpassung notwendig machen, falls das Thema bisher nicht im Scope adressiert war.

Änderungen an der IT-Landschaft

Wenn du von On-Premises zu Cloud migrierst, ein neues ERP-System einführst oder eine neue Plattform für die Kundenkommunikation aufbaust, ändert sich deine IT-Landschaft und damit potenziell auch dein Scope. Neue Systeme bringen neue Schnittstellen mit sich, die dokumentiert werden müssen.

Geänderte Geschäftsprozesse

Wenn du ein neues Geschäftsfeld erschließt, eine neue Dienstleistung anbietest oder einen bestehenden Prozess grundlegend umstellst, prüfe, ob der Scope noch die Realität abbildet. Besonders relevant ist das, wenn der neue Prozess andere oder zusätzliche Daten verarbeitet.

Regulatorische Anforderungen

Neue Gesetze oder Verordnungen können eine Scope-Anpassung erfordern. Ein aktuelles Beispiel: Die NIS2-Richtlinie verlangt von betroffenen Unternehmen umfassende Maßnahmen zur Cybersicherheit. Wenn du unter NIS2 fällst und dein ISMS-Scope bisher nicht alle von NIS2 geforderten Bereiche abdeckt, musst du erweitern.

Erkenntnisse aus Audits und Vorfällen

Interne Audits oder Sicherheitsvorfälle können zeigen, dass der Scope Lücken hat. Wenn ein Vorfall in einem Bereich passiert, der bisher außerhalb des Scope lag, ist das ein starkes Signal, diesen Bereich aufzunehmen.

Rhythmus der Überprüfung

Auch ohne konkreten Anlass solltest du den Scope mindestens einmal jährlich überprüfen, idealerweise im Rahmen der Managementbewertung (Management Review). Dabei prüfst du, ob der dokumentierte Scope noch mit der tatsächlichen Situation übereinstimmt, und dokumentierst das Ergebnis, auch wenn keine Änderung nötig ist.

Checkliste für die Scope-Definition

Nutze diese Checkliste, um sicherzustellen, dass dein Scope-Dokument vollständig ist:

• Alle relevanten Standorte sind benannt (inkl. Home Office falls zutreffend)
• Alle einbezogenen Abteilungen sind aufgelistet
• Die Kerngeschäftsprozesse im Scope sind beschrieben
• Relevante Informationssysteme und Anwendungen sind erfasst
• Netzwerke und Netzwerksegmente sind dokumentiert
• Externe Schnittstellen (Cloud, Dienstleister, Kunden) sind benannt
• Für jede Schnittstelle ist beschrieben, wie die Sicherheit gesteuert wird
• Ausschlüsse sind explizit aufgeführt und begründet
• Das Dokument ist versioniert (Versionsnummer, Datum, Autor)
• Die Geschäftsleitung hat den Scope formell freigegeben
• Der Scope ist den Mitarbeitenden im Geltungsbereich bekannt
• Ein Review-Zyklus ist definiert (mindestens jährlich)

Fazit: Lieber pragmatisch starten als perfekt planen

Der Scope ist das Fundament deines ISMS. Nimm dir die Zeit, ihn sorgfältig zu definieren, aber verfalle nicht in Perfektionismus. Ein gut begründeter Scope, der 80 % deiner Organisation abdeckt und die restlichen 20 % als geplante Erweiterung dokumentiert, ist besser als ein theoretisch perfekter Scope, mit dem du nie fertig wirst.

Starte mit den Bereichen, die geschäftskritisch sind. Dokumentiere klar, was drin ist und was nicht. Begründe deine Ausschlüsse nachvollziehbar. Hole die Freigabe der Geschäftsleitung und stelle sicher, dass alle Beteiligten wissen, wofür das ISMS gilt. Und plane von Anfang an ein, dass der Scope ein lebendes Dokument ist, das mit deinem Unternehmen wächst.

Weiterführende Artikel

• ISMS aufbauen: Der komplette Leitfaden für Unternehmen mit 50 bis 500 Mitarbeitern
• Statement of Applicability (SoA) erstellen: Controls auswählen und begründen
• IT-Asset-Management für das ISMS: Inventar, Kritikalität und Klassifizierung
• Die wichtigsten ISMS-Rollen: ISB, CISO, Risikoeigner – wer macht was?
• Risikobewertung im ISMS: Methodik, Matrix und Praxisbeispiel

Denn ein ISMS, das den falschen Bereich schützt, ist wie eine Alarmanlage, die nur das Garagentor überwacht, während die Haustür offen steht.