In ISO 27001 ist der Geltungsbereich die schriftliche Grenze dessen, was Ihr Managementsystem abdeckt, und die Erklärung zur Anwendbarkeit (Statement of Applicability, SoA) eine Tabelle aller 93 Controls aus Anhang A, die festhält, welche anwendbar sind und warum. Der Geltungsbereich entscheidet, wie viel Arbeit Sie sich vornehmen, und er steht auf Ihrem Zertifikat. Die SoA entscheidet, woran der Auditor Sie misst.
Dieser Leitfaden behandelt den Geltungsbereich, die drei häufigsten Fehler beim Zuschnitt, die SoA, die Formulierung von Begründungen, die Controls der Ausgabe 2022, an denen viele scheitern, und wie Sie beides aktuell halten.
| Beschreibung des Geltungsbereichs | Erklärung zur Anwendbarkeit | |
|---|---|---|
| Was es ist | Die schriftliche Grenze des Managementsystems | Eine Tabelle aller 93 Controls aus Anhang A |
| Was es festhält | Abgedeckte Organisation, Leistungen, Systeme, Standorte und Personen | Anwendbar oder nicht, warum, umgesetzt oder nicht, wo der Nachweis liegt |
| Wer es liest | Die Beschaffung Ihres Kunden, auf dem Zertifikat | Der Auditor, als Grundlage des Audits |
| Typischer Fehler | Eine Grenze, die zu eng, zu weit oder nicht zu verteidigen ist | Ein Ausschluss, der schon eine einzige Rückfrage nicht übersteht |
Fast jedes ISO-27001-Projekt, das schiefgeht, ist in den ersten zwei Wochen entgleist, und zwar an diesen beiden Dokumenten. Machen Sie sie falsch, leisten Sie entweder doppelt so viel Arbeit wie nötig, oder Sie haben am Ende ein Zertifikat, das die Frage Ihres Kunden nicht beantwortet.
Was ist der Geltungsbereich nach ISO 27001?
Der Geltungsbereich ist die schriftliche Grenze dessen, was Ihr Managementsystem abdeckt: welche Teile der Organisation, welche Leistungen, welche Systeme, welche Standorte und welche Personen.
Er steht auf dem Zertifikat. Dieses Detail vergessen alle. Die Beschaffung Ihres Großkunden liest nicht Ihr Risikoregister. Sie liest die Zeile zum Geltungsbereich auf dem Zertifikat und prüft, ob die Leistung darin vorkommt, die sie einkauft. Ein technisch perfektes Zertifikat mit dem falschen Geltungsbereich ist kommerziell wenig wert.
Was sind die häufigsten Fehler beim ISO-27001-Geltungsbereich?
1. Den Geltungsbereich so zuschneiden, dass das Audit leicht wird
Verengen Sie die Grenze auf ein Team, ein Produkt, ein Büro, und der Aufwand bricht ein. Der Wert ebenso. Wir haben Zertifikate gesehen, deren Geltungsbereich eine interne IT-Funktion war, während das Unternehmen ein gehostetes Produkt verkauft. Das beantwortet niemandes Frage.
2. Das ganze Unternehmen einbeziehen, weil es ehrlich wirkt
Ein Unternehmen mit 40 Personen, das jedes System, jedes Büro und jedes Nebenprojekt in den Geltungsbereich aufnimmt, hat die Nachweislast vervielfacht, ohne kommerziellen Nutzen. Ein weiter Geltungsbereich ist eine Entscheidung, die bezahlt werden muss, keine moralische Haltung.
3. Eine Grenze ziehen, die Sie nicht verteidigen können
Angenommen, Ihr einbezogenes Produkt läuft auf geteilter Infrastruktur, nutzt denselben Identitätsanbieter und wird von denselben Entwicklern gebaut wie das ausgeschlossene. Ein Auditor wird fragen, wie die Grenze durchgesetzt wird. Wird sie es nicht, ist die Grenze Fiktion und die Feststellung real.
Der praktische Test: Könnten Sie einem Auditor genau erklären, wo die Grenze verläuft, was sie überquert und wie diese Übergänge kontrolliert werden? Wenn Sie zögern, ziehen Sie sie neu.
Wie legen Sie einen ISO-27001-Geltungsbereich fest, der Arbeit spart?
Schneiden Sie den Geltungsbereich nach Leistung zu, nicht nach Abteilung.
Abteilungen sind politisch und durchlässig. Leistungen haben Schnittstellen, Infrastruktur und Verantwortliche, auf die man zeigen kann. Ein Geltungsbereich wie „die SaaS-Plattform sowie die Teams und Systeme, die sie entwickeln, betreiben und unterstützen“ ergibt eine Grenze, die ein Auditor abschreiten kann. Genau das will Ihr Kunde auch auf dem Zertifikat genannt sehen.
Die Entscheidung, die am häufigsten nach hinten losgeht, ist der Ausschluss einer geteilten Abhängigkeit: der Identitätsanbieter, die CI-Pipeline, das Ticketsystem, die Laptops. Alles, was einbezogene und ausgeschlossene Arbeit gemeinsam nutzen, landet in der Praxis ohnehin im Geltungsbereich. Nehmen Sie es also bewusst auf und kontrollieren Sie es einmal.
Dieselbe Überlegung entscheidet, ob eine Einrichtung in einen regulatorischen Anwendungsbereich fällt. Wenn Sie parallel an NIS2 arbeiten, finden Sie die Parallele in unserem Leitfaden zu Anwendungsbereich und Anwendbarkeit von NIS2.
Was ist die Erklärung zur Anwendbarkeit?
Die SoA ist eine einzige Tabelle mit jedem Control aus Anhang A der Norm: alle 93 in der Ausgabe 2022. Für jedes Control halten Sie vier Dinge fest:
- Ob es auf Sie zutrifft.
- Warum, in einem Satz. Diese Begründung ist für anwendbare wie für nicht anwendbare Controls erforderlich.
- Ob es derzeit umgesetzt ist.
- Wo der Nachweis liegt.
Mehr ist es nicht: 93 Zeilen und vier nützliche Spalten.
Ihre Bedeutung steht in keinem Verhältnis zu ihrer Komplexität, denn gegen die SoA werden Sie auditiert. Nicht gegen die Norm im Abstrakten, nicht gegen das, was ein vergleichbares Unternehmen tut. Sie ist Ihr Arbeitsplan, Ihre Audit-Checkliste und, wenn Sie sie nachlässig schreiben, die Munition, die Sie dem Auditor liefern.
Wie begründen Sie den Ausschluss eines Controls aus Anhang A?
Ein Control als nicht anwendbar zu markieren ist legitim, und die Norm erwartet es. Ein Unternehmen ohne physischen Serverraum braucht keine Zutrittskontrollen für den Serverraum. Ein Unternehmen, das keine Software schreibt, braucht keine Controls für sichere Programmierung. Der Fehler ist ein Ausschluss mit einer Begründung, die schon eine einzige Rückfrage nicht übersteht.
Begründungen, die scheitern:
- „Nicht anwendbar, wir sind ein kleines Unternehmen.“ Größe ist kein Grund. Die Norm skaliert bereits über das Risiko.
- „Nicht anwendbar, wir nutzen einen Cloud-Anbieter.“ Mit einem Anbieter geben Sie den Betrieb ab, nicht die Verantwortung. Sie müssen weiterhin zeigen, dass Sie ihn ausgewählt haben und überwachen.
- „Nicht anwendbar, für unser Geschäft nicht relevant.“ Das ist eine Umformulierung, kein Grund.
Begründungen, die halten:
- „Nicht anwendbar. Die Organisation betreibt kein Rechenzentrum vor Ort. Die gesamte Produktionsinfrastruktur wird von [Anbieter] gehostet und ist über die Lieferanten-Controls 5.19 bis 5.22 abgedeckt.“
- „Nicht anwendbar. Die Organisation entwickelt keine Software. Alle Anwendungen sind Standardsoftware und über 8.30 Ausgelagerte Entwicklung abgedeckt, das als anwendbar markiert ist.“
- „Anwendbar, noch nicht umgesetzt. Die Verhinderung von Datenlecks ist für Q1 mit dem Endgeräte-Rollout geplant. Risiko in der Zwischenzeit vom CTO akzeptiert, erfasst als R-014.“
Die guten Begründungen nennen den Grund, verweisen auf das kompensierende Control oder die Risikoentscheidung und geben dem Auditor einen nächsten Anlaufpunkt.
Einzuräumen, dass ein Control anwendbar und noch nicht umgesetzt ist, ist kein Versagen. Es ist ein legitimer Zustand, solange ein Plan und ein akzeptiertes Risiko dahinterstehen. In Schwierigkeiten geraten Unternehmen, wenn sie bloß angestrebte Controls als umgesetzt markieren. Damit wird aus einem Planungsgespräch eine Abweichung.
Bei den Lieferanten-Controls zieht sich die Arbeit am längsten hin, also beginnen Sie früh damit. Siehe Risikobeurteilung der Lieferkette.
Welche Controls aus Anhang A werden zur Stolperfalle?
Die Ausgabe 2022 hat elf Controls ergänzt, die in der alten Routine nicht vorkamen: Threat Intelligence, Cloud-Dienste, IKT-Bereitschaft für die Betriebskontinuität, Überwachung der physischen Sicherheit, Konfigurationsmanagement, Löschung von Informationen, Datenmaskierung, Verhinderung von Datenlecks, Überwachung von Aktivitäten, Webfilterung und sichere Programmierung.
Das sind die Zeilen, in denen SoAs vage werden, weil es keine alte Musterantwort zum Abschreiben gibt. Wenn Ihre SoA dünne Begründungen enthält, stehen sie mit ziemlicher Sicherheit hier.
Prüfen Sie auch die Vorlage. Der Übergang von der Ausgabe 2013 endete am 31. Oktober 2025, jede Vorlage mit der alten Nummerierung von 114 Controls ist also veraltet. Auditoren arbeiten inzwischen ausschließlich mit dem Satz von 2022.
Wie oft sollten Sie Geltungsbereich und SoA aktualisieren?
Geltungsbereich und SoA sind die beiden Dokumente, die am ehesten unbemerkt falsch werden.
Sie bringen ein Produkt auf den Markt, verlagern eine Arbeitslast, nutzen einen neuen Anbieter oder übernehmen ein Team. Jede dieser Änderungen verschiebt die Grenze oder ändert, welche Controls anwendbar sind. Bewegt sich keines der beiden Dokumente, beschreibt Ihr Managementsystem ein Unternehmen, das es nicht mehr gibt.
Die Ausgabe 2022 greift das über die Klausel auf, die verlangt, Änderungen am Managementsystem zu planen, statt es treiben zu lassen. Die Gewohnheit, die funktioniert:
- Prüfen Sie Geltungsbereich und SoA bei jeder Managementbewertung.
- Fragen Sie bei jeder wesentlichen technischen oder organisatorischen Änderung: Verschiebt das die Grenze oder ändert es eine Anwendbarkeitsentscheidung?
Hier verdienen Werkzeuge ihren Platz, nicht indem sie die Dokumente schreiben, sondern indem sie Controls, Risiken, Verantwortliche und Nachweise verbunden halten, sodass eine Änderung an einer Stelle in den anderen sichtbar wird. Dafür ist das Risiko- und Compliance-Modul unserer Plattform da. Das ist der Unterschied zwischen einem System, das stimmig bleibt, und einem, das ein Quartal lang stimmt.
Den größeren Zusammenhang für ein Unternehmen ohne Sicherheitsfunktion finden Sie in ISO 27001 für ein Unternehmen ohne Sicherheitsteam. Zum Budget lesen Sie Lohnen sich 50.000 € für ISO 27001. Den vollständigen Weg zeigt unsere ISO-27001-Lösungsseite.
Macht ein enger Geltungsbereich das Unternehmen sicherer?
Nein. Ein enger Geltungsbereich schützt das Zertifikat, nicht das Unternehmen.
Der Geltungsbereich legt die Grenze dessen fest, was auditiert wird, nicht dessen, was angegriffen wird. Ein Angreifer liest Ihre Beschreibung des Geltungsbereichs nicht. Ihre ausgeschlossene Marketing-Website nutzt womöglich denselben Identitätsanbieter wie Ihre einbezogene Plattform. Ihre ausgeschlossenen internen Werkzeuge enthalten womöglich Zugangsdaten für die Produktion. Dann haben die zertifizierte Grenze und die tatsächliche Angriffsfläche unterschiedliche Formen, und keines Ihrer Dokumente zeigt das.
Dasselbe gilt für die SoA. Ein Control, das mit tadelloser Begründung als nicht anwendbar markiert ist, bleibt ein Control, das Sie nicht betreiben. Das kann zugleich eine vertretbare Auditposition und eine schwache Sicherheitsposition sein, und die SoA ist nicht dafür gemacht, Ihnen zu zeigen, wann beides auseinanderläuft.
Führen Sie deshalb zwei Listen. Die SoA, die Sie dem Auditor schulden. Und eine kürzere, unverblümtere Liste dessen, was Sie ausgeschlossen oder aufgeschoben haben und was bei einer Ausnutzung wehtun würde: der geteilte Identitätspfad, die aufgeschobene Arbeit an der Erkennung, das akzeptierte Patch-Fenster, die ungetestete Wiederherstellung. Nach dieser zweiten Liste fragt niemand. Sie ist die, die sich in der Managementbewertung zu lesen lohnt.
Schneiden Sie Ihr Zertifikat so zu, dass es die Frage Ihres Kunden beantwortet. Sehen Sie sich dann an, was außerhalb geblieben ist, und seien Sie ehrlich, was davon ein Angreifer zuerst erreichen würde.
Checkliste für Geltungsbereich und SoA
- Schneiden Sie den Geltungsbereich nach Leistung zu, nicht nach Abteilung, und nennen Sie die Leistung, die Ihre Kunden einkaufen.
- Prüfen Sie, ob Sie erklären können, wo die Grenze verläuft, was sie überquert und wie die Übergänge kontrolliert werden.
- Nehmen Sie geteilte Abhängigkeiten bewusst in den Geltungsbereich auf: Identitätsanbieter, CI-Pipeline, Ticketsystem, Laptops.
- Bauen Sie die SoA auf den 93 Controls der Ausgabe 2022 auf, nicht auf der alten Nummerierung mit 114 Controls.
- Geben Sie jedem Control eine Begründung in einem Satz, die eine Rückfrage übersteht.
- Markieren Sie ein Control erst als umgesetzt, wenn es tatsächlich läuft; halten Sie für die übrigen den Plan und das akzeptierte Risiko fest.
- Prüfen Sie Geltungsbereich und SoA bei jeder Managementbewertung und jeder wesentlichen Änderung.
- Führen Sie eine separate Liste der Ausschlüsse und Aufschübe, die ein Angreifer zuerst erreichen würde.
Häufige Fragen
Was gehört in die Beschreibung des ISO-27001-Geltungsbereichs?
Der Geltungsbereich ist die schriftliche Grenze dessen, was Ihr Managementsystem abdeckt: welche Teile der Organisation, welche Leistungen, welche Systeme, welche Standorte und welche Personen. Er steht auf dem Zertifikat und sollte deshalb die Leistung nennen, die Ihre Kunden einkaufen.
Was ist die Erklärung zur Anwendbarkeit in ISO 27001?
Eine einzige Tabelle mit jedem Control aus Anhang A, in der Ausgabe 2022 sind es 93. Für jedes hält sie fest, ob es anwendbar ist, eine Begründung in einem Satz, ob es umgesetzt ist und wo der Nachweis liegt. Gegen dieses Dokument werden Sie auditiert.
Kann man Controls aus Anhang A in der Erklärung zur Anwendbarkeit ausschließen?
Ja. Ein Control als nicht anwendbar zu markieren ist legitim, und die Norm erwartet es. Die Begründung muss einen echten Grund nennen, etwa dass kein Rechenzentrum vor Ort betrieben wird, und eine Rückfrage überstehen. Die Unternehmensgröße ist kein Grund.
Kann ein Control anwendbar, aber noch nicht umgesetzt sein?
Ja, solange ein Plan und ein akzeptiertes Risiko dahinterstehen, etwa ein terminierter Rollout, dessen Übergangsrisiko eine namentlich benannte verantwortliche Person akzeptiert hat. Wer bloß angestrebte Controls als umgesetzt markiert, macht aus einem Planungsgespräch eine Abweichung.
Ist eine Erklärung zur Anwendbarkeit auf Basis von ISO 27001:2013 noch gültig?
Nein. Der Übergang von der Ausgabe 2013 endete am 31. Oktober 2025, eine Vorlage mit der alten Nummerierung von 114 Controls ist also veraltet. Auditoren arbeiten inzwischen ausschließlich mit dem Satz von 2022.
