Nicht-Anwendbare Controls in der ISO 27001 – Auditfest begründen

In der ISO 27001 ist es ausdrücklich erlaubt, Controls aus Anhang A als nicht anwendbar zu kennzeichnen. Entscheidend ist nicht die Anzahl der umgesetzten Maßnahmen, sondern die Qualität der Begründung. Genau hier setzen Auditoren an.

ISO 27001 Anhang A – Controls:

Der Anhang A der ISO/IEC 27001 beschreibt die 93 sicherheitsrelevanten Controls, die als mögliche Maßnahmen zur Behandlung identifizierter Risiken herangezogen werden. Die Controls gliedern sich in organisatorische, personenbezogene, physische sowie technologische Maßnahmen.

Entscheidend ist nicht die vollständige Umsetzung aller Controls, sondern deren systematische Bewertung, Begründung der Anwendbarkeit oder des Ausschlusses sowie die dokumentierte Ableitung im Statement of Applicability (SoA).

Die Erklärung der Anwendbarkeit (SoA) zeigt, welche Controls umgesetzt werden und vor allem warum. Jede Begründung ist ein direkter Nachweis, dass Risiken strukturiert bewertet und angemessene Maßnahmen ausgewählt wurden.

Auditoren bewerten weniger die Vollständigkeit, sondern die Nachvollziehbarkeit: Passt die Auswahl der Controls zum Kontext, zu den Risiken und zu den gesetzlichen oder vertraglichen Verpflichtungen.

Risiko- und Prozessbezug:

Jedes Control muss auf mindestens ein identifiziertes Risiko und auf konkrete Prozesse verweisen. Typisch ist die Verknüpfung mit Asset Management, HR-Prozessen oder dem IT-Betrieb.

Rechts- und Vertragsbezug:

Begründungen sollten klar machen, welche gesetzlichen, regulatorischen oder vertraglichen Anforderungen adressiert werden, etwa Datenschutzrecht oder Kundenanforderungen.

Verantwortlichkeiten und Aktualität:

Für jedes Control ist ein Verantwortlicher zu benennen. Begründungen müssen regelmäßig überprüft und bei veränderten Risiken angepasst werden, idealerweise im Rahmen der Managementbewertung.

Beispiel Verantwortlichkeiten für Informationssicherheit: Risiko durch unklare Zuständigkeiten. Begründung über dokumentierte Rollen, Bestellschreiben und Schulungen. Nachweise sind ISMS-Handbuch, Organigramm und Schulungsprotokolle.

Beispiel Zugriffsrechte: Risiko unautorisierter Zugriffe. Begründung über rollenbasiertes Berechtigungskonzept, Ticketprozesse und Rezertifizierungen. Nachweise sind Workflows, Protokolle und Auditberichte.

Controls werden pauschal als nicht anwendbar markiert, obwohl Risiken vorhanden sind. Häufig fehlen der Bezug zur Risikomatrix oder klare Nachweise.

Formulierungen wie wird umgesetzt oder ist geplant gelten im Audit nicht als Wirksamkeitsnachweis. Offene Punkte gehören in den Maßnahmenplan, nicht als erledigte Control-Begründung in die SoA.

Eine gute Begründung beantwortet immer drei Fragen: Warum relevant, wie umgesetzt und wo nachgewiesen. Wer diese Logik konsequent verfolgt, vermeidet Diskussionen im Audit und stärkt die Glaubwürdigkeit seines Informationssicherheits-Managementsystems.

Wann dürfen Controls ausgeschlossen werden:

Nicht jede Maßnahme aus Anhang A ist für jede Organisation relevant. Entscheidend ist, dass der Ausschluss nachvollziehbar ist und keine verbleibenden Risiken bestehen. Ein Control darf nur ausgeschlossen werden, wenn das zugrunde liegende Risiko nachweislich nicht existiert oder durch andere Maßnahmen ausreichend abgedeckt ist. Die Begründung sollte logisch zur Risikomatrix und zur Systemarchitektur passen.

Merksatz:

Kein Control ohne Risiko und kein Ausschluss ohne Nachweis.

Begründung für den Ausschluss:

Das Unternehmen betreibt keine eigenen Serverräume oder Rechenzentren. Sämtliche Systeme werden in einem Cloud Rechenzentrum eines Anbieters wie zum Beispiel Microsoft Azure in der Region Frankfurt betrieben. Die physische Sicherheit liegt nachweislich in der Verantwortung des Cloud Providers.

Risikobewertung und Nachweise:

Risiken aus physischem Zugriff gelten als an den Cloud Provider übertragen. Verträge, Sicherheitskonzepte und Zertifizierungen des Anbieters zum Beispiel ISO 27001 und SOC Berichte belegen die Angemessenheit der physischen Schutzmaßnahmen. Status: ausgeschlossen, dokumentiert im Kapitel A.7.5 der Anwendbarkeitserklärung inklusive Verweis auf Vertrag und Zertifikat.

Begründung für den Ausschluss:

Das Unternehmen besitzt keine eigenen Hardware Assets im Sinne von Laptops oder Mobilgeräten. Mitarbeitende nutzen private Geräte auf Basis einer klar geregelten BYOD Richtlinie. Der Zugriff auf Unternehmensinformationen erfolgt ausschließlich über gesicherte virtuelle Arbeitsumgebungen, ohne lokale Datenspeicherung auf Endgeräten.

Risikobewertung und alternative Kontrollen:

Das Risiko eines Verlustes physischer Unternehmensgeräte entfällt. Zugriffskontrolle, Multi Faktor Authentifizierung und schnelle Deaktivierung von Accounts regeln die sichere Trennung beim Ausscheiden. Relevante Risiken werden durch andere Maßnahmen wie Zugriffssteuerung und Monitoring von Systemaktivitäten abgedeckt. Status: ausgeschlossen, da das Risiko physischer Assets nicht besteht, dokumentiert im Abschnitt A.6.4 der Anwendbarkeitserklärung.

Begründung für den Ausschluss:

Das Unternehmen entwickelt keine eigenen Software Anwendungen. Es werden ausschließlich Standardprodukte externer Hersteller eingesetzt, die im Rahmen eines definierten Beschaffungsprozesses ausgewählt und regelmäßig aktualisiert werden.

Risikobewertung und Lieferantenbezug:

Das Risiko unsicherer Eigenentwicklungen besteht nicht, da keine interne Softwareentwicklung erfolgt. Risiken durch Software Dritter werden über Lieferantenmanagement, Sicherheitsanforderungen und die Auswahl von Herstellern mit gültigen Zertifizierungen gesteuert. Status: ausgeschlossen, mit Verweis auf Lieferantenmanagement und Zertifikate im Abschnitt A.8.22 dokumentiert.

Begründung für den Ausschluss:

Die Speicherung vertraulicher Daten auf mobilen Endgeräten ist untersagt. Zugriff auf Unternehmensinformationen erfolgt nur über zentrale virtuelle Sitzungen ohne lokale Speicherung. Endgeräte dienen lediglich als Anzeige und Eingabe, nicht als Datenträger.

Risikobewertung und technische Architektur:

Verlust oder Diebstahl eines mobilen Endgeräts führt nicht zu einem Datenabfluss, da keine Daten lokal gespeichert werden. Multi Faktor Authentifizierung und zentrale Sitzungsverwaltung schützen den Zugang. Status: ausgeschlossen, Risiko wird durch Architektur und Richtlinien eliminiert, dokumentiert im Abschnitt A.5.28 der Anwendbarkeitserklärung.

Ein Ausschluss von Controls ist nur zulässig, wenn das Risiko nachweislich nicht existiert oder an Dritte übertragen wurde und diese Verantwortung dokumentiert ist. Jede Nicht Anwendbarkeit gehört nachvollziehbar in die Anwendbarkeitserklärung mit Begründung, Nachweis und Zuständigkeit. Auditoren prüfen weniger die Anzahl ausgeschlossener Controls als die Logik der Begründung und deren Schlüssigkeit zur Risikobewertung.

Ein Ausschluss ist nur dann auditfest, wenn er risikobezogen, nachweisbar und konsistent mit den übrigen ISMS Dokumenten ist.

Ein Control darf nur dann als nicht anwendbar markiert werden, wenn das zugrunde liegende Risiko nachweislich nicht besteht oder durch andere Maßnahmen vollständig abgedeckt ist. Beispiel: Das Unternehmen entwickelt keine eigene Software, daher besteht kein Risiko unsicherer Eigenentwicklungen und das Control zur sicheren Entwicklung kann begründet ausgeschlossen werden.

Jeder Ausschluss benötigt eine kurze, aber nachvollziehbare Begründung mit Bezug zu Risiko, Verantwortlichem und Nachweis. Die Begründung sollte beantworten, warum das Control nicht relevant ist, welche Maßnahmen das Risiko kompensieren und in welchem Dokument dies festgehalten ist. Allgemeine Aussagen ohne Risikobezug reichen nicht aus.

In der Praxis bereitet der Informationssicherheitsbeauftragte die Ausschlüsse vor. Das Top Management entscheidet und gibt die Anwendbarkeitserklärung mit allen Ausschlüssen frei. Diese Freigabe sollte in Protokollen oder Managementbewertungen dokumentiert sein.

Verträge, Zertifikate von Dienstleistern, Richtlinien, Prozessbeschreibungen oder risikobezogene Analysen müssen belegen, dass die Verantwortung oder das Risiko anderweitig geregelt ist. Ohne belastbare Nachweise ist ein Ausschluss im Audit angreifbar.

Anwendbarkeitserklärung, Risikomatrix und Managementbewertung müssen inhaltlich zusammenpassen. Wenn ein Risiko in der Risikomatrix als hoch eingestuft ist, das entsprechende Control aber als nicht anwendbar gekennzeichnet wird, führt dies fast zwangsläufig zu kritischen Fragen oder Abweichungen.

ISO 27001 Statement of Applicability (SoA):

Die Anwendbarkeitserklärung (Statement of Applicability – SoA) ist eines der zentralen Kerndokumente der ISO/IEC 27001. Sie dokumentiert nachvollziehbar, welche Controls aus Anhang A angewendet oder begründet ausgeschlossen werden.

Die SoA stellt den direkten Bezug zwischen Risikoanalyse, Risikobehandlung und umgesetzten Maßnahmen her und bildet eine wesentliche Prüfgrundlage im Zertifizierungs- und Überwachungsaudit.

SMCT MANAGEMENT unterstützt bei der strukturieren Erstellung, der fachlich belastbaren Begründung sowie der auditfesten Pflege der SoA im laufenden Betrieb.

Ausschlüsse sind keine einmalige Entscheidung. Mindestens einmal jährlich sollten sie im Rahmen der Managementbewertung überprüft werden. Ändert sich der Kontext, zum Beispiel durch neue Technologien, Standorte oder Geschäftsmodelle, kann ein bisher ausgeschlossener Control plötzlich relevant werden.

Typische Fehler sind nicht anwendbar ohne Begründung, fehlende Freigabe durch das Management, Widersprüche zur Risikomatrix oder Nichtaktualisierung über mehrere Jahre. Solche Auffälligkeiten führen häufig zu Abweichungen im Audit.

Control: physische Zugangskontrolle für Rechenzentren. Begründung: Das Unternehmen betreibt kein eigenes Rechenzentrum, alle Systeme werden in einem zertifizierten Cloud Rechenzentrum betrieben. Nachweise sind Vertragsunterlagen, Sicherheitskonzepte und Zertifikate des Providers. Das Risiko physischen Zugriffs wird dort angemessen behandelt und im Anwendungsbereich entsprechend dokumentiert.

Jeder Ausschluss muss nachvollziehbar, dokumentiert und regelmäßig überprüft sein. Eine konsistente, risikobezogene Begründung im SoA verhindert Abweichungen im Audit und stärkt die Glaubwürdigkeit des Informationssicherheits Managementsystems.