Das Statement of Applicability — auf Deutsch Erklärung zur Anwendbarkeit, im Alltag fast immer SoA genannt — ist das Dokument, in dem eine Organisation jede Maßnahme aus Anhang A der ISO/IEC 27001 einzeln bewertet. Für jede Maßnahme steht darin, ob sie angewendet wird, warum, und wie weit sie umgesetzt ist. Es ist das einzige Dokument des ISMS, dessen Inhalt die Norm derart genau vorgibt.
Vier Angaben je Maßnahme
Die Erklärung entsteht aus der Risikobehandlung, nicht neben ihr. Aus der Risikobewertung ergeben sich die Maßnahmen, die notwendig sind. Erst danach wird gegen Anhang A abgeglichen, um Lücken zu finden. Die SoA hält das Ergebnis fest:
- Anwendbarkeit — wird die Maßnahme genutzt oder nicht?
- Begründung der Aufnahme — aus welchem Risiko, welcher gesetzlichen Anforderung oder welcher Vertragspflicht folgt sie?
- Umsetzungsstand — vollständig, teilweise, geplant, mit Verweis auf die Regelung, die sie umsetzt.
- Begründung des Ausschlusses — bei jeder nicht angewendeten Maßnahme.
Seit der Fassung 2022 umfasst Anhang A 93 Maßnahmen in vier Themen: organisatorisch, personenbezogen, physisch, technologisch. Vorher waren es 114 in 14 Abschnitten. Wer eine alte Vorlage weiterverwendet, produziert eine SoA, die zur geprüften Normfassung nicht passt.
Warum die Zertifizierungsstelle zuerst danach fragt
Die SoA ist neben dem Geltungsbereich das zentrale Dokument im Stufe-1-Audit. Der Auditor plant daraus das Stufe-2-Audit: Er sieht, welche Maßnahmen die Organisation für sich als anwendbar erklärt hat, und prüft im zweiten Schritt genau diese in der Praxis. Fehlt die Erklärung oder ist sie erkennbar unfertig, wird das Stufe-2-Audit nicht terminiert. Das ist die häufigste Ursache für eine Verschiebung im Ablauf der Zertifizierung.
Woran es in der Praxis scheitert
Der typische Fehler ist die aus einer Beratervorlage übernommene Tabelle, in der alle Maßnahmen als anwendbar markiert sind und in der Begründungsspalte durchgängig derselbe Satz steht. Das fällt in wenigen Minuten auf, weil der Auditor zwei oder drei Maßnahmen herausgreift und nach dem Risiko fragt, aus dem sie folgt.
Der zweite Klassiker ist der Widerspruch zwischen SoA und Risikobehandlungsplan: In der SoA steht „umgesetzt”, der Behandlungsplan führt dieselbe Maßnahme als offene Aufgabe. Beide Dokumente werden im Audit nebeneinandergelegt.
Der dritte betrifft Ausschlüsse mit falscher Begründung. „Nicht zutreffend, da keine eigene Softwareentwicklung” ist tragfähig — solange nicht im selben Audit die selbst gebaute Auswertungsanwendung auftaucht. Ausgeschlossen wird, was es nicht gibt, nicht was unbequem ist.
Schließlich: Die SoA unterliegt der Dokumentenlenkung wie jedes andere gelenkte Dokument. Version, Freigabe und Datum müssen erkennbar sein. Eine unversionierte Datei auf einem Gruppenlaufwerk ist im Audit kein Nachweis, sondern ein Fund.
Eine brauchbare Selbstprüfung vor dem Audit: Greifen Sie fünf Maßnahmen zufällig heraus und verfolgen Sie jede rückwärts bis zu dem Risiko, aus dem sie stammt, und vorwärts bis zu dem Nachweis, der ihre Wirksamkeit belegt. Wenn diese Kette bei mehr als einer der fünf reißt, ist die Erklärung noch nicht prüfungsreif.