Statement of Applicability (SoA)

Kurzdefinition

Das Statement of Applicability (SoA), deutsch „Erklärung zur Anwendbarkeit“, ist das zentrale ISMS-Dokument, das alle betrachteten Sicherheitsmaßnahmen (engl. controls, im Folgenden „Maßnahmen“) auflistet, deren Anwendbarkeit begründet, den Umsetzungsstatus festhält und auf Nachweise verweist. Es verknüpft Risikoergebnisse mit konkreter Maßnahmenwahl und schafft Audit-Transparenz.

Einordnung auf einen Blick

Detaillierte Erklärung

Das SoA bündelt in strukturierter Form die Entscheidung, welche Sicherheitsmaßnahmen eine Organisation im Rahmen ihres ISMS nutzt, welche nicht und aus welchen Gründen. Es basiert auf der Risikobewertung, rechtlichen/vertraglichen Anforderungen sowie Geschäftszielen und macht diese Bezüge sichtbar. Damit wird das SoA zur „Schaltstelle“ zwischen Risiko, Governance und operativer Umsetzung.

Inhaltlich listet das SoA typischerweise den kompletten Maßnahmenkatalog (z. B. Annex A) sowie gegebenenfalls zusätzliche unternehmensspezifische oder regulatorisch geforderte Maßnahmen auf. Für jede Maßnahme werden Anwendbarkeit („anwendbar“/„nicht anwendbar“), Begründung, Verantwortliche, Umsetzungsstatus (z. B. geplant, umgesetzt, in Überprüfung), sowie Referenzen auf Richtlinien, Prozesse, technische Konfigurationen und Prüf-Evidenzen dokumentiert.

Die Begründung ist der Kern: Sie sollte kurz, risikobasiert und prüffest sein. „Nicht anwendbar“ ist nur dann belastbar, wenn Scope, Architektur und Risiken dies herleiten lassen (z. B. keine physischen Standorte im Scope → bestimmte physische Maßnahmen plausibel nicht anwendbar). Ressourcenknappheit allein ist keine tragfähige Begründung.

Organisatorisch fungiert das SoA als Steuerungsinstrument. Es hilft, Verantwortlichkeiten („Maßnahmen-Owner“) zuzuweisen, Prioritäten im Umsetzungsplan zu setzen und Fortschritt nachzuhalten. In Audits dient es als Einstiegspunkt: Auditoren lesen im SoA, wählen Stichproben und lassen sich die hinterlegten Nachweise zeigen.

Mit ISO/IEC 27001:2022 wurde der Annex-A-Maßnahmenkatalog strukturell überarbeitet. Für das SoA ändert sich dadurch vor allem die Zuordnung der Maßnahmen und die Terminologie – die Logik bleibt gleich: risikobasierte Auswahl, klare Begründung, Status, Verantwortliche, Evidenzen.

Relevanz für ISO 27001

Die Norm fordert eine systematische Planung der Risikobehandlung und die Auswahl geeigneter Maßnahmen. Das SoA dokumentiert diese Auswahl, begründet Ausnahmen, referenziert rechtliche/vertragliche Anforderungen und verknüpft sie mit den Ergebnissen der Risikoanalyse. In Audits dient das SoA als primärer Nachweis, dass die Maßnahmenwahl vollständig, konsistent und risikobezogen ist. Zudem unterstützt es die laufende Wirksamkeitsbewertung (KPIs, interne Audits, Managementbewertung), indem es Status und Verantwortlichkeiten transparent macht.

Umsetzung in der Praxis

Schritt-für-Schritt-Vorgehen

1. Scope und Grundlagen klären: Geltungsbereich, Unternehmenskontext, interessierte Parteien und Anforderungen festhalten; Risikoakzeptanzkriterien definieren.
2. Maßnahmenkatalog festlegen: Annex A als Basiskatalog verwenden; zusätzliche regulatorische/vertragliche oder branchenspezifische Maßnahmen ergänzen.
3. SoA-Struktur/Template definieren: Spalten z. B. ID, Maßnahme, Anwendbarkeit, Begründung, Owner, Status, Evidenzen, Referenzen (Richtlinien, Verfahren), letzte Prüfung, Nächste Schritte.
4. Risikoergebnisse zuordnen: Für jede Maßnahme die relevanten Risiken/Anforderungen referenzieren; Auswahl risikobasiert begründen.
5. Anwendbarkeit entscheiden: „Anwendbar“ bei Risiko-, Compliance- oder Geschäftsbedarf; „nicht anwendbar“ nur bei schlüssiger Herleitung (z. B. kein On-Prem-Betrieb → bestimmte physische Themen).
6. Begründungen prägnant formulieren: Max. 2–3 Sätze; Verweise auf Risiko-IDs, Verträge, Gesetze oder Architekturdiagramme.
7. Status & Verantwortliche pflegen: Umsetzungsstand realistisch eintragen; Maßnahmen-Owner benennen; Abhängigkeiten und Fristen dokumentieren.
8. Evidenzen verlinken: Auf konkrete Artefakte verweisen (Policy-Version, Prozess-Dokument, Ticket, Change-Request, Screenshot, Konfig-Export, Log-Ausschnitt).
9. Freigabe & Versionierung etablieren: Vier-Augen-Prinzip, Änderungsprotokoll, periodischer Review (mind. jährlich oder anlassbezogen, z. B. größere Änderungen, neue Systeme).

Mindestumfang – Checkliste

• Vollständige Liste aller betrachteten Maßnahmen (inkl. Ergänzungen außerhalb Annex A).
• Für jede Maßnahme: klare Anwendbarkeit (ja/nein) mit nachvollziehbarer Begründung.
• Zuordnung von Owner, Umsetzungsstatus und Zielterminen.
• Referenzen auf Risiko-IDs und relevante Anforderungen.
• Verweise auf konkrete Evidenzen/Artefakte.
• Versionierung, Freigabe, Änderungsprotokoll.
• Geplanter Review-Zyklus und Trigger für anlassbezogene Aktualisierungen.

Beispiel aus der Praxis

Ausgangslage: Ein mittelständischer SaaS-Anbieter betreibt eine Multi-Tenant-Plattform in einer Public-Cloud. Relevante Risiken betreffen Mandantentrennung, Identitäts- und Zugriffsschutz, Lieferketten sowie Betriebsstabilität.

Entscheidung/Umsetzung: Das ISMS-Team ergänzt den Annex-A-Katalog um drei unternehmensspezifische Maßnahmen (z. B. Mandantensegregation, API-Rate-Limiting, Cloud-Kostenkontrollen). Für klassische Rechenzentrums-Themen wird „nicht anwendbar“ begründet (kein eigenes RZ, geteiltes Verantwortungsmodell mit dem Hyperscaler). Zugriffe werden über zentralen IdP, MFA und Just-in-Time-Privileged-Access umgesetzt.

Dokumentation/Nachweise (im ISMS):

• SoA-Tabelle mit Anwendbarkeit, Begründungen, Ownern, Status.
• Verweise auf Risiko-IDs (R-012 „Seitentrennung“, R-021 „Überprivilegierte Konten“).
• Evidenzen: IAM-Policy-Dokumente, Cloud-Config-Exports, Change-Tickets, Pen-Test-Berichte, Monitoring-Dashboards.
• Freigabeprotokoll und jährlicher Reviewtermin im ISMS-Kalender.

Typische Audit-Fragen:

• Wie wurde bestimmt, dass bestimmte Maßnahmen nicht anwendbar sind, und welche Nachweise stützen dies?
• Wie verknüpft das SoA konkrete Risiken mit ausgewählten Maßnahmen?
• Wo sind die Evidenzen abgelegt und wie wird ihre Aktualität sichergestellt?
• Wer verantwortet die Umsetzung, und wie wird der Status überwacht?
• Wie wird das SoA bei größeren Änderungen (z. B. neuer Dienstleister) aktualisiert?

Häufige Fehler & Missverständnisse

• Fehler: SoA nur als Annex-A-Checkliste verstanden.
  Problem: Keine Risikoableitung sichtbar.
  Besser: Risiko- und Anforderungsbezug je Maßnahme referenzieren.
• Fehler: „Nicht anwendbar“ aus Ressourcengründen.
  Problem: Begründung nicht prüffest.
  Besser: Auf Scope/Architektur/Risiko stützen; Ressourcen in Zeitplan adressieren.
• Fehler: Unpräzise Begründungen („machen wir anders“).
  Problem: Auslegungsspielraum, Audit-Risiko.
  Besser: Konkret, kurz, mit Referenzen (Policy-ID, Risiko-ID).
• Fehler: Keine Verlinkung zu Evidenzen.
  Problem: Aufwändige Nachweissuche.
  Besser: Direkt auf Artefakte verweisen; Version/Ort angeben.
• Fehler: Status „umgesetzt“ ohne Wirksamkeitsnachweis.
  Problem: Schein-Compliance.
  Besser: Wirksamkeitsprüfung (KPIs, Tests, Audit-Proben) dokumentieren.
• Fehler: Kein Owner je Maßnahme.
  Problem: Verantwortungsdiffusion.
  Besser: Maßnahmen-Owner benennen, Ziele und Termine festlegen.
• Fehler: Unklare Scope-Abgrenzung.
  Problem: Falsche „Nicht-Anwendbarkeit“.
  Besser: Geltungsbereich präzise beschreiben und im SoA referenzieren.

Abgrenzung zu ähnlichen Begriffen

Abgrenzung: SoA vs. Risikobehandlungsplan

Der Risikobehandlungsplan beschreibt, wie Risiken reduziert werden (Aktionen, Termine, Ressourcen). Das SoA dokumentiert, welche Maßnahmen grundsätzlich gelten bzw. nicht gelten und warum. Beide sind verknüpft: Der Plan liefert die Umsetzungsschritte; das SoA die normative Auswahl und Begründung.

Abgrenzung: SoA vs. Annex A

Annex A ist ein Maßnahmenkatalog. Das SoA ist die organisationsspezifische Auswahl und Begründung aus diesem Katalog (plus eventuelle Ergänzungen). Annex A beschreibt Optionen; das SoA trifft Entscheidungen.

Abgrenzung: SoA vs. Richtlinien/Policies

Richtlinien definieren interne Regeln. Das SoA verweist auf diese, ersetzt sie aber nicht. Policies sind Evidenzen für umgesetzte Maßnahmen; das SoA ist der Index und die Begründungsschicht darüber.

Abgrenzung: SoA vs. Maßnahmen-/Kontrollmatrix

Eine Kontrollmatrix ordnet Prozesse, Risiken, Maßnahmen und Tests tabellarisch zu. Das SoA kann eine abgespeckte Matrix sein, hat aber den Schwerpunkt auf Anwendbarkeit und Begründung, nicht auf Prüfhandlungen.

Abgrenzung: SoA vs. Verfahrensanweisungen

Verfahrensanweisungen beschreiben Abläufe. Das SoA verweist auf sie als Nachweise. Es dokumentiert keine detaillierten Prozessschritte.

FAQ

Was bedeutet „Statement of Applicability“ im ISMS-Kontext?
Es ist das Dokument, das die Auswahl der Sicherheitsmaßnahmen festhält, die Anwendbarkeit begründet und auf Nachweise verweist. Damit wird transparent, wie aus Risiken und Anforderungen konkrete Maßnahmenentscheidungen abgeleitet werden.

Wie wird das SoA nachgewiesen oder dokumentiert?
Typisch als versionierte Tabelle/Matrix im ISMS: Maßnahme, Anwendbarkeit, Begründung, Owner, Status, Referenzen und Evidenzen. Freigaben, Änderungsprotokoll und Review-Zyklen sichern Revisionsfestigkeit.

Wie hängt das SoA mit Risiko zusammen?
Die Risikoanalyse liefert die Grundlage für die Maßnahmenwahl. Jede anwendbare oder nicht anwendbare Maßnahme wird im SoA mit Risiko-IDs bzw. Anforderungen verknüpft. So entsteht eine prüfbare Kette von Risiko → Maßnahme → Evidenz.

Wie oft sollte ein SoA aktualisiert werden?
Mindestens jährlich sowie anlassbezogen bei Änderungen an Scope, Architektur, Bedrohungslage, gesetzlichen/vertraglichen Vorgaben oder wesentlichen Risiken. Änderungen werden versioniert und freigegeben.

Wer verantwortet das SoA?
Inhaltlich: ISMS-Leitung/CISO in Zusammenarbeit mit Risiko-/Fachbereichen. Operativ: Maßnahmen-Owner pflegen Status und Evidenzen. Governance: Freigabe durch ISMS-Gremium oder Management.

Dürfen zusätzliche Maßnahmen außerhalb Annex A aufgenommen werden?
Ja. Das SoA kann und sollte regulatorische, vertragliche oder organisationsspezifische Maßnahmen ergänzen. Wichtig ist eine konsistente Struktur und gleiche Begründungs- und Nachweislogik.

Wie detailliert müssen Begründungen sein?
Kurz, präzise, risikobasiert. Zwei bis drei Sätze mit Verweisen auf Risiko-IDs, Anforderungen oder Architektur reichen in der Regel. Lange Erklärungen sind selten nötig, konkrete Referenzen hingegen schon.