Ist die SoA bei ISO 27001 verpflichtend?

Ja. Die ISO/IEC 27001:2022 verlangt die Erklärung zur Anwendbarkeit (Statement of Applicability) ausdrücklich in Abschnitt 6.1.3 d). Ohne vollständige SoA ist eine Zertifizierung nicht möglich.

Wie viele Controls muss die SoA enthalten?

Alle 93 Maßnahmen des Anhangs A der ISO/IEC 27001:2022 – gegliedert in organisatorische (37), personenbezogene (8), physische (14) und technologische (34) Controls. Jede Maßnahme wird mit Anwendbarkeit, Begründung und Umsetzungsstatus geführt.

Was ist der Unterschied zwischen SoA und Risikobehandlungsplan?

Der Risikobehandlungsplan beschreibt, wie einzelne Risiken behandelt werden (mit Verantwortlichen und Terminen). Die SoA ist die Gesamtsicht auf alle 93 Annex-A-Controls und ihren Anwendbarkeits- und Umsetzungsstatus. Die SoA gleicht die aus der Risikobehandlung ausgewählten Controls mit dem vollständigen Anhang A ab.

Darf man Annex-A-Controls ausschließen?

Ja, ein Ausschluss ist zulässig, muss aber sachlich begründet sein – etwa weil keine eigene Softwareentwicklung stattfindet. Der Ausschluss und seine Begründung werden in der SoA dokumentiert.

Wissen · ISO 27001

SoA erstellen: das Statement of Applicability nach ISO 27001

Die SoA (Statement of Applicability, deutsch: Erklärung zur Anwendbarkeit) ist ein zwingend erforderliches Dokument der ISO/IEC 27001:2022 (Abschnitt 6.1.3 d). Sie führt sämtliche Maßnahmen des Anhangs A – seit der Fassung 2022 sind das 93 Controls – auf und hält für jede fest: ist sie anwendbar, ist sie umgesetzt, und wie wird das begründet. Die SoA verbindet die Risikobehandlung mit den konkreten Maßnahmen und ist im Zertifizierungsaudit das zentrale Prüfdokument. Fehlt sie oder ist sie unvollständig, ist keine Zertifizierung möglich.

Norm: ISO/IEC 27001:2022, Abschnitt 6.1.3 d)
Umfang: alle 93 Annex-A-Controls
Themen: A.5 organisatorisch (37) · A.6 personell (8) · A.7 physisch (14) · A.8 technologisch (34)
Je Control: anwendbar? · Begründung Einschluss/Ausschluss · umgesetzt?
Status: Pflichtdokument für die Zertifizierung, lebendes Dokument

Was ist die SoA – und warum ist sie Pflicht?

Die SoA ist die dokumentierte Erklärung, welche der Anhang-A-Maßnahmen für das ISMS anwendbar sind und welche nicht. ISO/IEC 27001:2022 verlangt sie ausdrücklich in Abschnitt 6.1.3 d) als Teil des Prozesses der Informationssicherheits-Risikobehandlung. Sie ist damit eines der wenigen namentlich vorgeschriebenen Dokumente der Norm.

Der Zweck: Die SoA macht nachvollziehbar und prüfbar, dass die Organisation jede der 93 Referenzmaßnahmen bewusst betrachtet hat – und Ausschlüsse nicht aus Nachlässigkeit, sondern aus begründeter Entscheidung erfolgen. Für Auditoren ist die SoA die Landkarte des ISMS: Sie zeigt, welche Controls greifen sollen, und ist Ausgangspunkt für die Stichproben im Audit.

Die 93 Annex-A-Controls in vier Themengruppen

Der Anhang A der ISO/IEC 27001:2022 enthält 93 Maßnahmen, gegliedert in vier Themen: organisatorische Maßnahmen (A.5, 37 Controls), personenbezogene Maßnahmen (A.6, 8 Controls), physische Maßnahmen (A.7, 14 Controls) und technologische Maßnahmen (A.8, 34 Controls). Die SoA muss jede dieser 93 Maßnahmen aufführen – kein Control darf fehlen.

Die Fassung 2022 hat die früheren 114 Controls (ISO 27001:2013) neu strukturiert und auf 93 konsolidiert; elf Controls sind neu hinzugekommen (u. a. Threat Intelligence, Cloud-Sicherheit, Data Leakage Prevention). Wer eine ältere SoA übernimmt, muss sie auf die 2022er-Struktur umstellen.

Pflichtinhalte je Control

Für jede der 93 Maßnahmen hält die SoA vier Angaben fest: (1) ob die Maßnahme anwendbar ist (Einschluss oder Ausschluss), (2) die Begründung für den Einschluss, (3) die Begründung für einen etwaigen Ausschluss und (4) ob die Maßnahme bereits umgesetzt ist. In der Praxis ergänzt man einen Verweis auf das umsetzende Dokument (Richtlinie, Verfahren, technische Maßnahme).

Die Begründung für Einschlüsse ergibt sich in der Regel aus der Risikobehandlung, aus rechtlichen oder vertraglichen Anforderungen oder aus internen Vorgaben. Ein Ausschluss ist zulässig, muss aber sachlich tragfähig sein – etwa „kein eigener Software-Entwicklungsprozess“ als Begründung für den Ausschluss entwicklungsbezogener Controls.

SoA vs. Risikobehandlungsplan – nicht dasselbe

SoA und Risikobehandlungsplan (Risk Treatment Plan) werden oft verwechselt. Der Risikobehandlungsplan (ebenfalls 6.1.3) beschreibt, wie identifizierte Risiken behandelt werden – mit Zuständigkeiten, Ressourcen und Terminen. Die SoA ist die statische Gesamtsicht auf alle Anhang-A-Controls und ihren Anwendbarkeits-/Umsetzungsstatus.

Beide hängen zusammen: Aus der Risikobehandlung entsteht die Auswahl der notwendigen Controls, und die SoA gleicht diese Auswahl mit dem vollständigen Anhang A ab (6.1.3 c–d). So stellt die Norm sicher, dass kein relevantes Control übersehen wurde.

Typische Fehler

Häufige Mängel: nicht alle 93 Controls gelistet; pauschale Ausschlüsse ohne Begründung; die SoA wird einmal erstellt und nie gepflegt (sie ist ein lebendes Dokument und bei Änderungen von Risiken oder Umfang zu aktualisieren); Widersprüche zwischen SoA („umgesetzt“) und tatsächlicher Lage im Audit. Auch ein häufiger Fehler: die alte 114-Control-Struktur aus 2013 weiterzuführen.

Das ISMS-Modul in MGMSYS führt die 93 Controls vorstrukturiert, verknüpft sie mit der Risikobehandlung und erzeugt die SoA als konsistenten, jederzeit aktuellen Nachweis für das Audit.

Häufige Fragen

Ist die SoA bei ISO 27001 verpflichtend?: Ja. Die ISO/IEC 27001:2022 verlangt die Erklärung zur Anwendbarkeit (Statement of Applicability) ausdrücklich in Abschnitt 6.1.3 d). Ohne vollständige SoA ist eine Zertifizierung nicht möglich.
Wie viele Controls muss die SoA enthalten?: Alle 93 Maßnahmen des Anhangs A der ISO/IEC 27001:2022 – gegliedert in organisatorische (37), personenbezogene (8), physische (14) und technologische (34) Controls. Jede Maßnahme wird mit Anwendbarkeit, Begründung und Umsetzungsstatus geführt.
Was ist der Unterschied zwischen SoA und Risikobehandlungsplan?: Der Risikobehandlungsplan beschreibt, wie einzelne Risiken behandelt werden (mit Verantwortlichen und Terminen). Die SoA ist die Gesamtsicht auf alle 93 Annex-A-Controls und ihren Anwendbarkeits- und Umsetzungsstatus. Die SoA gleicht die aus der Risikobehandlung ausgewählten Controls mit dem vollständigen Anhang A ab.
Darf man Annex-A-Controls ausschließen?: Ja, ein Ausschluss ist zulässig, muss aber sachlich begründet sein – etwa weil keine eigene Softwareentwicklung stattfindet. Der Ausschluss und seine Begründung werden in der SoA dokumentiert.