STOP.LI · Berichte · Nachweis
Statement of
Applicability.
Die Erklärung zur Anwendbarkeit nach ISO/IEC 27001: welche Kontrollen das ISMS braucht, warum, ob sie umgesetzt sind und warum Kontrollen aus Anhang A ausgeschlossen wurden.
Auf einen
Blick.
AdressatISMS-Verantwortliche, AuditorenPflichtdokument für die Zertifizierung; auch Grundlage für Prüfungen durch Kunden und Revision.
RhythmusLaufend gepflegtVersioniert bei jeder Änderung der Risikobehandlung und mit der Managementbewertung bestätigt.
ZweckBrücke zwischen Risiko und KontrolleDie SoA verbindet die Risikobehandlung mit den umgesetzten Kontrollen und macht Ausschlüsse begründbar.
Aufbau
des Berichts.
| Abschnitt | Inhalt | Leitfrage |
|---|---|---|
| Kopf | ISMS-Geltungsbereich, Version, Datum, Freigabe, Bezug zum Risikobehandlungsplan. | Für welchen Umfang gilt die Erklärung? |
| Kontrollen aus Anhang A | Alle 93 Kontrollen von ISO/IEC 27001:2022 in den vier Themen organisatorisch (37), personenbezogen (8), physisch (14) und technologisch (34). | Ist jede Kontrolle bewertet? |
| Zusätzliche Kontrollen | Kontrollen ausserhalb von Anhang A, etwa aus Branchenvorgaben oder Verträgen. | Was brauchen wir darüber hinaus? |
| Begründung | Für jede aufgenommene Kontrolle der Grund; für jeden Ausschluss die Begründung. | Warum ist die Kontrolle nötig oder nicht? |
| Umsetzungsstand | Ob die Kontrolle umgesetzt ist; in der Praxis oft feiner (umgesetzt, teilweise, geplant), mit Verweis auf Umsetzung und Nachweis. | Ist die Kontrolle in Kraft? |
| Verantwortung | Eigner jeder Kontrolle. | Wer ist zuständig? |
| Mappings | Optional: Bezug zu BSI IT-Grundschutz, IKT-Minimalstandard, NIS2 oder DORA. | Welche Pflichten deckt die Kontrolle mit ab? |
Spalten
der SoA.
Die Norm verlangt vier Angaben. Die übrigen Spalten machen die SoA prüfbar und wiederverwendbar.
| Spalte | Inhalt | Pflicht nach 6.1.3 d) |
|---|---|---|
| Notwendige Kontrolle | Kontroll-ID und Titel aus Anhang A oder eigener Katalog. | ja |
| Begründung der Aufnahme | Risiko aus der Risikobeurteilung, gesetzliche oder vertragliche Pflicht. | ja |
| Umsetzungsstatus | Ob die Kontrolle umgesetzt ist. | ja |
| Begründung des Ausschlusses | Warum eine Anhang-A-Kontrolle nicht nötig ist. | ja |
| Nachweis | Verweis auf Richtlinie, Verfahren, Konfiguration oder Testbericht. | nein, aber für jedes Audit nötig |
| Eigner und Mapping | Verantwortliche Person; Bezug zu weiteren Pflichten. | nein |
Deutschland
und Schweiz.
Gemeinsamer Aufbau für beide Rechtsräume. Die Tabelle zeigt, welche Vorgaben den Bericht wo prägen; wo keine Vorgabe besteht, steht das ausdrücklich.
| Rechtsraum | Grundlage | Bedeutung für den Bericht | Fundstelle |
|---|---|---|---|
| Norm | Die Organisation erstellt eine Erklärung zur Anwendbarkeit mit den notwendigen Kontrollen, der Begründung ihrer Aufnahme, ob sie umgesetzt sind, und der Begründung für den Ausschluss von Anhang-A-Kontrollen. | Identisch für Deutschland und die Schweiz. | ISO/IEC 27001:2022, Kap. 6.1.3 d) ↗ |
| Übergang | Zertifikate nach ISO/IEC 27001:2013 sind seit dem Ende der Übergangsfrist am 31. Oktober 2025 nicht mehr gültig. | SoA in der Struktur von 2022 führen, nicht mehr mit den 114 Kontrollen von 2013. | IAF MD 26:2023 |
| Deutschland | BSI-Gesetz verlangt Risikomanagementmassnahmen nach dem Stand der Technik unter Berücksichtigung einschlägiger Normen; ein Zertifikat ist keine Pflicht. | Mapping der SoA auf § 30 Abs. 2 BSIG erleichtert den Nachweis. | § 30 Abs. 2 BSIG ↗ |
| FinanzD und FinanzCH | Weder DORA noch das FINMA-Rundschreiben 2023/1 verlangen eine SoA. | Ein Mapping auf deren Anforderungen spart Doppelarbeit bei Prüfungen. | Keine Vorgabe |
| Schweiz | Der IKT-Minimalstandard des Bundes ist eine freiwillige Empfehlung und an das NIST Cybersecurity Framework angelehnt. | Als Mapping-Spalte geeignet. | Framework Navigator → |
Häufige
Fehler.
FehlerAusschluss ohne BegründungEin leeres Begründungsfeld ist im Zertifizierungsaudit eine Abweichung.
FehlerUmgesetzt ohne VerweisOhne Verweis auf die Umsetzung lässt sich der Status nicht prüfen.
FehlerLosgelöst vom RisikoDie SoA folgt aus dem Risikobehandlungsplan, nicht aus einer Checkliste.
FehlerVeraltete StrukturWer noch mit den Kontrollen von 2013 arbeitet, prüft gegen eine Norm, die nicht mehr zertifiziert wird.
Passende
Werkzeuge.
Diese Werkzeugklassen liefern Daten oder Nachweise für den Bericht. Einordnung und Produktvergleich stehen auf den verlinkten Seiten.
WerkzeugISMS-WerkzeugeFühren die Anwendbarkeit, Begründung und Umsetzung je Kontrolle.WerkzeugPolicy ManagementVerknüpft Kontrollen mit den zugehörigen Vorgaben.WerkzeugControl & Evidence ManagementBelegt den Umsetzungsstatus der als anwendbar erklärten Kontrollen.
Einordnung. Die Seite beschreibt Aufbau und Mindestinhalte des Berichts. Sie ersetzt keine Rechtsberatung; ob und in welcher Rolle ein Regelwerk gilt, hängt vom Geltungsbereich ab. Weiter: ISMS-Prozesslandkarte →, Auditbericht →, Framework Navigator →.
Quellen: ISO/IEC 27001 ↗§ 30 BSIG ↗