Statement of Applicability (SoA) erstellen: Controls auswählen und begründen

Was ist die Statement of Applicability?

Die Statement of Applicability, auf Deutsch Anwendbarkeitserklärung oder kurz SoA, ist eines der wichtigsten Dokumente in deinem ISMS. Sie listet sämtliche Sicherheitsmaßnahmen (Controls) aus dem Annex A der ISO 27001 auf und hält für jeden einzelnen fest, ob er für dein Unternehmen relevant ist oder nicht. Wer eine ISO-27001-Zertifizierung anstrebt, kommt an der SoA nicht vorbei: Die Norm fordert sie explizit in Abschnitt 6.1.3.

Aber die SoA ist weit mehr als eine Pflichtübung. Sie ist die Brücke zwischen deiner Risikoanalyse und den konkreten Maßnahmen, die du umsetzt. Während das Risikoregister zeigt, welche Bedrohungen existieren — aufgebaut durch eine sorgfältige Risikobewertung —, dokumentiert die SoA, mit welchen Controls du diesen Bedrohungen begegnest. Damit wird sie zum zentralen Steuerungsinstrument für dein gesamtes Informationssicherheitsprogramm.

Für Auditoren ist die SoA das erste Dokument, das sie sich ansehen. Sie zeigt auf einen Blick, wie reif dein ISMS ist, welche Entscheidungen du getroffen hast und ob diese Entscheidungen nachvollziehbar begründet sind. Eine gut gepflegte SoA beschleunigt jedes Audit erheblich, eine lückenhafte dagegen zieht sofort Rückfragen nach sich.

Die 93 Controls aus Annex A verstehen

Mit der ISO 27001:2022 wurde der Annex A komplett überarbeitet. Statt der früheren 114 Controls in 14 Kategorien gibt es jetzt 93 Controls in vier übersichtlichen Themengebieten:

Organisatorische Controls (37 Stück): Hier geht es um Richtlinien, Rollen, Verantwortlichkeiten und Prozesse. Beispiele sind die Informationssicherheitsrichtlinie (A.5.1), die Aufgabentrennung (A.5.3) oder die Lieferantensicherheit (A.5.19 bis A.5.23). Dieser Bereich betrifft jedes Unternehmen, unabhängig von Größe oder Branche.

Personenbezogene Controls (8 Stück): Screening vor der Einstellung (A.6.1), Sensibilisierung und Schulung (A.6.3), Meldeprozesse für Sicherheitsvorfälle (A.6.8). Auch diese Controls sind fast immer anwendbar, sobald du Mitarbeitende beschäftigst.

Physische Controls (14 Stück): Zutrittskontrollen, Schutz von Geräten, Sicherheitszonen. Hier wird es zum ersten Mal spannend bei der Frage der Anwendbarkeit: Ein reines Cloud-Unternehmen ohne eigenes Rechenzentrum wird einige physische Controls anders bewerten als ein produzierendes Unternehmen mit Serverraum.

Technische Controls (34 Stück): Zugriffsrechte, Kryptografie, Netzwerksicherheit, sichere Entwicklung, Logging. Das ist der Bereich, in dem die IT-Abteilung am stärksten gefordert ist und in dem sich technische Schulden am deutlichsten zeigen.

Jeder dieser 93 Controls hat in der ISO 27002:2022 eine ausführliche Beschreibung mit Umsetzungshinweisen. Die ISO 27002 ist zwar nicht zertifizierungsrelevant, aber sie liefert dir das nötige Verständnis, um fundierte Entscheidungen über die Anwendbarkeit zu treffen.

Control für Control entscheiden: anwendbar oder nicht

Der Kern der SoA-Erstellung ist die systematische Bewertung jedes einzelnen Controls. Für jeden der 93 Annex-A-Controls triffst du eine binäre Entscheidung: anwendbar oder nicht anwendbar. Was einfach klingt, erfordert in der Praxis sorgfältige Überlegung und saubere Dokumentation.

Wann ist ein Control anwendbar?

Ein Control ist anwendbar, wenn mindestens eine der folgenden Bedingungen zutrifft:

Er adressiert ein Risiko, das du in deiner Risikoanalyse identifiziert hast. Das ist der häufigste und stärkste Grund. Wenn deine Risikoanalyse beispielsweise das Risiko "Unbefugter Zugriff auf Kundendaten durch ehemalige Mitarbeitende" enthält, dann ist der Control A.5.11 (Rückgabe von Vermögenswerten) direkt anwendbar.

Er wird durch gesetzliche oder vertragliche Anforderungen gefordert. Die DSGVO verlangt beispielsweise Verschlüsselung personenbezogener Daten, was A.8.24 (Einsatz von Kryptografie) anwendbar macht, selbst wenn deine Risikoanalyse das Thema nicht explizit als hohes Risiko eingestuft hat.

Er entspricht einer bewährten Praxis, die für dein Geschäftsmodell relevant ist. Backup-Prozesse (A.8.13) wirst du kaum als nicht anwendbar begründen können, auch wenn kein spezifisches Risiko dazu im Register steht.

Wann kann ein Control ausgeschlossen werden?

Ausschlüsse sind möglich, aber sie brauchen eine solide Begründung. Typische legitime Gründe:

Technologischer Kontext trifft nicht zu. Wenn dein Unternehmen keine eigene Softwareentwicklung betreibt, kannst du die Controls zur sicheren Entwicklung (A.8.25 bis A.8.28) als nicht anwendbar kennzeichnen. Die Begründung ist klar und nachvollziehbar.

Keine relevanten Assets vorhanden. A.7.3 (Sicherung von Büros, Räumen und Einrichtungen) kann für ein vollständig remote arbeitendes Unternehmen ohne physische Büroflächen eingeschränkt anwendbar sein. Aber Vorsicht: Selbst Homeoffice-Arbeitsplätze stellen physische Assets dar.

Risiko wurde anderweitig behandelt. Wenn ein Risiko vollständig durch einen anderen Control abgedeckt wird, kannst du den redundanten Control theoretisch ausschließen. In der Praxis ist es aber meist klüger, beide als anwendbar zu kennzeichnen und auf die gemeinsame Umsetzung zu verweisen.

Die Begründung ist entscheidend

Für jeden ausgeschlossenen Control musst du dokumentieren, warum er nicht anwendbar ist. Auditoren prüfen diese Begründungen gezielt. Eine gute Begründung ist spezifisch, nachvollziehbar und bezieht sich auf den konkreten Kontext deines Unternehmens.

Schwache Begründung: "Nicht relevant für unser Unternehmen."

Starke Begründung: "A.8.28 (Sichere Programmierung) ist nicht anwendbar, da wir keine eigene Softwareentwicklung betreiben. Alle eingesetzten Anwendungen werden als SaaS-Lösungen bezogen. Die Sicherheit der Entwicklungsprozesse bei unseren Anbietern wird über A.5.21 (Informationssicherheit in der IKT-Lieferkette) und vertragliche SLAs abgesichert."

Beachte den Unterschied: Die starke Begründung erklärt nicht nur das Warum, sondern verweist auch darauf, wie das zugrundeliegende Risiko dennoch adressiert wird. Genau das erwarten Auditoren.

Umsetzungsstatus dokumentieren

Für jeden anwendbaren Control dokumentierst du, wie weit die Umsetzung fortgeschritten ist. Die vier üblichen Stufen sind:

Vollständig umgesetzt: Der Control ist implementiert, wird gelebt und es gibt Nachweise dafür. Beispiel: Eine Passwortrichtlinie existiert, wird technisch durch Mindestlängen im Active Directory erzwungen und Mitarbeitende wurden geschult.

Teilweise umgesetzt: Die Maßnahme existiert, hat aber Lücken. Beispiel: Zugriffsrechte werden vergeben, aber es fehlt ein regelmäßiger Rezertifizierungsprozess. Oder: Backups werden erstellt, aber noch nie in einem Restore-Test überprüft.

Geplant: Der Control ist als Maßnahme identifiziert, aber die Umsetzung hat noch nicht begonnen. Hier gehört ein konkretes Zieldatum dazu. "Geplant" ohne Zeitrahmen wirkt im Audit wie eine Ausrede.

Nicht anwendbar: Der Control wurde bewusst ausgeschlossen, mit dokumentierter Begründung (siehe oben).

Den Reifegrad ehrlich einschätzen

Die größte Falle bei der Statusdokumentation ist Selbstüberschätzung. Viele Organisationen stufen Controls als "vollständig umgesetzt" ein, die bei genauerem Hinsehen bestenfalls "teilweise" sind. Ein Control ist erst vollständig umgesetzt, wenn drei Bedingungen erfüllt sind:

Die Maßnahme ist definiert und dokumentiert. Es gibt also eine Richtlinie, eine Arbeitsanweisung oder eine technische Konfiguration, die nachweisbar existiert.

Die Maßnahme wird operativ gelebt. Sie existiert nicht nur auf dem Papier, sondern wird im Tagesgeschäft tatsächlich angewendet. Mitarbeitende kennen sie und handeln danach.

Die Wirksamkeit wird überprüft. Es gibt eine Form der Kontrolle, ob die Maßnahme ihren Zweck erfüllt. Das kann ein regelmäßiger Review, ein technisches Monitoring oder ein internes Audit sein.

Wenn eine dieser drei Bedingungen fehlt, ist der Status "teilweise umgesetzt". Das ist kein Problem und völlig normal, gerade beim initialen Aufbau eines ISMS. Problematisch wird es erst, wenn du den Status beschönigst und der Auditor die Lücke entdeckt.

Ergänzende Informationen pro Control

Neben dem reinen Status lohnt es sich, weitere Informationen in der SoA zu dokumentieren:

Verantwortlicher: Wer ist für die Umsetzung und den laufenden Betrieb dieses Controls zuständig? Das schafft Verbindlichkeit und vereinfacht die Kommunikation im Audit.

Nachweisdokument: Wo findet man den Beleg für die Umsetzung? Verweise auf Richtlinien, Konfigurationen, Screenshots oder Prüfprotokolle.

Maßnahmen-ID: Wenn du ein Maßnahmenregister führst, verknüpfe jeden Control mit den zugehörigen Maßnahmen. So entsteht eine durchgängige Nachverfolgbarkeit von Risiko über Control bis zur konkreten Maßnahme.

Zieldatum: Bei teilweise umgesetzten oder geplanten Controls das Datum, bis wann die vollständige Umsetzung erreicht sein soll.

In ISMS Lite sind alle 93 Controls mit Begründungsfeldern, Verantwortlichkeiten und Cross-Mappings vorstrukturiert, sodass du die SoA nicht von Grund auf in Excel aufbauen musst.

Cross-Mappings: Ein Control, viele Frameworks

Die SoA entfaltet ihren vollen Wert, wenn du sie nicht isoliert für ISO 27001 betrachtest, sondern als zentrales Compliance-Dokument nutzt. Viele Controls aus dem Annex A decken gleichzeitig Anforderungen aus anderen Regelwerken ab. Diesen Zusammenhang explizit zu dokumentieren, spart enorm viel doppelte Arbeit.

Typische Mappings

ISO 27001 zu NIS2: Die NIS2-Richtlinie fordert unter anderem Risikomanagement, Incident Response, Business Continuity und Lieferkettensicherheit. All das findet sich bereits in den Annex-A-Controls. Wenn du A.5.24 (Planung und Vorbereitung für die Bewältigung von Informationssicherheitsvorfällen) umsetzt, erfüllst du damit gleichzeitig die NIS2-Anforderung zur Vorfallsbewältigung.

ISO 27001 zu DSGVO: Technische und organisatorische Maßnahmen (TOMs) nach Art. 32 DSGVO lassen sich direkt auf Annex-A-Controls mappen. A.8.24 (Kryptografie) entspricht der DSGVO-Anforderung zur Verschlüsselung, A.5.12 (Klassifizierung von Informationen) unterstützt die datenschutzkonforme Datenklassifizierung.

ISO 27001 zu TISAX: Für Automobilzulieferer, die TISAX-Konformität nachweisen müssen, bildet die SoA eine exzellente Grundlage. Viele TISAX-Anforderungen haben direkte Entsprechungen im Annex A, ergänzt um branchenspezifische Zusatzanforderungen zum Prototypenschutz.

ISO 27001 zu BSI IT-Grundschutz: Die Bausteine des IT-Grundschutz-Kompendiums lassen sich ebenfalls auf Annex-A-Controls abbilden. Das ist besonders relevant, wenn du im öffentlichen Sektor arbeitest oder Kunden hast, die IT-Grundschutz voraussetzen.

Warum sich Cross-Mappings lohnen

Der offensichtliche Vorteil: Du vermeidest Doppelarbeit. Wenn du einmal sauber dokumentiert hast, dass dein Backup-Prozess sowohl A.8.13 (Informationssicherung) als auch die NIS2-Anforderung zur Betriebskontinuität als auch Art. 32 DSGVO abdeckt, musst du bei der nächsten Compliance-Prüfung nicht bei null anfangen.

Der weniger offensichtliche Vorteil: Cross-Mappings decken Lücken auf. Wenn ein NIS2-Anforderungspunkt keinem Annex-A-Control zugeordnet werden kann, hast du entweder einen Control übersehen oder es gibt eine Anforderung, die über den Annex A hinausgeht und die du separat adressieren musst.

In der Praxis empfiehlt sich pro Control eine zusätzliche Spalte oder ein Feld, in dem du die zugeordneten Framework-Referenzen auflistest. Also beispielsweise: "A.8.13 → ISO 27001 Annex A, NIS2 Art. 21 Abs. 2 lit. c, DSGVO Art. 32 Abs. 1 lit. c".

Snapshots: Den aktuellen Stand einfrieren

Deine SoA ist ein lebendes Dokument. Controls werden umgesetzt, Risiken verändern sich, neue Anforderungen kommen hinzu. Genau deshalb ist es wichtig, den aktuellen Stand regelmäßig als Snapshot einzufrieren.

Warum Snapshots wichtig sind

Fortschrittsmessung: Wenn du den Snapshot von vor sechs Monaten mit dem heutigen Stand vergleichst, siehst du sofort, wie viele Controls von "geplant" auf "umgesetzt" gewechselt haben. Das ist nicht nur motivierend, sondern liefert dem Management auch messbare KPIs zur Informationssicherheit.

Audit-Nachweise: Zertifizierungsaudits finden zu einem bestimmten Zeitpunkt statt. Der Snapshot zeigt den Stand genau zu diesem Zeitpunkt. Bei Überwachungsaudits in den Folgejahren wird der Auditor die Entwicklung vergleichen wollen. Ohne Snapshots fehlt diese historische Dimension.

Regulatorische Anforderungen: Sowohl die ISO 27001 als auch NIS2 fordern die regelmäßige Überprüfung und Aktualisierung von Sicherheitsmaßnahmen. Snapshots dokumentieren, dass diese Überprüfung stattfindet.

Veränderungsnachweis: Wenn ein Control seinen Status ändert, etwa weil eine neue Bedrohung auftaucht und ein zuvor ausgeschlossener Control jetzt relevant wird, zeigt die Snapshot-Historie diese bewusste Entscheidung. Das ist im Audit Gold wert.

Empfohlener Rhythmus

Erstelle Snapshots mindestens in diesen Situationen:

Vor jedem Zertifizierungsaudit oder Überwachungsaudit. Das ist der Mindeststandard, den jeder Auditor erwartet.

Nach Abschluss eines größeren Umsetzungsprojekts. Wenn du beispielsweise das gesamte Berechtigungsmanagement überarbeitet hast, halte den neuen Stand fest.

Quartalsweise als festen Rhythmus. Das ist die pragmatischste Lösung und liefert regelmäßige Datenpunkte für Trend-Analysen.

Nach wesentlichen organisatorischen Änderungen. Eine Fusion, ein neuer Geschäftsbereich oder die Einführung einer neuen Technologieplattform können die Anwendbarkeit mehrerer Controls verändern.

Praxisbeispiel: SoA-Auszug für ein 100-Mitarbeitende-Unternehmen

Nehmen wir ein mittelständisches IT-Dienstleistungsunternehmen mit 100 Mitarbeitenden als Beispiel. Das Unternehmen entwickelt keine eigene Software, betreibt keine eigenen Rechenzentren und arbeitet hybrid (Büro plus Homeoffice). Die Infrastruktur läuft überwiegend in der Cloud (Microsoft 365, Azure). Hier ein Auszug aus der SoA:

Organisatorische Controls (Auszug)

A.5.1 Richtlinien für die Informationssicherheit Status: Vollständig umgesetzt. Begründung: Zentrale Informationssicherheitsrichtlinie liegt vor, vom Geschäftsführer freigegeben, allen Mitarbeitenden zugänglich. Jährliche Überprüfung terminiert. Cross-Mapping: NIS2 Art. 21 Abs. 2 lit. a, DSGVO Art. 24.

A.5.3 Aufgabentrennung Status: Teilweise umgesetzt. Begründung: Kritische Funktionen (z.B. Buchhaltung/Freigabe) sind getrennt. Bei IT-Administratoren besteht noch Nachholbedarf bei der Trennung von Admin- und Benutzerkonten. Maßnahme geplant bis Q3 2026.

A.5.23 Informationssicherheit bei Nutzung von Cloud-Diensten Status: Teilweise umgesetzt. Begründung: Vertragsklauseln zur Informationssicherheit sind in den wichtigsten Cloud-Verträgen enthalten. Es fehlt noch ein systematischer Cloud-Security-Review-Prozess für neue Dienste. Umsetzung geplant bis Q2 2026. Cross-Mapping: NIS2 Art. 21 Abs. 2 lit. d.

Personenbezogene Controls (Auszug)

A.6.1 Screening Status: Vollständig umgesetzt. Begründung: Für alle Neueinstellungen werden Referenzprüfungen und Qualifikationsnachweise vor Arbeitsbeginn durchgeführt. Prozess in der Onboarding-Checkliste dokumentiert.

A.6.3 Informationssicherheitsbewusstsein, -ausbildung und -schulung Status: Teilweise umgesetzt. Begründung: Jährliche Online-Schulung für alle Mitarbeitenden eingeführt. Rollenspezifische Schulungen für IT-Admins und Führungskräfte sind noch in Planung (Ziel: Q4 2026). Cross-Mapping: NIS2 Art. 21 Abs. 2 lit. g.

Physische Controls (Auszug)

A.7.1 Physische Sicherheitsperimeter Status: Vollständig umgesetzt. Begründung: Bürogebäude mit Zutrittskontrollsystem (Chipkarte), Empfangsbereich mit Besucheranmeldung. Serverraum separat gesichert.

A.7.4 Physische Sicherheitsüberwachung Status: Nicht anwendbar. Begründung: Keine eigene Videoüberwachung. Das Bürogebäude wird durch den Vermieter mit Kamera-Überwachung im Eingangsbereich ausgestattet. Die Verantwortung liegt beim Gebäudemanagement; vertragliche Vereinbarungen zur Sicherheitsüberwachung sind im Mietvertrag geregelt.

Technische Controls (Auszug)

A.8.1 Benutzerendgeräte (User Endpoint Devices) Status: Vollständig umgesetzt. Begründung: Alle Laptops mit Festplattenverschlüsselung (BitLocker), MDM-Lösung (Intune) für Richtliniendurchsetzung, automatische Updates. Bring-Your-Own-Device ist nicht gestattet. Cross-Mapping: DSGVO Art. 32 Abs. 1 lit. a.

A.8.9 Konfigurationsmanagement Status: Geplant. Begründung: Aktuell kein systematisches Konfigurationsmanagement vorhanden. Die Einführung eines Configuration-Management-Prozesses inklusive Baseline-Dokumentation für Server und Netzwerkgeräte ist als Projekt für Q2 bis Q3 2026 vorgesehen.

A.8.25 Sicherer Entwicklungslebenszyklus Status: Nicht anwendbar. Begründung: Das Unternehmen betreibt keine eigene Softwareentwicklung. Alle Geschäftsanwendungen werden als SaaS-Lösungen bezogen oder als Standardsoftware eingesetzt. Die Sicherheit der Entwicklungsprozesse bei Lieferanten wird über A.5.21 (Informationssicherheit in der IKT-Lieferkette) und vertragliche Vereinbarungen sichergestellt.

A.8.28 Sichere Programmierung Status: Nicht anwendbar. Begründung: Keine interne Softwareentwicklung (siehe A.8.25). Für Konfigurationen und Skripte gelten interne Richtlinien zur sicheren Konfiguration im Rahmen von A.8.9.

Dieses Beispiel zeigt einige wichtige Muster: Die meisten Controls sind anwendbar, auch wenn nicht alle vollständig umgesetzt sind. Ausschlüsse betreffen vor allem Bereiche, die zum Geschäftsmodell nicht passen (keine eigene Softwareentwicklung). Und bei jedem Ausschluss wird erklärt, wie das zugrundeliegende Risiko anderweitig behandelt wird.

Typische Fehler bei der SoA-Erstellung

Zum Abschluss die häufigsten Fehler, die du vermeiden solltest:

Zu viele Ausschlüsse ohne Substanz. Wenn mehr als 15 bis 20 der 93 Controls als nicht anwendbar markiert sind, wird jeder Auditor kritisch nachfragen. Die meisten Controls sind für die meisten Organisationen relevant.

Copy-Paste-Begründungen. Jeder Ausschluss braucht eine individuelle Begründung, die zum spezifischen Kontext deines Unternehmens passt. Generische Texte wie "Nicht relevant" oder "Wird nicht benötigt" reichen nicht aus.

Fehlende Verbindung zur Risikoanalyse. Die SoA existiert nicht im luftleeren Raum. Jeder anwendbare Control sollte auf ein oder mehrere Risiken aus deinem Risikoregister zurückführbar sein. Wenn diese Verbindung fehlt, fehlt dem Auditor die Logik hinter deinen Entscheidungen.

Einmalige Erstellung ohne Pflege. Die SoA ist kein Dokument, das du einmal erstellst und dann im Schrank verstauben lässt. Mindestens jährlich — etwa im Rahmen des internen Audits —, besser quartalsweise, solltest du sie überprüfen und bei Bedarf aktualisieren.

Umsetzungsstatus beschönigen. "Teilweise umgesetzt" ist kein Makel, sondern ein Zeichen von Ehrlichkeit und Reife. Auditoren erkennen schnell, wenn der dokumentierte Status nicht zur Realität passt. Das beschädigt das Vertrauen in das gesamte ISMS.

SoA nur als Tabelle denken. Eine Tabelle ist ein guter Anfang, aber die SoA wird erst wertvoll, wenn sie mit dem Risikoregister, dem Maßnahmenplan und den Compliance-Anforderungen verknüpft ist. Isolierte Excel-Tabellen ohne Querverbindungen sind schwer zu pflegen und verlieren schnell an Aktualität.

Der Weg zur fertigen SoA

Die SoA zu erstellen ist keine Raketenwissenschaft, aber sie erfordert Sorgfalt, Kontext-Wissen und die Bereitschaft, jede Entscheidung sauber zu dokumentieren. Starte mit der vollständigen Liste aller 93 Controls, arbeite sie systematisch durch und nimm dir für die Begründungen ausreichend Zeit. Beziehe Fachabteilungen ein, denn ob ein Control anwendbar ist, lässt sich oft nicht allein vom Schreibtisch aus beurteilen.

Denke daran: Die SoA ist ein lebendes Dokument. Sie wird sich mit deinem ISMS weiterentwickeln, und genau darin liegt ihr Wert. Jeder Snapshot dokumentiert den Reifegrad deiner Informationssicherheit zu einem bestimmten Zeitpunkt. Über die Zeit entsteht so eine nachvollziehbare Geschichte deiner Sicherheitsentwicklung, die im Audit, im Management-Review und bei regulatorischen Prüfungen überzeugt.

Weiterführende Artikel

• ISMS aufbauen: Der komplette Leitfaden für Unternehmen mit 50 bis 500 Mitarbeitern
• Geltungsbereich (Scope) definieren: Was gehört ins ISMS und was nicht?
• NIS2 vs. ISO 27001: Unterschiede, Gemeinsamkeiten und wie beides zusammenpasst
• Risikobewertung im ISMS: Methodik, Matrix und Praxisbeispiel
• Internes ISMS-Audit durchführen: Planung, Checkliste und Bericht

Wenn du die SoA nicht als lästige Pflicht, sondern als zentrales Steuerungsinstrument begreifst, wird sie zu dem Dokument, das dein ISMS zusammenhält. Sie verbindet Risiken mit Maßnahmen, Maßnahmen mit Verantwortlichkeiten und Verantwortlichkeiten mit Nachweisen. Und genau das ist es, was ein funktionierendes ISMS ausmacht.