SoA nach ISO 27001: Was in die Anwendbarkeitserklärung gehört und worauf Auditoren achten

Was ist die SoA nach ISO 27001, und ist sie Pflicht?

Die Anwendbarkeitserklärung, englisch Statement of Applicability (SoA), ist eine Pflichtanforderung von ISO/IEC 27001:2022 Ziff. 6.1.3 d. Die deutsche Normfassung nennt sie «Erklärung zur Anwendbarkeit», in der Praxis spricht man meist von Anwendbarkeitserklärung oder schlicht von der SoA. Gemeint ist immer dasselbe Dokument.

Die Kapitel 4 bis 10 der Norm dürfen nicht ausgeschlossen werden (Ziff. 1). Ohne SoA werden Sie deshalb nicht zertifiziert. Dieser Beitrag zeigt, wie Sie die Anwendbarkeitserklärung erstellen, begründen und pflegen.

Die deutsche Normfassung nennt die Controls «Massnahmen». Wir verwenden in diesem Beitrag einheitlich diesen Begriff.

Wo steht die Anwendbarkeitserklärung im ISMS-Projekt?

Die SoA steht am Ende der Risikobehandlung, nicht am Anfang des Projekts. Wer mit der Liste aus Anhang A beginnt und Zeile für Zeile «ja» oder «nein» ankreuzt, dreht die Logik der Norm um. Die Reihenfolge ergibt sich aus Ziff. 4 und 6:

1. Anwendungsbereich festlegen (Ziff. 4.3).
2. Anforderungen erfassen (Ziff. 4.2): Gesetze wie das DSG, Branchenvorgaben, Kundenverträge, Ausschreibungen.
3. Risiken beurteilen (Ziff. 6.1.2) mit festgelegten Kriterien zur Risikoakzeptanz.
4. Behandlungsoptionen wählen und Massnahmen festlegen (Ziff. 6.1.3 a und b). Die Massnahmen dürfen aus jeder Quelle stammen (Anmerkung 1 zu b).
5. Mit Anhang A abgleichen (Ziff. 6.1.3 c): Haben Sie eine erforderliche Massnahme übersehen?
6. SoA erstellen (Ziff. 6.1.3 d).
7. Risikobehandlungsplan formulieren (Ziff. 6.1.3 e) und von den Risikoeigentümern genehmigen lassen (Ziff. 6.1.3 f).
8. Umsetzen (Ziff. 8.3) und den Status in der SoA nachführen.
9. Pflegen, sobald sich Scope, Risiken oder Anforderungen ändern.

Anhang A ist also eine Prüfliste gegen Lücken. Die Norm sagt selbst, dass die Massnahmen in Anhang A «nicht erschöpfend» sind und ergänzt werden können (Anmerkung 3 zu Ziff. 6.1.3 c).

Welche vier Inhalte verlangt die Norm in der SoA?

Ziff. 6.1.3 d verlangt genau vier Inhalte:

1. die erforderlichen Massnahmen (aus Ziff. 6.1.3 b und c),
2. die Gründe für ihre Einbeziehung,
3. ob die erforderlichen Massnahmen umgesetzt sind oder nicht,
4. die Gründe für die Nichteinbeziehung von Massnahmen aus Anhang A.

Alles Weitere ist gute Praxis, aber keine Normanforderung. In einer Tabelle sieht das so aus:

Ein bestimmtes Werkzeug verlangt die Norm nicht. Eine sauber geführte Tabelle genügt. Die Spalte mit dem Verweis auf Nachweise empfehlen wir trotzdem dringend: Sie zeigt Ihnen selbst, wo noch Belege fehlen, und Sie sparen im Audit Zeit.

Müssen alle 93 Massnahmen aus Anhang A in die SoA?

Umsetzen müssen Sie nicht alle, berücksichtigen schon. Anhang A der Fassung 2022 enthält 93 Massnahmen in vier Themen:

Für jede nicht einbezogene Massnahme aus Anhang A verlangt die Norm einen Grund. Deshalb führt eine SoA in der Praxis alle 93 Massnahmen auf, dazu Ihre zusätzlichen Massnahmen aus Kundenverträgen, Branchenvorgaben oder anderen Katalogen. Wer nur die umgesetzten Massnahmen auflistet, erfüllt Ziff. 6.1.3 d nicht.

Die Übergangsfrist von der Fassung 2013 endete am 31. Oktober 2025 (IAF MD 26). Seither wird ausschliesslich nach ISO/IEC 27001:2022 zertifiziert, mit 93 Massnahmen in vier Themen. Eine Übersicht mit Beispielen je Thema finden Sie in unserer ISO 27001 Checkliste.

Wie begründen Sie einen Ausschluss so, dass er im Audit hält?

Ein Ausschluss braucht eine nachvollziehbare Herleitung aus Ihrem Anwendungsbereich (Ziff. 4.3), Ihrer Risikobeurteilung (Ziff. 6.1.2) oder den Anforderungen interessierter Parteien (Ziff. 4.2). «Nicht relevant» allein ist keine Begründung. Ein Beispiel:

• Schwach: «A 8.28 Sichere Codierung: nicht relevant.»
• Tragfähig: «A 8.28 Sichere Codierung: nicht einbezogen. Im Anwendungsbereich wird keine Software entwickelt (Scope-Dokument Version X). Eingekaufte Entwicklung ist über A 8.30 und A 5.20 abgedeckt.»

Zulässig ist auch, ein Risiko nach Ihren festgelegten Akzeptanzkriterien zu akzeptieren und eine Massnahme deshalb nicht einzubeziehen. Dann muss die Begründung auf die Risikobeurteilung und auf die Akzeptanz durch den Risikoeigentümer verweisen (Ziff. 6.1.2 a und 6.1.3 f). «Kein Risiko vorhanden» ohne dokumentierte Risikobeurteilung lässt sich nicht belegen.

Besonders heikel sind Ausschlüsse bei diesen Massnahmen:

• A 5.31 und A 5.34: Sie betreffen gesetzliche, regulatorische und vertragliche Anforderungen sowie den Schutz personenbezogener Daten. Für ein Schweizer Unternehmen, das Personendaten bearbeitet und damit unter das DSG fällt, ist ein Ausschluss kaum begründbar.
• A 5.35 und A 5.36: Unabhängige Überprüfung und Einhaltung von Richtlinien und Normen gehören zur Überprüfung des ISMS selbst.
• A 5.19 bis 5.23 und A 8.30: Wer Betrieb, Rechenzentrum oder Entwicklung auslagert, muss die ausgelagerten Prozesse steuern (Ziff. 8.1). Ausgelagert heisst nicht ausgeschlossen.
• Abschnitt 7: Auch ohne eigenen Serverraum gelten physische Massnahmen in der Regel für Büros, Arbeitsplätze und Datenträger.

Wie unterscheiden sich SoA und Risikobehandlungsplan?

Beide entstehen in Ziff. 6.1.3, sind aber zwei verschiedene Dokumente mit verschiedenen Fragen:

Beide müssen sich decken. Steht im Plan eine Massnahme, die in der SoA ausgeschlossen ist, oder gilt in der SoA eine Massnahme als «umgesetzt», die im Plan noch offen ist, ist das ein typischer Auditbefund. Sie dürfen beides in einem Werkzeug führen, solange alle Pflichtinhalte erkennbar bleiben.

Was prüfen Auditoren in der SoA?

Im Stage-1-Audit prüft die Zertifizierungsstelle die dokumentierte Information, darunter die SoA (ISO/IEC 17021-1 Ziff. 9.3.1.2). Im Stage-2-Audit dient sie als Wegweiser: Die Auditoren wählen Stichproben aus den als erforderlich bestimmten Massnahmen und verlangen Nachweise wie Protokolle, Berichte oder Schulungsnachweise. Die SoA ist damit ein Versprechen, das geprüft wird.

Zertifizierungsstellen nennen die Version Ihrer Anwendbarkeitserklärung in den Zertifizierungsunterlagen, in der Regel auf dem Zertifikat. Das verlangt die Norm für Zertifizierungsstellen, ISO/IEC 27006-1. Ändern Sie später, welche Massnahmen im Geltungsbereich abgedeckt sind, informieren Sie die Zertifizierungsstelle. Eine Textänderung, welche die Abdeckung nicht verändert, erfordert keine neuen Zertifizierungsunterlagen.

Diese Fehler fallen in Audits immer wieder auf:

1. «Nicht relevant» ohne Herleitung aus Scope, Risikobeurteilung oder Anforderungen.
2. Ausschluss mit Verweis auf eine Risikobeurteilung, die es nicht gibt oder die das Risiko nicht enthält.
3. Status «umgesetzt» ohne Nachweis.
4. Widerspruch zwischen SoA und Risikobehandlungsplan.
5. Fremde Vorlage mit fremden Begründungen. Vorlagen sind sinnvoll, die Begründungen müssen aber zu Ihrem Scope und Ihren Risiken passen.
6. Nur Anhang A: Zusätzliche Massnahmen aus Kundenverträgen oder Branchenvorgaben fehlen.
7. Keine Version, keine Freigabe, keine Historie (Ziff. 7.5.2 und 7.5.3).
8. Keine Pflege nach dem Audit: neuer Cloud-Dienst, neuer Standort, neue Kundenanforderung, aber die SoA bleibt gleich. Das fällt typischerweise im Überwachungsaudit auf.

Wie oft müssen Sie die Anwendbarkeitserklärung aktualisieren?

Die Norm nennt kein festes Intervall. Sie verlangt aber, dass Sie Risiken in geplanten Abständen und bei erheblichen Änderungen neu beurteilen (Ziff. 8.2) und Änderungen am ISMS geplant durchführen (Ziff. 6.3). Daraus ergeben sich die Anlässe für eine Überprüfung der SoA:

• jede neue Risikobeurteilung (Ziff. 8.2),
• die Managementbewertung mit ihren Entscheidungen zu Änderungen (Ziff. 9.3),
• Korrekturmassnahmen nach Abweichungen (Ziff. 10.2),
• Änderungen am Anwendungsbereich (Ziff. 4.3), etwa ein neuer Standort oder ein neuer Dienst,
• neue gesetzliche oder vertragliche Anforderungen (Ziff. 4.2).

Jede neue Fassung erhält eine Version, ein Datum und eine Freigabe. Die Norm verlangt eine angemessene Überprüfung und Genehmigung dokumentierter Information (Ziff. 7.5.2 c). Wer die SoA freigibt, legt sie nicht fest. In der Praxis gibt sie eine dafür verantwortliche Stelle im Unternehmen frei, üblicherweise die oder der CISO beziehungsweise die ISMS-Verantwortung. Die Geschäftsleitung stellt die nötigen Ressourcen bereit und trägt die Gesamtverantwortung für das ISMS (Ziff. 5.1). Eine ausdrückliche Genehmigung verlangt Ziff. 6.1.3 nur für den Risikobehandlungsplan: Ihn genehmigen die Risikoeigentümer, und sie akzeptieren die Restrisiken (Ziff. 6.1.3 f).

Die Änderung ISO/IEC 27001:2022/Amd 1:2024 zum Klimawandel betrifft Kontext und interessierte Parteien (Ziff. 4.1 und 4.2), nicht Anhang A. Eine eigene «Klima-Massnahme» in der SoA ist nicht verlangt.

Verlangt das Schweizer Recht eine SoA?

Nein. Kein Schweizer Erlass verlangt von Unternehmen eine Anwendbarkeitserklärung oder ein Zertifikat nach ISO 27001. Die SoA ist eine Anforderung der Norm (Ziff. 6.1.3 d). Pflicht wird sie, wenn Sie sich nach ISO 27001 zertifizieren lassen oder wenn ein Kunde, eine Ausschreibung oder eine Aufsicht das Zertifikat verlangt.

Informationssicherheitsgesetz. Das ISG gilt für Bundesbehörden, die Bundesverwaltung und die Armee. Ein Informationssicherheits-Managementsystem verlangt erst die Informationssicherheitsverordnung in Art. 5, und zwar nur von den Bundesämtern, den Generalsekretariaten, den Gruppen und der Bundeskanzlei. Gemeint ist laut den Erläuterungen des VBS ein ISMS «light»: angelehnt an ISO 27001, aber nicht die vollständige Norm und ohne externe Zertifizierung. Eine SoA nennen weder das ISG noch die Verordnung.

Aufträge des Bundes. Unternehmen ohne Verwaltungsaufgaben des Bundes erfasst das ISG vor allem über Aufträge und über die Meldepflicht. Bei sicherheitsempfindlichen Aufträgen, etwa mit «vertraulich» klassifizierten Informationen, durchläuft Ihr Betrieb das Betriebssicherheitsverfahren und erstellt ein Sicherheitskonzept nach den Vorgaben der Fachstelle Betriebssicherheit (Art. 59 ISG, Art. 12 VBSV). Ein ISMS oder ein Zertifikat schreibt die Verordnung nicht vor. Bei anderen Aufträgen halten die Bundesstellen ihre Anforderungen im Vertrag fest (Art. 9 ISG).

Kritische Infrastrukturen. Seit 1. April 2025 müssen unter anderem Energieversorger, Banken, Versicherungen, Spitäler, Telekom- und Cloudanbieter Cyberangriffe innert 24 Stunden dem Bundesamt für Cybersicherheit melden (Art. 74a ff. ISG, Cybersicherheitsverordnung). Das ist eine Meldepflicht, keine Pflicht zu einem ISMS.

Branchenpflichten. Netzbetreiber und grosse Erzeuger und Speicherbetreiber müssen seit 1. Juli 2024 den IKT-Minimalstandard je nach Schutzniveau umsetzen (Art. 5a StromVV). Die darin genannten internationalen Standards wie ISO 27001 sind ausdrücklich nicht verbindlich. Von Banken verlangt die FINMA im Rundschreiben 2023/1 ein Management der IKT- und Cyber-Risiken nach «international anerkannten Standards und Practices», ohne eine bestimmte Norm vorzuschreiben. Für alle anderen Unternehmen ist der IKT-Minimalstandard eine Empfehlung.

Datenschutz. Art. 8 DSG verlangt eine dem Risiko angemessene Datensicherheit, Art. 1 bis 3 DSV nennen Kriterien und Schutzziele, schreiben aber keine Norm vor. Eine SoA kann zeigen, wie Sie Ihre technischen und organisatorischen Massnahmen ausgewählt haben. Die Anforderungen des DSG erfüllt sie damit nicht automatisch.

Verlangt wird ein Zertifikat in der Regel über Kundenverträge oder Ausschreibungen, wobei bei öffentlichen Ausschreibungen auch gleichwertige Nachweise zulässig sind. In der EU fordert NIS2 in Art. 21 Risikomanagementmassnahmen, aber weder eine SoA noch ein Zertifikat.

Wie entsteht die SoA in einem Projekt mit PlanSec?

In unseren Projekten erarbeiten wir die Anwendbarkeitserklärung gemeinsam mit Ihnen aus Ihrer Risikobeurteilung. Die Begründungen vertreten Sie im Audit, deshalb liegen Entscheid und Freigabe bei Ihrem Unternehmen, konkret bei Ihrer oder Ihrem CISO. Das interne Audit nach Ziff. 9.2 prüft danach, ob SoA, Risikobeurteilung, Behandlungsplan und Nachweise zueinander passen.

Unsere Zertifizierungsgarantie gilt, wenn Sie die Ihnen zugewiesenen Aufgaben vollständig und wie verlangt erledigen. Klappt die Zertifizierung trotzdem nicht, arbeiten wir kostenlos nach, bis Sie zertifiziert sind. Über das Zertifikat entscheidet die unabhängige Zertifizierungsstelle.

Mit welchem Aufwand Sie insgesamt rechnen müssen, lesen Sie im Ratgeber Was kostet eine ISO-27001-Zertifizierung?. Wenn Sie Ihre Anwendbarkeitserklärung gemeinsam einordnen möchten, buchen Sie ein kostenloses Erstgespräch von 15 bis 30 Minuten.

Stand: November 2026. Autor: Dieter Huber, PlanSec AG, Cham. Alle verlinkten Quellen wurden am 09.11.2026 abgerufen.