Statement of Applicability (SoA) nach ISO 27001: So machst du sie pragmatisch KMU-tauglich

Die SoA (Erklärung zur Anwendbarkeit) ist eines der wichtigsten Dokumente im ISMS nach ISO 27001 – und wird in KMU oft unnötig kompliziert gemacht. Hier erfährst du verständlich, wozu du sie brauchst, was zwingend drinstehen muss und wie du sie Schritt für Schritt als „lebende“ Steuerungsliste aufsetzt.

Inhaltsübersicht

• SoA nach ISO 27001: Was ist das und wo gehört sie hin?
• Warum die SoA für KMU ein echter Hebel ist (und nicht nur fürs Audit)
• Pflichtinhalt: Das muss mindestens in die SoA
• Pragmatisches Vorgehen: So erstellst du deine SoA Schritt für Schritt
• Praxis: Zwei Mini-SoAs zum Nachbauen (IT-Dienstleister & Bäckerei)
• SoA-Tabellenvorlage zum Copy & Paste
• Fazit, Auditor-Fragen, Förderhinweise & Quellen

SoA nach ISO 27001: Was ist das und wo gehört sie hin?

Die Statement of Applicability (SoA) – auf Deutsch Erklärung zur Anwendbarkeit – ist eine normativ geforderte Kerndokumentation im ISMS. Sie hält fest, welche Maßnahmen (Controls) aus Anhang A du in deinem ISMS anwendest – und welche nicht – jeweils mit Begründung. Genau so beschreibt es auch der ISACA-Implementierungsleitfaden: In der SoA dokumentierst du begründete Entscheidungen zu Controls aus Annex A, inkl. Anwendung oder Nichtanwendung samt Begründung.

Wichtig ist: Die SoA ist keine „Liste guter Ideen“, sondern die sichtbare Brücke zwischen deiner Risikoarbeit und deiner täglichen Sicherheitsumsetzung. Sie sitzt im Ablauf dort, wo aus Analyse konkrete Steuerung wird: Risiken bewerten → Controls auswählen → SoA dokumentieren → umsetzen & nachweisen. Dass dieser Vergleich mit dem Referenzkontrollsatz in Annex A explizit dazu dient, keine erforderliche Kontrolle „aus Versehen“ auszulassen, betont auch das IAF-Dokument zur Umstellung auf ISO/IEC 27001:2022.

Seit der Revision ISO/IEC 27001:2022 ist zudem wichtig: Annex A verweist auf die Informationssicherheitskontrollen in ISO/IEC 27002:2022. Gleichzeitig wurde die Kontrollstruktur modernisiert. Laut IAF sinkt die Zahl der Controls in ISO/IEC 27002:2022 von 114 (2013) auf 93 (2022), verteilt auf 4 Bereiche; außerdem kommen 11 neue Controls hinzu, einige wurden zusammengeführt oder aktualisiert. Das ist der Grund, warum SoAs beim Umstieg zwingend aktualisiert werden mussten – und warum du heute sauber auf der 2022er-Logik arbeiten solltest.

Noch ein Praxisdetail, das viele KMU überrascht: Bei Zertifikaten wird die SoA oft sogar direkt referenziert (z. B. „As per the Statement of Applicability …“). Ein aktuelles Beispiel zeigt ein ISO/IEC 27001:2022-Zertifikat, das explizit auf eine SoA-Version und ein Datum verweist.

Warum die SoA für KMU ein echter Hebel ist (und nicht nur fürs Audit)

Viele KMU sehen die SoA zuerst als „Audit-Papier“. Das ist verständlich – aber verschenkt Potenzial. Eine gut gebaute SoA ist in der Praxis vor allem drei Dinge: Steuerungsinstrument, Transparenzliste und Arbeitsplan.

• Du bekommst Klarheit: Welche Sicherheitsmaßnahmen gelten für deinen Scope wirklich – und warum? Gerade in KMU verhindert das endlose Diskussionen nach dem Motto „Brauchen wir das wirklich?“. Der ISACA-Leitfaden betont, dass die SoA Entscheidungen zur Umsetzung oder Nichtumsetzung von Annex-A-Controls begründet dokumentiert.
• Du vermeidest Lücken: Der Vergleich mit Annex A hilft dabei, keine notwendige Kontrolle versehentlich zu vergessen – und zwingt dich, bei Bedarf Risikobehandlungspläne zu aktualisieren. Genau diesen Sinn beschreibt das IAF-Dokument ausdrücklich.
• Du priorisierst sinnvoll: Wenn du in der SoA einen Umsetzungsstatus pflegst (umgesetzt / teilweise / geplant), entsteht automatisch ein realistischer Maßnahmenfahrplan. Auch Zertifizierer beschreiben die SoA als Pflichtdokument mit Begründung, Ein- und Ausschlüssen inkl. Umsetzungsstatus.
• Du wirst auditfest – ohne Hektik: Auditoren nutzen die SoA häufig als Einstieg, weil sie schnell zeigt, wie du Risiken in Controls übersetzt. Einige Zertifizierer nennen die SoA explizit „Pflichtdokument“ und Bestandteil des Zertifikats.

Das ist der KMU-Mehrwert in einem Satz: Die SoA macht Informationssicherheit steuerbar – mit einem Format, das du wie eine Projektliste pflegen kannst.

Typischer Auditblick: Warum Auditoren die SoA lieben

Auditoren mögen die SoA, weil sie ein schneller Prüfpfad ist: Scope → Risiken → Controls → Nachweise. Ein Zertifizierer beschreibt die SoA als detaillierte Liste aller Controls aus Annex A inklusive Begründung für Ergänzungen/Ausschlüsse und Umsetzungsstatus. Und ein weiterer Beitrag aus der Zertifizierer-Praxis weist darauf hin, dass Ausschlüsse zwar möglich sind, aber der Audit oft Korrekturen fordert, wenn Ausschlüsse zu großzügig gesetzt wurden oder Aktivitäten doch (teilweise) im Verantwortungsbereich liegen.

Pflichtinhalt: Das muss mindestens in die SoA

Eine SoA darf schlicht sein – aber sie muss die Normlogik abdecken. Für KMU hat sich eine „Minimum-Plus“-Struktur bewährt: Pflichtspalten plus zwei Spalten, die dir das Leben erleichtern.

Mindestens erforderlich (praxisnah formuliert):

• Referenz auf Control (z. B. „A.5.15 Access control“ / „5.15 Zugriffskontrolle“), damit klar ist, wovon du sprichst.
• Anwendbar? (Ja/Nein) – Entscheidung, ob das Control im Scope gilt. Der ISACA-Leitfaden beschreibt genau diese Entscheidung „Anwendung oder Nichtanwendung“ samt Begründung.
• Begründung – warum du es anwendest oder ausschließt. (Risikobezug, rechtliche Anforderungen, Kundenanforderungen, Prozessrealität.)
• Umsetzungsstatus – umgesetzt / teilweise / geplant / nicht umgesetzt. Zertifizierer beschreiben die SoA explizit als Liste inkl. Umsetzungsstatus. Ein öffentliches SoA-Beispiel zeigt die Spalten „Applicable“, „Reason“ und „Status“ genau in dieser Logik (inkl. Gründen wie „Risk assessment“ oder „Legal requirement“).

Plus-Spalten, die KMU extrem helfen:

• Nachweis/Evidenz-Link (z. B. „Policy IS-01“, „Screenshot MDM“, „Ticket #4711“, „Protokoll Backup-Job“).
• Owner (wer ist verantwortlich?) – weil „niemand zuständig“ in KMU der häufigste Grund für Stillstand ist.

Wichtig, wenn du nicht 1:1 Annex A nutzt: Du darfst Controls aus anderen Quellen verwenden (z. B. BSI IT-Grundschutz, NIST). Dann brauchst du ein Mapping in der SoA, das deine gewählten Maßnahmen auf Annex A referenziert. Genau das beschreibt der ISACA-Leitfaden: In diesem Fall ist eine SoA zu erstellen, die ein Mapping von den gewählten Maßnahmen zu den Controls aus Annex A enthält.

Pragmatisches Vorgehen: So erstellst du deine SoA Schritt für Schritt

Hier ist ein Vorgehen, das in KMU funktioniert, ohne dass du ein „Compliance-Projekt“ daraus machst. Plane je nach Reifegrad 90 Minuten bis 2 Tage ein.

1. Scope & Kontext klarziehen. Bevor du Controls bewertest, muss klar sein: Welche Bereiche, Standorte, Systeme und Prozesse sind im ISMS-Scope? Wenn du hier wackelst, wird deine SoA automatisch widersprüchlich. (Tipp: Falls du gerade erst startest: Lies dazu auch eure Kontextanalyse-Beiträge auf mitsicherheit.online.)
2. Annex-A-Control-Liste als Basis in eine Tabelle ziehen. Nutze die 2022er-Struktur (93 Controls, 4 Themen). Das IAF-Dokument erklärt die Umstellung und die neue Struktur samt neuen/zusammengeführten Controls – ideal, um die richtige Ausgangsliste zu wählen.
3. Risiken und Anforderungen „daneben legen“. Für jedes relevante Risiko (z. B. Ransomware, Datenabfluss, Ausfall Kasse/ERP, Lieferantenausfall) und für jede harte Anforderung (Gesetz/Vertrag/Kunde) markierst du die Controls, die helfen.
4. Pro Control entscheiden: Ja oder Nein – und eine Begründung in einem Satz. Eine gute Begründung ist kurz und prüfbar, z. B.: „Ja, weil Zugriff auf Kundendaten im Ticketsystem (Risiko R-07)“ oder „Nein, weil kein Software-Development im Scope“.Praxiswarnung: Ein Zertifizierer-Beitrag weist darauf hin, dass Ausschlüsse zwar möglich sind, aber oft im Audit korrigiert werden müssen, wenn Aktivitäten doch (teilweise) stattfinden oder Verantwortung nicht wirklich „weg“ ist.
5. Status setzen und ehrlich bleiben. Wenn ein Control „Ja“ ist, aber noch nicht vollständig umgesetzt: Markiere es als „geplant“ oder „teilweise“ – und verknüpfe es mit deinem Risikobehandlungsplan/Maßnahmenplan. In Transition-Audits wird laut IAF u. a. genau die Aktualisierung der SoA und ggf. des Risikobehandlungsplans geprüft.
6. Nachweise verlinken. Du sparst im Audit massiv Zeit, wenn du pro Control mindestens einen Nachweis-Typ referenzierst (Dokument, Prozess, Tool, Log, Ticket).
7. Review-Rhythmus festlegen. Mindestens jährlich (Managementreview) und zusätzlich bei Änderungen: neue Software, neuer Dienstleister, neue Standorte, neue Services. Seit ISO/IEC 27001:2022 sind „Planung von Änderungen“ (6.3) und strukturierte Updates stärker im Fokus – und in der Umstellung wird die Aktualisierung der SoA explizit adressiert.

Typische Fehler, die du vermeiden solltest

• „Nicht anwendbar“, obwohl du es nur noch nicht umgesetzt hast. Das fällt im Audit schnell auf (und bringt Baustellen statt Ruhe).
• Begründungen ohne Bezug. „Weil ISO“ ist keine Begründung. „Weil Risiko R-12“ ist eine.
• Zu viele Ausschlüsse, weil „machen wir nicht“. Gerade bei IT/Änderungen/Cloud/Remote ist vieles zumindest teilweise relevant. Genau diese Überdehnung von Ausschlüssen wird in der Zertifizierer-Praxis als Audit-Risiko beschrieben.
• SoA liegt irgendwo als PDF und wird nie gepflegt. Dann ist sie tot – und verliert den KMU-Mehrwert.

Praxis: Zwei Mini-SoAs zum Nachbauen (IT-Dienstleister & Bäckerei)

Eine vollständige SoA listet alle Annex-A-Controls. Damit du das Prinzip schnell greifst, bekommst du hier zwei Mini-Ausschnitte als Beispiel. Du kannst das 1:1 in Excel übernehmen und dann auf alle Controls ausrollen.

Mini-SoA für einen kleinen IT-Dienstleister

Ausgangslage: 25 Mitarbeitende, Microsoft 365, Remote-Support, Ticketsystem, Kunden-Connects per VPN, mehrere SaaS-Dienste. Hauptwerte: Kundenzugänge, Kundendaten, Betriebskontinuität.

Control (Beispiel)	Anwendbar?	Begründung (kurz & prüfbar)	Status	Nachweis/Evidenz	Owner
A.5.15 Access control	Ja	Schützt Ticketsystem/VPN/Remote-Tools vor unberechtigtem Zugriff (Risiken: Account-Missbrauch, Datenabfluss).	Teilweise	MFA-Policy, Rollenmodell, Zugriff-Reviews	IT-Leitung
A.5.23 Information security for use of cloud services	Ja	Nutzung von M365 und SaaS erfordert definierte Prozesse für Nutzung/Exit und Sicherheitsanforderungen.	Geplant	Cloud-Richtlinie, Lieferantencheck, Exit-Checkliste	ISB
A.5.19 Information security in supplier relationships	Ja	Kritische Abhängigkeit von Cloud-/Rechenzentrum-/Tool-Anbietern (Risiko: Ausfall/Incident bei Lieferant).	Umgesetzt	Lieferantenliste, Vertragsklauseln, Review-Protokolle	Einkauf/IT
A.8.8 Management of technical vulnerabilities	Ja	Patch- und Schwachstellenmanagement reduziert Angriffsfläche (Ransomware/Exploits).	Umgesetzt	Patch-Reports, Scanner-Reports, Change-Tickets	Ops
A.8.13 Information backup	Ja	RTO/RPO für Kundensysteme und interne Plattformen (Verfügbarkeit als Kern-SLA).	Umgesetzt	Backup-Konzept, Restore-Tests	Ops

Praxis-Tipp: In vielen öffentlich zugänglichen SoAs tauchen typische Begründungen wie „Risk assessment“ oder „Legal requirement“ als Standard auf – ein Beispiel zeigt genau diese Spaltenlogik („Applicable“, „Reason“, „Status“). Genau so kannst du es pragmatisch halten: Risiko-ID oder Anforderung als Begründung, fertig.

Mini-SoA für eine Bäckerei „Knusperglück“

Story: Anna führt die Bäckerei „Knusperglück“. Die Kunden bestellen zunehmend per WhatsApp, bezahlen mit Karte, und das Kassensystem ist cloudbasiert. Der Umsatz stimmt – aber Anna merkt: Wenn die Kasse ausfällt oder Daten weg sind, steht der Betrieb. Das größte Risiko ist nicht der Wettbewerber nebenan, sondern ein IT-Ausfall oder ein Vorfall beim Dienstleister.

Control (Beispiel)	Anwendbar?	Begründung (kurz & prüfbar)	Status	Nachweis/Evidenz	Owner
A.5.15 Access control	Ja	Nur berechtigte Rollen dürfen Kasse/Backoffice bedienen (Risiko: Manipulation, Fehlbuchungen).	Umgesetzt	Kassenrollen, Benutzerliste	Inhaberin
A.5.23 Information security for use of cloud services	Ja	Kasse/Bestellsystem als Cloud-Service: Anforderungen an Anbieter & Exit/Notfall klären.	Geplant	Vertrag, SLA, Notfall-Checkliste	Inhaberin
A.5.19 Information security in supplier relationships	Ja	Abhängigkeit vom Kassenanbieter/Internetprovider (Risiko: Ausfall/Supportzeiten).	Teilweise	Lieferantenliste, Kontaktkette	Inhaberin
A.8.13 Information backup	Ja	Umsatz- und Bestelldaten müssen wiederherstellbar sein (Risiko: Betriebsstillstand).	Geplant	Backup-Plan, Restore-Test-Termin	Externer ITler
A.6.7 Remote working	Nein	Keine Remote-Arbeitsplätze im Scope (nur Filiale/Backoffice vor Ort).	n/a	Scope-Definition	Inhaberin

Du siehst: Auch im Handwerk ist die SoA sinnvoll. Nicht, weil du „wie ein Konzern“ arbeiten willst, sondern weil du mit sehr wenig Aufwand Klarheit bekommst: Was ist wirklich kritisch? und was tust du konkret dagegen?

SoA-Tabellenvorlage zum Copy & Paste

Hier ist eine einfache SoA-Struktur, die für KMU funktioniert. Du kannst sie direkt in Excel übernehmen. Wenn du ein Tool nutzt, bildet es oft genau diese Logik ab.

Spalte	Was trägst du ein?	Warum hilft dir das?
Control-ID & Titel	z. B. A.5.15 „Access control“	Auditierbare Referenz auf Annex A / ISO 27002
Anwendbar?	Ja / Nein	Klare Entscheidung statt „gefühlter“ Umsetzung
Begründung	1 Satz: Risiko-ID, Gesetz, Vertrag, Prozessrealität	Prüfbar & nachvollziehbar (das ist der Kern der SoA)
Umsetzungsstatus	Umgesetzt / Teilweise / Geplant / n/a	Du bekommst automatisch einen Maßnahmenplan (und ehrliche Transparenz)
Nachweis/Evidenz	Dokument-ID, Ticket, Screenshot, Protokoll, Link	Spart Zeit im Audit und im Alltag („Wo war das nochmal?“)
Owner	Rolle oder Name	Verantwortung ist eindeutig (KMU-Gamechanger)
Review-Datum	z. B. jährlich oder bei Änderungen	SoA bleibt lebendig, nicht „in der Schublade“

Kleiner Extra-Hack für KMU: Ergänze eine Spalte „Risiko-ID(s)“. Dann kannst du schnell zeigen, welches Risiko durch welchen Control adressiert ist. Das passt perfekt zur Logik, dass die SoA die Auswahl der Controls aus der Risikobehandlung herleitet und im Audit mit Risikobehandlungsplan zusammen betrachtet wird.

Fazit, Auditor-Fragen, Förderhinweise & Quellen

Fazit

• Die SoA ist Pflichtdokument für ISO 27001 und listet Annex-A-Controls mit Begründung und Status.
• Sie ist gleichzeitig ein KMU-taugliches Steuerungsinstrument: Klarheit, Priorisierung, Nachweisführung.
• Wenn du sie als Tabelle pflegst, wird sie „lebendig“ – und deine Informationssicherheit wird planbar.

Typische Auditor-Fragen zur SoA

Diese Fragen kommen sehr häufig – wenn du sie beantworten kannst, bist du in der Regel gut vorbereitet:

• Ist die SoA aktuell? Welche Version gilt, wer hat sie freigegeben, und wann wurde sie zuletzt überprüft?
• Passt die SoA zum Scope? Deckt sie alle Prozesse/Systeme im Geltungsbereich ab – oder hast du Controls ausgeschlossen, obwohl Aktivitäten doch stattfinden?
• Wie begründest du „nicht anwendbar“? Welche konkrete Prozess-/Systemrealität steckt dahinter?
• Wie leitest du Controls aus Risiken ab? Zeig mir das Mapping Risiko → Maßnahme → Nachweis.
• Wie weist du „umgesetzt“ nach? Wo sind Policy, Prozess, technische Umsetzung und Wirksamkeitscheck dokumentiert?
• Wie gehst du mit teilweiser Umsetzung um? Was ist der Plan, bis wann, mit welchem Owner?

Förderhinweis für KMU

Wenn du die SoA nicht nur „schreiben“, sondern sauber im ISMS verankern willst, lohnt sich ein Blick auf Förderungen:

• BAFA – Förderung von Unternehmensberatungen für KMU: Die Förderrichtlinie gilt für Anträge ab 01.01.2023 und läuft bis 31.12.2026. Pro Unternehmen sind max. fünf Beratungen (max. zwei pro Jahr) möglich; beantragt wird online vor Beratungsbeginn über deinen zugelassenen und zertifizierten Berater.
• Förderdatenbank des Bundes: Dort findest du auch Landesförderungen und EU-Programme – mit Suchfunktion nach Region und Thema.
• EU-Förderbeispiel (Digital Europe): Im Rahmen des SECURE-Projekts können KMU für bestimmte Aktivitäten zur Stärkung der Cybersicherheit von Hard- und Software-Produkten Co-Funding bis max. 30.000 EUR beantragen (zeitlich befristete Calls).

Wenn du Unterstützung willst: Auf mitsicherheit.online begleiten wir KMU pragmatisch beim ISMS-Aufbau – von der Kontextanalyse über Risiko & Maßnahmen bis zur auditfähigen SoA. Und wenn du Fördermöglichkeiten nutzen willst, helfen wir dir, die passenden Programme sauber einzuordnen.

Quellen (Auswahl)

1. ISACA Germany Chapter e.V.: Implementierungsleitfaden ISO/IEC 27001:2022 (PDF). Enthält Definition und Rolle der SoA sowie Mindestanforderungen an Dokumentation (Scope, SoA etc.).
2. International Accreditation Forum (IAF), Deutsche Übersetzung via DAkkS: IAF MD 26:2023 – Anforderungen für die Umstellung auf ISO/IEC 27001:2022. Enthält u. a. Hinweise zu Annex A, Vergleichsprozess 6.1.3(c) und Erstellung SoA 6.1.3(d), neue Control-Struktur (93 Controls) und Anforderungen im Transition-Audit.
3. DAkkS: Umstellungsanleitung ISO/IEC 27001:2022 (Stand 11.08.2023). Enthält Umstellungsfrist bis 31.10.2025 und Hinweis zur Ungültigkeit alter Zertifikate ab diesem Datum.
4. GUTcert GmbH: Webseite Zertifizierung nach ISO/IEC 27001. Enthält Beschreibung von Annex A („mindestens 93 Controls“) und SoA als Pflichtdokument inkl. Umsetzungsstatus.
5. GUTcert GmbH: Newsbeitrag Erklärung zur Anwendbarkeit (SoA) – … Fragen an Ihr ISMS (Praxisblick zu Annex-A-Abdeckung und Risiken zu breiten Ausschlüssen).
6. Bundesamt für Wirtschaft und Ausfuhrkontrolle (BAFA): Programmseite Förderung von Unternehmensberatungen für KMU (Förderrichtlinie bis 31.12.2026, Antragslogik).
7. Förderdatenbank des Bundes: Home / Überblick über Programme von Bund, Ländern, EU; Suchfunktion.
8. EU-Kommission (Shaping Europe’s digital future): News Financial support for small businesses to improve cybersecurity of products (SECURE-Projekt, Call-Details, max. 30.000 EUR).
9. Öffentliches SoA-Beispiel: Ionite B.V.: Statement of Applicability (2022) (zeigt typische Spalten „Applicable/Reason/Status“ und Begründungstypen wie „Risk assessment“/„Legal requirement“).
10. Wikimedia Commons/ENISA: Datei The Risk Management Process.png (ENISA, nach ISO 27005), Lizenz: Nutzung mit Attribution.
11. Wikimedia Commons: Datei PDCA Process.png (Johannes Vietze), Lizenz: CC BY-SA 3.0.