Das Statement of Applicability, kurz SoA, gehört zu den wichtigsten Dokumenten in einem ISMS nach ISO 27001. Trotzdem wird es erstaunlich oft missverstanden.
Viele behandeln die SoA wie eine bloße Liste aus Anhang A. Andere sehen sie nur als Auditpflicht. Beides greift zu kurz.
Die SoA ist der Punkt, an dem sichtbar wird, welche Sicherheitsmaßnahmen für Ihr Unternehmen wirklich notwendig sind, warum das so ist und wie diese Auswahl begründet wurde. Genau deshalb ist sie weit mehr als eine Formalität. In der offiziellen ISO-Arbeitshilfe zur SoA wird sie als dokumentierte Information beschrieben, die die notwendigen Informationssicherheitsmaßnahmen einer Organisation enthält, ihre Begründung, ihren Umsetzungsstand und die Begründung für ausgeschlossene Anhang A-Controls.
Die kurze Antwort
Eine gute SoA beantwortet vier Fragen:
- Welche Sicherheitsmaßnahmen brauchen wir wirklich?
- Warum brauchen wir genau diese?
- Was davon ist bereits umgesetzt und was noch nicht?
- Warum sind bestimmte Referenz-Controls aus Anhang A für uns nicht notwendig?
Genau darin liegt ihr Wert. Sie zwingt Unternehmen dazu, Sicherheitsmaßnahmen nicht nur zu übernehmen, weil sie irgendwo in Anhang A stehen, sondern weil sie zum eigenen Kontext, zu den eigenen Risiken und zu den eigenen Anforderungen passen.
Was die SoA eigentlich ist
Die SoA ist nicht einfach eine hübsche Tabelle für Auditoren. Sie ist auch nicht bloß ein Nachschlagewerk für Anhang A.
Praktisch ist sie die Verdichtung Ihrer Entscheidungen zur Risikobehandlung. Sie bringt an einer Stelle zusammen, welche Controls für Ihr Unternehmen notwendig sind, wie diese begründet sind und ob sie bereits umgesetzt wurden. Genau so beschreibt es die offizielle ISO-Arbeitshilfe: Die SoA dokumentiert die necessary controls der Organisation, nicht einfach nur die Überschriften aus Anhang A.
Warum die SoA so wichtig ist
Die SoA ist deshalb so wichtig, weil sie die Brücke schlägt zwischen drei Dingen:
- Ihrer Risikobetrachtung;
- Ihrer Auswahl von Sicherheitsmaßnahmen;
- Ihrem Auditnachweis.
Wenn diese Brücke fehlt, entsteht schnell ein typisches Problem: Risiken wurden irgendwie betrachtet, Controls irgendwie eingeführt, aber die innere Logik dazwischen ist nicht sauber dokumentiert. Genau dort schafft die SoA Klarheit. Sie hilft nicht nur dem Auditor, sondern vor allem Ihnen selbst.
Was wirklich in eine SoA hineingehört
Eine brauchbare SoA sollte mindestens diese Elemente enthalten:
1. Die für Ihr Unternehmen notwendigen Controls
Nicht einfach nur Anhang A abgeschrieben, sondern die Controls, die Sie für Ihr Unternehmen als notwendig bestimmt haben.
2. Die Begründung für die Aufnahme
Zu jedem aufgenommenen Control sollte nachvollziehbar sein, warum es aufgenommen wurde. Und genau diese Begründung sollte sich aus Ihrem Kontext, Ihrem Risikomanagement und gegebenenfalls rechtlichen oder vertraglichen Anforderungen ergeben - nicht bloß aus der Tatsache, dass das Control in Anhang A steht.
3. Der Umsetzungsstatus
Die SoA sollte erkennbar machen, ob ein Control bereits umgesetzt ist, noch in Umsetzung ist oder in Teilen noch offen ist. Auch dieser Punkt wird in der ISO-Arbeitshilfe ausdrücklich genannt.
4. Die Begründung für ausgeschlossene Anhang A-Controls
Wenn ein Referenz-Control aus Anhang A für Ihr Unternehmen nicht notwendig ist, muss diese Entscheidung in der SoA begründet werden. Genau das ist einer der zentralen Zwecke des Dokuments.
Anhang A ist nicht die eigentliche Wahrheit
Anhang A ist eine Referenzmenge von Controls. Nicht mehr und nicht weniger. Die Controls dort sind weder automatisch vollständig noch automatisch für jede Organisation notwendig. Anhang A ist weder vollständig noch pauschal umzusetzen; die Entscheidung, welche Controls wirklich notwendig sind, liegt bei der Organisation selbst.
Das heißt praktisch: Ihre SoA sollte nicht den Eindruck machen, dass Sie nur brav jede Zeile aus Anhang A abgearbeitet haben. Sie sollte zeigen, dass Sie verstanden haben, welche Maßnahmen für Ihr Unternehmen notwendig sind.
Eine SoA ist keine bloße Anhang A-Tabelle
Die SoA ist Ihr maßgeschneidertes Dokument zur Anwendbarkeit von Controls. Sie darf zwar wie Anhang A strukturiert sein, sie muss es aber nicht. Die offizielle ISO-Arbeitshilfe sagt ausdrücklich, dass die Norm vorgibt, was in der SoA stehen muss, aber nicht, wie sie strukturiert sein muss. Sie kann also als Tabelle im Anhang A-Stil aufgebaut sein, aber auch anders — solange die nötigen Inhalte sauber enthalten sind.
Eigene Controls sind erlaubt – und manchmal sinnvoll
Das ist ein Punkt, den viele übersehen.
Wenn Ihr Unternehmen notwendige Controls nutzt, die nicht direkt aus Anhang A stammen, dürfen und sollen diese ebenfalls in die SoA aufgenommen werden. Die offizielle Arbeitshilfe nennt solche Maßnahmen ausdrücklich custom controls und beschreibt auch, dass sie Anhang A-Controls ersetzen oder ergänzen können.
Das ist wichtig, weil es zeigt: Die SoA ist kein Korsett. Sie ist ein Dokument Ihrer eigenen Sicherheitslogik.
Woran man eine gute SoA erkennt
Eine gute SoA ist nicht dadurch gut, dass sie besonders lang ist. Gut ist sie dann, wenn sie drei Dinge schafft:
- sie ist nachvollziehbar,
- sie ist sauber begründet,
- und sie passt wirklich zum Unternehmen.
Wenn die SoA bloß aus Standardphrasen besteht oder Controls nur deshalb aufgenommen wurden, weil sie "halt in Anhang A stehen", ist sie fachlich schwach. Wenn sie dagegen erkennbar aus dem eigenen Kontext, den Risiken und den realen Anforderungen des Unternehmens entwickelt wurde, ist sie stark.
FAQ
Die SoA ist ein zentrales ISMS-Dokument, das die notwendigen Sicherheitsmaßnahmen einer Organisation, deren Begründung, ihren Umsetzungsstatus und die Begründung für ausgeschlossene Annex-A-Controls dokumentiert.
Ja. Für die Zertifizierung gehört sie zu den zentralen dokumentierten Informationen rund um Risikobehandlung und Control-Auswahl. Die Version der SoA muss sogar in Zertifizierungsunterlagen referenziert werden.
Nein. Die Norm legt fest, was inhaltlich enthalten sein muss, aber nicht die konkrete Struktur. Eine Tabelle im Annex-A-Stil ist möglich, aber nicht zwingend.
Nein. Annex A ist eine Referenzmenge. Ob ein Control notwendig ist, entscheidet die Organisation selbst auf Basis von Kontext, Risiken und Anforderungen.
Ja. Eigene oder zusätzliche Controls sind ausdrücklich möglich und müssen in die SoA aufgenommen werden, wenn sie zu den notwendigen Controls Ihrer Organisation gehören.
Die SoA ist vor allem ein zentrales Steuerungs- und Auditdokument. Ob und in welcher Form Sie sie extern teilen, sollten Sie bewusst entscheiden. Da sich Ihr ISO 27001-Zertifikat jedoch explizit auf Ihr SoA-Dokument bezieht, macht es Sinn, eine Veröffentlichung nicht grundsätzlich abzulehnen.
Unser Tipp
Die SoA ist nicht einfach eine Annex-A-Liste mit Ampelfarben. Sie ist das Dokument, in dem sichtbar wird, welche Sicherheitsmaßnahmen Ihr Unternehmen wirklich braucht, warum das so ist und wie weit die Umsetzung ist. Genau deshalb ist sie so wertvoll: Sie verbindet Risikobetrachtung, Control-Auswahl und Auditnachweis an einer Stelle. Wenn sie sauber gemacht ist, wird das ganze ISMS verständlicher und belastbarer.
Interesse geweckt?
Wenn Sie Ihr Statement of Applicability so aufbauen wollen, dass es nicht wie ein Pflichtanhang wirkt, sondern wirklich Ihre Sicherheitslogik sauber abbildet, sprechen Sie mit uns oder schreiben uns etwas gleich hier rechts unten auf der Seite in den Chat!