ISO 27001 Content Hub
Statement of Applicability (SoA)
Das Pflichtdokument für deine ISO 27001-Zertifizierung: alle 93 Annex-A-Controls, 9 Pflichtfelder, CC-BY-4.0 Vorlage zum Download.
Das Statement of Applicability (SoA) ist das zentrale Dokument jeder ISO 27001-Zertifizierung. Es listet alle 93 Annex-A-Controls mit ihrer Anwendbarkeit, Begründung, Umsetzungsstatus und dem Verweis auf die zugehörige Policy. Ohne ein vollständiges, korrekt befülltes SoA ist keine ISO 27001-Zertifizierung möglich. Auditoren nutzen das SoA als Hauptreferenz, um zu prüfen, ob dein ISMS vollständig und konsistent ist.
Was ist das Statement of Applicability?
Das Statement of Applicability ist ein Pflichtdokument nach ISO 27001:2022 Klausel 6.1.3 lit. d. Die Norm verlangt, dass du für alle Controls aus Anhang A explizit dokumentierst, ob sie anwendbar sind oder nicht, und warum. Das SoA enthält drei Kernelemente:
- 1.Liste der Controls: Alle 93 Annex-A-Controls einzeln aufgeführt, gegliedert nach A.5 bis A.8.
- 2.Begründung: Für jede Control eine schriftliche Begründung, warum sie anwendbar oder nicht anwendbar ist. Nicht anwendbar ist kein Freifahrtschein, sondern eine begründungspflichtige Entscheidung.
- 3.Implementierungsstatus: Der aktuelle Stand der Umsetzung je Control: implementiert, teilweise umgesetzt, geplant oder nicht anwendbar.
Zertifizierungsauditoren verwenden das SoA als primäres Referenzdokument. Sie prüfen anhand des SoA, welche Controls du für anwendbar erklärt hast, und testen dann stichprobenartig, ob die genannten Policies und Nachweise tatsächlich vorhanden sind.
Der Unterschied zum ISMS und zur Risikobehandlung
Ein häufiges Missverständnis: Das SoA ist nicht das ISMS-Dokument selbst. Es ist auch kein Risikobehandlungsplan. Diese drei Dokumente haben unterschiedliche Rollen:
| Dokument | Zweck | Inhalt |
|---|---|---|
| ISMS-Dokumentation | Managementsystem beschreiben | Scope, Kontext, Policies, Verfahren |
| Risikobehandlungsplan | Operative Maßnahmen planen | Risiken, Maßnahmen, Verantwortliche, Fristen |
| Statement of Applicability | Formale Erklärung der Controls | 93 Controls, Anwendbarkeit, Begründung, Status |
Die Risikobehandlung entscheidet, welche Controls notwendig sind. Das SoA dokumentiert diese Entscheidungen strukturiert in einem standardisierten Format. Der Risikobehandlungsplan zeigt, wie die Controls operativ umgesetzt werden. Alle drei Dokumente müssen aufeinander verweisen und konsistent sein.
Die 9 Pflichtfelder einer SoA-Zeile
Jede Zeile im SoA repräsentiert genau einen Annex-A-Control. Damit das SoA audit-tauglich ist, braucht jede Zeile diese 9 Felder:
Control-Nummer
Die offizielle Kennung nach ISO 27001:2022, z. B. A.5.1. Standardisiert und unveränderlich.
Control-Titel
Der normative Titel des Controls, z. B. "Informationssicherheitsrichtlinien". Exakt aus der Norm übernehmen.
Anwendbar (Ja / Nein)
Binäre Entscheidung. "Nein" ist erlaubt, aber immer begründungspflichtig.
Begründung der Anwendung / Nicht-Anwendung
Schriftlich, nachvollziehbar. Beispiel: "Nicht anwendbar, da keine physischen Serverräume im ISMS-Scope." Auditoren prüfen diese Begründungen besonders kritisch.
Umsetzungsstatus
Vier mögliche Werte: implementiert, teilweise umgesetzt, geplant, nicht anwendbar. "Geplant" sollte nicht länger als 6 Monate alt sein.
Verweis auf Policy / Verfahren
Link oder Dokumentennummer der zugehörigen Policy. Beispiel: "POL-SEC-001 Informationssicherheitsrichtlinie, Version 3.2".
Verweis auf Nachweis / Evidence
Wo liegt der Beweis der Umsetzung? Ticket-Nummer, Audit-Log, Schulungsnachweis oder Systemkonfiguration.
Verantwortliche Rolle
Wer ist zuständig für diesen Control? Immer eine Rolle (nicht einen Namen), z. B. CISO, IT-Leiter, HR-Manager.
Zuletzt geprüft (Datum)
Wann wurde dieser Control zuletzt reviewed? Pflichtfeld für die jährliche Überarbeitung und Management-Review.
Die 4 Annex-A-Kategorien im SoA
ISO 27001:2022 strukturiert die 93 Controls in vier Themengruppen. Das SoA muss alle vier Kategorien vollständig abdecken:
Organisatorische Controls
Richtlinien, Rollen, Lieferantenmanagement, Vorfallmanagement, Business Continuity. Die größte Kategorie mit den meisten Policy-Verweisen.
Beispiele: A.5.1 Informationssicherheitsrichtlinien, A.5.19 Lieferantensicherheit
Personenbezogene Controls
Mitarbeitersicherheit vom Onboarding bis zum Offboarding: Überprüfung, Schulung, Telearbeit, Meldepflichten.
Beispiele: A.6.1 Sicherheitsüberprüfung, A.6.3 Schulung und Awareness
Physische Controls
Gebäudeschutz, Zutrittskontrolle, physische Sicherheitszonen, Schutz von Hardware. Besonders relevant für Unternehmen mit eigenen Rechenzentren.
Beispiele: A.7.1 Physische Sicherheitsperimeter, A.7.2 Physischer Zutritt
Technologische Controls
IT-Sicherheitsmaßnahmen: Zugangskontrollen, Kryptographie, Netzwerksicherheit, Patch-Management, Backup, sichere Entwicklung.
Beispiele: A.8.5 Sichere Authentifizierung, A.8.24 Kryptographie
Wichtig: Kein Control darf im SoA fehlen. Selbst Controls, die du als "nicht anwendbar" bewertest, müssen explizit dokumentiert sein. Das SoA ist nur dann vollständig, wenn alle 93 Controls aufgeführt sind.
So nutzt du die Risikobehandlung zur SoA-Füllung
Das SoA sollte nicht im luftleeren Raum entstehen, sondern direkt aus deiner Risikoanalyse hervorgehen. Dieser 4-Schritt-Workflow verbindet beides:
Risikoregister aufbauen
Identifiziere alle relevanten Informationssicherheitsrisiken deines Unternehmens. Bewerte Eintrittswahrscheinlichkeit und potenzielle Auswirkung. Das Risikoregister ist die Grundlage für alle weiteren Entscheidungen.
Controls je Risiko zuordnen
Für jedes identifizierte Risiko: Welche Annex-A-Controls mitigieren dieses Risiko? Dieser Schritt macht den Kausalzusammenhang explizit und ist entscheidend für die Begründungsqualität im SoA.
Anwendbare Controls markieren
Alle Controls, die mindestens einem Risiko zugeordnet sind, werden im SoA als "anwendbar" markiert. Das Ergebnis ist eine direkt aus der Risikoanalyse abgeleitete Auswahl, die im Audit belastbar ist.
Nicht-anwendbare Controls begründen
Für alle verbleibenden Controls (die keinem Risiko zugeordnet wurden) formulierst du eine Begründung. Prüfe dabei auch: Gibt es andere Gründe für die Anwendbarkeit, z. B. vertragliche Anforderungen oder branchenspezifische Vorgaben?
Praxisbeispiel: Control A.7.11 (Versorgungseinrichtungen) ist ein physischer Control für Serverraum-Infrastruktur. Wenn dein Scope keine eigenen Serverräume umfasst, kannst du diesen Control als "nicht anwendbar" markieren. Begründung im SoA: "A.7.11 nicht anwendbar: Kein physischer Serverraum im ISMS-Scope. Alle IT-Infrastruktur wird bei zertifizierten Cloud-Providern (AWS EU) betrieben."
Häufige Fehler bei der SoA-Erstellung
Diese fünf Fehler sehen Auditoren am häufigsten in der Praxis:
"Nicht anwendbar" ohne Begründung
Jede "nicht anwendbar"-Entscheidung braucht eine schriftliche Begründung. "n/a" oder ein leeres Feld ist ein automatisches Audit-Finding.
SoA als letzter Schritt erstellt
Das SoA sollte parallel zur Risikoanalyse entstehen, nicht als nachträgliche Dokumentation. Ein SoA, das nach der Implementierung rückwärts befüllt wird, ist meist inkonsistent.
Policy-Verweise fehlen oder sind veraltet
Controls ohne Policy-Verweis sind ein rotes Flag. Noch schlimmer: Verweise auf Policies, die inzwischen gelöscht oder umbenannt wurden.
Umsetzungsstatus "geplant" über 6 Monate
Ein Control mit Status "geplant" signalisiert Handlungsbedarf. Wenn ein Control seit mehr als 6 Monaten "geplant" ist, fragt der Auditor nach einem verbindlichen Umsetzungszeitplan.
Keine klare Rolle pro Control
Jeder Control braucht eine zuständige Rolle. Ohne Zuständigkeit gibt es keine Accountability, und Auditoren können nicht prüfen, ob jemand den Control aktiv verantwortet.
Best Practice: Die SoA-Versionierung
Das SoA ist kein statisches Dokument, das nach der Zertifizierung in der Schublade verschwindet. Es ist ein lebendes Dokument, das mit deinem ISMS wächst:
- →Jährliche Überarbeitung ist Pflicht nach ISO 27001 Klausel 9.3 (Management-Review). Neue Risiken, neue Controls, geänderte Begründungen.
- →Versionierung mit Änderungshistorie: Jede neue Version des SoA bekommt eine Versionsnummer (z. B. 2.0), ein Datum und einen kurzen Changelog-Eintrag.
- →Management-Genehmigung: Änderungen am SoA, insbesondere neue "nicht anwendbar"-Entscheidungen, müssen vom Management genehmigt und dokumentiert werden.
- →Anlassbezogene Aktualisierungen: Neue Technologien (z. B. KI-Systeme), geänderte Geschäftsprozesse oder Sicherheitsvorfälle können eine außerordentliche SoA-Revision erfordern.
Audit-Perspektive: Was Prüfer in der SoA suchen
ISO 27001-Auditoren folgen einem dreistufigen Prüfprozess, wenn sie das SoA unter die Lupe nehmen:
Stufe 1: Vollständigkeit
Sind alle 93 Controls im SoA aufgeführt? Kein einziger Control darf fehlen. Selbst wenn du nur 5 Controls als "nicht anwendbar" markierst, müssen alle 93 explizit dokumentiert sein.
Stufe 2: Konsistenz mit der Risikoanalyse
Passt die Anwendbarkeitsentscheidung zur Risikoanalyse? Wenn dein Risikoregister ein hohes Datenleck-Risiko ausweist, aber A.8.12 (Verhinderung von Datenlecks) als "nicht anwendbar" markiert ist, wird der Auditor nachhaken.
Stufe 3: Stichproben-Verifikation
Der Auditor wählt stichprobenartig Controls aus und prüft: Existiert die im SoA referenzierte Policy tatsächlich? Gibt es den angegebenen Nachweis? Typisches Finding: SoA sagt "implementiert", die referenzierte Policy wurde aber seit 3 Jahren nicht aktualisiert oder ist nicht mehr auffindbar.
Tooling: SoA in Excel vs. GRC-Software
Die Wahl des Werkzeugs beeinflusst, wie aufwendig die SoA-Pflege wird:
| Kriterium | Excel / Tabelle | GRC-Software |
|---|---|---|
| Einstieg | Sofort, keine Kosten | Onboarding erforderlich |
| Skalierung | Bis ca. 50 MA gut handhabbar | Skaliert ohne Aufwand |
| Konsistenz | Manuell sicherstellen | Automatisch durch Verlinkungen |
| Evidence-Verknüpfung | Manuelle Links / Dateiablage | Automatische Verknüpfung |
| Versionierung | Manuelle Dateiversionierung | Automatischer Audit-Trail |
| Management-Review | Export + E-Mail-Workflow | Direkt im System mit Genehmigung |
Excel funktioniert für den ersten Zertifizierungslauf gut, wenn du ein kleines Team und einen überschaubaren Scope hast. Ab dem zweiten Audit-Zyklus wird die manuelle Pflege aufwendig. GRC-Software wie Kopexa verknüpft die SoA-Zeilen automatisch mit dem Risikoregister, dem Evidence-Archiv und dem Management-Review-Workflow. Das spart Zeit und verhindert Konsistenzfehler.
Download: SoA-Vorlage (CC-BY-4.0)
Damit du sofort starten kannst, haben wir eine vollständige SoA-Vorlage erstellt. Sie enthält alle 93 Annex-A-Controls mit den 9 Pflichtfeldern als ausfüllbare Tabelle. Lizenziert unter CC-BY-4.0, also frei nutzbar mit Quellenangabe.
ISO 27001:2022 SoA-Vorlage
93 Annex-A-Controls, 9 Pflichtfelder, nach Kategorien gegliedert
CC-BY-4.0 Lizenz — freie Nutzung mit Nennung Kopexa GmbH. Kein Rechtsberatungsersatz.
Die Vorlage ist ein strukturiertes Arbeitsblatt. Sie ersetzt nicht die individuelle Auseinandersetzung mit deinen Unternehmensrisiken und Ihren spezifischen Kontrollentscheidungen.
Verwandte Ressourcen
Das SoA ist ein Kernstück der ISO 27001-Zertifizierung. Hier findest du weitere Ressourcen, die direkt damit zusammenhängen:
ISO 27001 Control Explorer
Alle 93 Annex-A-Controls interaktiv erkunden mit Cross-Mappings zu NIS2, TISAX und DSGVO
ISO 27001 Roadmap
12-Monats-Plan zur ISO 27001-Zertifizierung mit Meilensteinen und SoA-Integration
NIS2 vs. ISO 27001
85 % Überlappung: So nutzt du dein SoA für beide Frameworks gleichzeitig
Weitere ISO 27001 Themen
Start
Zertifizierung
Branchen-Anwendung
Framework-Mapping
Lass uns über deine ISO 27001-Einführung sprechen
Kostenlos & unverbindlich