Das Statement of Applicability (SoA) ist ein Pflichtdokument der ISO 27001 nach Kapitel 6.1.3 d). Es listet alle 93 Controls aus Anhang A auf und dokumentiert für jedes: ob es anwendbar ist, warum es aufgenommen oder ausgeschlossen wurde und wie der Umsetzungsstand ist. Auditoren nutzen es als zentrale Landkarte des ISMS.
Kaum ein Dokument entscheidet so sehr über den Verlauf eines ISO-27001-Audits wie das Statement of Applicability. Auditoren öffnen es als Erstes, planen damit ihre Stichproben – und erkennen an seiner Qualität binnen Minuten, ob ein ISMS durchdacht oder zusammenkopiert ist. Trotzdem wird das SoA in vielen Projekten als lästige Tabelle behandelt, die kurz vor dem Audit noch schnell befüllt wird.
Dieser Artikel zeigt, was das SoA nach der Norm enthalten muss, wie Sie es in fünf Schritten sauber aufbauen, wie eine brauchbare SoA-Tabelle konkret aussieht – mit Beispielzeilen zum Nachbauen – und welche Fehler Sie sich ersparen sollten.
Was das Statement of Applicability ist
Das Statement of Applicability – auf Deutsch Erklärung zur Anwendbarkeit – ist in Kapitel 6.1.3 d) der ISO/IEC 27001 verankert und gehört zu den wenigen ausdrücklich geforderten Dokumenten. Es verbindet die beiden Ebenen der Norm: die individuelle Risikoanalyse des Unternehmens und den generischen Maßnahmenkatalog des Anhangs A mit seinen 93 Controls.
Die Logik dahinter: Jedes Unternehmen wählt seine Sicherheitsmaßnahmen risikobasiert selbst. Damit dabei nichts Wesentliches übersehen wird, verlangt die Norm einen vollständigen Abgleich mit Anhang A – und das SoA ist das dokumentierte Ergebnis dieses Abgleichs. Es beantwortet für jedes einzelne Control drei Fragen: Gilt das für uns? Warum beziehungsweise warum nicht? Und wie weit sind wir mit der Umsetzung?
Für Auditoren ist das SoA die Landkarte des gesamten ISMS: Sie wählen daraus Stichproben, lassen sich zu einzelnen Controls die Regelung und den gelebten Nachweis zeigen und prüfen die Konsistenz mit der Risikoanalyse. Ein präzises, aktuelles SoA verkürzt das Audit spürbar – ein schlampiges verlängert es und weckt Misstrauen für alles Weitere.
Diese vier Angaben verlangt die Norm
Kapitel 6.1.3 d) benennt den Pflichtinhalt präzise. Für jedes der 93 Controls muss das SoA enthalten:
- Die notwendigen Controls: Welche Maßnahmen das Unternehmen zur Behandlung seiner Risiken für erforderlich hält – einschließlich eventueller zusätzlicher Controls, die über Anhang A hinausgehen, etwa aus Kundenverträgen oder TISAX-Anforderungen.
- Die Begründung für die Aufnahme: Warum ein Control anwendbar ist – idealerweise mit Bezug auf konkrete Risiken, rechtliche Pflichten oder Vertragsanforderungen.
- Den Umsetzungsstatus: Ob das Control umgesetzt ist, teilweise umgesetzt oder geplant. Die Norm verlangt hier Ehrlichkeit, keine Schönfärberei – ein „geplant“ mit Termin ist völlig auditfähig.
- Die Begründung für Ausschlüsse: Warum ein Control nicht anwendbar ist. Diese Begründung muss sachlich nachvollziehbar sein und darf der Risikoanalyse nicht widersprechen.
Format und Werkzeug sind frei: Die meisten Unternehmen führen das SoA als Tabellenkalkulation oder in einem ISMS-Tool. Bewährt haben sich Zusatzspalten für die Referenz auf das umsetzende Dokument und den Verantwortlichen – Pflicht sind sie nicht, aber sie machen das Dokument im Audit erheblich schlagkräftiger.
SoA in fünf Schritten erstellen
Der Weg zum fertigen SoA folgt einer klaren Reihenfolge – wer sie einhält, vermeidet die häufigsten Konsistenzprobleme:
- Risikoanalyse abschließen: Das SoA ist ein Ergebnis der Risikobehandlung, nicht ihr Ausgangspunkt. Erst wenn Risiken bewertet und Behandlungsentscheidungen getroffen sind, lässt sich sinnvoll über Anwendbarkeit urteilen.
- Alle 93 Controls auflisten: Legen Sie eine Tabelle mit sämtlichen Controls aus Anhang A an – Nummer, Titel, und die vier Pflichtangaben als Spalten. Vorlagen dafür sind frei verfügbar; entscheidend ist die eigene Befüllung.
- Anwendbarkeit je Control entscheiden: Gehen Sie den Katalog durch und ordnen Sie jedem Control die zugehörigen Risiken, Vertragspflichten oder rechtlichen Anforderungen zu. Findet sich nichts, ist das Control ein Ausschlusskandidat – mit Begründung.
- Umsetzungsstatus ehrlich erfassen: Prüfen Sie je anwendbarem Control, was bereits existiert: Regelung vorhanden? Nachweis vorhanden? Daraus ergibt sich der Status – umgesetzt, teilweise, geplant – und nebenbei eine belastbare Projektliste für die verbleibende Arbeit.
- Review und Freigabe: Lassen Sie das SoA von einer zweiten Person gegen die Risikoanalyse prüfen, versehen Sie es mit Version, Datum und Freigabe – und verankern Sie einen festen Aktualisierungsanlass, mindestens jährlich.
Realistischer Zeitaufwand für ein kleines Unternehmen: zwei bis vier Arbeitstage, verteilt über die ISMS-Einführung – nicht an einem Stück kurz vor dem Audit.
Aufbau-Beispiel: So sieht eine SoA-Tabelle aus
So könnte der Auszug eines SoA für einen IT-Dienstleister mit 15 Mitarbeitenden ohne eigene Softwareentwicklung aussehen:
| Control | Anwendbar? | Begründung | Status | Referenz |
|---|---|---|---|---|
| A.5.7 Threat Intelligence | Ja | Risiko R-12 (Ransomware); frühzeitige Warnung vor aktiven Kampagnen nötig | Umgesetzt | RL-08 Schwachstellen- und Bedrohungsmanagement; BSI-Warnmeldungen abonniert |
| A.6.3 Awareness-Schulungen | Ja | Risiken R-03 (Phishing), R-07 (Fehlbedienung); Kundenvertrag K-2024-11 fordert jährliche Schulung | Umgesetzt | Schulungsplan PL-02; Nachweise im Personalordner |
| A.7.9 Werte außerhalb des Standorts | Ja | Risiko R-15 (Laptopverlust im Außendienst) | Teilweise – Verschlüsselung aktiv, Richtlinie mobiles Arbeiten in Freigabe | RL-05 Mobiles Arbeiten (Entwurf); MDM-Konfiguration |
| A.8.13 Sicherung von Informationen | Ja | Risiken R-01 (Datenverlust), R-12 (Ransomware); Wiederanlauf vertraglich zugesichert | Umgesetzt | RL-03 Backup-Konzept; Restore-Testprotokolle quartalsweise |
| A.8.28 Sicheres Codieren | Nein | Keine eigene Softwareentwicklung; ausschließlich Betrieb von Standardsoftware | – | – |
Die Beispielzeilen zeigen das Prinzip: Jede Aufnahme verweist auf konkrete Risiken oder Verträge, jeder Status ist ehrlich, jede Referenz führt zu einem echten Dokument oder Nachweis. Mit dieser Struktur kann ein Auditor jede Zeile in zwei Minuten verifizieren – genau das macht ein gutes SoA aus.
Ausschlüsse sauber begründen
Ausschlüsse sind normkonform und bei fast jedem Unternehmen vorhanden – entscheidend ist die Qualität der Begründung. Tragfähig sind sachliche Feststellungen über das Unternehmen: keine eigene Softwareentwicklung (A.8.25 bis A.8.34), kein Quellcode im Besitz (A.8.4), keine eigenen Serverräume, weil vollständig Cloud-basiert gearbeitet wird (Teile von A.7). Solche Begründungen sind überprüfbar und bleiben stabil.
Nicht tragfähig sind dagegen Begründungen, die in Wahrheit Entscheidungen gegen Sicherheit sind: „zu aufwendig“, „bisher kein Vorfall“, „machen wir später“ – all das sind keine Ausschlussgründe, sondern unbehandelte Risiken, die als solche in der Risikoanalyse stehen müssten. Ebenfalls kritisch: Ausschlüsse, die der Risikoanalyse widersprechen. Wer das Risiko „Laptopdiebstahl“ bewertet hat, kann A.7.9 nicht als nicht anwendbar führen.
Ein Praxistipp: Formulieren Sie jede Ausschlussbegründung so, dass ein Externer sie ohne Rückfrage versteht und nachprüfen kann. Ein einziger vollständiger Satz reicht fast immer. Und prüfen Sie Ausschlüsse bei jeder Aktualisierung neu – wer plötzlich doch entwickelt, Cloud-Dienste wechselt oder einen Serverraum einrichtet, muss die betroffenen Zeilen anfassen.
Das SoA aktuell halten
Das SoA ist ein lebendes Dokument. Veraltet es, verliert es seinen Wert als Steuerungsinstrument – und wird im Überwachungsaudit zur Schwachstelle. Bewährt haben sich feste Aktualisierungsanlässe: nach jeder Wiederholung der Risikoanalyse (mindestens jährlich), bei wesentlichen Änderungen wie neuen Cloud-Diensten, neuen Geschäftsfeldern oder Standortwechseln, nach relevanten Sicherheitsvorfällen und nach internen wie externen Audits, wenn sich daraus Maßnahmen ergeben.
Praktisch heißt das: Das SoA braucht einen benannten Eigentümer – üblicherweise den Informationssicherheitsbeauftragten –, eine Versionsnummer, ein Änderungsdatum und eine dokumentierte Freigabe. Änderungen sollten nachvollziehbar sein, etwa über eine kurze Änderungshistorie am Dokumentenanfang. Auditoren vergleichen gern die Versionsstände von Risikoanalyse und SoA: Liegt die letzte SoA-Änderung Jahre zurück, während sich die Risikoanalyse bewegt hat, ist die Abweichung offensichtlich. Umgekehrt gilt: Ein SoA mit sichtbarer Pflegehistorie ist einer der stärksten Belege dafür, dass das ISMS tatsächlich betrieben wird und nicht nur zum Audittermin auflebt.
Typische Fehler beim SoA – und wie Sie sie vermeiden
Aus der Audit- und Beratungspraxis wiederholen sich beim Statement of Applicability dieselben Muster:
- Vorlage ungeprüft übernommen: Begründungen aus dem Muster-SoA passen nicht zum Unternehmen – etwa Verweise auf einen Serverraum, den es gar nicht gibt. Auditoren erkennen Textbausteine sofort.
- Alles auf „umgesetzt“: Ein SoA ohne einen einzigen offenen Punkt wirkt nicht stark, sondern unglaubwürdig. Ehrliche Teilumsetzungen mit Terminen sind auditfähig und zeigen funktionierende Selbstkontrolle.
- Kein Bezug zur Risikoanalyse: Begründungen wie „Best Practice“ bei jeder Zeile verschenken die Kernfunktion des Dokuments – die Verbindung zwischen Risiko und Maßnahme.
- Fehlende Begründung für Aufnahmen: Seit der Fassung 2022 wird ausdrücklich auch begründet, warum ein Control anwendbar ist – nicht nur, warum eines fehlt.
- Keine Referenzen: Ohne Verweis auf Richtlinien und Nachweise muss der Auditor jede Zeile erfragen – das kostet Zeit und Vertrauen.
- Einmal erstellt, nie gepflegt: Das SoA vom Erstaudit überlebt unverändert drei Überwachungsaudits – spätestens bei der Rezertifizierung fällt das auf.
Die Gegenstrategie ist unspektakulär: Reihenfolge einhalten (erst Risiken, dann SoA), ehrlich dokumentieren, Referenzen pflegen, jährlich aktualisieren. Damit wird das SoA vom Pflichtdokument zum nützlichsten Steuerungsinstrument des ganzen ISMS.
Häufige Fragen
Ja. Das SoA gehört nach Kapitel 6.1.3 d) der ISO 27001 zu den ausdrücklich geforderten dokumentierten Informationen. Ohne vollständiges SoA ist keine Zertifizierung möglich – es zählt neben Geltungsbereich, Leitlinie und Risikoanalyse zu den Dokumenten, die jeder Auditor sehen will, meist gleich zu Beginn des Stufe-1-Audits.
Da alle 93 Controls aus Anhang A aufgeführt werden müssen, hat das SoA immer mindestens 93 Zeilen – plus eventuelle Zusatz-Controls aus Verträgen oder anderen Anforderungsquellen. Als Tabelle sind das je nach Detailtiefe fünf bis fünfzehn Seiten. Die Länge ist unkritisch; entscheidend sind Konsistenz mit der Risikoanalyse und belastbare Referenzen.
Ja, vollkommen. Die Norm macht keine Formatvorgaben – eine gepflegte Tabellenkalkulation mit Versionsstand, Eigentümer und Freigabevermerk ist auditfähig und für kleine Unternehmen meist die beste Wahl. ISMS-Tools lohnen sich erst, wenn mehrere Normen, Standorte oder viele Beteiligte koordiniert werden müssen.
Federführend meist der Informationssicherheitsbeauftragte, fachlich zwingend gemeinsam mit den Wissensträgern: IT-Administration für die technologischen Controls, Personalabteilung für die personenbezogenen, Geschäftsleitung für organisatorische Grundsatzfragen. Die Freigabe liegt bei der Leitung – sie trägt die Verantwortung für die Risikoentscheidungen, die das SoA dokumentiert.
Der Risikobehandlungsplan ist maßnahmenorientiert: Er beschreibt je Risiko die gewählte Behandlung, Verantwortliche und Termine. Das SoA ist katalogorientiert: Es dokumentiert für alle 93 Anhang-A-Controls Anwendbarkeit, Begründung und Status. Beide Dokumente sind Pflicht, überlappen sich inhaltlich und müssen konsistent sein – Auditoren prüfen genau diese Verbindung.
Manchmal. Großkunden und Konzerne fordern im Rahmen von Lieferantenprüfungen gelegentlich Einblick in SoA oder Zertifikatsanhang, um den Geltungsbereich zu verstehen. Das ist legitim, sollte aber kontrolliert ablaufen: unter Vertraulichkeitsvereinbarung und gegebenenfalls in gekürzter Fassung, denn das SoA verrät viel über die eigene Sicherheitsarchitektur.
In 4–6 Wochen zum Zertifikat – zum Festpreis.
Kostenloses Erstgespräch: Wir sagen Ihnen ehrlich, ob eine nicht akkreditierte Zertifizierung für Ihren Fall reicht – oder eben nicht.
Erstgespräch vereinbaren
Thomas KowollInhaber und Leitung Zertifizierung bei KCERT. Auditiert Managementsysteme nach ISO 9001, 14001, 45001, 27001 und 50001. Mehr über KCERT