ISO 27001 Erklaerung zur Anwendbarkeit (SoA): So erstellen Sie sie

Die Erklaerung zur Anwendbarkeit ist das wichtigste einzelne Dokument in Ihrem ISO 27001 ISMS. Das ist keine Uebertreibung. Es ist das Dokument, das Ihre Risikobewertung mit Ihren Kontrollen verbindet, begruendet, warum Sie implementiert haben, was Sie implementiert haben (und ausgeschlossen haben, was Sie ausgeschlossen haben), und als primaerer Referenzpunkt fuer Zertifizierungsauditoren dient. Eine unzureichende SoA ist der schnellste Weg zu Audit-Nichtkonformitaeten, und eine gut erarbeitete SoA zeigt, dass Ihr ISMS ein kohaerentes, risikogetriebenes System ist und keine zufaellig zusammengestellte Sammlung von Kontrollen.

Klausel 6.1.3 d) von ISO 27001 verlangt von Organisationen, eine Erklaerung zur Anwendbarkeit zu erstellen, die die notwendigen Kontrollen, die Begruendung fuer ihre Einbeziehung, ob sie implementiert sind oder nicht, und die Begruendung fuer den Ausschluss jeglicher Kontrollen aus Annex A enthaelt. Jede der 93 Annex A Kontrollen muss adressiert werden — Sie koennen Kontrollen nicht einfach ohne Erklaerung weglassen.

Dieser Leitfaden erlaeutert, was die SoA ist, was sie enthalten muss, wie Sie eine Schritt fuer Schritt aus Ihrem Risikobehandlungsplan erstellen und welche haeufigen Fehler zu Audit-Feststellungen fuehren.

Was ist die Erklaerung zur Anwendbarkeit?

Die Erklaerung zur Anwendbarkeit ist eine dokumentierte Aufzeichnung aller fuer das ISMS in Betracht gezogenen Kontrollen, zusammen mit der Begruendung fuer ihre Einbeziehung oder ihren Ausschluss. Sie verbindet zwei kritische Prozesse:

1. Ergebnisse der Risikobewertung — die Risiken, die Sie identifiziert, analysiert und bewertet haben
2. Kontrollimplementierung — die spezifischen Massnahmen, die Sie zur Behandlung dieser Risiken eingesetzt haben

Ohne die SoA gibt es keine formale Verbindung zwischen “wir haben diese Risiken identifiziert” und “wir haben diese Kontrollen implementiert.” Die Risikobewertung sagt Ihnen, was schiefgehen koennte. Die SoA sagt Ihnen, was Sie dagegen unternommen haben — und, ebenso wichtig, was Sie beschlossen haben, nicht zu tun und warum.

Wo die SoA im ISMS steht

Die SoA wird nach der Risikobewertung und dem Risikobehandlungsplan erstellt und vor (oder gleichzeitig mit) der Kontrollimplementierung. Die Reihenfolge ist:

1. Risikobewertung (Klausel 6.1.2) — Risiken identifizieren und bewerten
2. Risikobehandlungsplan (Klausel 6.1.3) — entscheiden, wie jedes Risiko behandelt wird
3. Erklaerung zur Anwendbarkeit (Klausel 6.1.3 d) — dokumentieren, welche Kontrollen welche Risiken adressieren
4. Kontrollimplementierung — die in der SoA dokumentierten Kontrollen umsetzen
5. Internes Audit (Klausel 9.2) — ueberpruefen, ob Kontrollen implementiert und wirksam sind
6. Zertifizierungsaudit — externer Auditor prueft die SoA und verifiziert die Implementierung

In der Praxis sind die Schritte 3 und 4 oft iterativ — Sie koennen die SoA verfeinern, waehrend Sie Kontrollen implementieren und feststellen, dass einige Kontrollen angepasst oder zusaetzliche Kontrollen benoetigt werden.

Was Klausel 6.1.3 tatsaechlich verlangt

Klausel 6.1.3 d) besagt, dass die Organisation eine Erklaerung zur Anwendbarkeit erstellen soll, die Folgendes enthaelt:

• Die notwendigen Kontrollen — unter Beruecksichtigung der Ergebnisse der Risikobewertung und des Risikobehandlungsprozesses, und unabhaengig davon, ob sie aus Annex A oder einer anderen Quelle stammen
• Begruendung fuer ihre Einbeziehung — warum jede Kontrolle im Geltungsbereich ist
• Ob die notwendigen Kontrollen implementiert sind oder nicht — aktueller Implementierungsstatus
• Begruendung fuer den Ausschluss von Annex A Kontrollen — warum ausgeschlossene Kontrollen nicht zutreffen

Der Ausdruck “unabhaengig davon, ob sie aus Annex A oder einer anderen Quelle stammen” ist wichtig. Ihre SoA muss alle 93 Annex A Kontrollen als Grundlage enthalten, aber Sie koennen auch Kontrollen aus anderen Quellen aufnehmen (NIST, CIS, branchenspezifische Rahmenwerke oder benutzerdefinierte Kontrollen, die Ihre Organisation entwickelt hat). Annex A ist das Mindestset, das zu beruecksichtigen ist, nicht das Maximum.

Erforderliche Bestandteile der SoA

Eine vollstaendige SoA enthaelt die folgenden Informationen fuer jede Kontrolle:

Kontrollreferenz und Titel

Die Annex A Kontrollnummer und ihr Name. Fuer die 2022-Version ist dies A.5.1 bis A.8.34. Wenn Sie zusaetzliche Kontrollen aus anderen Quellen haben, fuegen Sie diese mit einem konsistenten Referenzschema ein (z.B. CUSTOM-001, NIST-AC-2).

Einbeziehungs- oder Ausschlussentscheidung

Eine klare Aussage, ob die Kontrolle fuer Ihr ISMS einbezogen (anwendbar) oder ausgeschlossen (nicht anwendbar) ist. Dies ist eine binaere Entscheidung — es gibt kein “teilweise anwendbar.” Wenn irgendein Aspekt einer Kontrolle zutrifft, ist sie einbezogen.

Begruendung fuer die Einbeziehung

Fuer jede einbezogene Kontrolle geben Sie an, warum sie notwendig ist. Die Begruendung sollte auf einen oder mehrere der folgenden Punkte zurueckfuehrbar sein:

• Risikobehandlung — die Kontrolle mindert ein bestimmtes, in der Risikobewertung identifiziertes Risiko (Referenz auf die Risiko-ID)
• Gesetzliche oder regulatorische Anforderung — die Kontrolle ist durch geltendes Recht oder Vorschriften erforderlich (z.B. GDPR, Branchenregulierung)
• Vertragliche Verpflichtung — die Kontrolle ist durch Kundenvertraege oder Geschaeftsvereinbarungen erforderlich
• Bewaehrte Praxis — die Kontrolle wird als bewaehrte Praxis implementiert, auch wenn kein spezifisches Risiko, keine gesetzliche oder vertragliche Anforderung sie vorschreibt (dies ist akzeptabel, sollte aber die Ausnahme sein, nicht die Regel)

Beispiel fuer eine Einbeziehungsbegruendung: “Einbezogen. A.8.5 (Sichere Authentifizierung) adressiert RISK-2026-003 (Unautorisierter Zugriff auf Kundendaten durch Kompromittierung von Anmeldeinformationen) und RISK-2026-015 (Account-Uebernahme durch Phishing). MFA ist auch eine vertragliche Anforderung in unseren Enterprise-Kundenvereinbarungen.”

Begruendung fuer den Ausschluss

Fuer jede ausgeschlossene Kontrolle geben Sie an, warum sie fuer Ihr ISMS nicht anwendbar ist. Die Begruendung muss nachweisen, dass der Ausschluss der Kontrolle die Informationssicherheit nicht gefaehrdet. Allgemeine Aussagen wie “nicht anwendbar” sind unzureichend.

Beispiel fuer eine Ausschlussbegruendung: “Ausgeschlossen. A.7.12 (Verkabelungssicherheit) ist nicht anwendbar, da die Organisation kein eigenes Rechenzentrum oder keinen Serverraum betreibt. Die gesamte Produktionsinfrastruktur wird bei AWS gehostet, wo die physische Verkabelungssicherheit von AWS im Rahmen ihres Shared-Responsibility-Modells verwaltet wird. Die Buerovernetzung verwendet standardmaessige kommerzielle Ausruestung, ohne dass sensible Daten lokal verarbeitet werden. Der Ausschluss dieser Kontrolle erzeugt kein unadressiertes Sicherheitsrisiko.”

Implementierungsstatus

Fuer jede einbezogene Kontrolle geben Sie an, ob sie:

• Implementiert — die Kontrolle ist vollstaendig eingesetzt und in Betrieb
• Teilweise implementiert — einige Aspekte sind vorhanden, andere stehen noch aus (beschreiben Sie, was erledigt ist und was noch aussteht)
• Geplant — die Kontrolle ist noch nicht implementiert, aber zur Implementierung vorgesehen (einschliesslich Zieldatum)
• Noch nicht begonnen — die Kontrolle ist einbezogen, aber die Implementierung hat noch nicht begonnen (einschliesslich Zieldatum)

Der Implementierungsstatus ist besonders wichtig bei der Erstzertifizierung. Es ist akzeptabel, Kontrollen zu haben, die zum Zeitpunkt der SoA-Erstellung “geplant” oder “teilweise implementiert” sind — aber sie muessen vor dem Stage-2-Zertifizierungsaudit vollstaendig implementiert sein. Auditoren werden die Implementierung anhand dessen verifizieren, was die SoA behauptet.

Kontrolleigentuemer

Bestimmen Sie eine Person, die fuer die Implementierung und den laufenden Betrieb jeder Kontrolle verantwortlich ist. Dies wird nicht immer von Auditoren verlangt, ist aber dringend empfohlen, da es Verantwortlichkeit schafft und sicherstellt, dass Kontrollen nicht verwaisen.

Schritt fuer Schritt: Die SoA aus Ihrem Risikobehandlungsplan erstellen

Schritt 1: Mit der vollstaendigen Annex A Kontrollliste beginnen

Erstellen Sie ein Dokument (Tabelle, Datenbank oder Compliance-Management-Tool), das alle 93 Annex A Kontrollen auflistet. Jede Zeile repraesentiert eine Kontrolle mit Spalten fuer: Kontrollreferenz, Kontrolltitel, Einbeziehung/Ausschluss, Begruendung, Implementierungsstatus, Risikorreferenz(en) und Eigentuemer.

Ueberspringen Sie keine Kontrollen. Jede der 93 muss eine Zeile und eine Entscheidung haben. Auditoren werden auf Vollstaendigkeit pruefen.

Schritt 2: Ihren Risikobehandlungsplan auf Annex A Kontrollen abbilden

Nehmen Sie Ihren Risikobehandlungsplan — der jedes Risiko und die von Ihnen beschlossenen Behandlungsmassnahmen auflistet — und bilden Sie jede Behandlungsmassnahme auf eine oder mehrere Annex A Kontrollen ab.

Beispiel-Zuordnung:

Risiko	Behandlungsmassnahme	Annex A Kontrolle
RISK-001: Unautorisierter Zugriff auf Produktionsdatenbank	MFA fuer alle Produktionszugriffe implementieren	A.8.5 (Sichere Authentifizierung)
RISK-001: Unautorisierter Zugriff auf Produktionsdatenbank	Rollenbasierte Zugriffskontrolle mit geringsten Rechten durchsetzen	A.5.15 (Zugriffskontrolle), A.8.3 (Einschraenkung des Informationszugriffs)
RISK-001: Unautorisierter Zugriff auf Produktionsdatenbank	Vierteljaehrliche Zugangspruefungen durchfuehren	A.5.18 (Zugriffsrechte)
RISK-002: Datenschutzverletzung durch Software-Schwachstelle	Schwachstellen-Scanning in CI/CD implementieren	A.8.8 (Management technischer Schwachstellen), A.8.29 (Sicherheitstests)
RISK-002: Datenschutzverletzung durch Software-Schwachstelle	Code-Review fuer alle Aenderungen durchsetzen	A.8.25 (Sicherer Entwicklungslebenszyklus)
RISK-003: Lieferantenverletzung mit Offenlegung von Kundendaten	Sicherheitsbewertungen von Lieferanten durchfuehren	A.5.19 (Lieferantenbeziehungen)
RISK-003: Lieferantenverletzung mit Offenlegung von Kundendaten	Sicherheitsanforderungen in Lieferantenvertraege aufnehmen	A.5.20 (Lieferantenvereinbarungen)

Diese Zuordnung identifiziert, welche Annex A Kontrollen “notwendig” sind — sie sind einbezogen, weil sie direkt identifizierte Risiken adressieren.

Schritt 3: Kontrollen identifizieren, die durch Gesetze, Vorschriften oder Vertraege erforderlich sind

Einige Annex A Kontrollen sind notwendig, nicht wegen eines bestimmten Risikos in Ihrem Register, sondern aufgrund gesetzlicher, regulatorischer oder vertraglicher Verpflichtungen.

Beispiele:

• A.5.34 (Datenschutz und Schutz personenbezogener Daten) — erforderlich, wenn Sie personenbezogene Daten verarbeiten, die der GDPR oder anderen Datenschutzvorschriften unterliegen
• A.5.31 (Gesetzliche, regulatorische und vertragliche Anforderungen) — erforderlich fuer alle Organisationen, um geltende gesetzliche Anforderungen zu identifizieren
• A.5.28 (Beweissicherung) — kann durch Branchenvorschriften erforderlich sein, die forensische Bereitschaft vorschreiben
• A.8.24 (Einsatz von Kryptographie) — Verschluesselungsanforderungen koennen vertragliche Verpflichtungen in Enterprise-Kundenvereinbarungen sein

Kennzeichnen Sie diese Kontrollen als einbezogen mit der entsprechenden Begruendung (gesetzliche Anforderung, vertragliche Verpflichtung).

Schritt 4: Verbleibende Kontrollen auf Anwendbarkeit pruefen

Nachdem Sie Risikobehandlungsmassnahmen und gesetzliche/vertragliche Anforderungen zugeordnet haben, sind moeglicherweise einige Annex A Kontrollen noch nicht adressiert. Fuer jede verbleibende Kontrolle bestimmen Sie, ob sie auf Ihre Organisation anwendbar ist:

• Adressiert die Kontrolle ein Risiko, das in Ihrer Umgebung besteht? Wenn ja, haben Sie moeglicherweise eine Luecke in Ihrer Risikobewertung — erwaegen Sie, ob das Risiko in Ihr Register aufgenommen werden sollte oder ob bestehende Kontrollen es bereits unter einer anderen Annex A Referenz adressieren.
• Ist die Kontrolle fuer Ihren Betrieb, Ihre Technologie oder Ihr Geschaeftsmodell relevant? Cloud-native SaaS-Unternehmen koennen feststellen, dass einige physische Kontrollen tatsaechlich nicht anwendbar sind. Aber seien Sie vorsichtig mit Ausschluessen — Auditoren pruefen sie genau.
• Wuerde der Ausschluss der Kontrolle eine Sicherheitsluecke schaffen? Wenn der Ausschluss einer Kontrolle bedeutet, dass keine Massnahme eine relevante Bedrohung adressiert, ist der Ausschluss unangemessen.

Schritt 5: Begruendungen dokumentieren

Fuer jede Kontrolle — einbezogene und ausgeschlossene — schreiben Sie eine klare, spezifische Begruendung. Dies ist der zeitaufwaendigste Schritt, aber auch der wichtigste fuer die Audit-Bereitschaft.

Qualitaetsspektrum der Begruendungen:

Schlecht (wird Audit-Fragen ausloesen):

• “Einbezogen — fuer die Sicherheit erforderlich”
• “Ausgeschlossen — nicht anwendbar”
• “Einbezogen — bewaehrte Praxis”

Akzeptabel (erfuellt Mindestanforderungen):

• “Einbezogen — adressiert das Risiko des unautorisierten Zugriffs auf Produktionssysteme (RISK-2026-003)”
• “Ausgeschlossen — die Organisation hat kein physisches Rechenzentrum; die gesamte Infrastruktur ist cloud-gehostet”

Stark (demonstriert ein ausgereiftes, risikogetriebenes ISMS):

• “Einbezogen — adressiert RISK-2026-003 (Unautorisierter Zugriff auf Produktionssysteme durch Kompromittierung von Anmeldeinformationen, als Hoch eingestuft). Implementiert durch Okta MFA-Durchsetzung fuer alle Produktionszugriffe, SSO-Integration mit AWS IAM Identity Center und Sitzungsmanagement-Richtlinien, die eine erneute Authentifizierung nach 12 Stunden Inaktivitaet erfordern. Zuletzt verifiziert waehrend der Zugangspruefung Q3 2026.”
• “Ausgeschlossen — die Organisation betreibt kein physisches Rechenzentrum oder keinen Serverraum. Die gesamte Produktionsinfrastruktur wird in AWS eu-west-1 und eu-central-1 Regionen gehostet, wo die physische Verkabelungssicherheit von AWS unter SOC 2 Type II Zertifizierung verwaltet wird (Bericht jaehrlich unter A.5.22 ueberprueft). Die Buerovernetzung besteht aus standardmaessiger kommerzieller Ausruestung, die keine sensiblen Daten verarbeitet. Restrisiko aus diesem Ausschluss: vernachlaessigbar.”

Schritt 6: Implementierungsstatus erfassen

Fuer jede einbezogene Kontrolle bewerten und dokumentieren Sie den aktuellen Implementierungsstatus. Seien Sie ehrlich — den Implementierungsstatus falsch darzustellen und waehrend des Audits ertappt zu werden, ist weitaus schlimmer als zuzugeben, dass eine Kontrolle noch implementiert wird.

Beispiele fuer den Implementierungsstatus:

• A.8.5 (Sichere Authentifizierung) — Implementiert. MFA ueber Okta fuer alle internen Systeme durchgesetzt. SSO konfiguriert fuer AWS, GitHub, Datadog und Jira. Hardware-Sicherheitsschluessel an alle Ingenieure mit Produktionszugriff ausgegeben. Letzte Konfigurationsueberpruefung: Januar 2026.

• A.8.12 (Verhinderung von Datenlecks) — Teilweise implementiert. Endpunkt-DLP auf allen firmenverwalteten Laptops bereitgestellt (CrowdStrike Falcon). E-Mail-DLP-Regeln in Google Workspace aktiv. API-Level-DLP-Ueberwachung fuer Q2 2026 geplant (Zielabschluss: Mai 2026).

• A.8.11 (Datenmaskierung) — Geplant. Evaluierung des Datenmaskierungstools abgeschlossen. Ausgewaehlte Loesung: Tonic.ai. Implementierung fuer Q2 2026 geplant, beginnend mit der Staging-Umgebungs-Datenaktualisierungspipeline. Zielabschluss: Juni 2026.

Schritt 7: Eigentuemer zuweisen

Weisen Sie eine namentlich genannte Person (kein Team oder keine Rolle) als Eigentuemer fuer jede Kontrolle zu. Der Eigentuemer ist verantwortlich fuer:

• Sicherstellung, dass die Kontrolle wie dokumentiert implementiert ist
• Pflege von Nachweisen fuer den Betrieb der Kontrolle
• Berichterstattung ueber die Wirksamkeit der Kontrolle waehrend Management-Reviews
• Aktualisierung der Kontrolle, wenn sich Risiken, Anforderungen oder die Umgebung aendern

Fuer SaaS-Unternehmen folgt die Kontrolleigentuemschaft oft diesem Muster:

Kontrollthema	Typischer Eigentuemer
A.5 Organisatorisch (Governance, Richtlinien)	CISO / Leiter Sicherheit
A.5 Organisatorisch (Lieferantenmanagement)	Lieferantenmanagement-Leiter / Beschaffung
A.6 Personen	HR-Leiter / People Operations
A.7 Physisch	Bueromanager / Gebaeudeverwaltung
A.8 Technologisch (Infrastruktur)	Leiter Plattform / Infrastruktur-Engineering
A.8 Technologisch (Anwendung)	Leiter Engineering / CTO
A.8 Technologisch (Endpunkte)	Leiter IT-Betrieb

Schritt 8: Ueberpruefen und genehmigen

Die fertiggestellte SoA muss vom Management ueberprueft und genehmigt werden — typischerweise der ISMS-Eigentuemer (CISO), der Managementvertreter oder das Risikokomitee. Die Genehmigung zeigt, dass das Management die Kontrollauswahl, die Ausschlussentscheidungen und den aktuellen Implementierungsstatus ueberprueft und akzeptiert hat.

Dokumentieren Sie die Genehmigung mit:

• Name und Rolle des Genehmigenden
• Genehmigungsdatum
• Versionsnummer — die SoA ist ein versioniertes Dokument, das sich im Laufe der Zeit aendert
• Naechstes Ueberpruefungsdatum — wann die SoA formell ueberprueft wird (mindestens jaehrlich)

Die SoA als lebendes Dokument

Die Erklaerung zur Anwendbarkeit ist kein einmaliges Ergebnis, das Sie fuer die Zertifizierung erstellen und abheften. Sie ist ein lebendes Dokument, das aktualisiert werden muss, wann immer sich Ihr ISMS aendert.

Ausloeser fuer SoA-Aktualisierungen

Aenderungen der Risikobewertung. Wenn neue Risiken identifiziert werden, bestehende Risiken neu bewertet werden oder Risikobehandlungsplaene sich aendern, muss die SoA aktualisiert werden, um etwaige Aenderungen bei der Kontrollauswahl oder Begruendung widerzuspiegeln. Wenn Ihre jaehrliche Risikobewertung neue Bedrohungen identifiziert, die zusaetzliche Kontrollen erfordern, werden diese Kontrollen der SoA hinzugefuegt.

Fortschritt der Kontrollimplementierung. Wenn Kontrollen von “geplant” ueber “teilweise implementiert” zu “implementiert” wechseln, aktualisieren Sie die SoA, um den aktuellen Status widerzuspiegeln. Dies ist besonders wichtig in der Zeit zwischen der ersten SoA-Erstellung und dem Stage-2-Zertifizierungsaudit.

Organisatorische Aenderungen. Neue Produkte, Dienstleistungen, Maerkte oder Geschaeftsmodelle koennen neue Risiken einfuehren oder zuvor ausgeschlossene Kontrollen relevant machen. Wenn Ihr SaaS-Unternehmen ein Produkt einfuehrt, das Gesundheitsdaten verarbeitet, muessen Kontrollen zur regulatorischen Compliance (A.5.31, A.5.34) moeglicherweise aktualisiert begruendet werden.

Regulatorische Aenderungen. Neue Gesetze oder aktualisierte Vorschriften koennen zusaetzliche Kontrollen erfordern oder die Begruendung fuer bestehende aendern.

Audit-Feststellungen. Wenn Ihr internes Audit oder ein Ueberwachungsaudit Luecken identifiziert, muss die SoA moeglicherweise aktualisiert werden, um Kontrollen hinzuzufuegen, Begruendungen zu staerken oder Behauptungen zum Implementierungsstatus zu korrigieren.

Technologieaenderungen. Die Migration von Cloud-Anbietern, die Einfuehrung neuer Entwicklungstools oder die Aenderung Ihrer Architektur koennen sich darauf auswirken, welche Kontrollen anwendbar sind und wie sie implementiert werden.

Versionskontrolle

Fuehren Sie eine Versionshistorie fuer die SoA:

Version	Datum	Autor	Aenderungen	Genehmigt von
1.0	15.01.2026	Jane Smith, CISO	Erste SoA fuer die Zertifizierung	John Doe, CTO
1.1	20.04.2026	Jane Smith, CISO	Status von A.8.12 auf Implementiert aktualisiert; RISK-2026-042-Zuordnung zu A.5.23 hinzugefuegt	John Doe, CTO
1.2	10.07.2026	Jane Smith, CISO	Jaehrliche Ueberpruefung; Begruendungen fuer A.7.1-A.7.6 nach Bueroumzug aktualisiert	John Doe, CTO

Ueberpruefungsrhythmus

• Minimum: Jaehrliche Ueberpruefung abgestimmt auf den Management-Review-Zyklus
• Empfohlen: Vierteljaehrliche Ueberpruefung abgestimmt auf die Risikoregister-Reviews
• Anlassgetrieben: Aktualisierung innerhalb von 30 Tagen nach signifikanten Aenderungen (neue Risiken, Audit-Feststellungen, organisatorische Aenderungen)

SoA vs. Risikobehandlungsplan: Den Unterschied verstehen

Die SoA und der Risikobehandlungsplan sind eng miteinander verbunden, dienen aber unterschiedlichen Zwecken. Die beiden zu verwechseln — oder sie als austauschbar zu behandeln — ist ein haeufiger Fehler.

Risikobehandlungsplan

Zweck: Dokumentiert, wie jedes identifizierte Risiko behandelt wird (mindern, uebertragen, vermeiden, akzeptieren) und die konkreten geplanten Massnahmen.

Inhalt:

• Jedes behandlungsbeduerftige Risiko
• Gewaehlte Behandlungsoption
• Konkrete Behandlungsmassnahmen
• Eigentuemer und Zieltermine
• Erwartetes Restrisiko nach der Behandlung

Fokus: Risikozentriert. Organisiert nach Risiken, nicht nach Kontrollen.

Zielgruppe: Risikoeigentuemer, Management, Auditoren (zur Verifizierung der Behandlungsentscheidungen).

Erklaerung zur Anwendbarkeit

Zweck: Dokumentiert, welche Kontrollen fuer das ISMS im Geltungsbereich sind, mit Begruendung fuer Einbeziehung und Ausschluss.

Inhalt:

• Jede Annex A Kontrolle (alle 93)
• Einbeziehungs-/Ausschlussentscheidung mit Begruendung
• Implementierungsstatus
• Risikorreferenzen (Rueckverfolgung der Kontrollen zu Risiken)
• Kontrolleigentuemer

Fokus: Kontrollzentriert. Organisiert nach der Annex A Kontrollstruktur.

Zielgruppe: Auditoren (primaere Referenz waehrend der Zertifizierung), Management, Implementierungsteams.

Wie sie zusammenhaengen

Der Risikobehandlungsplan ist ein Input fuer die SoA. Wenn Ihr Risikobehandlungsplan sagt “RISK-001 durch Implementierung von MFA mindern”, erfasst die SoA, dass A.8.5 (Sichere Authentifizierung) einbezogen ist, weil sie RISK-001 adressiert, und vermerkt deren Implementierungsstatus.

Die Beziehung ist viele-zu-viele:

• Ein Risiko kann mehrere Kontrollen erfordern (RISK-001 wird A.5.15, A.5.18, A.8.3, A.8.5 zugeordnet)
• Eine Kontrolle kann mehrere Risiken adressieren (A.8.15 Protokollierung adressiert Risiken im Zusammenhang mit unautorisiertem Zugriff, Vorfallserkennung, forensischer Bereitschaft und Compliance)

Beide Dokumente muessen konsistent sein. Wenn der Risikobehandlungsplan besagt, dass ein Risiko durch bestimmte Kontrollen gemindert wird, muss die SoA diese Kontrollen als einbezogen zeigen. Wenn die SoA eine Kontrolle ausschliesst, sollte kein Risiko im Behandlungsplan von dieser Kontrolle fuer die Minderung abhaengen.

Haeufige SoA-Audit-Nichtkonformitaeten

Das Verstaendnis dessen, worauf Auditoren achten, hilft Ihnen, die haeufigsten Feststellungen zu vermeiden.

Nichtkonformitaet 1: Fehlende oder unvollstaendige Begruendungen

Die Feststellung: Kontrollen sind als einbezogen oder ausgeschlossen gekennzeichnet, ohne angemessene Begruendung. Die SoA sagt “Einbezogen” oder “Ausgeschlossen”, erklaert aber nicht warum.

Warum es wichtig ist: Ohne Begruendung kann der Auditor nicht ueberpruefen, ob Ihre Kontrollauswahl risikogetrieben ist. Es erscheint, als waeren Kontrollen willkuerlich ausgewaehlt oder aus einer Vorlage kopiert worden.

Wie Sie es vermeiden: Schreiben Sie spezifische Begruendungen, die auf Risiko-IDs, gesetzliche Anforderungen oder vertragliche Verpflichtungen verweisen. Fuer Ausschluesse erklaeren Sie, warum das Risiko, das die Kontrolle adressiert, nicht auf Ihre Organisation anwendbar ist.

Nichtkonformitaet 2: Kontrollen ohne gueltige Begruendung ausgeschlossen

Die Feststellung: Kontrollen werden mit Begruendungen ausgeschlossen, die einer Pruefung nicht standhalten. Zum Beispiel der Ausschluss von A.8.8 (Management technischer Schwachstellen) mit der Begruendung “wird vom Cloud-Anbieter verwaltet”, obwohl die Organisation benutzerdefinierten Anwendungscode betreibt, der eindeutig in den Bereich des Schwachstellenmanagements faellt.

Warum es wichtig ist: Ungueltige Ausschluesse deuten entweder auf ein mangelndes Verstaendnis der Kontrollen oder auf den Versuch hin, den Implementierungsaufwand durch Ausschluss anwendbarer Kontrollen zu reduzieren.

Wie Sie es vermeiden: Bevor Sie eine Kontrolle ausschliessen, fragen Sie: “Gibt es ein Szenario innerhalb unseres ISMS-Geltungsbereichs, in dem das Risiko, das diese Kontrolle adressiert, eintreten koennte?” Wenn ja, sollte die Kontrolle wahrscheinlich einbezogen werden. Das Shared-Responsibility-Modell mit Cloud-Anbietern ist eine haeufige Quelle der Verwirrung — Ihr Cloud-Anbieter verwaltet die physische Sicherheit, aber Sie verwalten die Anwendungssicherheit, Zugriffskontrolle, Konfiguration und die meisten anderen Kontrollen.

Nichtkonformitaet 3: Implementierungsstatus falsch dargestellt

Die Feststellung: Die SoA behauptet, eine Kontrolle sei “Implementiert”, aber der Auditor findet keine Nachweise fuer die Implementierung, oder die Implementierung entspricht nicht dem Zweck der Kontrolle.

Warum es wichtig ist: Die falsche Darstellung des Implementierungsstatus untergraebt die Glaubwuerdigkeit der gesamten SoA und kann zu einer schwerwiegenden Nichtkonformitaet fuehren.

Wie Sie es vermeiden: Seien Sie ehrlich beim Implementierungsstatus. “Teilweise implementiert” oder “Geplant mit Zieldatum” ist weitaus besser als eine vollstaendige Implementierung zu behaupten, die nicht nachgewiesen werden kann. Auditoren respektieren Transparenz und arbeiten mit Organisationen an der Behebung von Luecken — sie respektieren keine Falschdarstellungen.

Nichtkonformitaet 4: SoA nicht nach Aenderungen aktualisiert

Die Feststellung: Die SoA spiegelt den Zustand des ISMS zu einem Zeitpunkt wider, der nicht mehr der Realitaet entspricht. Neue Risiken wurden identifiziert, Kontrollen wurden implementiert oder entfernt, aber die SoA wurde nicht aktualisiert.

Warum es wichtig ist: Eine veraltete SoA zeigt, dass das Dokument als einmaliges Zertifizierungsartefakt behandelt wird und nicht als lebendiger Teil des ISMS. Es bedeutet auch, dass der Auditor sich nicht auf die SoA als genaue Darstellung der Kontrollumgebung verlassen kann.

Wie Sie es vermeiden: Etablieren Sie einen Ueberpruefungsrhythmus (vierteljaehrlich empfohlen) und Ausloeser fuer Ad-hoc-Aktualisierungen. Nehmen Sie die SoA-Pflege als Agendapunkt in Management-Reviews auf.

Nichtkonformitaet 5: Keine Rueckverfolgbarkeit zwischen Risikobewertung und SoA

Die Feststellung: Das Risikoregister identifiziert bestimmte Risiken, aber die SoA enthaelt keine Kontrollen, die diese Risiken adressieren. Oder die SoA enthaelt Kontrollen, ohne auf die Risiken zu verweisen, die sie adressieren.

Warum es wichtig ist: Rueckverfolgbarkeit ist das Kernprinzip von ISO 27001. Der Standard verlangt einen risikogetriebenen Ansatz bei der Kontrollauswahl. Ohne Rueckverfolgbarkeit gibt es keinen Nachweis, dass der Ansatz risikogetrieben ist.

Wie Sie es vermeiden: Nehmen Sie Risiko-Referenz-IDs in die SoA-Begruendungsspalte auf. Gleichen Sie bei der Ueberpruefung der SoA gegen das Risikoregister ab, um zu verifizieren, dass jedes Risiko ueber der Akzeptanzschwelle entsprechende Kontrollen hat und jede einbezogene Kontrolle einen dokumentierten Grund fuer die Einbeziehung hat.

Nichtkonformitaet 6: Annex A Kontrollen nicht vollstaendig adressiert

Die Feststellung: Die SoA listet nicht alle 93 Annex A Kontrollen auf. Einige Kontrollen fehlen im Dokument einfach.

Warum es wichtig ist: Klausel 6.1.3 d) verlangt von der Organisation, “alle notwendigen Kontrollen” zu bestimmen und sie mit Annex A zu vergleichen, um sicherzustellen, dass nichts uebersehen wurde. Wenn Kontrollen in der SoA fehlen, gibt es keinen Nachweis, dass sie beruecksichtigt wurden.

Wie Sie es vermeiden: Beginnen Sie mit einer vollstaendigen Liste aller 93 Kontrollen und arbeiten Sie jede einzelne durch. Verwenden Sie eine Vorlage oder ein Compliance-Tool, das Vollstaendigkeit sicherstellt.

Nichtkonformitaet 7: SoA und tatsaechliche Kontrollen stimmen nicht ueberein

Die Feststellung: Die SoA dokumentiert bestimmte Kontrollen, aber die tatsaechliche Implementierung weicht ab. Zum Beispiel sagt die SoA, MFA sei fuer alle Benutzer implementiert, aber der Auditor stellt fest, dass Dienstkonten MFA umgehen.

Warum es wichtig ist: Die SoA soll die Kontrollumgebung genau abbilden. Abweichungen zeigen entweder, dass die SoA eher wunschgemaess als tatsaechlich ist, oder dass Kontrollen seit der letzten Aktualisierung der SoA abgewichen sind.

Wie Sie es vermeiden: Validieren Sie die SoA vor Audits gegen die tatsaechliche Implementierung. Fuehren Sie eine interne Ueberpruefung durch, bei der jemand (nicht der Kontrolleigentuemer) verifiziert, dass jede als “Implementiert” gekennzeichnete Kontrolle tatsaechlich wie beschrieben operiert.

Eine praktische SoA erstellen: Format und Struktur

Tabellenformat

Das gaengigste Format ist eine Tabelle mit den folgenden Spalten:

Spalte	Inhalt
Kontrollreferenz	A.5.1 bis A.8.34
Kontrolltitel	Vollstaendiger Kontrollname aus Annex A
Anwendbar?	Ja / Nein
Begruendung	Grund fuer Einbeziehung oder Ausschluss
Risikorreferenz(en)	Risiko-IDs aus dem Risikoregister
Implementierungsstatus	Implementiert / Teilweise / Geplant / Nicht begonnen
Implementierungsdetails	Wie die Kontrolle implementiert ist (kurz)
Nachweisreferenz	Wo Nachweise fuer die Implementierung zu finden sind
Eigentuemer	Namentlich genannte verantwortliche Person
Zuletzt ueberprueft	Datum der letzten Ueberpruefung
Anmerkungen	Zusaetzlicher Kontext fuer Auditoren

Gliederung nach Thema

Gliedern Sie die SoA nach der Annex A Struktur: A.5 Organisatorisch, A.6 Personen, A.7 Physisch, A.8 Technologisch. Innerhalb jedes Themas listen Sie Kontrollen in numerischer Reihenfolge auf. Dies macht es Auditoren leicht, zu navigieren und mit dem Standard abzugleichen.

Detailgrad

Finden Sie ein Gleichgewicht zwischen Gruendlichkeit und Wartbarkeit. Die Begruendung sollte spezifisch genug sein, um risikogetriebene Entscheidungsfindung zu demonstrieren, aber pragnant genug, dass das Dokument nutzbar bleibt. Eine einzeilige Begruendung pro Kontrolle ist in der Regel zu kurz. Ein ganzer Absatz pro Kontrolle ist in der Regel ausreichend. Eine Seite pro Kontrolle ist uebertrieben und macht das Dokument unwartbar.

Beispiel-SoA-Eintraege

Einbezogene Kontrolle mit Risikobegruendung:

Feld	Inhalt
Referenz	A.8.5
Titel	Sichere Authentifizierung
Anwendbar	Ja
Begruendung	Adressiert RISK-2026-003 (Kompromittierung von Anmeldeinformationen fuehrt zu unautorisiertem Zugriff) und RISK-2026-015 (Phishing-basierte Account-Uebernahme). Auch eine vertragliche Anforderung in Enterprise-Kunden-DPAs.
Risiko-Ref.	RISK-2026-003, RISK-2026-015
Status	Implementiert
Implementierung	MFA ueber Okta fuer alle internen Systeme. SSO-Integration mit AWS, GitHub, Datadog. Hardware-Sicherheitsschluessel fuer Produktionszugriff. Sitzungs-Timeout: 12 Stunden.
Nachweis	Okta MFA-Registrierungsbericht, SSO-Konfigurations-Screenshots, Hardware-Schluessel-Inventar
Eigentuemer	Sarah Chen, Leiterin IT
Ueberprueft	15.02.2026

Ausgeschlossene Kontrolle mit Begruendung:

Feld	Inhalt
Referenz	A.7.12
Titel	Verkabelungssicherheit
Anwendbar	Nein
Begruendung	Die Organisation betreibt kein physisches Rechenzentrum, keinen Serverraum oder keine Netzwerkinfrastruktur ueber die Standardbueroausruestung hinaus. Die gesamte Produktionsinfrastruktur wird in AWS (eu-west-1, eu-central-1) gehostet, wo die physische Verkabelungssicherheit von AWS unter ihrer SOC 2 Type II Zertifizierung verwaltet wird. Die Buerovernetzung verwendet drahtlose Verbindungen fuer Mitarbeitergeraete, ohne dass sensible Daten vor Ort verarbeitet werden.
Risiko-Ref.	Nicht zutreffend
Status	Nicht zutreffend
Implementierung	Nicht zutreffend
Nachweis	Nicht zutreffend
Eigentuemer	Nicht zutreffend
Ueberprueft	15.02.2026

SoA fuer SaaS-Unternehmen: Praktische Ueberlegungen

Cloud-Shared-Responsibility-Modell

Viele SaaS-Unternehmen haben Schwierigkeiten damit, wie Kontrollen zu handhaben sind, die unter das Shared-Responsibility-Modell des Cloud-Anbieters fallen. Das Schluesselprinzip: Sie koennen eine Kontrolle nicht einfach ausschliessen, weil Ihr Cloud-Anbieter einen Teil davon uebernimmt. Sie koennen die Kontrollen des Cloud-Anbieters als Teil Ihrer Implementierung referenzieren, aber die Kontrolle ist weiterhin auf Ihre Organisation anwendbar.

Beispiel: A.7.5 (Schutz vor physischen und umgebungsbedingten Bedrohungen) wird fuer die Produktionsinfrastruktur hauptsaechlich von AWS uebernommen. Aber die Kontrolle wird nicht ausgeschlossen — sie ist einbezogen mit der Begruendung: “Fuer die Produktionsinfrastruktur wird der physische und umgebungsbedingte Schutz von AWS bereitgestellt, verifiziert durch jaehrliche Ueberpruefung des AWS SOC 2 Type II Berichts (A.5.22). Fuer die Bueroraeumlichkeiten werden Branderkennungs- und Loeschsysteme vom Gebaeudeeigntuemer gewartet, verifiziert durch jaehrliche Mietvertragsueberpruefung.”

Multi-Framework-Abstimmung

Wenn Ihr SaaS-Unternehmen auch SOC 2 anstrebt, kann die Abstimmung Ihrer SoA mit den SOC 2 Trust Service Criteria Doppelarbeit reduzieren. Viele Annex A Kontrollen lassen sich direkt auf SOC 2 Common Criteria abbilden. Ihre SoA kann diese Zuordnungen vermerken, um ein einheitliches Kontrollrahmenwerk zu demonstrieren.

Skalierung der SoA mit dem Wachstum

Wenn Ihr SaaS-Unternehmen waechst, wird sich Ihre SoA weiterentwickeln:

• Fruehes Stadium (< 50 Mitarbeiter): Mehr Kontrollen koennen “Geplant” oder “Teilweise implementiert” sein. Konzentrieren Sie sich darauf, die Struktur richtig aufzubauen und auf vollstaendige Implementierung hinzuarbeiten.
• Wachstumsphase (50-200 Mitarbeiter): Die meisten Kontrollen sollten implementiert sein. Beginnen Sie mit der Formalisierung von Prozessen, die zuvor informell gehandhabt wurden. Fuegen Sie Kontrollen fuer das Lieferantenmanagement hinzu, wenn Ihr Lieferantenoekosystem waechst.
• Skalierungsphase (200+ Mitarbeiter): Vollstaendige Implementierung wird erwartet. Konzentrieren Sie sich auf Nachweiserhebung, kontinuierliches Monitoring und Messung der Kontrollwirksamkeit. Erwaegen Sie die Hinzufuegung von Kontrollen ueber Annex A hinaus fuer fortgeschrittene Bedrohungen.

SoA und internes Audit

Ihr internes Audit-Programm nutzt die SoA als Grundlage fuer die Auditplanung. Der interne Auditor verifiziert, dass:

• Jede einbezogene Kontrolle wie beschrieben implementiert ist
• Ausschlussbegruendungen weiterhin gueltig sind
• Der Implementierungsstatus korrekt ist
• Nachweise die Behauptungen in der SoA unterstuetzen
• Die SoA aktuelle Risiken und Kontrollen widerspiegelt

Interne Audit-Feststellungen sollten in SoA-Aktualisierungen einfliessen und eine Schleife zur kontinuierlichen Verbesserung bilden.

Wie GRCTrail hilft

GRCTrail bietet SaaS-Teams einen strukturierten, audit-bereiten Ansatz zur Erstellung und Pflege der Erklaerung zur Anwendbarkeit.

• Automatisierte SoA-Generierung, die Ihre Risikobewertungsergebnisse auf alle 93 Annex A Kontrollen abbildet und Begruendungen basierend auf Ihren identifizierten Risiken und Behandlungsentscheidungen vorausfuellt, sodass Sie mit einem risikogetriebenen Dokument beginnen statt mit einer leeren Tabelle
• Kontrollimplementierungs-Tracking mit Nachweisverknuepfung, sodass jeder SoA-Eintrag mit Implementierungsdetails, zugewiesenen Eigentuemern und unterstuetzenden Nachweisen verbunden ist — Auditoren erhalten die Rueckverfolgbarkeit, die sie suchen, ohne manuelles Abgleichen
• Lebendes-Dokument-Management mit Versionskontrolle, Aenderungsverfolgung und automatisierten Ueberpruefungserinnerungen, die Ihre SoA zwischen Audits aktuell halten, anstatt sie zu einem veralteten Zertifizierungsartefakt werden zu lassen

Starten Sie mit GRCTrail →

Verwandte Leitfaeden

• Was ist ISO 27001? Ein Leitfaden fuer SaaS-Unternehmen
• ISO 27001 Risikobewertung: Prozess, Methodik und Beispiele
• ISO 27001 Annex A Kontrollen: Vollstaendiger Leitfaden zu allen 93 Kontrollen
• ISO 27001 Zertifizierungs-Checkliste
• ISO 27001 Internes-Audit-Leitfaden
• ISO 27001 Anforderungen: Klauseln 4-10 verstehen