Statement of Applicability (SoA) — ISO 27001 Erklärung zur Anwendbarkeit

Das Statement of Applicability (SoA, „Erklärung zur Anwendbarkeit“) ist das zentrale Pflichtdokument der ISO 27001. Es listet alle 93 Annex-A-Controls auf und hält für jedes fest, ob es anwendbar ist, ob es umgesetzt wurde und — bei Ausschluss — warum. Ohne vollständiges SoA ist keine Zertifizierung möglich.

Was ist das Statement of Applicability (SoA)?

Das Statement of Applicability (SoA), auf Deutsch „Erklärung zur Anwendbarkeit“, ist eines der wichtigsten Dokumente im ISMS nach ISO 27001. Es dokumentiert, welche der 93 Controls aus dem Annex A der ISO 27001:2022 für das Unternehmen relevant sind, welche implementiert wurden und welche bewusst ausgeschlossen werden — inklusive Begründung.

Das SoA ist ein Pflichtdokument für die ISO 27001 Zertifizierung und wird bei jedem Zertifizierungsaudit intensiv geprüft.

Warum ist das SoA so wichtig?

• Zertifizierungspflicht: Ohne SoA keine ISO 27001 Zertifizierung
• Risikobezug: Verknüpft Risikoanalyse-Ergebnisse mit konkreten Maßnahmen
• Transparenz: Macht sichtbar, welche Sicherheitsmaßnahmen implementiert sind
• Audit-Grundlage: Auditoren prüfen das SoA als zentrale Referenz
• Kommunikation: Ermöglicht Stakeholdern eine Übersicht des Sicherheitsniveaus

SoA, Risikoanalyse und Risikobehandlungsplan — wie sie zusammenhängen

Das SoA steht nicht allein, sondern ist das Ergebnis von zwei vorgelagerten Dokumenten. Die Reihenfolge ist nach ISO 27001 logisch zwingend:

• 1. Risikoanalyse: identifiziert und bewertet die Risiken für Ihre Informationswerte (was kann passieren?).
• 2. Risikobehandlungsplan (RTP): entscheidet pro Risiko über die Behandlung und wählt dazu die passenden Annex-A-Controls aus (was tun wir dagegen?).
• 3. Statement of Applicability (SoA): fasst alle 93 Controls zusammen und dokumentiert für jedes Anwendbarkeit, Status und Begründung (welche Maßnahmen gelten und warum?).

Vereinfacht: Der Risikobehandlungsplan ist die Entscheidung, das SoA der vollständige, prüfbare Nachweis dieser Entscheidungen. Die Basis bildet eine saubere Gap-Analyse.

SoA erstellen: Schritt für Schritt

1. Risikobehandlungsplan als Basis

Das SoA baut auf dem Risikobehandlungsplan auf. Für jedes identifizierte Risiko werden die passenden Controls aus Annex A zugeordnet. Controls können auch aus operativen oder vertraglichen Gründen ausgewählt werden — nicht nur wegen Risiken.

2. Alle 93 Controls durchgehen

Die ISO 27001:2022 enthält 93 Controls in 4 Kategorien:

• Organisatorische Controls (37): Policies, Rollen, Asset Management, Zugriffsrechte
• Personenbezogene Controls (8): Screening, Schulungen, Disziplinarverfahren
• Physische Controls (14): Zutrittskontrolle, Geräteschutz, Entsorgung
• Technische Controls (34): Authentifizierung, Kryptografie, Monitoring, Backup

3. Für jedes Control dokumentieren

Pro Control werden im SoA festgehalten:

• Control-Nummer und Titel (z.B. A.8.24 Use of Cryptography)
• Anwendbar? Ja/Nein
• Implementierungsstatus: Vollständig / Teilweise / Geplant
• Begründung: Warum anwendbar oder warum ausgeschlossen
• Referenz: Verweis auf Policy, Verfahren oder technische Maßnahme

4. Ausschlüsse begründen

Jeder Ausschluss muss nachvollziehbar begründet werden. Auditoren prüfen besonders kritisch, ob Ausschlüsse gerechtfertigt sind. Ein häufiger Audit-Befund: „Unzureichende Begründung für den Ausschluss von Control X.“

Wie sieht ein SoA aus? (Beispiel-Struktur)

In der Praxis ist das SoA eine Tabelle mit einer Zeile pro Control. So sieht ein typischer Auszug aus:

Typische Audit-Findings beim SoA

Diese Schwachstellen führen im Zertifizierungsaudit regelmäßig zu Abweichungen:

• Pauschale Ausschlüsse ohne nachvollziehbare Begründung (häufigster Befund).
• SoA und Risikobehandlungsplan passen nicht zusammen — ein Control ist im RTP gewählt, im SoA aber als „nicht anwendbar“ markiert.
• Veraltete Version: das SoA wurde nach Prozessänderungen nicht aktualisiert.
• Fehlende Referenzen: „implementiert“, aber ohne Verweis auf eine konkrete Policy oder Maßnahme.
• Status „geplant“ ohne Termin — Auditoren erwarten einen verbindlichen Umsetzungsplan.

SoA und die ISO 27001:2022 Änderungen

Die ISO 27001:2022 hat den Annex A grundlegend überarbeitet: von 114 Controls in 14 Kategorien auf 93 Controls in 4 Kategorien. Die Übergangsfrist für bestehende Zertifikate endete am 31. Oktober 2025 — seitdem sind ausschließlich SoAs nach der 2022-Struktur (93 Controls) zertifizierungsfähig. Neue ISMS-Projekte werden ohnehin direkt nach ISO 27001:2022 aufgebaut.

SoA-Vorlage und Tools

Ein SoA lässt sich mit einer strukturierten ISO 27001 Vorlage in Excel führen oder über ein ISMS-Tool wie verinice, das Risikoanalyse, Risikobehandlungsplan und SoA automatisch verknüpft. Bei kleinen Scopes genügt Excel; ab mehreren Standorten oder häufigen Änderungen spart ein Tool erheblichen Pflegeaufwand.

Häufig gestellte Fragen zum Statement of Applicability

Muss jedes Control aus Annex A implementiert werden?

Nein, aber jedes Control muss betrachtet werden. Nicht anwendbare Controls werden im SoA mit Begründung ausgeschlossen. Es gibt kein Minimum — aber Auditoren werden bei vielen Ausschlüssen kritisch nachfragen.

Wie oft muss das SoA aktualisiert werden?

Das SoA muss bei jeder wesentlichen Änderung aktualisiert werden: neue Risiken, geänderte Geschäftsprozesse, technische Veränderungen. Mindestens jährlich im Rahmen des Management-Reviews sollte eine Prüfung erfolgen.

Wer erstellt das SoA?

Typischerweise erstellt der Informationssicherheitsbeauftragte das SoA in Zusammenarbeit mit den Fachabteilungen. Die Geschäftsleitung genehmigt das Dokument. Ein externer ISB kann den Prozess erheblich beschleunigen und die Audit-Konformität sicherstellen.

Was ist der Unterschied zwischen SoA und Risikobehandlungsplan?

Der Risikobehandlungsplan trifft die Entscheidung, wie jedes einzelne Risiko behandelt wird, und wählt dazu Controls aus. Das SoA ist die vollständige Übersicht aller 93 Controls mit Anwendbarkeit, Status und Begründung — der prüfbare Gesamtnachweis. Beide Dokumente müssen widerspruchsfrei zueinander sein.

Excel oder ISMS-Tool für das SoA?

Für kleine, stabile Scopes reicht eine gepflegte Excel-Vorlage. Sobald Risikoanalyse, RTP und SoA konsistent gehalten werden müssen oder mehrere Standorte/Verantwortliche beteiligt sind, reduziert ein ISMS-Tool Fehler und Pflegeaufwand deutlich.

SoA-konform mit DATUREX

Als externer Informationssicherheitsbeauftragter erstellen und pflegen wir Ihr Statement of Applicability audit-konform — verknüpft mit Risikoanalyse und Risikobehandlungsplan. Kontaktieren Sie uns für ein unverbindliches Erstgespräch zur ISO 27001 Beratung.