Wer das lesen sollte: alle, die ISO 27001 in einem Unternehmen ohne eigenes Sicherheitsteam starten wollen, und alle, deren Projekt hängt, weil die ersten beiden Dokumente nie sauber geklärt wurden.
Fast jedes ISO-27001-Projekt, das schiefgeht, ist in den ersten zwei Wochen entgleist, an zwei Dokumenten, die nach Verwaltung aussehen. Die Bereichsangabe entscheidet, wie viel Arbeit Sie sich eingehandelt haben. Die Erklärung zur Anwendbarkeit entscheidet, woran ein Auditor Sie misst. Machen Sie beide richtig, und der Rest des Projekts ist Fleißarbeit. Machen Sie sie falsch, dann leisten Sie entweder doppelte Arbeit oder Sie sind fertig und stellen fest, dass das Zertifikat die Frage Ihres Kunden nicht beantwortet.
Kompliziert ist keines der beiden Dokumente. Sie werden nur schlecht erklärt.
Anwendungsbereich: was er ist, in einem Satz
Der Anwendungsbereich 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. Wenn Ihr Großkunde einen Nachweis verlangt, liest seine Beschaffung nicht Ihr Risikoregister. Sie liest die Bereichszeile auf dem Zertifikat und prüft, ob die Leistung darin vorkommt, die sie einkauft. Ein technisch perfektes Zertifikat mit dem falschen Anwendungsbereich ist kommerziell wenig wert.
Die drei Arten, wie kleinere Unternehmen den Zuschnitt verfehlen
Zuschneiden, damit das Audit leicht wird. Die Versuchung liegt auf der Hand. Verengen Sie die Grenze auf ein Team, ein Produkt, ein Büro, und der Aufwand bricht ein. Der Wert bricht ebenfalls ein. Wir haben Zertifikate gesehen, die auf eine interne IT-Funktion zugeschnitten waren, während das Unternehmen ein gehostetes Produkt verkauft. Das beantwortet niemandes Frage.
Das ganze Unternehmen einbeziehen, weil es ehrlich wirkt. Der umgekehrte Fehler. Ein Unternehmen mit 40 Personen, das jedes System, jedes Büro und jedes Nebenprojekt einbezieht, hat die Nachweislast vervielfacht, ohne kommerziellen Gewinn. Ein breiter Anwendungsbereich ist eine Entscheidung, die bezahlt wird, keine moralische Haltung.
Eine Grenze ziehen, die Sie nicht verteidigen können. Der Anwendungsbereich muss an den Rändern haltbar sein. Wenn Ihr einbezogenes Produkt auf geteilter Infrastruktur läuft, denselben Identitätsanbieter nutzt und von denselben Entwicklerinnen gebaut wird wie das ausgeschlossene, wird ein Auditor fragen, wie die Grenze durchgesetzt wird. Lautet die Antwort, dass sie es nicht wird, ist die Grenze Fiktion und die Abweichung real.
Der praktische Test: Lesen Sie Ihren Entwurf der Bereichsangabe und fragen Sie sich, ob Sie einem Auditor genau erklären könnten, wo die Grenze verläuft, was sie kreuzt und wie die Übergänge kontrolliert werden. Wenn Sie zögern, ziehen Sie sie neu.
Die Zuschnittsentscheidung, die am meisten Arbeit spart
Schneiden Sie nach Leistung zu, nicht nach Abteilung.
Abteilungen sind politisch und durchlässig. Leistungen haben Schnittstellen, Infrastruktur und Verantwortliche, auf die Sie zeigen können. Der Zuschnitt auf die SaaS-Plattform samt der Teams und Systeme, die sie bauen, betreiben und unterstützen, ergibt eine Grenze, die ein Auditor ablaufen kann, und genau das will Ihr Kunde auf dem Zertifikat genannt sehen.
Die Zuschnittsentscheidung, die am häufigsten nach hinten losgeht, ist der Ausschluss einer geteilten Abhängigkeit: der Identitätsanbieter, die CI-Pipeline, das Ticketsystem, die Notebooks. Alles, was zwischen einbezogener und ausgeschlossener Arbeit geteilt wird, landet in der Praxis ohnehin im Anwendungsbereich. Dann können Sie es auch bewusst aufnehmen und einmal kontrollieren.
Es ist dieselbe Logik, die entscheidet, ob eine Einrichtung in einen regulatorischen Geltungsbereich fällt. Wenn Sie zugleich an NIS2 arbeiten, lohnt die Parallele in unserem Leitfaden zu Anwendungsbereich und Anwendbarkeit von NIS2.
Die Erklärung zur Anwendbarkeit: was sie wirklich ist
Die Erklärung zur Anwendbarkeit, meist als SoA abgekürzt, ist eine einzige Tabelle mit jeder Maßnahme aus Anhang A der Norm. Alle 93 in der Ausgabe 2022. Für jede halten Sie vier Dinge fest:
- Ob sie auf Sie zutrifft.
- Warum, in einem Satz. Das ist die Begründung, und sie ist sowohl für anwendbar als auch für nicht anwendbar erforderlich.
- Ob sie derzeit umgesetzt ist.
- Wo der Nachweis liegt.
Mehr nicht. Eine Tabelle mit 93 Zeilen und vier nützlichen Spalten.
Ihre Bedeutung steht in keinem Verhältnis zu ihrer Komplexität, aus einem Grund: Sie werden gegen die SoA auditiert. Nicht gegen die Norm im Abstrakten, nicht gegen das, was ein vergleichbares Unternehmen tut. Gegen das Dokument, in dem Sie dem Auditor gesagt haben, was Sie tun werden. Sie ist zugleich Ihr Arbeitsplan, Ihre Audit-Checkliste und, wenn Sie sie nachlässig schreiben, der Strick, den Sie dem Auditor reichen.
Wo Audits gewonnen und verloren werden: das Wort anwendbar
Eine Maßnahme als nicht anwendbar zu markieren ist völlig legitim. Die Norm erwartet es. Ein Unternehmen ohne Serverraum braucht keine Maßnahmen zum Serverraumzugang. Ein Unternehmen, das keine Software schreibt, braucht keine Maßnahmen zur sicheren Programmierung.
Der Fehler ist nicht der Ausschluss. Der Fehler ist der Ausschluss mit einer Begründung, die 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. Ein Anbieter übernimmt den Betrieb, 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 eigenes Rechenzentrum. Die gesamte Produktionsinfrastruktur wird von [Anbieter] gehostet und ist über die Lieferantenmaßnahmen 5.19 bis 5.22 abgedeckt.
- Nicht anwendbar. Die Organisation entwickelt keine Software. Alle Anwendungen sind Standardprodukte und über Maßnahme 8.30 ausgelagerte Entwicklung abgedeckt, die als anwendbar markiert ist.
- Anwendbar, noch nicht umgesetzt. Die Verhinderung von Datenlecks ist für das erste Quartal mit dem Endgeräte-Rollout geplant. Risiko in der Zwischenzeit vom CTO akzeptiert, erfasst als R-014.
Achten Sie auf die Form der guten Begründungen. Sie benennen den Grund, zeigen auf die kompensierende Maßnahme oder die Risikoentscheidung und geben dem Auditor einen Anschlusspunkt. Das letzte Beispiel lohnt das Kopieren: einzuräumen, dass eine Maßnahme 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 Dinge als umgesetzt markieren, die Absicht geblieben sind. Damit wird aus einem Planungsgespräch eine Abweichung.
Die elf Maßnahmen, die alle erwischen
Die Ausgabe 2022 hat elf Maßnahmen ergänzt, die in der alten Routine fehlten: Bedrohungsinformationen, Cloud-Dienste, IKT-Bereitschaft für die Geschäftskontinuität, Überwachung der physischen Sicherheit, Konfigurationsmanagement, Löschung von Informationen, Datenmaskierung, Verhinderung von Datenlecks, Überwachungstätigkeiten, 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 fast sicher in dieser Liste. Ebenfalls prüfenswert: Der Übergang von der Ausgabe 2013 endete am 31. Oktober 2025, also ist jede SoA-Vorlage mit der alten Nummerierung über 114 Maßnahmen veraltet. Auditoren arbeiten inzwischen ausschließlich mit dem Satz von 2022.
Beide Dokumente am Leben halten
Anwendungsbereich und SoA sind keine einmaligen Lieferergebnisse. Sie sind die beiden Dokumente, die am ehesten unbemerkt falsch werden.
Sie starten ein neues Produkt. Sie verschieben eine Arbeitslast. Sie nehmen einen neuen Anbieter. Sie übernehmen ein Team. Jedes davon verschiebt die Grenze oder ändert, welche Maßnahmen zutreffen, und wenn keines der Dokumente sich bewegt, beschreibt Ihr Managementsystem jetzt ein Unternehmen, das es nicht mehr gibt.
Die Ausgabe 2022 adressiert das direkt über die Klausel, die verlangt, Änderungen am Managementsystem zu planen, statt es treiben zu lassen. In der Praxis funktioniert die Gewohnheit, Anwendungsbereich und SoA bei jeder Managementbewertung zu prüfen und jeder wesentlichen technischen oder organisatorischen Änderung eine einzige Frage anzuhängen: Verschiebt das die Grenze, oder ändert es eine Anwendbarkeitsentscheidung?
Genau hier verdient Werkzeug seinen Platz, nicht indem es die Dokumente für Sie schreibt, sondern indem es Maßnahmen, Risiken, Verantwortliche und Nachweise verbunden hält, sodass eine Änderung an einer Stelle in den anderen sichtbar wird. Dafür ist das Risiko- und Compliance-Modul unserer Plattform da, und das ist der Unterschied zwischen einem System, das wahr bleibt, und einem, das ein Quartal lang stimmt.
Für den größeren Zusammenhang einer Erstzertifizierung in einem Unternehmen ohne Sicherheitsfunktion beginnen Sie mit ISO 27001 für ein Unternehmen ohne Sicherheitsteam, und zur Budgetfrage im Besonderen mit Sind 50.000 Euro für ISO 27001 das wert. Lieferanten verdienen frühe Aufmerksamkeit, denn die Lieferantenmaßnahmen der SoA ziehen den längsten Arbeitsschwanz nach sich, behandelt in Risikobewertung der Lieferkette. Den vollständigen Weg zeigt unsere ISO-27001-Lösungsseite.
Die technische Realität: ein enger Anwendungsbereich schützt das Zertifikat, nicht das Unternehmen
Hier ist, was die Norm offenlässt, und es folgt unmittelbar aus allem Vorherigen.
Der Anwendungsbereich definiert die Grenze dessen, was auditiert wird. Er definiert nicht die Grenze dessen, was angegriffen wird. Ein Angreifer liest Ihre Bereichsangabe nicht. Wenn Ihre ausgeschlossene Marketing-Website denselben Identitätsanbieter nutzt wie Ihre einbezogene Plattform, oder Ihr ausgeschlossenes internes Werkzeug Produktionszugangsdaten hält, dann haben zertifizierte Grenze und tatsächliche Angriffsfläche unterschiedliche Formen, und der Unterschied ist in keinem Ihrer Dokumente sichtbar.
Dasselbe gilt für die SoA. Eine Maßnahme, die mit tadelloser Begründung als nicht anwendbar markiert ist, bleibt eine Maßnahme, die Sie nicht betreiben. Das ist eine haltbare Auditposition und kann zugleich eine schlechte Sicherheitsposition sein. Beide Aussagen können gleichzeitig wahr sein, und die SoA ist nicht dafür gebaut, Ihnen zu sagen, wann sie auseinanderlaufen.
Die sinnvolle Disziplin ist deshalb, zwei Listen zu führen. Die SoA, die Sie dem Auditor schulden. Und eine kürzere, härtere Liste dessen, was Sie ausgeschlossen oder verschoben haben und was Ihnen bei Ausnutzung wirklich wehtun würde: der geteilte Identitätspfad, die verschobene Erkennungsarbeit, das akzeptierte Patch-Fenster, die ungetestete Wiederherstellung. Nach dieser zweiten Liste fragt niemand. Sie ist die, die man in der Managementbewertung lesen sollte.
Schneiden Sie Ihr Zertifikat so zu, dass es die Frage Ihres Kunden beantwortet. Dann sehen Sie sich an, was außerhalb liegt, und seien Sie ehrlich darüber, was ein Angreifer zuerst erreichen würde.
