Was ist ein Statement of Applicability (SoA)?
Das Statement of Applicability (SoA, deutsch: Erklärung zur Anwendbarkeit) legt fest, welche Sicherheitsmaßnahmen (Controls) aus Anhang A der ISO 27001 in deinem Informationssicherheits-Managementsystem (ISMS) gelten.
Die SoA verbindet drei Dinge: deine Risikobeurteilung, die ausgewählten Maßnahmen und den Nachweis, dass kein relevantes Control übersehen wurde. Sie ist damit das Dokument, das Auditor:innen meist zuerst anfordern – und das Kund:innen in Sicherheitsfragebögen oft mitsehen wollen.
Pflichtangaben einer SoA nach ISO 27001:2022
Kapitel 6.1.3 d) verlangt vier Angaben. Ein weiteres Feld ist keine Normpflicht, erleichtert das Audit aber erheblich.
Die 93 Controls des Anhangs A im Überblick
Die ISO 27001:2022 hat die früheren 114 Controls in 14 Bereichen auf 93 Controls in vier Themen verdichtet.
Diese 11 Controls sind seit 2022 neu
- 5.7 Threat Intelligence
- 5.23 Informationssicherheit für die Nutzung von Cloud-Diensten
- 5.30 IKT-Bereitschaft für Business Continuity
- 7.4 Überwachung der physischen Sicherheit
- 8.9 Konfigurationsmanagement
- 8.10 Löschung von Informationen
- 8.11 Datenmaskierung
- 8.12 Verhinderung von Datenlecks (DLP)
- 8.16 Überwachungstätigkeiten
- 8.23 Webfilterung
- 8.28 Sichere Programmierung
Gerade diese Controls fehlen in SoAs, die aus alten 2013er-Vorlagen kopiert wurden.
SoA erstellen in 6 Schritten
- Geltungsbereich festlegen. Standorte, Systeme, Prozesse und Dienstleister im ISMS-Scope bestimmen – sie entscheiden, welche Controls überhaupt relevant sein können.
- Risiken beurteilen. Werte, Bedrohungen und Schwachstellen erfassen und nach Eintrittswahrscheinlichkeit und Auswirkung bewerten. Eine bewährte Methodik dafür liefert Risikomanagement nach ISO 31000.
- Risikobehandlung planen. Für jedes nicht akzeptierte Risiko Maßnahmen festlegen – egal aus welcher Quelle.
- Mit Anhang A abgleichen. Alle 93 Controls durchgehen und prüfen, ob ein notwendiges Control fehlt. Jede Entscheidung mit Risiko, Gesetz oder Vertrag begründen.
- Status und Nachweise dokumentieren. Umsetzungsstand, Verantwortliche und Belege je Control eintragen.
- Freigeben und versionieren. Die SoA von der Geschäftsführung freigeben lassen und bei jeder Änderung am Scope, nach Vorfällen und mindestens jährlich prüfen.
Kein Update verpassen.
Neue Gesetze, Fristen und Praxistipps direkt in dein Postfach – einmal pro Monat, kein Spam.
Beispiel: So sieht eine ausgefüllte SoA aus
Fiktives Beispiel: ein SaaS-Unternehmen mit 40 Mitarbeitenden, reiner Cloud-Betrieb, kein eigenes Rechenzentrum.
Häufige Fehler in der SoA
Die SoA im Zertifizierungsaudit
In Stufe 1 prüft die Zertifizierungsstelle, ob die SoA vollständig ist und zur Risikobeurteilung passt. In Stufe 2 werden Stichproben gezogen: Ist ein als „umgesetzt“ markiertes Control in der Praxis wirksam? Nach der Zertifizierung bleibt die SoA Grundlage der jährlichen Überwachungsaudits.
Automatisierung & SoA-Umsetzung mit heyData
Bei heyData begleiten wir Unternehmen auf ihrem gesamten Weg zur ISO-27001-Zertifizierung – und das Statement of Applicability spielt dabei eine zentrale Rolle. Wir bieten nicht nur ein Tool zur Dokumentation deiner SoA, sondern unterstützen dich aktiv dabei, sie richtig aufzubauen und kontinuierlich an dein wachsendes ISMS anzupassen.
Unser Ansatz sorgt dafür, dass deine SoA kein statisches Dokument bleibt, sondern ein dynamisches Abbild deiner Sicherheitsstrategie wird.
Mit heyData kannst du:
- Annex-A-Maßnahmen mit deiner Risikoanalyse und deinen Richtlinien verknüpfen.
- Deine SoA generieren, basierend auf deinem Asset- und Risikoregister – mit klarer Nachvollziehbarkeit und Belegen für jede Maßnahme.
- Den Umsetzungsfortschritt verfolgen und Verantwortlichkeiten transparent zuweisen.
- Audit-Bereitschaft sicherstellen, dank Versionierung und Änderungsverfolgung bei jeder SoA-Aktualisierung.
- Kontinuierliche Verbesserungen integrieren, indem Ergebnisse aus Audits und Management-Reviews direkt in deine SoA einfließen.
Kurz gesagt: heyData verwandelt die SoA von einer reinen Compliance-Anforderung in ein lebendiges Management-Werkzeug, das Governance, Risiko und Sicherheit in einem zentralen System vereint.
Mach den ersten Schritt: Buche jetzt eine kostenlose Demo
ISO 27001:2022 Leitfaden zur Zertifizierung | heyData
Erfahre, wie du ein ISMS nach ISO 27001:2022 aufbaust, dein Unternehmen auf das Audit vorbereitest und die Zertifizierung strukturiert erreichst.
Kostenlos & unverbindlich
FAQ
Was ist das Statement of Applicability (Erklärung zur Anwendbarkeit) nach ISO 27001:2022?
Was ist das Statement of Applicability (Erklärung zur Anwendbarkeit) nach ISO 27001:2022?
Die SoA ist ein Pflichtdokument nach ISO 27001:2022. Sie geht alle 93 Controls aus Anhang A durch und hält fest, welche notwendig sind, ob sie umgesetzt sind und warum sie aufgenommen oder ausgeschlossen wurden.
Wie hängt die SoA mit der Risikobewertung zusammen?
Wie hängt die SoA mit der Risikobewertung zusammen?
Die SoA ist das direkte Ergebnis der zuvor durchgeführten Risikobeurteilung. Ein Unternehmen identifiziert im ersten Schritt seine spezifischen IT- und Informationssicherheitsrisiken. Anschließend prüft es anhand der Normkontrollen aus Anhang A, welche Maßnahmen geeignet sind, um diese Risiken auf ein akzeptables Maß zu reduzieren. In der SoA wird dieser Zusammenhang lückenlos dokumentiert: Jede Auswahl oder Ablehnung einer Kontrolle muss sich schlüssig aus der Risikoanalyse, gesetzlichen Vorgaben oder vertraglichen Pflichten ableiten lassen.
Darf ein Unternehmen bestimmte ISO 27001 Controls aus der SoA ausschließen?
Darf ein Unternehmen bestimmte ISO 27001 Controls aus der SoA ausschließen?
Ja, das ist ausdrücklich erlaubt und oft sinnvoll. Nicht jede Kontrolle aus Anhang A passt zu jedem Geschäftsmodell. Wenn ein Unternehmen beispielsweise reine Cloud-Software entwickelt und keine eigenen physischen Server oder Rechenzentren betreibt, können Kontrollen zur physischen Gebäudesicherheit für Rechenzentren ausgeschlossen werden. Entscheidend ist jedoch die rechtfertigende Begründung: Jeder Ausschluss muss in der SoA nachvollziehbar begründet werden, beispielsweise durch das Fehlen entsprechender Risiken, physischer Gegebenheiten oder regulatorischer Anforderungen.
Wie oft sollte die SoA aktualisiert werden?
Wie oft sollte die SoA aktualisiert werden?
Mindestens einmal jährlich sowie bei wesentlichen Änderungen, etwa am Geltungsbereich, an den Risiken oder nach Sicherheitsvorfällen.
Wer erstellt die SoA?
Wer erstellt die SoA?
In der Regel das ISMS-Team bzw. die oder der Informationssicherheitsbeauftragte. Freigegeben wird die SoA von der Geschäftsführung.
Wie kann ich die SoA automatisieren?
Wie kann ich die SoA automatisieren?
Mit Tools wie heyData kannst du deine SoA automatisch pflegen, versionieren und auditfertig exportieren.
