Statement of Applicability (SOA)🔗

Die Statement of Applicability (SOA) ist das zentrale Nachweisdokument deines ISO-27001-Scopes.
Hier legst du fest:

welche Normanforderungen / Controls für deinen Scope anwendbar sind,
welche nicht anwendbar sind – inkl. Begründung,
wie der Umsetzungsstand (Realisierung / Erfüllungsgrad) aussieht,
welche Maßnahmen, Dokumente, Prozesse und Anwendungsbereiche auf das Control einzahlen.

Damit ist die SOA ein Pflichtartefakt für jede ISO-27001-Zertifizierung.

Einstieg in die SOA🔗

Öffne das Modul ISMS ISO 27001.
Wähle die Kachel Statement of Applicability.
Oben wählst du:
- den Anwendungsbereich (Scope), für den du die SOA bearbeiten möchtest,
- die Norm(en), die du betrachten willst (z. B. ISO/IEC 27001 Annex A).

GRASP lädt daraufhin die Controls der gewählten Norm(en) für diesen Scope.

Aufbau der SOA-Ansicht🔗

In der Tabelle siehst du je Normbereich/ Norm u. a.:

Bezeichnung und ID des Controls (z. B. „A.7.1 Physische Sicherheitsparameter“),
Anwendbarkeit (anwendbar / nicht anwendbar),
Begründung der Anwendbarkeit,
Realisierungsgrad, Erfüllungsgrad und Zielerfüllungsgrad,
verknüpfte Maßnahmen, Dokumente, Prozesse, Anwendungsbereiche.

Über Info-Icons bei den Feldern (z. B. Realisierungsgrad) kannst du dir jederzeit Hilfetexte einblenden lassen, was genau in das Feld gehört.

Anwendbarkeit und Begründung pflegen🔗

Für jeden Normbereich/ Norm entscheidest du:

Anwendbar
→ Norm ist für deinen Anwendungsbereich (Scope) relevant (z. B. weil du ein Rechenzentrum betreibst).
Nicht anwendbar
→ Norm ist im konkreten Anwendungsbereich (Scope) nicht relevant (z. B. physische Parameter eines Rechenzentrums, wenn du ausschließlich Cloud-Services ohne eigenen Betrieb nutzt).

Vorgehen:

Control in der Liste auswählen.
Auf „Verbinden“ bzw. die Bearbeitungsaktion klicken.
Anwendbarkeit wählen (anwendbar / nicht anwendbar).
Eine Begründung hinterlegen (Pflichtfeld, wichtig für Auditor:innen).

Gerade bei „nicht anwendbar“ ist die Begründung essenziell, da die SOA hier den formalen Nachweis liefert, warum du ein Control ausklammerst.

Realisierungs-, Erfüllungs- und Zielerfüllungsgrad🔗

Für anwendbare Controls dokumentierst du zusätzlich den Umsetzungsstand:

Realisierungsgrad – in welchem Umfang sind organisatorische/technische Maßnahmen umgesetzt?
Erfüllungsgrad – wie gut erfüllt die Umsetzung die Normanforderung?
Zielerfüllungsgrad – welcher Zielzustand soll erreicht werden (z. B. im nächsten Auditzyklus)?

Die genaue Skala (z. B. 0–4 oder Prozent) richtet sich nach der in deinem System hinterlegten Konfiguration. Über die Info-Icons in der UI bekommst du dazu konkrete Hinweise.

Typischer Ablauf:

Ist-Stand einschätzen (Realisierungs-/Erfüllungsgrad).
Gewünschten Zielzustand festlegen (Zielerfüllungsgrad).
Bei Abweichungen entsprechende Maßnahmen anlegen oder verknüpfen.

Maßnahmen, Dokumente und Prozesse verknüpfen🔗

Zu jedem Control kannst du auf einen Blick sehen, wodurch es umgesetzt wird:

Maßnahmen – konkrete organisatorische oder technische Maßnahmen
Anlagen – Policies, Richtlinien, Konzepte, Protokolle als Umsetzungsnachweise
Prozesse – operative Abläufe, die das Control unterstützen
Anwendungsbereiche / Scopes – falls ein Control mehrere Scopes betrifft

Du kannst:

bereits existierende Maßnahmen/Dokumente/Prozesse verbinden, oder
direkt aus der SOA heraus neue anlegen (z. B. neue Maßnahme für ein fehlendes Control).

Wichtig: Maßnahmen sind wiederverwendbar – du musst sie nicht je Scope neu anlegen, sondern kannst sie in mehreren Scopes und Modulen (z. B. ISO & IT-Grundschutz & BCM) verwenden.

Typische Arbeitsweise in der SOA🔗

Anwendungsbereich und Norm wählen
→ z. B. Scope „Security 2025“, Norm „ISO 27001 – Annex A“.
Controls durchgehen
- Anwendbarkeit definieren,
- Begründungen erfassen,
- Realisierungs-/Erfüllungs-/Zielerfüllungsgrad setzen.
Maßnahmen und Anlagen verknüpfen oder erstellen
- bestehende Maßnahmen/Anlagen wiederverwenden,
- Lücken durch neue Maßnahmen schließen.
Review mit Auditor:in/ISB vorbereiten
- SOA als Export oder direkt im Tool vorstellen,
- offene Punkte (z. B. Zielerfüllungsgrad < 100 %) in Maßnahmen überführen.

Zusammenhang mit Schutzbedarf, Risiko und Audits🔗

Die SOA liefert den Normenbezug: Welche Controls sind relevant und wie sind sie umgesetzt?
Die Schutzbedarfsfeststellung (SBF) bewertet die Schutzwürdigkeit deiner Prozesse/Assets.
Das Risikomanagement nutzt SBF & SOA, um Risiken und Maßnahmen zielgerichtet zu priorisieren.
Im Audit-Management dienen die SOA-Einträge als Prüfgrundlage – insbesondere um nachzuweisen, dass du für alle anwendbaren Controls eine belastbare Begründung und Umsetzung hast.

Die SOA ist damit das verbindende Element zwischen Normtext, technischer/organisatorischer Umsetzung und Auditnachweis.