Statement of Applicability als zentrales Audit-Dokument

Problem in der Praxis

In vielen Unternehmen entsteht das SoA als letztes Dokument vor dem Audit. Jemand nimmt den Referenz-Controlsatz, setzt überall "anwendbar" und ergänzt allgemeine Begründungen. Das Ergebnis sieht vollständig aus, ist aber von der tatsächlichen Risikolage abgekoppelt.

Solche SoA-Dokumente fallen im Audit auf. Auditoren prüfen nicht nur, ob das SoA existiert, sondern ob es zur Risikobewertung, zum Risikobehandlungsplan und zum gelebten Betrieb passt. Begründungen wie "Best Practice" oder "branchenüblich" tragen nicht, wenn der Bezug zum konkreten Risiko fehlt.

Ein zweites Muster ist das eingefrorene SoA: einmal erstellt, danach nicht mehr gepflegt. Neue Systeme, neue Dienstleister oder geänderte Risiken schlagen sich nicht nieder, und das SoA wird zum historischen Schnappschuss, während sich die Realität weiterbewegt.

CISO-Einordnung

Das SoA gehört in der ISO/IEC 27001 zur Risikobehandlung (Klausel 6.1.3) und schließt direkt an die Risikobewertung (Klausel 6.1.2) an. Es ist der Punkt, an dem aus bewerteten Risiken konkrete, begründete Maßnahmen werden.

Die Logik dahinter ist eine Kette: Zuerst werden Risiken bewertet, dann Behandlungsoptionen gewählt, dann die notwendigen Controls bestimmt. Danach erfolgt ein Abgleich mit dem Referenz-Controlsatz im Annex A der Norm, damit kein wesentliches Control übersehen wird. Das SoA hält das Ergebnis fest.

Inhaltlich verdichtet das SoA aus Managementsicht vier Aussagen: welche Controls notwendig sind, warum sie aufgenommen wurden, wie weit ihre Umsetzung ist und warum einzelne Annex-A-Controls bewusst nicht angewendet werden. Diese vier Aussagen sind der eigentliche Mehrwert. Sie machen das SoA zu einer Entscheidungsdokumentation, nicht zu einer Inventarliste.

Zur Einordnung: Der Annex A ist ein Referenz- und Abgleichsatz, keine Pflichtmenge. Notwendige Controls können auch aus anderen Quellen stammen oder eigenständig entworfen werden. Der Annex dient der Vollständigkeitsprüfung, nicht als Vorgabe, alles anzuwenden. Genau deshalb braucht jeder Ausschluss eine tragfähige Begründung statt einer Floskel. Der Referenz-Controlsatz umfasst 93 Controls in vier Themenfeldern (organisatorisch, personenbezogen, physisch, technologisch); die vollständige Liste führt die Originalnorm.

Umsetzungsperspektive

Ein belastbares SoA entsteht nicht am Ende, sondern parallel zur Risikobehandlung. Sinnvoll ist, das SoA als Sichtbarmachung der Behandlungsentscheidungen zu führen und nicht als separates Auditprodukt.

Praktisch hilft eine klare Struktur in eigenen Worten: das Control, der Bezug zum Risiko oder Szenario, die Aufnahme- oder Ausschlussbegründung, der Umsetzungsstatus und ein Verweis auf den zugehörigen Nachweis. Das ist ein eigenes Managementartefakt, keine Rekonstruktion der Norm.

Das SoA ist eng mit dem Risikobehandlungsplan verbunden, aber nicht identisch. Das SoA beschreibt, was angewendet wird und warum; der Plan beschreibt, wer bis wann umsetzt. Beide müssen konsistent sein. Die Genehmigung des Plans und die Akzeptanz der Restrisiken liegen bei den Risikoeignern, nicht bei der IT allein.

In der anerkannten Zertifizierungspraxis ist das SoA eines der ersten Dokumente in der Dokumentenprüfung, die im Markt oft als Stage 1 bezeichnet wird. Diese Stufenlogik stammt aus der Zertifizierungspraxis und den einschlägigen Konformitätsbewertungs-Normen, nicht aus der ISO/IEC 27001 selbst; die genauen Regeln gibt die akkreditierte Zertifizierungsstelle vor. Für den CISO ist praktisch relevant: Ein widerspruchsfreies, aktuelles SoA reduziert Rückfragen und Reibung deutlich.

Typische Fehler

1. Das SoA wird kurz vor dem Audit aus dem Referenz-Controlsatz erzeugt, ohne Bezug zur Risikobewertung.
2. Ausschlüsse werden mit Floskeln begründet statt mit nachvollziehbarer Risikologik.
3. Der Umsetzungsstatus wird zu optimistisch gesetzt und passt nicht zum Betrieb.
4. SoA und Risikobehandlungsplan widersprechen sich.
5. Das SoA wird nach Erstellung nicht mehr gepflegt.

Risiken und Trade-offs

Ein sehr detailliertes SoA wirkt gründlich, erzeugt aber hohen Pflegeaufwand. Jede Änderung an Risiken, Systemen oder Dienstleistern muss nachgezogen werden. Ein zu grobes SoA ist leichter zu pflegen, kann aber im Audit Lücken offenbaren und die Risikologik verschleiern.

Beim Umgang mit Ausschlüssen gibt es einen Zielkonflikt. Wer vorsichtshalber fast alles als anwendbar markiert, vermeidet Begründungsaufwand, bindet sich aber an Maßnahmen, die er womöglich nicht betreibt. Wer viel ausschließt, reduziert Aufwand, muss aber jeden Ausschluss tragfähig begründen können.

Ein weiterer Trade-off betrifft die Aktualität. Ein SoA, das bei jeder kleinen Änderung sofort angepasst wird, bindet Ressourcen; ein SoA, das nur jährlich gepflegt wird, veraltet zwischen den Zyklen. Sinnvoll ist eine Aktualisierungslogik, die an wesentliche Änderungen und an die regelmäßige Risikobetrachtung gekoppelt ist.

Entscheidungspunkte

• Wie eng wird das SoA an die Risikobewertung und den Behandlungsplan gekoppelt?
• Welche Granularität ist tragbar, ohne den Pflegeaufwand zu sprengen?
• Wer ist für die Pflege des SoA verantwortlich, und wer genehmigt Änderungen?
• Welche Ausschlüsse muss das Unternehmen belastbar begründen können?
• Wann wird das SoA aktualisiert: ereignisbasiert, zyklisch oder beides?

Praktische Empfehlungen

1. Führen Sie das SoA als Ergebnis der Risikobehandlung, nicht als separates Auditdokument.
2. Begründen Sie jeden Einschluss und jeden Ausschluss aus dem konkreten Risiko heraus.
3. Halten Sie SoA und Risikobehandlungsplan konsistent und widerspruchsfrei.
4. Setzen Sie den Umsetzungsstatus ehrlich; offene Punkte mit Owner und Frist sind besser als geschönte Stati.
5. Verankern Sie eine klare Aktualisierungslogik, gekoppelt an wesentliche Änderungen und die regelmäßige Risikobetrachtung.

Relevante Normreferenzen

• ISO/IEC 27001: Referenzrahmen für das Statement of Applicability als Teil der Risikobehandlung (Klausel 6.1.3) und für den Annex A als Referenz-Controlsatz.
• ISO/IEC 27002: Referenz für Leitlinien zu den Informationssicherheits-Controls, die im SoA referenziert werden.
• ISO/IEC 27005: Referenz für das Informationssicherheitsrisikomanagement und die Risikobehandlung, an die das SoA anschließt.
• ISO/IEC 27006-1: Referenz für Anforderungen an Stellen, die ISMS auditieren und zertifizieren; relevant für die Einordnung der Dokumentenprüfung als Zertifizierungspraxis.