Ratgeber › Erklärung zur Anwendbarkeit
Erklärung zur Anwendbarkeit (SoA): Inhalt, Aufbau, Beispiele.
Die Erklärung zur Anwendbarkeit, englisch Statement of Applicability (SoA), ist eines der wichtigsten Dokumente im ISMS. Sie zeigt für jede Maßnahme aus Anhang A der ISO 27001, ob Sie sie anwenden und warum. Kein Auditor zertifiziert ohne sie.
Was die Norm verlangt.
ISO 27001 fordert die SoA in Kapitel 6.1.3 d. Sie verbindet Ihre Risikobehandlung mit dem Maßnahmenkatalog aus Anhang A und muss vier Dinge enthalten:
Notwendige Maßnahmen
Alle Controls, die Sie zur Behandlung Ihrer Risiken brauchen, auch solche, die nicht aus Anhang A stammen.
Begründung der Aufnahme
Warum ein Control angewendet wird: wegen eines Risikos, einer gesetzlichen oder vertraglichen Pflicht oder einer Geschäftsanforderung.
Umsetzungsstand
Ob das Control bereits umgesetzt ist oder sich noch in Umsetzung befindet.
Begründung des Ausschlusses
Warum ein Control aus Anhang A nicht angewendet wird. Ein Ausschluss ohne nachvollziehbare Begründung ist eine Abweichung.
So sieht eine SoA aus.
In der Praxis ist die SoA eine Tabelle mit einer Zeile je Control. Alle 93 Controls aus Anhang A der ISO 27001:2022 müssen darin vorkommen, auch die ausgeschlossenen. Drei Beispielzeilen:
| Control | Anwendbar | Begründung | Stand | Nachweis |
|---|---|---|---|---|
| A.5.15 Zugangssteuerung | ja | Risiko R-012 unberechtigter Zugriff auf Kundendaten; vertragliche Anforderung von Kunden | umgesetzt | Richtlinie Zugangssteuerung, Zugriffsmatrix |
| A.8.13 Sicherung von Information | ja | Risiko R-004 Datenverlust durch Ransomware | in Umsetzung | Backup-Konzept, Maßnahme M-031 Restore-Test |
| A.8.28 Sichere Codierung | nein | Keine eigene Softwareentwicklung im Geltungsbereich | – | – |
Bewährt haben sich zusätzlich Spalten für den Verantwortlichen und das Datum der letzten Überprüfung. Die SoA ist ein gelenktes Dokument: Sie bekommt eine Version und wird freigegeben.
Die SoA in 5 Schritten erstellen.
Die SoA entsteht nicht am Anfang, sondern aus der Risikobehandlung. Wer sie vorher ausfüllt, rät.
Risiken beurteilen
Ohne Risikobeurteilung gibt es keine belastbare Begründung für Aufnahme oder Ausschluss.
Maßnahmen auswählen
Zu jedem Risiko, das Sie behandeln, die passenden Controls festlegen.
Mit Anhang A abgleichen
Jedes der 93 Controls durchgehen: Ist es nötig? Wurde etwas übersehen?
Begründen und belegen
Für jedes Control Aufnahme oder Ausschluss begründen, Stand und Nachweis eintragen.
Freigeben und pflegen
Version freigeben und bei jeder Änderung von Risiken oder Maßnahmen aktualisieren.
Was Auditoren in der SoA finden.
SoA und Risikobehandlung passen nicht zusammen
Im Behandlungsplan steht eine Maßnahme, in der SoA ist das passende Control ausgeschlossen, oder umgekehrt. Das ist der häufigste Befund.
Ausschlüsse ohne Begründung
„Nicht relevant“ reicht nicht. Die Begründung muss erkennen lassen, warum das Control in Ihrem Geltungsbereich keine Rolle spielt.
Alles auf „umgesetzt“
Steht überall „umgesetzt“, will der Auditor die Nachweise sehen. Ehrliche Einträge mit „in Umsetzung“ und einem Termin sind glaubwürdiger.
Die SoA ist veraltet
Einmal zur Zertifizierung erstellt und danach nicht mehr angefasst. Spätestens im Überwachungsaudit fällt das auf.
Die SoA, die sich selbst aktuell hält.
In WolfISMS verknüpfen Sie jedes Control mit Risiken, Maßnahmen und Dokumenten. Die Erklärung zur Anwendbarkeit erstellt WolfISMS daraus automatisch, mit Begründung, Umsetzungsstand und Nachweisen. Ändert sich ein Risiko, stimmt die SoA trotzdem.