SoA Statement of Applicability.

Warum ISO 27001 das SoA verpflichtend macht

Die Anwendbarkeitserklärung ist die Brücke zwischen Ihrer Risikoarbeit und den Maßnahmen, die ein Auditor tatsächlich prüfen wird. ISO/IEC 27001 lässt den Normtext bewusst offen, welche Maßnahmen Sie umsetzen müssen, weil die richtige Antwort von Ihrem Kontext und Ihren Risiken abhängt. Im SoA schließen Sie diese Lücke: für jede Referenzmaßnahme aus Anhang A halten Sie fest, ob sie anwendbar ist, die Begründung für Aufnahme oder Ausschluss, ob sie bereits umgesetzt ist und wo die zugehörigen Nachweise liegen. Es ist eines der wenigen Dokumente, die die Norm ausdrücklich als erforderliches Ergebnis benennt, weshalb kein Zertifizierungsaudit ohne es abläuft.

Eine hilfreiche Sichtweise ist, dass das SoA einen generischen Maßnahmenkatalog in eine Aussage speziell über Ihre Organisation verwandelt. Der Referenzsatz aus Anhang A ist für alle gleich. Ihr SoA ist es nicht. Zwei zertifizierte Unternehmen ähnlicher Größe können legitim unterschiedliche Maßnahmen ausschließen, weil sich ihre Risikobeurteilungen und ihr Betriebskontext unterscheiden. Das Dokument existiert, um diese Entscheidungen sichtbar und begründbar zu machen, statt sie implizit zu lassen.

Wie das SoA mit der Risikobeurteilung und der Risikobehandlung zusammenhängt

Das SoA steht nicht für sich allein. Es ist das nachgelagerte Ergebnis der Risikobeurteilung und des Risikobehandlungsplans, und die drei müssen übereinstimmen. Die Risikobeurteilung identifiziert, was schiefgehen könnte. Der Risikobehandlungsplan entscheidet, was bei jedem Risiko zu tun ist, einschließlich der anzuwendenden Maßnahmen. Das SoA erklärt dann, Maßnahme für Maßnahme, was diese Entscheidung gegenüber dem Referenzsatz aus Anhang A bedeutet. Wenn ein Auditor das SoA liest, prüft er in Wahrheit, ob die Linie von einem dokumentierten Risiko über eine Behandlungsentscheidung zu einer angewendeten Maßnahme und schließlich zu echten Nachweisen durchgängig hält.

Ausschlüsse verdienen besondere Sorgfalt. Eine Maßnahme als nicht anwendbar zu markieren ist legitim, aber nur mit einer genannten und an Ihren Kontext gebundenen Begründung. «Wir entwickeln keine Software im Haus» ist eine vertretbare Grundlage, um bestimmte Entwicklungsmaßnahmen einzugrenzen. «Wir sind nicht dazu gekommen» ist kein Ausschluss, sondern eine Lücke. Auditoren hinterfragen Ausschlüsse genau deshalb, weil Organisationen dort mitunter unfertige Arbeit verbergen.

Was Praktiker tatsächlich pflegen

Das SoA als lebendes Register statt als einmalige Tabelle zu behandeln, ist das, was ein reibungsloses Überwachungsaudit von einer hektischen Aufholjagd unterscheidet. In der Praxis sieht eine gute Pflege so aus:

1. Führen Sie eine Zeile je Maßnahme aus Anhang A, mit Anwendbarkeit, Begründung, Umsetzungsstatus und einem Nachweisverweis, dem ein Auditor auch ohne Sie im Raum folgen kann.
2. Erstellen Sie das SoA jedes Mal neu, wenn sich die Risikobeurteilung oder der Behandlungsplan ändert, damit die drei Dokumente nie stillschweigend auseinanderlaufen.
3. Knüpfen Sie jeden Nachweisverweis an etwas Reales und Aktuelles: eine Richtlinie, eine Konfiguration, ein Ticket, ein Log, nicht an das Versprechen, ihn später zu erstellen.
4. Überprüfen Sie das Dokument in festem Takt und in der Managementbewertung, nicht erst in den Wochen vor einem Audit.
5. Beim Übergang zwischen Versionen der Norm bilden Sie das SoA auf den überarbeiteten Maßnahmensatz neu ab und stellen sicher, dass bei zusammengeführten oder neu eingeführten Maßnahmen nichts durchgefallen ist.

Auf diese Weise gepflegt, hört das SoA auf, Audit-Papierkram zu sein, und wird zum Index Ihres gesamten Informationssicherheits-Managementsystems. Es ist das erste Dokument, nach dem ein erfahrener Auditor fragt, weil es ihm zeigt, wo alles andere liegt.