Was ist Statement of Applicability?
Statement of Applicability (SoA) — auf Deutsch Anwendbarkeitserklärung — ist ein zentrales Dokument in ISO 27001. Es listet alle Kontrollen in Anhang A auf und gibt für jede Kontrolle an:
- Ob sie anwendbar ist oder nicht
- Begründung für die Entscheidung
- Implementierungsstatus
Wichtige Erkenntnis: SoA ist keine Checkliste zum Abhaken. Es ist ein strategisches Dokument, das zeigt, dass die Organisation bewusste, risikobasierte Entscheidungen über ihre Sicherheitsmaßnahmen getroffen hat.
Warum ist SoA wichtig?
SoA erfüllt mehrere Funktionen:
- Zertifizierungsanforderung — Obligatorisch nach ISO 27001 Klausel 6.1.3
- Kommunikation — Zeigt Stakeholdern, welche Kontrollen implementiert wurden
- Referenz — Ausgangspunkt für interne Audits und Kontrollverfolgung
- Nachverfolgbarkeit — Verbindet Risikobewertung mit konkreten Maßnahmen
- Transparenz — Dokumentiert bewusste Entscheidungen und Prioritäten
Ohne SoA:
- Keine ISO 27001-Zertifizierung möglich
- Schwer, systematische Sicherheitsarbeit nachzuweisen
- Risiko willkürlicher Kontrollauswahl
ISO 27001:2022 Anhang A Struktur
Die 93 Kontrollen sind in vier Themenbereiche organisiert:
| Thema | Anzahl Kontrollen | Fokus |
|---|---|---|
| A.5 Organisatorische | 37 | Richtlinien, Rollen, Lieferanten |
| A.6 Personenbezogene | 8 | Einstellung, Schulung, Ausscheiden |
| A.7 Physische | 14 | Räumlichkeiten, Ausrüstung, Umgebung |
| A.8 Technische | 34 | Systeme, Netzwerke, Verschlüsselung |
SoA-Prozess Schritt für Schritt
- Risikobewertung zuerst durchführen SoA basiert auf Ihrer Risikobewertung. Identifizieren Sie, welche Risiken existieren, welche Assets geschützt werden müssen und welche Bedrohungen relevant sind. Ohne Risikobewertung wird SoA willkürlich.
- Alle Anhang A-Kontrollen auflisten Erstellen Sie eine Tabelle mit allen 93 Kontrollen. Fügen Sie Kontrollnummer, Name und Beschreibung hinzu. Dies wird die Grundlage Ihrer SoA.
- Anwendbarkeit bewerten Für jede Kontrolle: Ist sie relevant für Ihr Unternehmen und Ihre Risikolage? Antworten Sie mit Ja oder Nein. Bedenken Sie, dass "nicht anwendbar" eine starke Begründung erfordert.
- Jede Entscheidung begründen Ob die Kontrolle anwendbar ist oder nicht — dokumentieren Sie das Warum. Verknüpfen Sie es mit der Risikobewertung. "Implementiert zur Behandlung von Risiko X" oder "Nicht anwendbar, da wir Y nicht haben".
- Implementierungsstatus dokumentieren Für anwendbare Kontrollen: Ist sie implementiert? Teilweise? Geplant? Geben Sie Status und eventuelle Deadline an.
- Mit Dokumentation verknüpfen Verbinden Sie jede Kontrolle mit relevanter Richtlinie, Verfahren oder technischer Implementierung. Dies erleichtert das Audit.
- Überprüfen und genehmigen SoA soll von der Geschäftsleitung genehmigt werden. Es zeigt Eigentümerschaft und Verantwortung für die Sicherheitsentscheidungen.
Beispiel einer SoA-Struktur
| Kontrolle | Beschreibung | Anwendbar | Begründung | Status | Dokumentation |
|---|---|---|---|---|---|
| A.5.1 | Policies for information security | Ja | Grundlegende Governance erforderlich | Implementiert | POL-001 |
| A.5.9 | Inventory of information assets | Ja | Risiko: Nicht identifizierte Assets | Implementiert | PROC-012 |
| A.7.3 | Securing offices and facilities | Ja | Physische Büroräume vorhanden | Implementiert | POL-015 |
| A.7.4 | Physical security monitoring | Nein | Wird vom Immobilieneigentümer übernommen, Vertrag vorhanden | Nicht anwendbar | AVT-023 |
| A.8.20 | Networks security | Ja | Kritische Infrastruktur | Teilweise | PROJ-007 |
Gültige und ungültige Begründungen
• Das Risiko existiert nicht (z.B. keine physischen Server = keine physische Serversicherheit)
• Wird durch andere Kontrolle abgedeckt
• An Dienstleister ausgelagert mit Vertrag
• Unternehmen hat keinen relevanten Prozess (z.B. keine Systementwicklung)
• "Wir haben kein Budget"
• "Wir haben keine Zeit"
• "Es ist zu kompliziert"
• "Niemand hat danach gefragt"
• Keine Begründung
Häufige Kontrollen, die oft ausgeschlossen werden
Kontrollen, die oft (legitim) ausgeschlossen werden:
| Kontrolle | Häufige Begründung |
|---|---|
| A.5.23 Information security for cloud services | Keine Cloud-Nutzung |
| A.7.4 Physical security monitoring | Wird vom Immobilieneigentümer übernommen |
| A.8.25 Secure development life cycle | Keine eigene Entwicklung |
| A.8.26 Application security requirements | Keine eigene Entwicklung |
| A.8.28 Secure coding | Keine eigene Entwicklung |
| A.8.31 Separation of development environments | Keine eigene Entwicklung |
Wichtig: Auch wenn Sie nicht intern entwickeln, können Sie Software verwenden, die sichere Konfiguration erfordert. Denken Sie sorgfältig durch.
Auditor-Perspektive
Was der Auditor prüft:
- Vollständigkeit — Alle 93 Kontrollen müssen enthalten sein
- Konsistenz — Begründungen müssen logisch und konsistent sein
- Risikoverbindung — Entscheidungen sollen mit Risikobewertung verknüpft sein
- Implementierung — Anwendbare Kontrollen sollen tatsächlich existieren
- Dokumentation — Verweise sollen zu korrekten Dokumenten führen
- Aktualität — SoA soll aktuell sein
Häufige Abweichungen:
- Fehlende Kontrollen
- Unzureichende Begründungen
- Anwendbare Kontrollen, die nicht implementiert sind
- Veraltete SoA, die den aktuellen Stand nicht widerspiegelt
SoA und NIS2-Anforderungen
SoA kann erweitert werden, um NIS2-Anforderungen abzudecken, die über ISO 27001 hinausgehen:
| NIS2-Anforderung | Relevante ISO 27001 Kontrollen | SoA-Notiz |
|---|---|---|
| Vorfallsmeldung 72h | A.5.24-A.5.28 | Erweiterte Verfahren für Zeitanforderungen |
| Lieferkettensicherheit | A.5.19-A.5.22 | Verstärkte Due Diligence |
| Geschäftskontinuität | A.5.29-A.5.30 | Testfrequenz nach NIS2UmsuCG |
| Führungskräfteschulung | A.6.3 | Spezifische Inhalte für Geschäftsleitung |
Pflege der SoA
- Jährliche Überprüfung Gehen Sie die gesamte SoA mindestens jährlich durch. Stimmt der Kontrollstatus? Hat sich das Unternehmen verändert? Gibt es neue Risiken?
- Bei Änderungen aktualisieren Neue Geschäftsbereiche, neue Systeme, Organisationsänderungen — alle können SoA beeinflussen. Proaktiv aktualisieren.
- Mit internem Audit verknüpfen Internes Audit soll verifizieren, dass SoA die Realität widerspiegelt. Abweichungen führen zu Aktualisierungen.
- Versionskontrolle Verfolgen Sie Änderungen. Wer hat was und warum geändert? Speichern Sie Historie.
Checkliste für SoA
Vor Zertifizierungsaudit:
- Alle 93 Anhang A-Kontrollen aufgeführt
- Anwendbarkeit für jede Kontrolle angegeben
- Begründung für jede Entscheidung dokumentiert
- Ausnahmen haben gültige Gründe
- Implementierungsstatus aktualisiert
- Verweise auf Richtlinien/Verfahren vorhanden
- Verbindung zur Risikobewertung klar
- Von Geschäftsleitung genehmigt
- Versionskontrolle etabliert
- Datum der letzten Aktualisierung angegeben
So kann Securapilot helfen
Securapilot vereinfacht SoA-Management:
- Vorgefertigte Struktur — Alle 93 Kontrollen vordefiniert
- Begründungsvorlagen — Beispiele und Leitfaden
- Statusverfolgung — Implementierungsfortschritt sehen
- Dokumentenverknüpfung — Mit Richtlinien und Verfahren verknüpfen
- Versionshistorie — Vollständige Nachverfolgbarkeit von Änderungen
- Auditberichte — Export für externe Audits
Demo buchen und sehen Sie, wie wir Ihre SoA-Arbeit vereinfachen.
Häufig gestellte Fragen
Müssen alle 93 Kontrollen in der SoA enthalten sein?
Ja, alle 93 Kontrollen in Anhang A müssen in der SoA aufgeführt werden. Für jede Kontrolle müssen Sie angeben, ob sie anwendbar ist oder nicht, und die Entscheidung begründen.
Kann ich Kontrollen ausschließen?
Ja, aber jede Ausnahme muss begründet werden. Gültige Gründe sind z.B. dass das Risiko nicht existiert (z.B. keine mobilen Arbeitsplätze) oder dass es durch eine andere Kontrolle abgedeckt wird. 'Wir haben kein Budget' ist keine gültige Begründung.
Wie oft sollte die SoA aktualisiert werden?
Die SoA sollte ein lebendiges Dokument sein, das bei Änderungen im Unternehmen, der Risikolage oder der Kontrollimplementierung aktualisiert wird. Mindestens jährlich sollte sie überprüft werden.
Was prüft der Auditor bei der SoA?
Der Auditor kontrolliert: 1) Dass alle Kontrollen aufgeführt sind, 2) Dass die Begründungen nachvollziehbar sind, 3) Dass anwendbare Kontrollen tatsächlich implementiert sind, 4) Die Verbindung zur Risikobewertung.
