Statement of Applicability ISO 27001: die Vorlage als Auditscharnier

Das Statement of Applicability, kurz SoA, ist nach Abschnitt 6.1.3 d) der ISO/IEC 27001:2022 ein Pflichtdokument jedes zertifizierten Informationssicherheits-Managementsystems. Es listet die anwendbaren Maßnahmen aus Anhang A, begründet jede Auswahl oder Abwahl, dokumentiert den Implementierungsstand und verweist auf Risikobehandlungspläne. Mit der Revision 2022 ist Anhang A von 114 auf 93 Controls reduziert und in vier Themen gegliedert worden: organisatorisch, personell, physisch, technologisch.

Dieser Leitfaden liefert eine Strukturvorlage für die SoA, erklärt die Schlüsselfelder, zeigt typische Auditfehler und ordnet die Pflege in den ISMS-Betrieb ein. CIVAC ist eine Compliance-Plattform und Officer-as-a-Service für deutsche Unternehmen und stellt eine SoA-Vorlage bereit, die mit Risikoregister, Behandlungsplan und Auditkalender verknüpft ist und damit nicht jährlich neu gebaut werden muss.

Abschnitt 6.1.3 d) der Norm fordert ein Statement of Applicability, das die erforderlichen Maßnahmen sowie deren Aufnahme oder Ausschluss begründet. Damit ist die SoA kein Marketingdokument, sondern der Beleg, dass das Unternehmen den Anhang A vollständig betrachtet, jede Maßnahme bewusst eingestuft und Abwahlen plausibel begründet hat.

Mit der Revision 2022 ist Anhang A strukturell überarbeitet. Vier Themenbereiche ersetzen die alten 14 Domänen: A.5 organisatorisch (37 Controls), A.6 personell (8 Controls), A.7 physisch (14 Controls), A.8 technologisch (34 Controls). Elf Controls sind neu, darunter A.5.7 Threat Intelligence, A.5.23 Information Security for use of Cloud Services, A.8.9 Configuration Management, A.8.10 Information Deletion und A.8.28 Secure Coding. Sechsundfünfzig Controls sind zusammengelegt oder umformuliert.

Die SoA muss diese Struktur abbilden. Wer mit einer 2013er Vorlage weiterarbeitet, hat keinen 2022-konformen Nachweis. Bestehende Zertifikate sind nach IAF MD 26 bis spätestens 31. Oktober 2026 auf die 2022er Fassung umzustellen. Die Übergangsfrist ist verbindlich, eine Verlängerung nicht vorgesehen. Wer den Wechsel verschleppt, verliert mit Ablauf des Übergangs die Zertifizierung und muss neu beantragen.

Eine auditfähige SoA-Vorlage führt sechs Spalten. Erstens Control-Nummer und Titel exakt nach Anhang A der 2022er Fassung. Zweitens Anwendbarkeit, in der Regel Ja oder Nein, alternativ teilweise mit Klärung. Drittens Begründung, sowohl für die Auswahl als auch für die Abwahl, mit Bezug auf Risikoregister, gesetzliche Anforderung, vertragliche Pflicht oder Geschäftsbedürfnis. Viertens Implementierungsstand mit klaren Stufen, etwa nicht umgesetzt, in Umsetzung, umgesetzt, kontinuierlich überwacht.

Fünftens Verweis auf konkrete Nachweise: Richtlinie, Verfahrensanweisung, Konfigurationsstandard, Auditbericht, Risikobehandlungsplan. Diese Referenzen müssen auffindbar sein, im Workspace verlinkbar, nicht nur als Dateiname genannt. Sechstens Verantwortlicher mit Name oder Rolle und Datum der letzten Prüfung. Manche Vorlagen ergänzen eine siebte Spalte für die Risiko-ID, was die Auditrückverfolgung beschleunigt.

Die häufigsten Vorlagefehler sind drei. Erstens Begründungen wie "trifft nicht zu" ohne Risikobezug, was Auditoren regelmäßig als Major werten. Zweitens veraltete Verweise auf alte Richtlinien, die zwischenzeitlich abgelöst wurden. Drittens fehlende Pflegedaten, sodass nicht erkennbar ist, ob das Dokument nach dem letzten Audit überhaupt geöffnet wurde. Bestellurkunde, unterschrieben, abgelegt, belegbar.

Anwendbarkeit ist nicht Geschmacksfrage. Sie folgt aus dem Risikoregister, aus rechtlichen Vorgaben und aus den Anforderungen interessierter Parteien nach Abschnitt 4.2 der Norm. Wer Control A.5.30 ICT readiness for business continuity als nicht anwendbar markiert, muss erklären, warum keinerlei IT-bezogene Geschäftskontinuität benötigt wird. In der Praxis ist eine vollständige Abwahl selten begründbar.

Begründungen sollten drei Bausteine enthalten. Erstens den Risikobezug: welche Risiken adressiert das Control, welche Risiken bleiben offen, wenn man es abwählt. Zweitens den rechtlich-vertraglichen Bezug: verlangen DSGVO, NIS-2, Kundenverträge oder branchenspezifische Normen das Control. Drittens den Geschäftsbedürfnisbezug: passt das Control zur Tätigkeit, zur Datenklassifikation, zur Branche.

Im Audit prüft der Zertifizierer Stichproben gegen die Realität. Wer Control A.8.16 Monitoring activities als umgesetzt einträgt, muss SIEM-Konfiguration, Alarmkriterien, Auswertungsroutinen und dokumentierte Vorfallreaktionen vorlegen. Wer A.5.23 Cloud Services als umgesetzt erklärt, braucht Cloud-Inventar, Risikobewertungen pro Anbieter und AV-Verträge. Andere führen Compliance wie einen Aktenschrank. Wir führen sie wie Software.

Die elf neuen Controls sind die häufigsten Stolpersteine in Übergangsaudits. A.5.7 Threat Intelligence verlangt einen dokumentierten Prozess für die Beschaffung und Auswertung von Bedrohungsinformationen, nicht nur ein Abo bei einem Threat-Feed. A.5.23 ICloud Services fordert dokumentierte Beschaffung, Nutzung und Beendigung von Cloud-Diensten, einschließlich Exit-Strategie.

A.5.30 ICT Readiness for Business Continuity bezieht Geschäftskontinuität explizit auf IT, mit BIA, RTO, RPO und Tests. A.7.4 Physical Security Monitoring erweitert physische Überwachung um dokumentierte Detektion und Reaktion. A.8.9 Configuration Management fordert Soll-Konfigurationen, Abweichungsmanagement, Inventarisierung. A.8.10 Information Deletion verlangt belegbare Löschverfahren über Lebenszyklen, einschließlich Cloud.

A.8.11 Data Masking, A.8.12 Data Leakage Prevention, A.8.16 Monitoring Activities, A.8.23 Web Filtering und A.8.28 Secure Coding ergänzen technische Controls, die früher implizit durch andere Maßnahmen abgedeckt waren. Auditoren verlangen seit 2024 explizite Nachweise. Eine 2022er SoA-Vorlage muss diese elf Controls vollständig enthalten, mit klarem Implementierungsstand und konkretem Nachweis, auch wenn die Anwendbarkeit im Einzelfall begründet eingeschränkt ist.

Die SoA steht nicht allein. Abschnitt 6.1.2 der Norm verlangt einen Risikobeurteilungsprozess, 6.1.3 a) bis c) den Risikobehandlungsplan. SoA, Risikoregister und Behandlungsplan sind drei verbundene Dokumente, die im Audit gemeinsam geprüft werden. Auditoren ziehen ein Risiko aus dem Register, suchen die zugeordneten Controls in der SoA und verlangen den Nachweis aus dem Behandlungsplan und der Linie.

Eine belastbare Vorlage führt deshalb eine Risiko-ID-Spalte in der SoA und umgekehrt eine Control-Liste pro Risiko im Register. Wechselseitige Verlinkung beschleunigt nicht nur den Audit, sondern macht Lücken sichtbar: ein Risiko ohne adressierende Controls, ein Control ohne Risikobezug, ein Behandlungsplan ohne SoA-Eintrag. Das CIVAC-ISMS verknüpft diese drei Schichten automatisch im Workspace.

Im Betrieb bedeutet das, dass jede Risiko-Änderung eine SoA-Prüfung anstößt und jede Control-Änderung im Register sichtbar wird. Der ISO/IEC 27001:2022 ISMS-Standard verlangt diese Konsistenz nicht nur einmal jährlich, sondern als laufenden Prozess. Der Prüfer ruft an, der Nachweis liegt bereit. Die SoA ist im Audit der erste Punkt, an dem ein nicht gelebter Betrieb sichtbar wird.

Die SoA ist ein lenkungspflichtiges Dokument nach Abschnitt 7.5 der Norm. Erforderlich sind Identifikation, Format, Freigabe, Überprüfung in geplanten Abständen, Schutz vor unbeabsichtigter Änderung und Versionsverwaltung. In der Praxis bedeutet das eine eindeutige Dokumentennummer, eine Verantwortlichkeit beim Informationssicherheitsbeauftragten, eine Freigabe durch die oberste Leitung und einen Prüfintervall von in der Regel zwölf Monaten.

Ein laufender Pflegezyklus umfasst sechs Auslöser. Erstens Risikobeurteilungs-Updates, zweitens neue oder geänderte Controls bei Normrevisionen, drittens regulatorische Änderungen wie NIS-2 oder DORA, viertens organisatorische Änderungen wie Akquisitionen oder Standortwechsel, fünftens Vorfälle mit Lessons Learned, sechstens jährliche Management-Reviews nach Abschnitt 9.3.

Wer die SoA nur kurz vor dem Audit aufräumt, riskiert Inkonsistenzen mit Risikoregister, Behandlungsplan, internen Audits und Vorfallberichten. Auditoren prüfen Pflegedaten als Indiz, ob das ISMS lebt. Eine SoA mit Datum vom Vortag der Begehung ist verdächtig, eine SoA mit zwölf Monaten Pflegehistorie überzeugend. Der externe Informationssicherheitsbeauftragte übernimmt diese Pflege im Mandat.

Vor einem Zertifizierungsaudit nutzen erfahrene ISBs die SoA als zentrale Vorbereitungsachse. Drei Schritte führen zur Auditreife. Erstens Konsistenzprüfung gegen Risikoregister und Behandlungsplan: jede Risiko-ID muss in der SoA wiederzufinden sein, jedes ausgewählte Control im Risikoregister. Zweitens Nachweisstichprobe: pro Themenbereich werden zwei bis drei Controls ausgewählt, der dokumentierte Stand mit der Realität in der Linie abgeglichen.

Drittens Mock-Interviews mit den genannten Verantwortlichen. Auditoren fragen nicht das ISMS-Team, sondern den HR-Verantwortlichen zu A.6.3 Information Security Awareness oder den IT-Operations-Lead zu A.8.9 Configuration Management. Wer hier zögert oder andere Antworten gibt als die SoA, produziert Findings. Eine gute Vorbereitung simuliert diese Gespräche.

Stage-1-Audits prüfen die Dokumentation und identifizieren Lücken, Stage-2 prüft die Wirksamkeit in der Linie. Bei Übergangsaudits 2022 ist die Begehung verkürzt, aber die Anforderungen an die SoA strenger. Die CIVAC-SoA-Vorlage ist mit den 37 Audit-Vorlagen verknüpft und führt durch Stage-1 und Stage-2 in einem Lauf, mit klaren Vorbereitungsschritten und Erinnerungen vor den geplanten Audits.

Die erstmalige Erstellung einer SoA dauert in einem mittelständischen Unternehmen ohne Vorerfahrung sechs bis zwölf Wochen, abhängig von der Reife der bestehenden Dokumentation. Wer mit einer leeren Vorlage und 93 Controls startet, braucht je Control im Schnitt zwei bis vier Stunden für Beurteilung, Begründung, Nachweissammlung und interne Abstimmung.

Beratungsangebote für die SoA-Erstellung liegen zwischen 15.000 und 80.000 Euro, je nach Größe und Tiefe. Ein laufendes ISB-Mandat reduziert diesen Aufwand, weil die SoA Teil der monatlichen Berichtslinie wird und nicht jährlich neu gebaut werden muss. Die häufigsten Fallstricke sind drei. Erstens Copy-Paste-Begründungen, die in der Stichprobe sofort auffallen. Zweitens nicht versionierte Anhänge, die in der Diskussion mit dem Auditor verwechselt werden. Drittens fehlende Verknüpfung mit der DSGVO-TOM-Dokumentation, was nach NIS-2 und ISO doppelten Aufwand erzeugt.

Die SoA ist kein Einmaldokument, sondern das Auditscharnier des ISMS. Wer sie als Tabelle in einem Ordner führt, hat ein dokumentarisches Problem. Wer sie als verlinktes Modul im Workspace führt, hat einen Betrieb. CIVAC pflegt SoA, Risikoregister und Behandlungsplan in einer Struktur, mit EU-Datenresidenz und revisionssicherer Versionierung.

Eine Vorlage löst das SoA-Problem nicht. Sie löst nur den ersten Tag. Die Schwierigkeit liegt in der Pflege, in der Verzahnung mit Risikoregister und Behandlungsplan und in der Nachweisführung über Audits hinweg. Wer 2026 vor der Übergangspflicht steht, braucht weder ein neues Word-Dokument noch eine neue Excel-Tabelle, sondern einen Betrieb, der die SoA lebendig hält.

CIVAC ist eine Compliance-Plattform und Officer-as-a-Service. Im Workspace finden Sie eine ISO/IEC 27001:2022 SoA-Vorlage mit allen 93 Controls, verknüpft mit Risikoregister, Behandlungsplan, 37 Audit-Vorlagen, internem Auditkalender und Berichtslinie an die Geschäftsleitung. EU-Datenresidenz, revisionssichere Versionierung, Bestellurkunde für den ISB im Standard. Lizenzieren Sie den Workspace für Ihre internen Beauftragten, oder lassen Sie unsere Beauftragten bestellen.

Aus dem Lesen einen Auftrag machen. Schreiben Sie an info@civac.de oder nutzen Sie das Kontaktformular auf civac.de. Innerhalb von zwei Werktagen erhalten Sie eine SoA-Erstabstimmung mit Ihrem aktuellen ISMS-Stand und einen Migrationsplan zur 2022er Fassung, statt der branchenüblichen zwei bis sechs Wochen Vorlaufzeit.