Das Statement of Applicability (SoA) ist nach Klausel 6.1.3 d) der ISO/IEC 27001:2022 ein Pflicht-Dokument und das zentrale Bindeglied zwischen Risikobehandlung und implementierten Controls. Es listet alle 93 Annex-A-Controls auf, dokumentiert je Control die Anwendbarkeit, die Begründung der Auswahl oder des Ausschlusses und den Umsetzungsstatus. Ohne SoA gibt es keine Zertifizierung – und ein schlecht strukturiertes SoA ist in Stage 1 die häufigste Ursache für eine Verschiebung des Stage-2-Audits.

Dieser Beitrag behandelt:

• Die normativen Anforderungen an das SoA aus Klausel 6.1.3 d)
• Die empfohlenen Spalten und ihre inhaltlichen Anforderungen
• Die Verknüpfung von Risikobehandlungsplan und SoA
• Mapping der Behandlung auf die vier Themen A.5 (organisatorisch), A.6 (personell), A.7 (physisch), A.8 (technologisch)
• Häufige Audit-Befunde und wie Sie diese vermeiden
• Eine bewährte SoA-Vorlage als Ausgangspunkt

Adressaten sind ISMS-Manager, CISOs und Berater, die das SoA aufbauen oder überarbeiten. Wir zeigen die Norm-Interpretation, wie Schweizer und EU-Auditoren das Dokument lesen, und konkrete Formulierungsbeispiele für Begründungen.

Klausel 6.1.3 d) der ISO 27001:2022 verlangt explizit ein Statement of Applicability, das folgende Inhalte enthält:

1. die notwendigen Controls (entsprechend dem Risikobehandlungsplan),
2. die Begründung ihrer Einbeziehung,
3. ob sie umgesetzt sind oder nicht,
4. die Begründung des Ausschlusses von Controls aus Annex A.

Annex A der ISO 27001:2022 enthält 93 Controls in vier Gruppen: A.5 Organizational Controls (37 Controls), A.6 People Controls (8 Controls), A.7 Physical Controls (14 Controls), A.8 Technological Controls (34 Controls). Jeder dieser 93 Controls muss im SoA adressiert werden – entweder als anwendbar mit Implementierungsbeschreibung oder als ausgeschlossen mit substanzieller Begründung.

Wichtige Klarstellung: Ein Control darf nur dann als nicht anwendbar deklariert werden, wenn er für die Organisation keinerlei Risiko adressiert. Wer A.8.24 (Cryptography) ausschliesst mit der Begründung wir haben keine Kryptografie im Einsatz, muss erklären, wie alle Datenflüsse (TLS, Datenbankverschlüsselung, Backup, Authentifizierung) ohne Kryptografie auskommen. In der Regel ist das nicht plausibel und führt zu einer Minor Nonconformity. Eine seriöse Begründung lautet eher: Control A.7.13 (Equipment maintenance) ist nicht anwendbar, weil alle IT-Endgeräte vollumfänglich durch den Cloud-Workplace-Anbieter geleast und gewartet werden – die Verantwortung liegt vertraglich beim Anbieter.

Die ISO verlangt keine spezifische Tabellenform, aber eine praxiserprobte SoA-Struktur enthält folgende Spalten:

1. Control-ID (z. B. A.5.7, A.8.24)
2. Control-Titel (laut Annex A)
3. Anwendbar? (Ja / Nein)
4. Begründung der Auswahl / des Ausschlusses (substanzielle Erklärung, kein blosses n/a)
5. Status der Umsetzung (umgesetzt / teilweise umgesetzt / geplant; mit Zieldatum für geplant)
6. Verantwortlicher / Owner (Funktion oder Person)
7. Implementierungsbeschreibung (Verweis auf Policy, Verfahren, technische Massnahme)
8. Verifikations-Evidence (Dokument-ID, Log, Audit-Ergebnis)
9. Verknüpfte Risiken (IDs aus dem Risiko-Inventar)
10. Letztes Review (Datum, Auditor)
11. Hinweise / Kommentare (z. B. compensatorische Massnahmen, geplante Verbesserung)

Optional, aber empfohlen für regulierte Branchen: zusätzliche Spalten für regulatorische Bezüge (z. B. FINMA-Rundschreiben 2023/1, NIS2 Art. 21, DSG Art. 8 / DSV Art. 3, BAIT, BAFin). Das vereinfacht spätere Aufsichts-Audits oder Kundenaudits, die sich auf konkrete regulatorische Normen beziehen.

Vermeiden Sie eine SoA, die nur aus drei Spalten besteht (Anwendbar – Ja/Nein – Verweis auf Policy). Sie ist zwar normativ minimal konform, aber für externe Audits, Kundenaudits und Re-Zertifizierungen nicht hilfreich – und führt im Surveillance zu wiederholten Rückfragen.

Das SoA ist nicht freistehend; es muss die Logik des Risikobehandlungsplans (Risk Treatment Plan) widerspiegeln. Klausel 6.1.3 verlangt, dass die ausgewählten Controls die identifizierten Risiken adressieren – das SoA ist der Beweis dafür.

Empfohlenes Vorgehen:

1. Risiko-Inventar erstellen: Jeder Risiko-Eintrag erhält eine ID (R-001, R-002, ...), Beschreibung, Eintrittswahrscheinlichkeit, Schadenausmass, Risikoinhaber.
2. Risikobehandlung wählen: Pro Risiko eine der vier Optionen aus ISO/IEC 27005: Risikomodifikation (Controls anwenden), Risikoteilung (Versicherung, Outsourcing), Risikoakzeptanz (formal dokumentiert), Risikoumgehung (Aktivität einstellen).
3. Controls zuordnen: Bei Risikomodifikation – welche Annex-A-Controls (und welche zusätzlichen, ggf. nicht aus Annex A stammenden) adressieren das Risiko?
4. SoA aktualisieren: Jede Control-Auswahl wird im SoA in der Spalte Verknüpfte Risiken auf die R-IDs verwiesen.
5. Akzeptierte Risiken dokumentieren: Wenn ein Risiko akzeptiert wird, muss das durch den Risikoinhaber schriftlich genehmigt sein (Klausel 6.1.3 f).

Häufiger Fehler: Das SoA listet alle Controls als anwendbar auf, ohne dass die Risiko-IDs hinterlegt sind. Der externe Auditor stellt dann die Frage, welches Risiko A.5.34 (Privacy and protection of PII) in Ihrer Organisation konkret adressiert. Wer das nicht beantworten kann, hat den Linkage-Beweis nicht erbracht – Minor NC zu Klausel 6.1.3.

Die 2022er-Version hat Annex A von 14 Domains (A.5–A.18 in der 2013er-Version) auf vier Themen reduziert. Das hilft, die Controls nach Verantwortlichkeit zu gruppieren und die SoA-Pflege auf passende Owner zu verteilen.

A.5 Organizational Controls (37 Controls) – Owner: ISMS-Manager, Geschäftsleitung, Legal:

Politiken, Rollen, Lieferantenmanagement, Vorfallsmanagement, Continuity, Compliance. Beispiele: A.5.1 (Policies for information security), A.5.7 (Threat intelligence – NEU), A.5.23 (Information security for use of cloud services – NEU), A.5.30 (ICT readiness for business continuity – NEU).

A.6 People Controls (8 Controls) – Owner: HR, ISMS-Manager:

Screening, Beschäftigungsbedingungen, Awareness, Disziplinarverfahren, Remote-Working (NEU als A.6.7). Compactest aller vier Themen; oft unterschätzt im Audit, weil HR-Owner nicht im Audit-Programm vertreten ist.

A.7 Physical Controls (14 Controls) – Owner: Facility-Management, IT-Operations:

Perimeterschutz, Zutritt, Schreibtisch- und Bildschirm-Politik, Lieferanten-Zonen, Wartung. Bei Cloud-only-Unternehmen sind viele A.7-Controls auf den Office-Standort oder den Cloud-Provider-Vertrag zu reduzieren.

A.8 Technological Controls (34 Controls) – Owner: IT-Operations, Engineering, SecOps:

Endpoint-Sicherheit, Zugriffsmanagement, Kryptografie, Logging, Netzwerk, Application Security, Backup. Enthält die neuen Controls A.8.9 (Configuration management), A.8.10 (Information deletion), A.8.11 (Data masking), A.8.12 (Data leakage prevention), A.8.16 (Monitoring activities), A.8.22 (Web filtering), A.8.23 (Secure coding), A.8.28 (Secure coding ergänzend), A.8.29 (Security testing in development and acceptance).

Wir empfehlen, das SoA technisch nach den vier Themen zu blattieren (z. B. vier Tabs in einer Excel) und je Tab einen Owner zuzuweisen. Das beschleunigt die jährliche SoA-Review.

In der Audit-Praxis treten am SoA wiederkehrende Schwächen auf. Die folgenden sieben Befunde sehen wir am häufigsten – mit jeweiliger Empfehlung zur Vermeidung.

• Generische Begründungen: Floskeln wie Best Practice oder Industry Standard ohne konkreten Risiko-Bezug. Empfehlung: Verweisen Sie auf die R-IDs aus dem Risiko-Inventar.
• Ausschluss ohne Begründung: A.7.X ist als nicht anwendbar markiert mit dem Hinweis n/a. Empfehlung: Substanz erklären (z. B. vollständige Cloud-Workplace-Auslagerung an Microsoft 365 mit dokumentiertem Subprocessing-Vertrag).
• SoA und Implementierung divergieren: Status umgesetzt, aber Auditor findet keine technische Belege. Empfehlung: Verifikations-Spalte mit Dokument-ID füllen.
• Veraltetes SoA: Letztes Update vor 18 Monaten. Empfehlung: Mindestens jährliche Pflicht-Review, getriggert durch Management Review oder bei wesentlichen Änderungen.
• SoA und Risikobehandlungsplan inkonsistent: Risiken mit Behandlung Modifikation verweisen auf Controls, die im SoA als ausgeschlossen markiert sind. Empfehlung: Cross-Reference bei jeder Aktualisierung beider Dokumente.
• Owner fehlt: Ohne klare Owner pro Control kann der Implementierungsstatus nicht ohne Rückfrage bestätigt werden. Empfehlung: Funktion (nicht Person) als Owner – das überlebt Personalwechsel.
• Keine Verifikations-Evidence: Implementierungsbeschreibung ohne Beleg-Verweis. Empfehlung: Pro umgesetztem Control mindestens ein verifizierbarer Beleg (Policy-Link, Konfigurations-Snapshot, Audit-Bericht).

Bei einer Major Nonconformity zur SoA-Pflicht (z. B. komplettes Fehlen oder Auslassung mehrerer Annex-A-Controls) wird die Zertifizierung blockiert. Bei systematischen Minor NCs droht die Eskalation zur Major im Surveillance.

Wir empfehlen, das SoA als strukturiertes Excel oder als Datenbank-View aus einer ISMS-Plattform zu pflegen – nicht als Word-Dokument. Die Tabellenform erlaubt Filterung, Sortierung und automatisierte Reports im Audit.

Beispiel-Zeile für A.5.7 (Threat intelligence) in einem typischen B2B-SaaS-KMU:

• Control-ID: A.5.7
• Control-Titel: Threat intelligence
• Anwendbar: Ja
• Begründung: Mehrere Risiken adressieren externe Bedrohungen (R-007 Phishing-Angriffe, R-012 Supply-Chain-Kompromittierung); regelmässige Bedrohungslage-Bewertung erforderlich.
• Status: Umgesetzt
• Owner: CISO
• Implementierung: Abonnement BACS-CSIRT-Bulletins, monatliches Threat-Intelligence-Briefing aus kommerzieller Quelle (Recorded Future), Quartalsweise Threat-Modeling-Workshop, Integration in das vierteljährliche Management Review.
• Verifikations-Evidence: Doc-ID POL-027 (Threat Intelligence Policy), Schulungsnachweise Q1–Q4, BACS-Subscription-Bestätigung.
• Verknüpfte Risiken: R-007, R-012, R-024
• Letztes Review: 15.04.2026 durch M. Grob (SIDD)
• Kommentar: Quelle Recorded Future läuft 2027 aus – Alternative evaluieren bis Q3/2026.

Eine solche Zeile vermittelt dem externen Auditor in 30 Sekunden, dass das Control gelebt wird, durch wen, mit welcher Evidenz und mit welchem Vorausblick. Das ist der Standard, an dem wir uns orientieren – nicht die minimalistische Ja / Verweis-auf-Policy-Variante.

SIDD erstellt SoAs für Schweizer Unternehmen schlüsselfertig und pflegt sie über den dreijährigen Zertifizierungszyklus. Im Rahmen unseres ISMS / ISO 27001-Implementierungsmandats bauen wir das Risiko-Inventar auf, leiten den Risikobehandlungsplan ab und erstellen ein SoA, das den 93 Annex-A-Controls vollständig Rechnung trägt. Wir stellen eine bewährte SoA-Vorlage zur Verfügung und passen sie an Ihren Branchen-Kontext an (FinTech, MedTech, Industrie, Öffentliche Hand, B2B-SaaS).

Für die laufende Pflege empfehlen wir die Priverion-Plattform: Sie verbindet Risiko-Register, SoA, Massnahmenkatalog und Audit-Trail in einem Datenmodell, so dass Inkonsistenzen automatisch erkannt und über das Dashboard visualisiert werden. Bei vorhandenem ISMS prüfen wir Ihr bestehendes SoA gegen die typischen Audit-Befunde und liefern in einer 5-tägigen Engagement-Phase einen priorisierten Verbesserungsplan. Für ein externes CISO-Mandat, das die SoA-Verantwortung dauerhaft trägt, kombinieren Sie unser CISO / ISB-Angebot.

Senden Sie uns Ihr aktuelles SoA (oder eine Beschreibung des Status) über das Kontaktformular – wir liefern innert 48 Stunden eine Ersteinschätzung. Für ein verbindliches Mandat fordern Sie eine Offerte an.