Was ist eine Erklärung zur Anwendbarkeit (SoA)?

Übersicht

Die Erklärung zur Anwendbarkeit (SoA) ist ein verpflichtendes ISO-27001-Dokument, das alle 93 Anhang-A-Kontrollen auflistet und erklärt, ob jede Kontrolle in Ihr ISMS aufgenommen oder ausgeschlossen wird. Für aufgenommene Kontrollen wird beschrieben, wie sie implementiert werden. Für ausgeschlossene Kontrollen wird die Begründung für den Ausschluss angegeben.

Was es in der Praxis bedeutet

Die SoA ist Ihr Kontrollauswahl-Blaupause – sie verbindet die Ergebnisse Ihrer Risikobewertung mit den spezifischen Sicherheitskontrollen, die Sie zur Implementierung ausgewählt haben. Auditoren nutzen sie als ihren Fahrplan, um zu überprüfen, ob Ihr ISMS identifizierte Risiken angemessen behandelt.

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 Kontrollen und die Begründung für deren Aufnahme und Ausschluss enthält“. Ohne eine vollständige und genaue SoA können Sie keine Zertifizierung erreichen.

Nachweis eines risikobasierten Ansatzes

Die SoA beweist, dass Sie Kontrollen nicht willkürlich implementieren oder blind Vorlagen anwenden. Sie zeigt, wie jede Kontrollentscheidung auf Ihre Risikobewertung zurückgeführt werden kann.

Audit-Fahrplan

Auditoren nutzen Ihre SoA, um zu planen, was sie während der Zertifizierungsaudits überprüfen werden. Aufgenommene Kontrollen benötigen Nachweise über Implementierung und Wirksamkeit. Ausschlüsse müssen auf Basis der Risikobewertung oder des Geschäftskontexts begründet werden.

Change Management

Da sich Risiken weiterentwickeln, sollte Ihre SoA aktualisiert werden, um neue Kontrollanforderungen widerzuspiegeln oder zuvor ausgeschlossene Kontrollen zu entfernen, wenn die Risiken abnehmen.

Was die SoA enthalten muss

Vollständige Kontrollliste

Alle 93 Anhang-A-Kontrollen aus ISO 27001:2022 müssen in Ihrer SoA erscheinen, nach Themen geordnet:

• Organisatorische Kontrollen: A.5.1 bis A.5.37 (37 Kontrollen)
• Personenbezogene Kontrollen: A.6.1 bis A.6.8 (8 Kontrollen)
• Physische Kontrollen: A.7.1 bis A.7.14 (14 Kontrollen)
• Technologische Kontrollen: A.8.1 bis A.8.34 (34 Kontrollen)

Aufnahme-/Ausschlussstatus

Für jede Kontrolle ist klar anzugeben, ob sie in Ihr ISMS aufgenommen oder ausgeschlossen wird. Vermeiden Sie unklare Statusangaben wie „teilweise anwendbar“ – Kontrollen sind entweder enthalten oder nicht.

Implementierungsbeschreibung (für aufgenommene Kontrollen)

Beschreiben Sie kurz, wie Sie jede aufgenommene Kontrolle implementieren. Enthalten sein sollten:

• Spezifische Richtlinien, Verfahren oder verwendete Technologien
• Verantwortliche Person für die Kontrolle
• Wo Nachweise der Implementierung zu finden sind
• Wie die Kontrolle identifizierte Risiken adressiert

Begründung für Ausschlüsse (für ausgeschlossene Kontrollen)

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

• Risikobasiert: „In unserer Bewertung gibt es keine Risiken, die diese Kontrolle erfordern“
• Kontextbasiert: „Nicht anwendbar – wir sind rein cloudbasiert ohne physische Infrastruktur“
• Rechtlich/regulatorisch: „Durch Datenresidenzgesetze in unserem Zuständigkeitsbereich verboten“

SoA-Struktur und Format

Tabellarisches Format (am häufigsten)

Eine Tabelle mit Spalten für:

• Kontrollnummer (z. B. A.5.1)
• Kontrollname (z. B. „Richtlinien für Informationssicherheit“)
• Status (Aufgenommen / Ausgeschlossen)
• Implementierungsbeschreibung oder Begründung für den Ausschluss
• Risikoreferenz (Verknüpfung zum Risikoregister)
• Nachweisort (optional, aber hilfreich)

Narratives Format

Einige Organisationen bevorzugen ein narratives Dokument, das die Kontrollimplementierung nach Themen gruppiert beschreibt. Weniger verbreitet, aber akzeptabel, wenn alle 93 Kontrollen klar behandelt werden.

Toolbasiertes Format

GRC-Plattformen und ISMS-Tools generieren SoAs oft automatisch basierend auf der Kontrollauswahl und der Verknüpfung mit Risikobewertungen. Diese müssen dennoch manuell auf Richtigkeit überprüft werden.

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 Kontrollen implementiert werden sollen.

Schritt 2: Kontrollen auf Risiken abbilden

Für jedes Risiko, das einer Behandlung bedarf, identifizieren Sie, welche Anhang-A-Kontrollen es auf ein akzeptables Niveau reduzieren würden. Ein Risiko kann mehrere Kontrollen erfordern; eine Kontrolle kann mehrere Risiken adressieren.

Schritt 3: Aufnahme/Ausschluss bestimmen

Kontrollen, die identifizierte Risiken adressieren, werden aufgenommen. Kontrollen, die keine Ihrer Risiken adressieren, können ausgeschlossen werden (mit Begründung).

Schritt 4: Implementierung beschreiben

Für aufgenommene Kontrollen dokumentieren Sie, wie Sie diese implementieren. Seien Sie spezifisch genug, damit Auditoren Ihren Ansatz verstehen, ohne ganze Verfahren zu duplizieren.

Schritt 5: Ausschlüsse begründen

Für ausgeschlossene Kontrollen erklären Sie, warum diese basierend auf Ihrer Risikobewertung oder dem organisatorischen Kontext nicht anwendbar sind. Verweisen Sie nach Möglichkeit auf spezifische Ergebnisse Ihres Risikoregisters.

Schritt 6: Überprüfung und Genehmigung

Die Geschäftsführung sollte die SoA formal überprüfen und genehmigen, wobei die Kontrollauswahlentscheidungen und etwaige verbleibende Risiken anerkannt werden.

Häufige SoA-Fehler

Zu viele Kontrollen ausschließen

Organisationen schließen manchmal Kontrollen aus, um den Implementierungsaufwand zu reduzieren. Auditoren prüfen Ausschlüsse sorgfältig – wenn Ihre Risikobewertung gründlich ist, sollten die meisten Kontrollen aufgenommen werden.

Generische Implementierungsbeschreibungen

Kontrollbeschreibungen aus ISO 27002 kopieren, ohne Ihre tatsächliche Implementierung zu beschreiben. Auditoren müssen verstehen, was Sie tun, nicht was der Standard sagt.

Fehlende Risikoverknüpfungen

Es versäumen, Kontrollen mit spezifischen Risiken in Ihrer Risikobewertung zu verknüpfen. Dies unterbricht die Nachvollziehbarkeit und deutet darauf hin, dass Kontrollen willkürlich ausgewählt wurden.

Unvollständige Abdeckung

Vergessen, alle 93 Kontrollen zu behandeln. Selbst wenn eine Kontrolle offensichtlich nicht anwendbar erscheint, muss sie in der SoA mit einer Begründung für den Ausschluss aufgeführt werden.

Kein Überprüfungszyklus

Die SoA einmalig während der Erstimplementierung erstellen und nie aktualisieren, trotz organisatorischer Änderungen oder neuer Risiken.

SoA vs. andere ISO-27001-Dokumente

SoA vs. Risikobehandlungsplan

Der Risikobehandlungsplan beschreibt, wie Sie ausgewählte Kontrollen implementieren werden (Zeitpläne, Verantwortlichkeiten, Ressourcen). Die SoA erklärt, welche Kontrollen implementiert werden und warum. Die beiden Dokumente ergänzen sich.

SoA vs. Kontrollnachweise

Die SoA beschreibt, welche Kontrollen Sie implementieren. Nachweise belegen, dass die Kontrollen tatsächlich wirksam betrieben werden. Während Audits entnehmen Auditoren Kontrollen aus Ihrer SoA und fordern entsprechende Nachweise an.

SoA vs. Richtlinien und Verfahren

Richtlinien und Verfahren bieten detaillierte Anweisungen zur Implementierung von Kontrollen. Die SoA fasst auf hoher Ebene zusammen, welche Kontrollen existieren und wie sie funktionieren.

Wie Auditoren die SoA nutzen

Stufe-1-Audit (Dokumentenprüfung)

Auditoren überprüfen, ob Ihre SoA vollständig ist (alle 93 Kontrollen behandelt), logisch strukturiert und mit Ihrer Risikobewertung abgestimmt. Sie prüfen, ob die Begründungen für Ausschlüsse sinnvoll sind.

Stufe-2-Audit (Implementierungsüberprüfung)

Auditoren entnehmen Kontrollen aus Ihrer SoA und fordern Nachweise an, dass diese wie beschrieben implementiert wurden. Sie testen Kontrollen über alle vier Themenbereiche und organisatorischen Bereiche innerhalb des Geltungsbereichs.

Auslöser für Nichtkonformitäten

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

• Als „aufgenommen“ markierte Kontrollen, die nicht tatsächlich implementiert sind
• Ausschlüsse ohne gültige Begründung
• SoA spiegelt nicht die tatsächlichen Ergebnisse der Risikobewertung wider
• Fehlende Kontrollen (weniger als 93 aufgeführt)
• Implementierungsbeschreibungen zu vage, um sie zu überprüfen

Pflege der SoA im Laufe der Zeit

Jährliche Aktualisierung der Risikobewertung

Wenn Sie geplante Risikobewertungen durchführen, überprüfen Sie die SoA, um festzustellen, ob die Kontrollauswahl weiterhin angemessen ist. Neue Risiken können zuvor ausgeschlossene Kontrollen erforderlich machen.

Organisatorische Änderungen

Aktualisieren Sie die SoA, wenn:

• Neue Technologien eingeführt werden (können neue technische Kontrollen erfordern)
• Das Geschäftsmodell sich ändert (z. B. Umstellung auf Cloud verändert physische Kontrollen)
• Geografische Expansion neue regulatorische Anforderungen mit sich bringt
• Fusionen oder Übernahmen das Risikoprofil verändern

Ereignisgesteuerte Überprüfungen

Nach erheblichen Sicherheitsvorfällen überprüfen Sie, ob bestehende Kontrollen wirksam waren oder ob zusätzliche Kontrollen (zuvor ausgeschlossen) implementiert werden sollten.

Überwachungsaudits

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

SoA und Anpassung von Kontrollen

Standard erlaubt Anpassungen

ISO 27001 erlaubt es Organisationen, Kontrollen basierend auf Größe, Komplexität und Risiko unterschiedlich zu implementieren. Ihre SoA sollte Ihre spezifische Implementierung widerspiegeln, nicht eine generische Vorlage.

Zusätzliche Kontrollen über Anhang A hinaus

Wenn Ihre Risikobewertung Risiken identifiziert, die durch die 93 Standardkontrollen nicht ausreichend abgedeckt werden, können Sie zusätzliche Kontrollen implementieren. Listen Sie diese in Ihrer SoA oder einem ergänzenden Dokument auf.

Verhältnismäßigkeit ist entscheidend

Die Implementierung von „A.6.3 Schulung zur Informationssicherheit“ durch ein 10-Personen-Startup wird sich von der eines 10.000-Personen-Unternehmens unterscheiden. Beide können konform sein, wenn sie dem Kontext angemessen sind und das Risiko wirksam reduzieren.

Verwandte Konzepte

• Annex A Controls – Die 93 Sicherheitskontrollen, die Ihre SoA behandeln muss
• Risk Assessment – Prozess, der die Kontrollauswahl in Ihrer SoA steuert
• Risk Treatment – Implementierung der in Ihrer SoA identifizierten Kontrollen
• Control – Die Sicherheitsmaßnahmen, die Sie in Ihrer SoA auswählen
• Wie Sie mit der ISO-27001-Implementierung mithilfe von KI beginnen

Hilfe erhalten

Beschleunigen Sie die Erstellung der SoA mit ISMS Copilot. Generieren Sie maßgeschneiderte Implementierungsbeschreibungen, validieren Sie Ihre Begründungen anhand der Ergebnisse der Risikobewertung und stellen Sie sicher, dass alle 93 Kontrollen ordnungsgemäß behandelt werden.