ISMS Copilot
ISO 27001 Glossar

Was ist eine Anwendbarkeitserklärung (Statement of Applicability, SoA)?

Übersicht

Die Anwendbarkeitserklärung (SoA) ist ein obligatorisches ISO 27001-Dokument, das alle 93 Maßnahmen von Anhang A auflistet und erklärt, ob die jeweilige Maßnahme in Ihr ISMS aufgenommen oder davon ausgeschlossen wurde. Für einbezogene Maßnahmen wird beschrieben, wie sie umgesetzt werden. Für ausgeschlossene Maßnahmen wird eine Begründung für den Ausschluss geliefert.

Was das in der Praxis bedeutet

Die SoA ist Ihr Entwurf für die Maßnahmenwahl – sie verbindet die Ergebnisse Ihrer Risikobewertung mit den spezifischen Sicherheitsmaßnahmen, die Sie zur Umsetzung ausgewählt haben. Auditoren nutzen sie als Leitfaden, um zu verifizieren, dass Ihr ISMS die identifizierten Risiken angemessen adressiert.

Praxisbeispiel: Ihre Risikobewertung identifiziert Ransomware als kritische Bedrohung. Ihre SoA würde die Maßnahme A.8.7 (Schutz vor Malware) als „Einbezogen“ ausweisen, mit Umsetzungsdetails wie „Endpoint Detection and Response Software auf allen Geräten mit zentraler Verwaltung installiert“, während Maßnahme A.7.4 (Physische Sicherheitsüberwachung) als „Ausgeschlossen – Organisation arbeitet rein cloudbasiert ohne physisches Rechenzentrum“ aufgeführt sein könnte.

Warum die SoA für ISO 27001 wichtig ist

Verpflichtende Anforderung

ISO 27001 Klausel 6.1.3(d) verlangt ausdrücklich die Führung einer „Erklärung zur Anwendbarkeit, die die notwendigen Maßnahmen und die Begründung für Einlschlüsse und Ausschlüsse enthält“. Ohne eine vollständige, genaue SoA können Sie keine Zertifizierung erhalten.

Demonstriert risikobasierten Ansatz

Die SoA beweist, dass Sie Maßnahmen nicht willkürlich implementieren oder blind Vorlagen übernehmen. Sie zeigt, wie jede Entscheidung für eine Maßnahme auf Ihre Risikobewertung zurückzuführen ist.

Audit-Leitfaden

Auditoren nutzen Ihre SoA, um zu planen, was sie während der Zertifizierungsaudits verifizieren werden. Einbezogene Maßnahmen erfordern Nachweise über deren Umsetzung und Wirksamkeit. Ausschlüsse müssen basierend auf der Risikobewertung oder dem Geschäftskontext gerechtfertigt sein.

Änderungsmanagement

Wenn sich Risiken weiterentwickeln, sollte Ihre SoA aktualisiert werden, um neue Anforderungen an Maßnahmen widerzuspiegeln oder die Entfernung zuvor ausgeschlossener Maßnahmen zu ermöglichen, wenn die Risiken sinken.

Häufige Audit-Feststellung: SoA-Begründungen, die nicht mit den Ergebnissen der Risikobewertung übereinstimmen. Wenn Sie beispielsweise Backup-Maßnahmen (A.8.13) ausschließen, während Ihre Risikobewertung Datenverlust als hohes Risiko identifiziert, führt dies zu einer Nichtkonformität.

Was die SoA enthalten muss

Vollständige Maßnahmenliste

Alle 93 Maßnahmen des Anhangs A aus ISO 27001:2022 müssen in Ihrer SoA erscheinen, organisiert nach Themen:

  • Organisatorische Maßnahmen: A.5.1 bis A.5.37 (37 Maßnahmen)

  • Personenbezogene Maßnahmen: A.6.1 bis A.6.8 (8 Maßnahmen)

  • Physische Maßnahmen: A.7.1 bis A.7.14 (14 Maßnahmen)

  • Technologische Maßnahmen: A.8.1 bis A.8.34 (34 Maßnahmen)

Status des Einschlusses/Ausschlusses

Geben Sie für jede Maßnahme klar an, ob sie in Ihr ISMS einbezogen oder davon ausgeschlossen ist. Vermeiden Sie mehrdeutige Status wie „teilweise anwendbar“ – Maßnahmen sind entweder drin oder draußen.

Beschreibung der Umsetzung (für einbezogene Maßnahmen)

Beschreiben Sie kurz, wie Sie jede einbezogene Maßnahme umsetzen. Geben Sie an:

  • Spezifische Richtlinien, Verfahren oder eingesetzte Technologien

  • Wer für die Maßnahme verantwortlich ist

  • Wo Nachweise über die Umsetzung zu finden sind

  • Wie die Maßnahme die identifizierten Risiken adressiert

Begründung des Ausschlusses (für ausgeschlossene Maßnahmen)

Erklären Sie, warum ausgeschlossene Maßnahmen nicht Teil Ihres ISMS sind. Gültige Begründungen sind:

  • Risikobasiert: „Keine Risiken in unserer Bewertung erfordern diese Maßnahme“

  • Kontextbasiert: „Nicht anwendbar – wir sind rein cloudbasiert ohne physische Infrastruktur“

  • Rechtlich/Regulatorisch: „Durch Datenspeichergesetze in unserer Jurisdiktion untersagt“

Qualität der Begründung: Starke Ausschlussbegründungen beziehen sich auf spezifische Ergebnisse der Risikobewertung oder den organisatorischen Kontext. Schwache Begründungen wie „nicht relevant“ oder „noch nicht implementiert“ werden von Auditoren angefochten.

Struktur und Format der SoA

Tabellarisches Format (am gebräuchlichsten)

Eine Tabelle mit Spalten für:

  • Maßnahmennummer (z. B. A.5.1)

  • Maßnahmenname (z. B. „Informationssicherheitsrichtlinien“)

  • Status (Einbezogen / Ausgeschlossen)

  • Umsetzungsbeschreibung oder Ausschlussbegründung

  • Risikoreferenz (Verknüpfung zum Risikoregister)

  • Ort der Nachweise (optional, aber hilfreich)

Narratives Format

Einige Organisationen bevorzugen ein erzählendes Dokument, das die Maßnahmenumsetzung nach Themen gruppiert beschreibt. Weniger verbreitet, aber akzeptabel, wenn es alle 93 Maßnahmen klar adressiert.

Tool-basiertes Format

GRC-Plattformen und ISMS-Tools generieren SoAs oft automatisch basierend auf der Maßnahmenauswahl und der Verknüpfung mit Risikobewertungen. Diese müssen dennoch manuell auf Richtigkeit validiert werden.

Präferenz der Auditoren: Die meisten Auditoren bevorzugen tabellarische SoAs, da sie leicht zu scannen und abzugleichen sind. Halten Sie Umsetzungsbeschreibungen prägnant (2–3 Sätze pro Maßnahme) – detaillierte Verfahren gehören in separate Verfahrensdokumente, nicht in die SoA.

Erstellung Ihrer SoA

Schritt 1: Risikobewertung abschließen

Ihre SoA ist ein direktes Ergebnis der Risikobewertung. Identifizieren Sie alle Risiken, die einer Behandlung bedürfen, bevor Sie festlegen, welche Maßnahmen implementiert werden sollen.

Schritt 2: Maßnahmen den Risiken zuordnen

Identifizieren Sie für jedes behandlungsbedürftige Risiko, welche Anhang-A-Maßnahmen dieses auf ein akzeptables Maß reduzieren würden. Ein Risiko kann mehrere Maßnahmen erfordern; eine Maßnahme kann mehrere Risiken adressieren.

Schritt 3: Einschluss/Ausschluss festlegen

Maßnahmen, die identifizierte Risiken adressieren, werden einbezogen. Maßnahmen, die keines Ihrer Risiken adressieren, können ausgeschlossen werden (mit Begründung).

Schritt 4: Umsetzung beschreiben

Dokumentieren Sie für einbezogene Maßnahmen, wie Sie diese umsetzen. Seien Sie so spezifisch, dass Auditoren Ihren Ansatz verstehen, ohne ganze Verfahrensbeschreibungen zu duplizieren.

Schritt 5: Ausschlüsse begründen

Erklären Sie für ausgeschlossene Maßnahmen basierend auf Ihrer Risikobewertung oder Ihrem organisatorischen Kontext, warum diese nicht gelten. Beziehen Sie sich nach Möglichkeit auf spezifische Feststellungen aus Ihrem Risikoregister.

Schritt 6: Überprüfung und Genehmigung

Das Management sollte die SoA formell prüfen und genehmigen und damit die Entscheidungen zur Maßnahmenwahl sowie etwaige Restrisiken anerkennen.

Versionskontrolle: Die SoA ist ein lebendes Dokument, das aktualisiert werden muss, wenn sich Risiken ändern, Maßnahmen hinzugefügt oder geändert werden oder Ausschlüsse neu bewertet werden. Führen Sie eine Versionshistorie, die zeigt, wann und warum Änderungen vorgenommen wurden.

Häufige SoA-Fehler

Ausschluss von zu vielen Maßnahmen

Organisationen schließen manchmal Maßnahmen aus, um den Implementierungsaufwand zu verringern. Auditoren prüfen Ausschlüsse sehr genau – wenn Ihre Risikobewertung gründlich ist, sollten die meisten Maßnahmen einbezogen sein.

Generische Umsetzungsbeschreibungen

Das Kopieren von Maßnahmenbeschreibungen aus ISO 27002, ohne Ihre tatsächliche Umsetzung zu beschreiben. Auditoren müssen verstehen, was Sie tun, nicht was der Standard besagt.

Fehlende Risikoverknüpfungen

Das Versäumnis, Maßnahmen mit spezifischen Risiken in Ihrer Risikobewertung zu verknüpfen. Dies unterbricht die Rückverfolgbarkeit und deutet darauf hin, dass Maßnahmen willkürlich gewählt wurden.

Unvollständige Abdeckung

Das Vergessen, alle 93 Maßnahmen zu behandeln. Selbst wenn eine Maßnahme offensichtlich nicht anwendbar erscheint, muss sie mit Ausschlussbegründung in der SoA erscheinen.

Kein Überprüfungszyklus

Die SoA wird einmalig während der Erstimplementierung erstellt und trotz organisatorischer Änderungen oder neuer Risiken nie aktualisiert.

Effizienz-Tipp: Nutzen Sie den ISMS Copilot, um eine SoA-Vorlage mit gängigen Umsetzungsbeschreibungen für Ihre Branche zu erstellen. Passen Sie das Ergebnis basierend auf Ihren spezifischen Risikobewertungsergebnissen und Ihrem Kontext an.

SoA im Vergleich zu anderen ISO 27001-Dokumenten

SoA vs. Risikobehandlungsplan

Der Risikobehandlungsplan detailliert, wie Sie die ausgewählten Maßnahmen umsetzen (Zeitpläne, Verantwortlichkeiten, Ressourcen). Die SoA deklariert, welche Maßnahmen implementiert sind und warum. Beide Dokumente ergänzen einander.

SoA vs. Maßnahmen-Nachweise

Die SoA beschreibt, welche Maßnahmen Sie implementieren. Nachweise belegen, dass die Maßnahmen tatsächlich effektiv funktionieren. Während der Audits prüfen Auditoren Stichproben von Maßnahmen aus Ihrer SoA und fordern die entsprechenden Nachweise an.

SoA vs. Richtlinien und Verfahren

Richtlinien und Verfahren bieten detaillierte Anweisungen zur Umsetzung der Maßnahmen. Die SoA fasst auf hoher Ebene zusammen, welche Maßnahmen existieren und wie sie funktionieren.

Wie Auditoren die SoA nutzen

Stage 1 Audit (Dokumentenprüfung)

Auditoren verifizieren, dass Ihre SoA vollständig ist (alle 93 Maßnahmen behandelt), logisch strukturiert ist und mit Ihrer Risikobewertung übereinstimmt. Sie prüfen, ob die Begründungen für Ausschlüsse sinnvoll sind.

Stage 2 Audit (Überprüfung der Implementierung)

Auditoren wählen Stichproben von Maßnahmen aus Ihrer SoA aus und fordern Nachweise an, dass diese wie beschrieben implementiert sind. Sie testen Maßnahmen aus allen vier Themenbereichen und organisatorischen Einheiten innerhalb des Geltungsbereichs.

Auslöser für Nichtkonformitäten

Häufige Gründe, warum Auditoren Nichtkonformitäten im Zusammenhang mit der SoA feststellen:

  • Maßnahmen sind als „einbezogen“ markiert, aber nicht tatsächlich implementiert

  • Ausschlüsse ohne gültige Begründung

  • Die SoA spiegelt nicht die tatsächlichen Ergebnisse der Risikobewertung wider

  • Fehlende Maßnahmen (weniger als 93 aufgelistet)

  • Umsetzungsbeschreibungen sind zu vage, um sie zu verifizieren

Audit-Vorbereitung: Überprüfen Sie vor dem Zertifizierungsaudit jede „einbezogene“ Maßnahme in Ihrer SoA und sammeln Sie die entsprechenden Nachweise. Wenn Sie für eine Maßnahme keine Nachweise finden können, implementieren Sie diese entweder ordnungsgemäß oder aktualisieren Sie die SoA, um sie begründet auszuschließen.

Die SoA über die Zeit pflegen

Jährliche Aktualisierung der Risikobewertung

Wenn Sie geplante Risiko-Neubewertungen durchführen, prüfen Sie die SoA, um festzustellen, ob die Maßnahmenwahl weiterhin angemessen ist. Neue Risiken erfordern möglicherweise zuvor ausgeschlossene Maßnahmen.

Organisatorische Änderungen

Aktualisieren Sie die SoA, wenn:

  • Neue Technologien eingeführt werden (könnte neue technische Maßnahmen erfordern)

  • Sich das Geschäftsmodell ändert (z. B. ändert der Wechsel in die Cloud physische Maßnahmen)

  • Geografische Expansion neue regulatorische Anforderungen mit sich bringt

  • Fusionen oder Übernahmen das Risikoprofil verändern

Durch Vorfälle ausgelöste Überprüfungen

Prüfen Sie nach signifikanten Sicherheitsvorfällen, ob bestehende Maßnahmen wirksam waren oder ob zusätzliche (zuvor ausgeschlossene) Maßnahmen implementiert werden sollten.

Überwachungsaudits

Auditoren prüfen während der jährlichen Überwachungsaudits, ob die SoA aktuell gehalten wurde. Nachweise über regelmäßige Überprüfungen zeigen, dass Ihr ISMS aktiv ist und nicht nach der Zertifizierung vernachlässigt wurde.

SoA und Anpassung von Maßnahmen

Standard erlaubt maßgeschneiderte Anpassungen

ISO 27001 gestattet es Organisationen, Maßnahmen je nach Größe, Komplexität und Risiko unterschiedlich zu implementieren. Ihre SoA sollte Ihre spezifische Umsetzung widerspiegeln, keine generische Vorlage.

Zusätzliche Maßnahmen über Anhang A hinaus

Wenn Ihre Risikobewertung Risiken identifiziert, die durch die 93 Standard-Maßnahmen nicht ausreichend adressiert werden, können Sie zusätzliche Maßnahmen implementieren. Listen Sie diese in Ihrer SoA oder einem ergänzenden Dokument auf.

Proportionalität zählt

Die Umsetzung von „A.6.3 Bewusstseinsschulung zur Informationssicherheit“ in einem Startup mit 10 Personen wird sich von der in einem Unternehmen mit 10.000 Personen unterscheiden. Beide können konform sein, wenn sie dem Kontext angemessen und wirksam zur Risikoreduzierung sind.

Beispiel für proportionale Umsetzung: Ein kleines, rein cloudbasiertes SaaS-Unternehmen könnte A.7.1-A.7.14 (physische Maßnahmen) ausschließen mit der Begründung: „Keine physische Infrastruktur – alle Systeme laufen in AWS, wobei die Sicherheit durch die SOC 2-Kontrollen des Cloud-Anbieters verwaltet wird.“ Dies ist akzeptabel, wenn ihre Risikobewertung die Cloud-First-Architektur widerspiegelt.

Verwandte Konzepte

Hilfe erhalten

Beschleunigen Sie die Erstellung Ihrer SoA mit dem ISMS Copilot. Generieren Sie maßgeschneiderte Umsetzungsbeschreibungen, validieren Sie Ihre Begründungen gegen die Ergebnisse der Risikobewertung und stellen Sie sicher, dass alle 93 Maßnahmen ordnungsgemäß adressiert sind.

War das hilfreich?