Die Erklärung zur Anwendbarkeit ist keine Liste von Maßnahmen. Sie ist die Begründung für jede einzelne davon.

Fragt man die meisten Organisationen, die sich auf ihr erstes Zertifizierungsaudit nach ISO/IEC 27001 vorbereiten, was die Erklärung zur Anwendbarkeit (Statement of Applicability, SoA) ist, lautet die Antwort meist: die Liste der 93 Maßnahmen aus Anhang A, versehen mit einer Spalte, die jede als anwendbar oder nicht anwendbar kennzeichnet. Das ist eine gängige Vereinfachung, aber fachlich unvollständig. Abschnitt 6.1.3 verlangt von der Organisation, die Maßnahmen zu bestimmen, die zur Behandlung ihrer Risiken erforderlich sind – dazu können auch Maßnahmen gehören, die nicht in Anhang A enthalten sind – und diese Liste erst anschließend mit Anhang A abzugleichen, um sicherzustellen, dass keine erforderliche Maßnahme übersehen wurde. Nach 6.1.3 d) muss die daraus entstehende Erklärung zur Anwendbarkeit für jede enthaltene Maßnahme eine Begründung und einen Umsetzungsstatus enthalten sowie für jede ausgeschlossene Maßnahme aus Anhang A eine Begründung für den Ausschluss. Eine Ja/Nein-Spalte neben einer festen Liste von 93 Positionen ist eine Checkliste. Was der Abschnitt beschreibt, ist eher ein dokumentiertes, überprüfbares Argument – mit der Risikobeurteilung und der Risikobehandlung als Beleg.

Diese Lücke zwischen den beiden Lesarten ist nicht akademischer Natur. Veröffentlichte Prüfleitfäden – einschließlich der eigenen Auditing Practice Notes von ISO/IEC JTC 1/SC 27 zur Erklärung zur Anwendbarkeit und zu Anhang A – identifizieren schwache, veraltete oder unzureichend begründete SoAs wiederholt als wiederkehrende Ursache für Auditfeststellungen. Das Problem ist selten eine fehlende Maßnahme. Meist hält die Begründung hinter der Liste einer Prüfung nicht stand: eine als anwendbar markierte Maßnahme ohne nachvollziehbare Grundlage, ein Ausschluss, der lediglich als „nicht anwendbar auf unser Unternehmen" vermerkt ist, statt einer dokumentierten Begründung, oder ein Umsetzungsstatus, der eine Absicht statt der tatsächlichen Situation der Organisation beschreibt.

Für nichts davon braucht es eine aktuelle Entwicklung, damit es der Erwähnung wert ist – es handelt sich um ein wiederkehrendes Muster, weshalb es sich lohnt, dies außerhalb des Drucks eines bereits terminierten Audits präzise darzulegen. Im Folgenden wird dargestellt, was Abschnitt 6.1.3 d) verlangt, was ein akkreditiertes Audit nach ISO/IEC 27006-1 auf jeder Stufe prüft, und warum diese unabhängige Prüfung mehr wert ist als das Dokument, das sie hervorbringt.

Wo die SoA im ISMS steht

Die Erklärung zur Anwendbarkeit entsteht nicht isoliert, und in einem etablierten ISMS wird sie selten nur einmal erstellt. Sie steht in einer Abfolge, die sich wiederholt, sobald sich die Risikolage der Organisation ändert, und die eine Zertifizierungsstelle an mehr als einer Stelle prüft:

‍

‍

Die meisten der im Folgenden beschriebenen Schwachstellen lassen sich darauf zurückführen, dass die SoA als einmalig erstelltes Dokument behandelt wird, direkt aus Anhang A abgeleitet, statt als etwas, das der dahinterliegenden Risikobehandlung fortlaufend Rechenschaft ablegen muss.

‍

Was Abschnitt 6.1.3 d) tatsächlich verlangt

Sie ist nicht nur eine Kopie von Anhang A

Anhang A gliedert seine 93 Maßnahmen in vier Themen: organisatorisch (37 Maßnahmen), personenbezogen (8), physisch (14) und technologisch (34). Anhang A selbst ist keine Anforderungsliste, die Punkt für Punkt abzuarbeiten wäre – die eigenen Prüfleitlinien von ISO/IEC JTC 1/SC 27 stellen ausdrücklich klar, dass das bloße Vorkommen einer Maßnahme in Anhang A diese noch nicht für eine bestimmte Organisation erforderlich macht, und beschreiben Anhang A als Gedächtnisstütze zur Vollständigkeitsprüfung, nicht als zu erfüllende Checkliste. Die richtige Reihenfolge ist umgekehrt zu der, in der viele Organisationen tatsächlich vorgehen: zunächst die Maßnahmen bestimmen, die zur Behandlung der in der Risikobeurteilung identifizierten Risiken erforderlich sind – dazu können auch Maßnahmen außerhalb von Anhang A gehören –, diese Liste mit Anhang A abgleichen, um sicherzustellen, dass nichts Erforderliches übersehen wurde, und erst danach die SoA mit dem Ergebnis erstellen.

„Anwendbar" braucht eine Begründung, unabhängig von der Anzahl

Alle 93 Maßnahmen aus Anhang A einzubeziehen, ist für sich genommen kein Problem. ISO/IEC 27001 belohnt keine Ausschlüsse, und ein Audit sollte nicht allein aus der Anzahl der als anwendbar markierten Maßnahmen auf eine schwache Risikoanalyse schließen. Geprüft wird, ob jede Maßnahme eine angegebene Begründung hat – und die Leitlinien von SC 27 stellen unmissverständlich klar, dass das bloße Vorkommen in Anhang A diese Begründung nicht ersetzt. Für Ausschlüsse gilt dieselbe Logik umgekehrt: „nicht anwendbar auf unser Unternehmen" ist für sich genommen keine Begründung. Eine Begründung verknüpft die Entscheidung mit dem beurteilten Risiko der Organisation, einer rechtlichen oder vertraglichen Verpflichtung, oder einer anderen dokumentierten und eigenständig nachvollziehbaren Grundlage.

Sie muss auf etwas zurückführbar sein — nicht nur auf ein Risikoregister

Abschnitt 6.1.3 d) verlangt eine Begründung, kein bestimmtes Dokumentenformat, und ISO/IEC 27001 schreibt keiner Organisation vor, ein Dokument zu führen, das wörtlich „Risikoregister" heißt. Die Erforderlichkeit einer Maßnahme ergibt sich meist aus den beurteilten Risiken der Organisation, kann aber ebenso aus rechtlichen oder vertraglichen Verpflichtungen entstehen oder, ausnahmsweise, aus einer anderen eigenständig begründeten Grundlage, wenn sich das zugrunde liegende Risiko nur schwer quantifizieren lässt. Was jede erforderliche Maßnahme braucht, ist eine nachvollziehbare Grundlage in den Risikobehandlungs-Unterlagen der Organisation – die eine aus einem früheren Zyklus, einer Vorlage oder dem Dokument einer anderen Organisation übernommene SoA in der Regel nicht hat, wenn sie nicht überarbeitet wurde. Wiederverwendete, nicht überarbeitete SoAs werden durchgängig als vermeidbare Quelle von Inkonsistenzen benannt.

„Umgesetzt" ist ein Status, keine Absichtserklärung

Abschnitt 6.1.3 d) verlangt, dass die SoA angibt, ob jede erforderliche Maßnahme umgesetzt ist oder nicht – nicht, ob sie beabsichtigt, geplant oder terminiert ist. Eine SoA, die umgesetzte Maßnahmen korrekt von noch nicht umgesetzten unterscheidet, ist nützlicher und zutreffender als eine, die Absichten als Tatsachen darstellt. Diese Genauigkeit ist notwendig, aber allein nicht ausreichend: Stufe 2 prüft anschließend, ob die als umgesetzt vermerkten Maßnahmen tatsächlich umgesetzt und wirksam sind – nicht nur, ob das Dokument dies behauptet.

Was schwache SoAs gemeinsam haben

• Eine kopierte oder wiederverwendete SoA ist eine häufige, vermeidbare Quelle von Inkonsistenzen. Formulierungen, die nicht an die tatsächliche Risikobehandlung der Organisation angepasst wurden, lassen sich im Audit leicht anhand der übrigen Nachweise erkennen.
• Alles als „anwendbar" zu markieren, schafft für sich genommen keine zusätzliche Sicherheit. Geprüft wird, ob jeder Eintrag eine echte, nachvollziehbare Grundlage hat – nicht, wie viele Maßnahmen einbezogen wurden.
• Eine SoA, die unverändert bleibt, während sich die Organisation verändert, zieht eine genauere Prüfung nach sich. Neue Systeme, Lieferanten, Verpflichtungen oder organisatorische Änderungen können verändern, welche Maßnahmen erforderlich sind; wenn das der Fall ist, sucht das Audit nach einer entsprechenden Aktualisierung – oder einer dokumentierten Begründung, warum es keine gibt.

Wo die ISO/IEC 27001-Zertifizierung ansetzt — und wo ihre Grenze liegt

Ein akkreditiertes ISO/IEC 27001-Zertifikat ist eine unabhängige Bestätigung, dass der Risikobeurteilungs- und Risikobehandlungsprozess einer Organisation, die von ihr bestimmten erforderlichen Maßnahmen, ihre Erklärung zur Anwendbarkeit sowie die Umsetzung und Wirksamkeit dieser Maßnahmen tatsächlich gegen den Standard geprüft wurden – nicht lediglich, dass die Organisation ihre eigenen Unterlagen vervollständigt hat.

Es garantiert nicht, dass niemals ein Sicherheitsvorfall eintritt, und es bedeutet nicht, dass es für ein gegebenes Risiko nur eine einzig richtige Behandlung gibt. Ihr Wert liegt in einer unabhängigen, kompetenten Prüfung, ob die eigenen risikobasierten Entscheidungen einer Organisation kohärent, umgesetzt und wirksam sind – eine Prüfung, die von einer Partei kommen muss, die kein Eigeninteresse an der Gestaltung des ISMS hat.

Die eigene SoA prüfen — und das Zertifikat anderer

Drei Fragen reichen meist aus, um einzuschätzen, ob eine Erklärung zur Anwendbarkeit einer solchen Prüfung standhält: Hat jede als anwendbar markierte Maßnahme eine nachvollziehbare Grundlage in der Risikobehandlung, in rechtlichen oder vertraglichen Verpflichtungen der Organisation oder in einer anderen dokumentierten Begründung? Nennt jeder Ausschluss eine Begründung, die über eine Variante von „nicht anwendbar" hinausgeht? Und spiegelt der Umsetzungsstatus wider, wo die Organisation tatsächlich steht, nicht, wo ein Projektplan sie erwartet? Eine SoA, die diese Fragen ehrlich beantwortet, erfüllt das, was Abschnitt 6.1.3 d) verlangt – unabhängig von ihrem Alter oder Format.

Derselbe Prüfmaßstab lohnt sich auch gegenüber jeder Zertifizierung, die behauptet wird: das Akkreditierungszertifikat selbst verlangen, nicht die Marketingaussage, und im öffentlichen Register der zuständigen Akkreditierungsstelle – DAkkS, UKAS, ANAB, RvA und vergleichbare – nachsehen, welcher Standard, welche Ausgabe und welcher Geltungsbereich tatsächlich abgedeckt sind. Die Proks Certification GmbH ist von der DAkkS für die ISMS-Zertifizierung akkreditiert; unser aktueller Geltungsbereich, DAkkS-Dokument D-ZM-21201-01-02, umfasst DIN EN ISO/IEC 27001:2024-01 – die deutsche und europäische Übernahme der ISO/IEC 27001:2022 –, auditiert nach DIN EN ISO/IEC 27006-01:2024-08, und ist Teil unserer übergeordneten Akkreditierung D-ZM-21201-01-00.

Die Rolle von Proks unterscheidet sich bewusst von der eines ISMS-Beraters. ISO/IEC 17021-1 verlangt von einer Zertifizierungsstelle – zusammen mit jedem Teil derselben juristischen Person und jeder Stelle unter ihrer organisatorischen Kontrolle –, unparteilich zu bleiben, und untersagt es, neben der Zertifizierung Managementsystem-Beratung anzubieten. Wir können erläutern, was Abschnitt 6.1.3 d) und der übrige Standard verlangen, und Auditfeststellungen erläutern; wir erstellen weder die Erklärung zur Anwendbarkeit eines Kunden noch wählen wir dessen Maßnahmen aus. Diese Trennung ist keine Einschränkung, die wir umgehen – sie ist Teil dessen, was eine akkreditierte Zertifizierung zu etwas macht, das ein Berater nicht eigenständig bieten kann.

Worauf ein akkreditiertes Audit achtet

Bei Stufe 1 oder jeder Dokumentenprüfung

• Die Übereinstimmung zwischen der SoA und dem Risikobehandlungsplan, den sie abbilden soll, wird geprüft, bevor Umsetzungsnachweise stichprobenartig untersucht werden – eine Abweichung bei Daten oder Geltungsbereich ist oft das erste Anzeichen, dass ein Dokument nicht mehr aktuell ist.
• Ob internes Audit und Managementbewertung die SoA bereits berücksichtigt haben, beeinflusst, wie viel das externe Audit selbst noch direkt prüfen muss.

Bei Stufe 2, Überwachungs- oder Rezertifizierungsaudits

• Ob als umgesetzt vermerkte Maßnahmen tatsächlich umgesetzt und wirksam sind, wird anhand von Stichproben geprüft – nicht anhand der Formulierung in der SoA.
• Ob sich Risiken, Geltungsbereich, Werte oder Verpflichtungen seit der letzten Prüfung verändert haben und ob sich die SoA entsprechend mitverändert hat, wird bei jedem weiteren Besuch untersucht – nicht allein daraus geschlossen, dass sich auf dem Papier nichts geändert hat.

Immer, wenn sich in der Organisation etwas ändert

• Ein neues System, ein neuer Lieferant, eine neue rechtliche Verpflichtung oder eine organisatorische Änderung ist die Art von Ereignis, die ein späteres Audit innerhalb eines angemessenen, nachvollziehbaren Zeitraums in der SoA widergespiegelt erwartet – nicht zwangsläufig am selben Tag, aber auch nicht erst beim nächsten planmäßigen Besuch.

Warum das mehr wert ist, als ein Audit zu bestehen

Hinter der Dokumentationspflicht verlangt Abschnitt 6.1.3 d) von einer Organisation, etwas schriftlich festzuhalten: welche Risiken sie zu behandeln beschlossen hat, welche nicht, und warum – so konkret, dass jemand anderes die Begründung später nachvollziehen könnte. Explizite, überprüfbare Risikoentscheidungen sind unabhängig von der Zertifizierung aus eigenem Recht wertvoll, weil sie Ermessensentscheidungen in etwas verwandeln, das überprüft und nicht nur vorausgesetzt werden kann.

Was die akkreditierte Zertifizierung hinzufügt, ist eine Partei ohne Eigeninteresse an der Gestaltung des ISMS, die prüft, ob diese Begründung den Nachweisen tatsächlich standhält – ein anderer Wert als Hilfe bei der Ordnung der Unterlagen, und der Grund, warum eine akkreditierte Zertifizierung mehr wert ist als die Summe der Dokumente, die sie hervorbringt.

Eine gut gestaltete Erklärung zur Anwendbarkeit gehört der Organisation, die sie erstellt hat. Die Aufgabe einer akkreditierten Zertifizierungsstelle ist es, unabhängig und kompetent zu prüfen, ob die dahinterliegende Begründung mit dem ISMS übereinstimmt und durch Nachweise gestützt wird. Wenn Sie eine Zertifizierung nach ISO/IEC 27001 in Betracht ziehen und mehr über den akkreditierten Geltungsbereich, den Zertifizierungsprozess oder die Auditstufen von Proks erfahren möchten, nehmen Sie Kontakt mit uns auf.

Quellen

• ISO/IEC 27001:2022, Abschnitt 6.1.3 (Risikobehandlung) und Anhang A
• ISO/IEC JTC 1/SC 27/WG 1, „Auditing Practices Note — Statement of Applicability" (N3298)
• ISO/IEC JTC 1/SC 27/WG 1, „Auditing Practices Note — Annex A" (N3297)
• ISO/IEC 27006-1:2024, Anforderungen an Stellen, die ISMS auditieren und zertifizieren
• ISO/IEC 17021-1:2015, Abschnitt 5.2.5 (Unparteilichkeit und Managementsystem-Beratung), wie von European Accreditation zusammengefasst
• NQA, „ISO 27001 SoA & Risk Register: Common Mistakes Explained", März 2026
• Cyberday, „10 Most Common Non-Conformities in ISO 27001 Audits"
• DAkkS, Akkreditierungsumfangsdokumente D-ZM-21201-01-00 und D-ZM-21201-01-02 (Proks Certification GmbH)

Zuletzt überprüft: 22. September 2026. Dieser Beitrag erläutert in allgemeiner Form, was Abschnitt 6.1.3 d) der ISO/IEC 27001:2022 von einer Erklärung zur Anwendbarkeit verlangt und was ein akkreditiertes Audit prüft; er stellt keine Akkreditierungs-, Audit- oder Rechtsberatung für das ISMS einer bestimmten Organisation dar.

‍

‍

‍

‍

‍