Erklärung zur Anwendbarkeit schreiben, die das Audit besteht

ISO/IEC 27001 Klausel 6.1.3(d) verlangt eine Erklärung zur Anwendbarkeit: ein Dokument, das die von Ihnen benötigten Maßnahmen auflistet, begründet, warum Sie diese einbeziehen, ob sie umgesetzt sind und warum Sie einzelne der 93 Maßnahmen aus Anhang A ausgeschlossen haben. Das klingt nach Verwaltungsaufwand. In der Praxis ist sie die Brücke zwischen Ihrer Risikobewertung und Ihren Maßnahmen, und Zertifizierungsauditoren lesen sie genau, denn eine schwache Erklärung deutet meist auf einen schwachen Risikoprozess dahinter hin.

Was sie enthalten muss

Für jede Maßnahme in Anhang A sowie für eigene Maßnahmen:

1. Anwendbar oder nicht.
2. Begründung für die Einbeziehung: meist die Risiken, die sie adressiert, eine gesetzliche oder vertragliche Anforderung oder eine unternehmerische Entscheidung.
3. Umsetzungsstatus: umgesetzt, teilweise umgesetzt oder geplant.
4. Begründung für den Ausschluss, falls ausgeschlossen.

Die meisten Erklärungen ergänzen eine kurze Beschreibung, wie jede Maßnahme umgesetzt wird, und einen Verweis auf die Richtlinie oder Verfahrensanweisung. Das ist nicht zwingend vorgeschrieben, beschleunigt Audits aber deutlich.

Begründung der Einbeziehung

Verknüpfen Sie jede Maßnahme mit etwas Konkretem: einem Risiko in Ihrem Risikoregister, einer gesetzlichen Anforderung (DSGVO Artikel 32, NIS2, branchenspezifische Regulierung), einem Vertrag oder einer Kundenanforderung. „Best Practice“ ist eine schwache Begründung; „adressiert die Risiken R-12 und R-17 und ist durch unsere NIS2-Pflichten gefordert“ ist eine starke. Die Verknüpfung mit gesetzlichen Anforderungen hilft auch, wenn Sie mehreren Frameworks gegenüber verantwortlich sind: Auf unseren Anforderungsseiten sehen Sie, welchen anderen Frameworks jede Maßnahme aus Anhang A zugeordnet ist, zum Beispiel A.8.24 Verwendung von Kryptografie.

Begründung des Ausschlusses

Ausschlüsse sind zulässig, doch jeder braucht einen Grund, den Auditoren überprüfen können. Gute Gründe:

• Die Tätigkeit findet im Geltungsbereich nicht statt. Keine ausgelagerte Entwicklung: A.8.30 ausgeschlossen.
• Das Risiko besteht im Geltungsbereich nicht. Eine vollständig remote arbeitende Organisation ohne Büros kann einige physische Maßnahmen aus A.7 ausschließen, nicht jedoch jene, die Geräte und Datenträger unabhängig von ihrem Standort abdecken.

Schwache Gründe: „nicht relevant“, „wird von der IT erledigt“, „der Cloud-Anbieter übernimmt das“. Führt ein Dienstleister die Maßnahme aus, bleibt sie anwendbar; Sie steuern sie über Lieferantenmaßnahmen.

Typische Auditfeststellungen

• Die Erklärung passt nicht zum Risikobehandlungsplan. Im Risikobehandlungsplan gewählte Maßnahmen müssen in der Erklärung erscheinen und umgekehrt.
• Umgesetzte Maßnahmen ohne Nachweis. Wer eine Maßnahme als umgesetzt markiert, muss mit einer Aufforderung zum Nachweis rechnen.
• Vorlagentexte. Beschreibungen, die aus einer Vorlage kopiert wurden und nicht zu dem passen, was Sie tatsächlich tun.
• Veraltete Versionen. Eine Erklärung, die noch die Nummerierung aus Anhang A von 2013 verwendet oder nach einer wesentlichen Änderung nicht aktualisiert wurde.

Eine praktische Struktur

Eine Zeile pro Maßnahme: ID und Titel, anwendbar (ja/nein), Begründung (Risiken, gesetzliche und vertragliche Anforderungen), Status, eine einzeilige Beschreibung der Umsetzung, der Verantwortliche und der Verweis auf den Nachweis. Führen Sie sie in einer Tabellenkalkulation oder Ihrem GRC-Tool unter Dokumentenlenkung und prüfen Sie sie bei jeder Risikobewertung.

Die Erklärung aktuell halten

Eine Erklärung, die für die erste Zertifizierung erstellt und danach nie wieder angefasst wird, wird beim nächsten Audit zur Feststellung. Halten Sie sie aktuell, indem Sie sie immer dann aktualisieren, wenn:

• die Risikobewertung die ausgewählten Maßnahmen verändert;
• sich der Geltungsbereich ändert (ein neues Produkt, ein neuer Standort oder ein neuer Cloud-Anbieter);
• sich der Umsetzungsstatus einer Maßnahme ändert;
• eine neue gesetzliche oder vertragliche Anforderung gilt (zum Beispiel NIS2 oder der Vertrag eines Kunden).

Halten Sie bei jeder Änderung Version, Datum und Genehmiger fest.

Die wichtigsten Punkte

• Jede Maßnahme aus Anhang A braucht eine Entscheidung und eine Begründung, auch Ausschlüsse.
• Verknüpfen Sie Einbeziehungen mit konkreten Risiken sowie gesetzlichen oder vertraglichen Anforderungen.
• Halten Sie die Erklärung konsistent mit dem Risikobehandlungsplan und aktuell.

Mehrere Frameworks gleichzeitig abdecken

Wenn Sie auch gegenüber SOC 2, NIS2 oder PCI DSS verantwortlich sind, ergänzen Sie für jedes eine Spalte mit den passenden Anforderungen. Die Erklärung wird dann zum Rückgrat eines gemeinsamen Maßnahmensatzes. Unser Beitrag zu einem gemeinsamen Maßnahmensatz für SOC 2 und ISO 27001 zeigt den Ansatz, und die Lückenanalyse stellt jede Maßnahme aus Anhang A jedem anderen Framework gegenüber. Der ISO-27001-Leitfaden behandelt den Rest der Zertifizierung.

Fragen

Dürfen Maßnahmen aus Anhang A in ISO 27001 ausgeschlossen werden?

Ja, sofern der Ausschluss begründet ist, typischerweise weil das Risiko im Geltungsbereich nicht besteht (zum Beispiel ausgelagerte Entwicklung, wenn Sie Entwicklung nicht auslagern). Ausschlüsse müssen in der Erklärung zur Anwendbarkeit begründet werden.

Was muss eine Erklärung zur Anwendbarkeit enthalten?

ISO 27001 Klausel 6.1.3(d) verlangt die erforderlichen Maßnahmen, die Begründung für ihre Einbeziehung, ob sie umgesetzt sind, und die Begründung für den Ausschluss von Maßnahmen aus Anhang A.

Wird die Erklärung zur Anwendbarkeit mit Kunden geteilt?

In der Regel nicht vollständig; sie ist ein internes Dokument, das von der Zertifizierungsstelle geprüft wird. Manche Organisationen teilen eine Zusammenfassung unter NDA mit Kunden, um zu zeigen, welche Maßnahmen gelten.