Statement of Applicability (SoA) erstellen – die Schritt-für-Schritt-Anleitung

Inhalt in Kürze

• Das Statement of Applicability (SoA) – auf Deutsch “Erklärung zur Anwendbarkeit” – ist das einzige Pflichtdokument, das jeden einzelnen der 93 Annex-A-Controls der ISO 27001:2022 abdeckt.
• Für jedes Control hält die SoA fest: anwendbar oder nicht, Begründung, Umsetzungsstatus und der Verweis auf die Maßnahme.
• Die SoA entsteht nach der Risikobewertung und der Risikobehandlung – nicht davor.
• Auditoren nutzen die SoA als Landkarte: Sie ist meist das erste Dokument, das im Zertifizierungsaudit geprüft wird.

Wer eine ISO-27001-Zertifizierung anstrebt, stolpert früher oder später über drei Buchstaben: SoA. Viele Unternehmen unterschätzen dieses Dokument – und genau daran scheitern Audits. Dabei ist die Logik einfach, wenn man die Reihenfolge versteht. Diese Anleitung zeigt sie Ihnen Schritt für Schritt.

Was ist das Statement of Applicability?

Die SoA ist ein dokumentierter Nachweis, der für jedes der 93 Controls aus Annex A der ISO/IEC 27001:2022 festhält, ob es für Ihr Unternehmen anwendbar ist – und warum. Sie ist nach Kapitel 6.1.3 d) der Norm verpflichtend und damit eines der wenigen Dokumente, ohne das keine Zertifizierung möglich ist.

Man kann sich die SoA als Brücke vorstellen: zwischen Ihrer individuellen Risikobewertung auf der einen Seite und den konkreten Sicherheitsmaßnahmen auf der anderen. Sie übersetzt “Welche Risiken haben wir?” in “Welche Controls setzen wir deshalb ein?”.

Was muss in der SoA stehen?

Kapitel 6.1.3 d) der Norm verlangt für jedes Control vier Angaben, als fünfte hat sich der Verweis auf die Maßnahme bewährt:

Der häufigste Fehler: ein Control auf “nicht anwendbar” zu setzen, ohne eine saubere Begründung. Ein pauschales “brauchen wir nicht” reicht dem Auditor nicht. Die Praxis-Leitfäden zur SoA betonen durchgehend, dass jede Ausschluss-Entscheidung nachvollziehbar dokumentiert sein muss.

Wann entsteht die SoA? Die Reihenfolge ist entscheidend

Viele Teams scheitern, weil sie die SoA zu früh schreiben. Die richtige Reihenfolge:

1. Geltungsbereich (Scope) festlegen: Welche Bereiche, Standorte und Werte umfasst Ihr ISMS?
2. Risikobewertung durchführen: Welche Bedrohungen treffen welche Werte? Wie hoch ist das Risiko?
3. Risikobehandlung planen: Welche Risiken mindern Sie mit welchen Maßnahmen?
4. Controls auswählen: Gleichen Sie Ihre Maßnahmen mit den 93 Annex-A-Controls ab.
5. SoA erstellen: Dokumentieren Sie Anwendbarkeit, Begründung und Status pro Control.

Die SoA ist also das Ergebnis Ihrer Risikoarbeit, nicht ihr Ausgangspunkt. Wer mit der Control-Liste anfängt und rückwärts begründet, baut ein Kartenhaus, das im Audit zusammenfällt. Auch Fachpublikationen beschreiben die SoA-Erstellung als Prozess, der mit der Control-Auswahl endet – nicht beginnt.

SoA erstellen: die Schritt-für-Schritt-Checkliste

• Vorlage anlegen. Eine Tabelle mit allen 93 Controls aus Annex A der ISO 27001:2022 – sortiert nach den vier Kategorien (Organisatorisch, Personenbezogen, Physisch, Technologisch).
• Anwendbarkeit entscheiden. Pro Control prüfen: Trifft das auf unseren Scope und unsere Risiken zu?
• Begründung schreiben. Für "anwendbar": Bezug zur Risikobewertung. Für "nicht anwendbar": warum das Risiko nicht besteht.
• Status erfassen. Umgesetzt, in Umsetzung oder geplant – ehrlich, nicht geschönt.
• Maßnahme verlinken. Verweis auf die Richtlinie, das Verfahren oder das technische Mittel.
• Version und Datum setzen. Jede SoA braucht Versionsnummer, Datum und Freigabe durch die Leitung.

Für jeden ist Informationssicherheit wichtig. Und für uns ist es wichtig, eine pragmatische Lösung zu finden, wie Unternehmen sie umsetzen – ohne dabei den Geschäftsbetrieb einzustellen. Die SoA ist dafür das ehrlichste Dokument: Sie zeigt, was Sie wirklich tun.

Nils OehmichenDatenschutzberater bei frag.hugo

Typische Fehler, die Audits kosten

Die häufigsten Stolpersteine sehen wir in der Praxis immer wieder:

• Generische Begründungen. “Best Practice” ist keine Begründung. Der Bezug zur eigenen Risikobewertung fehlt.
• Controls voreilig ausschließen. Wer A.8 (technologische Controls) großzügig auf “nicht anwendbar” setzt, weckt Misstrauen.
• Status schönen. Ein als “umgesetzt” deklariertes Control ohne Nachweis fällt im Audit sofort auf.
• Veraltetes Datum. Eine SoA, die seit zwei Jahren nicht angefasst wurde, signalisiert ein totes ISMS.

Wer die SoA sauber führt, hat die ISO-27001-Anforderungen für KMU zum großen Teil im Griff. Sie ist das Dokument, an dem sich entscheidet, ob Ihr ISMS gelebt wird oder nur auf dem Papier existiert.

Ihr nächster Schritt

Eine SoA, die im Audit besteht, braucht eine saubere Risikobewertung als Fundament. Wir bauen mit Ihnen beides auf – pragmatisch und auditfest.

Mehr zum Gesamtaufbau lesen Sie in unserem ISMS-Leitfaden für Geschäftsführer. Eine strukturierte Plattform dafür ist Hugo ISMS.

Häufige Fragen (FAQ)

Was ist das Statement of Applicability bei ISO 27001?

Das Statement of Applicability (SoA), deutsch “Erklärung zur Anwendbarkeit”, ist ein Pflichtdokument der ISO 27001:2022. Es hält für jedes der 93 Annex-A-Controls fest, ob es anwendbar ist, mit welcher Begründung und in welchem Umsetzungsstatus.

Ist die SoA bei ISO 27001 verpflichtend?

Ja. Nach Kapitel 6.1.3 d) der ISO 27001:2022 ist die SoA verpflichtend. Ohne sie ist keine Zertifizierung möglich. Sie ist meist das erste Dokument, das ein Auditor prüft.

Wann erstellt man die SoA?

Die SoA entsteht nach der Risikobewertung und der Risikobehandlung. Erst legen Sie den Scope fest, dann bewerten Sie Risiken, planen Maßnahmen, wählen Controls aus – und dokumentieren das Ergebnis in der SoA.

Was ist der Unterschied zwischen SoA und Risikobehandlungsplan?

Die SoA listet alle 93 Annex-A-Controls mit Angabe der Anwendbarkeit. Der Risikobehandlungsplan beschreibt nur die konkreten Maßnahmen für die tatsächlich behandelten Risiken. Beide sind getrennte Dokumente.

Wie oft muss die SoA aktualisiert werden?

ISO 27001 schreibt keinen festen Turnus vor. Bewährt hat sich eine Aktualisierung mindestens einmal jährlich sowie bei jeder wesentlichen Änderung des ISMS, der Risikolage oder der eingesetzten Maßnahmen. Ein veraltetes Datum gilt im Audit als Warnsignal.