SoA - Statement of Applicability
Erklärung zur Anwendbarkeit der Maßnahmen aus ISO 27001 Anhang A
Lesezeit: 6 Min.
Was bedeutet SoA?
Das Statement of Applicability ist das Dokument, in dem eine Organisation für jeden Kontrollpunkt aus ISO/IEC 27001 Anhang A begründet, ob er angewendet wird oder nicht.
Das Statement of Applicability (SoA), auf Deutsch Erklärung zur Anwendbarkeit, ist neben dem Risikoregister das zweite zwingend vorgeschriebene Dokument eines ISO/IEC-27001-ISMS. ISO/IEC 27001:2022 Kap. 6.1.3 d) verlangt, dass eine Organisation für jeden der 93 Referenz-Controls aus Anhang A festhält: ob er als anwendbar eingestuft wird, eine Begründung für Einschluss oder Ausschluss, und, bei anwendbaren Controls, den aktuellen Umsetzungsstatus. Auditoren arbeiten das SoA bei Zertifizierungsaudits typischerweise Zeile für Zeile durch. Es ist faktisch das Inhaltsverzeichnis des gesamten Prüfprozesses.
Aufbau: 93 Controls in vier Themen
Anhang A der ISO/IEC 27001:2022 gliedert sich in vier Themen: A.5 Organisatorische Maßnahmen (37 Controls), A.6 Personelle Maßnahmen (8 Controls), A.7 Physische Maßnahmen (14 Controls) und A.8 Technologische Maßnahmen (34 Controls). Für jeden einzelnen Control verlangt das SoA vier Angaben: Anwendbarkeit (ja/nein), Begründung, Verweis auf die umsetzende Richtlinie oder Maßnahme, und, falls anwendbar, den Umsetzungsstatus (umgesetzt, teilweise, geplant, nicht umgesetzt).
Warum Ausschlüsse begründet werden müssen
Ein Control darf im SoA nur dann als nicht anwendbar markiert werden, wenn dafür eine nachvollziehbare Begründung existiert, typischerweise, weil kein zugehöriges Risiko im Risikoregister vorliegt oder die betroffene Tätigkeit nicht stattfindet. Typische, in der Praxis anerkannte Ausschlüsse im Mittelstand sind etwa A.8.30 (ausgelagerte Entwicklung) bei rein intern entwickelter Software oder Teile von A.7 (physische Maßnahmen) bei vollständig Cloud-basierten Organisationen ohne eigene Serverräume. Ein unbegründeter Ausschluss ist im Audit ein klassischer Findungspunkt.
SoA im Zertifizierungsaudit
Auditoren nutzen das SoA als Leitfaden durch die gesamte Prüfung: Jeder als „anwendbar" markierte Control wird auf tatsächliche Umsetzung geprüft, jeder Ausschluss auf Plausibilität. Das SoA muss deshalb konsistent mit Risikoregister, Richtlinien und Nachweisdokumenten gepflegt werden und bei jeder relevanten Änderung (neues Risiko, neuer Dienstleister, neue Technologie) aktualisiert werden, nicht nur einmalig zur Zertifizierung.
Die vier Control-Themen im Überblick
A.5 Organisatorische Maßnahmen umfasst mit 37 Controls den größten Block: Richtlinien, Rollen und Verantwortlichkeiten, Lieferantenbeziehungen, Umgang mit Informationssicherheitsvorfällen, Klassifizierung von Informationen und Zugangssteuerung auf konzeptioneller Ebene. A.6 Personelle Maßnahmen regelt mit 8 Controls den Lebenszyklus von Beschäftigten: Überprüfung vor der Einstellung, Vertragsklauseln, Sensibilisierung und Schulung, Disziplinarverfahren sowie Pflichten nach dem Ausscheiden. A.7 Physische Maßnahmen deckt mit 14 Controls Gebäude, Zutrittssteuerung, Absicherung von Büros und Technikräumen, Versorgungseinrichtungen, Verkabelung, Gerätewartung und die sichere Entsorgung von Datenträgern ab. A.8 Technologische Maßnahmen enthält 34 Controls zu Endgeräten, Zugriffsrechten, Kryptografie, Protokollierung, Netzwerksicherheit, sicherer Entwicklung und Schutz vor Schadsoftware. Die 2022er-Fassung hat die früheren 114 Controls auf 93 zusammengefasst und dabei elf neue aufgenommen, darunter Threat Intelligence (A.5.7), Informationssicherheit für Cloud-Dienste (A.5.23), Konfigurationsmanagement (A.8.9) und Datenmaskierung (A.8.11).
Was eine gute SoA-Zeile enthält
Ein häufiger Fehler ist die reine Ja-Nein-Tabelle ohne Substanz. Prüffähig wird eine Zeile erst durch vier Angaben.
Anwendbarkeit: ja oder nein, ohne Zwischenstufen.
Begründung: der Grund für Einschluss oder Ausschluss, idealerweise mit Verweis auf die Risiko-ID im Risikoregister, aus der sich die Anwendbarkeit ergibt.
Umsetzung: der Verweis auf das Dokument oder die technische Maßnahme, die den Control tatsächlich erfüllt, etwa „Richtlinie Zugriffssteuerung, Abschnitt 4" oder „MFA-Erzwingung im Identity Provider".
Status: umgesetzt, teilweise umgesetzt, geplant oder nicht umgesetzt, bei geplanten Maßnahmen mit Termin. Beispiel für A.8.5 (Sichere Authentifizierung): anwendbar ja; Begründung Risiko R-014, Kontoübernahme über gestohlene Zugangsdaten; Umsetzung MFA-Pflicht für alle Konten, dokumentiert in der Zugriffsrichtlinie Abschnitt 3.2; Status umgesetzt seit 09/2026.
Zulässige und unzulässige Ausschlüsse
Ein Ausschluss ist zulässig, wenn die betroffene Tätigkeit im Unternehmen schlicht nicht stattfindet oder kein zugehöriges Risiko besteht.
Anerkannt sind im Mittelstand typischerweise: A.8.30 (ausgelagerte Entwicklung), wenn ausschließlich intern oder gar nicht entwickelt wird; Teile von A.7, wenn keine eigenen Serverräume betrieben werden; A.5.7 (Threat Intelligence) dagegen fast nie, weil eine Form der Bedrohungsbeobachtung praktisch immer angemessen ist. Nicht zulässig sind Ausschlüsse mit wirtschaftlicher Begründung. „Zu teuer", „zu aufwendig" oder „dafür haben wir kein Personal" sind keine Begründungen für Nicht-Anwendbarkeit, sie beschreiben ein akzeptiertes Risiko.
Der richtige Weg ist dann: Control als anwendbar markieren, Status „nicht umgesetzt", und das verbleibende Risiko im Risikoregister als bewusst akzeptiert mit Freigabe der Leitung führen. Diese Unterscheidung zwischen „nicht anwendbar" und „anwendbar, aber nicht umgesetzt" ist der am häufigsten übersehene Punkt im gesamten SoA.
SoA erstellen: typischer Ablauf
Der Ablauf folgt einer festen Reihenfolge, die sich aus der Norm ergibt. Zuerst wird der Geltungsbereich des ISMS festgelegt, denn er entscheidet, welche Controls überhaupt greifen. Dann folgt die Risikobewertung nach Kap. 6.1.2 mit dem Risikoregister als Ergebnis. Erst danach lässt sich die Anwendbarkeit begründen, nicht umgekehrt. Anschließend wird für jeden der 93 Controls die Anwendbarkeit entschieden und mit Verweis auf Risiken oder gesetzliche Anforderungen begründet. Für anwendbare Controls wird die umsetzende Maßnahme benannt und der Status erfasst. Zuletzt gibt die Leitung das SoA frei und es erhält eine Versionsnummer mit Datum. Für die Erstversion sind ein bis drei Arbeitstage realistisch, wenn Geltungsbereich und Risikoregister bereits stehen. Danach ist das SoA ein lebendes Dokument, das bei jedem neuen Risiko, jedem neuen Dienstleister und jeder wesentlichen technischen Änderung fortgeschrieben wird.
SoA in der ISO 42001 für KI-Managementsysteme
Die ISO/IEC 42001 für KI-Managementsysteme (AIMS) übernimmt die Systematik, arbeitet aber mit einem eigenen Anhang A aus 38 Controls, die sich auf KI-spezifische Themen beziehen: Datenqualität, Transparenz gegenüber Betroffenen, menschliche Aufsicht, Lebenszyklus von KI-Systemen. Wer bereits ein ISO-27001-SoA pflegt, kann die Vorgehensweise unverändert übernehmen, muss aber ein zweites, getrenntes SoA führen. Die beiden Dokumente werden nicht zusammengelegt, weil sie unterschiedliche Anhänge und unterschiedliche Geltungsbereiche haben.
Auch bekannt als
Statement of Applicability · Anwendbarkeitserklärung · Erklärung zur Anwendbarkeit · SoA ISO 27001
Teil des Themenbereichs: Compliance & Regulierung
- TARA - Threat Analysis and Risk Assessment
- NIS-2 - Network and Information Security Directive 2
- IT-Notfallmanagement - IT Incident Response
- CRA - Cyber Resilience Act
- IEC 62443 - Industrial Automation and Control Systems Security
- Risikoregister - Risk Register
- Risikomatrix - Risk Matrix
- Annex A - Annex A (ISO/IEC 27001:2022)
- BSI TR-03183 - Technische Richtlinie TR-03183: Cyber Resilience Requirements for Manufacturers and Products
- BSI TR-03185 - Technische Richtlinie TR-03185: Sicherer Software-Lebenszyklus
- EN 40000 - Horizontale Normenreihe EN 40000-1-x zum Cyber Resilience Act
- Harmonisierte Norm - Harmonisierte europäische Norm mit Konformitätsvermutung
- CE-Kennzeichnung - CE-Kennzeichnung nach dem Cyber Resilience Act
- Konformitätsbewertung - Konformitätsbewertungsverfahren nach Art. 32 des Cyber Resilience Act
- Benannte Stelle - Notifizierte Konformitätsbewertungsstelle
- ISO 42001 - ISO/IEC 42001:2023 - AI Management System
- Fördermittel IT-Sicherheit - öffentliche Zuschüsse, Kredite und Beratungsförderung für IT-Sicherheitsmaßnahmen
Verwandte Begriffe
Quellen
Zuletzt aktualisiert: 2026-08-02
Häufige Fragen zu SoA
Was ist ein Statement of Applicability (SoA)?
Das Statement of Applicability, auf Deutsch Erklärung zur Anwendbarkeit, ist das Dokument, in dem eine Organisation für jeden der 93 Controls aus Anhang A der ISO/IEC 27001:2022 festhält, ob er anwendbar ist, warum, wie er umgesetzt wird und wie weit die Umsetzung fortgeschritten ist. Es ist nach Kap. 6.1.3 d) verpflichtend und dient Auditoren als Leitfaden durch die gesamte Prüfung.
Wie heißt das Statement of Applicability auf Deutsch?
Die gebräuchliche deutsche Bezeichnung ist „Erklärung zur Anwendbarkeit", häufig verkürzt zu „Anwendbarkeitserklärung". In der Praxis wird auch im deutschsprachigen Raum überwiegend die englische Abkürzung SoA verwendet, weil Zertifizierungsstellen und Normtexte sie durchgängig nutzen.
Muss ich wirklich alle 93 Controls im SoA bewerten?
Ja. Die Norm verlangt für jeden einzelnen Control aus Anhang A eine Entscheidung über die Anwendbarkeit samt Begründung. Nicht anwendbare Controls dürfen nicht weggelassen, sondern müssen mit Begründung als ausgeschlossen dokumentiert werden. Ein SoA mit weniger als 93 Zeilen ist im Audit unvollständig.
Darf ich Controls aus Kostengründen ausschließen?
Nein. Wirtschaftliche Gründe rechtfertigen keine Nicht-Anwendbarkeit. Ist ein Control grundsätzlich einschlägig, wird er als anwendbar geführt und der Status auf „nicht umgesetzt" gesetzt; das verbleibende Risiko gehört dann als bewusst akzeptiert mit dokumentierter Freigabe der Leitung ins Risikoregister. Die Verwechslung von „nicht anwendbar" und „anwendbar, aber nicht umgesetzt" ist einer der häufigsten Auditbefunde.
Was ist der Unterschied zwischen SoA und Risikoregister?
Das Risikoregister sammelt die identifizierten Risiken mit Bewertung, Behandlung und Verantwortlichen. Das SoA begründet, welche der 93 Annex-A-Controls anwendbar sind und wie sie umgesetzt werden. Das Risikoregister kommt zuerst: Aus ihm ergibt sich die Begründung für die Anwendbarkeit im SoA. Beide Dokumente müssen widerspruchsfrei zueinander sein.
Wie viele Controls hat Anhang A der ISO 27001:2022?
93 Controls in vier Themen: A.5 Organisatorische Maßnahmen (37), A.6 Personelle Maßnahmen (8), A.7 Physische Maßnahmen (14) und A.8 Technologische Maßnahmen (34). Die Fassung von 2022 hat die vorher 114 Controls zusammengefasst und elf neue ergänzt, darunter Threat Intelligence, Cloud-Sicherheit und Konfigurationsmanagement.
Wie oft muss das SoA aktualisiert werden?
Bei jeder Änderung, die die Anwendbarkeit oder Umsetzung eines Controls berührt: neue Risiken, neue Dienstleister, neue Technologien, organisatorische Veränderungen. Zusätzlich empfiehlt sich eine vollständige Durchsicht einmal jährlich im Rahmen des Management-Reviews. Ein SoA, das seit der Zertifizierung unverändert ist, fällt im Überwachungsaudit auf.