Statement of Applicability: Das Statement of Applicability (SoA) ist ein Pflichtdokument nach ISO 27001 Kapitel 6.1.3d, das für jedes der 93 Controls aus Anhang A begründet, ob es angewendet wird oder nicht, und den Umsetzungsstand dokumentiert.
Das SoA verknüpft die zuvor durchgeführte Risikobeurteilung mit den konkreten Controls aus Anhang A der ISO 27001:2022. Für jedes der 93 Controls muss dokumentiert sein, ob es angewendet wird, warum, und ob es bereits umgesetzt ist.
| Spalte im SoA | Inhalt |
|---|---|
| Control-Nummer | z. B. A.5.12, A.8.24 |
| Anwendbar (ja/nein) | Begründet aus der Risikobeurteilung |
| Umsetzungsstand | Geplant, teilweise, vollständig umgesetzt |
| Referenz | Verweis auf Richtlinie oder Verfahren |
Ein Control als nicht anwendbar auszuschließen ist zulässig, muss aber sachlich begründet sein – etwa weil ein Unternehmen keine physischen Rechenzentren betreibt und bestimmte physische Sicherheits-Controls deshalb entfallen. Ein häufiger Fehler ist, Controls pauschal als nicht anwendbar zu markieren, um Aufwand zu sparen, ohne die Begründung im Risikokontext zu prüfen – das fällt im Audit regelmäßig auf.
Das SoA ist ein lebendes Dokument: Ändern sich Risiken, Systeme oder Geschäftsprozesse, muss es aktualisiert werden, mindestens jedoch im Rahmen der jährlichen Managementbewertung.
Viele Unternehmen pflegen das SoA als Tabelle parallel zur Risikobeurteilung, sodass Änderungen an einem Risiko automatisch die Anwendbarkeit verknüpfter Controls mit reflektieren. Eine gängige Praxis ist zudem, das SoA um eine kurze Spalte mit dem Verantwortlichen je Control zu ergänzen, damit im Audit sofort ersichtlich ist, wer für die Umsetzung zuständig ist.
Relevanz für die Zertifizierung
Das SoA gehört zu den ersten Dokumenten, die KCERT im Stufe-1-Audit prüft, da es die gesamte inhaltliche Reichweite des ISMS abbildet – ohne ein sauberes SoA lässt sich das Stufe-2-Audit nicht sinnvoll planen. Unternehmen sollten das SoA nicht als einmalige Checkliste zum Zertifizierungstermin verstehen, sondern als Steuerungsinstrument, das im Alltag zeigt, welche Controls tatsächlich fehlen oder unvollständig umgesetzt sind. Wer das SoA erst kurz vor dem Audit erstellt, statt es parallel zur Risikobeurteilung zu entwickeln, riskiert im Audit unvollständige Begründungen und damit Abweichungen.
Häufige Fragen zu Statement of Applicability
Ja, ohne Ausnahme. ISO 27001 Kapitel 6.1.3d verlangt das SoA als eines der wenigen namentlich benannten Pflichtdokumente der Norm. Es muss für alle 93 Controls aus Anhang A eine begründete Aussage zur Anwendbarkeit enthalten und dem tatsächlichen Umsetzungsstand entsprechen; ein fehlendes oder unvollständiges SoA führt im Zertifizierungsaudit zu einer schwerwiegenden Abweichung.
Nur mit sachlicher Begründung aus der Risikobeurteilung, nicht um Aufwand zu sparen. Ein Control gilt als nicht anwendbar, wenn das zugrunde liegende Risiko im Unternehmen faktisch nicht existiert, etwa physische Sicherheits-Controls bei vollständig ausgelagerter IT-Infrastruktur. Auditoren prüfen solche Ausschlüsse gezielt und verlangen eine nachvollziehbare Herleitung aus dem Risikokontext.
Der Risikobehandlungsplan legt fest, welche Maßnahmen zur Behandlung identifizierter Risiken ergriffen werden. Das SoA überträgt diese Entscheidungen in eine strukturierte Übersicht über alle 93 Controls aus Anhang A und dokumentiert Anwendbarkeit und Umsetzungsstand. Beide Dokumente hängen eng zusammen, das SoA ist aber das für Auditoren zentrale Nachschlagewerk.