Wie man die Controls aus Anhang A der ISO 27001 sauber begründet

Warum eine saubere Begründung entscheidend ist

Statement of Applicability als Herzstück des Informationssicherheits Managementsystems Die Anwendbarkeitserklärung zeigt, welche Maßnahmen aus Anhang A umgesetzt werden und vor allem warum. Jede Begründung ist ein Nachweis für die Wirksamkeit der Risikobehandlung und belegt, dass die Organisation Risiken strukturiert bewertet und passende Kontrollen ausgewählt hat. Auditoren prüfen weniger die Länge der Liste, sondern vor allem, ob Relevanz und Ausschlüsse nachvollziehbar begründet wurden.

Grundprinzipien einer nachvollziehbaren Begründung

Risiko- und Prozessbezug Jedes Control sollte sich auf mindestens ein identifiziertes Risiko und auf einen oder mehrere Prozesse beziehen. Typischer Ansatz: das Risiko wird in der Risikomatrix beschrieben, das Control ist als Maßnahme verknüpft und im SoA wird erklärt, in welchen Prozessen die Maßnahme wirkt zum Beispiel Asset Management, HR, IT Betrieb.

Rechts- und Vertragsbezug Kontrollen sollten zeigen, welchen gesetzlichen, regulatorischen oder vertraglichen Anforderungen sie dienen, etwa Datenschutzrecht, branchenspezifische Vorgaben oder Kundenanforderungen. So wird klar, dass die Auswahl nicht willkürlich, sondern aus Verpflichtungen abgeleitet ist.

Verantwortlichkeiten und Aktualität Für jedes Control sollte ein Verantwortlicher benannt sein. Begründungen werden idealerweise im Rahmen der Managementbewertung überprüft und bei geänderten Risiken oder neuen Anforderungen angepasst. Veraltete Begründungen führen schnell zu kritischen Fragen im Audit.

Nachweisführung als fester Bestandteil Eine Begründung ist erst vollständig, wenn sie durch konkrete Nachweise gestützt wird. Typische Nachweise sind Richtlinien, Verfahren, Protokolle, Auditberichte oder Konfigurationsdokumente. Merksatz: kein Control ohne Risiko, keine Begründung ohne Nachweis.

Aufbau einer guten Control Begründung

Beispiel A.8.1 Verantwortlichkeiten für Informationssicherheit Risiko: Unklare Zuständigkeiten führen zu Verzögerungen bei Sicherheitsvorfällen und zu uneinheitlichen Entscheidungen. Begründung: Verantwortlichkeiten und Rollen sind im Handbuch für Informationssicherheit definiert. Informationssicherheitsbeauftragter und Stellvertretung sind offiziell bestellt, schriftlich dokumentiert und durch Schulungen in ihre Aufgaben eingeführt. Nachweise: ISMS Handbuch, Organigramm, Bestellschreiben, Schulungsprotokolle. Status: umgesetzt, jährliche Überprüfung im Rahmen der Managementbewertung.

Beispiel A.5.18 Zugriffsrechte und Identitätsmanagement Risiko: Unautorisierte Zugriffe auf Systeme durch ungeprüfte oder veraltete Berechtigungen. Begründung: Zugriffsrechte werden zentral über Rollen und Gruppen im Verzeichnisdienst gesteuert. Beantragung, Änderung und Entzug erfolgen ausschließlich auf Basis von Tickets mit Vier Augen Freigabe. Regelmäßige Rezertifizierungen der Berechtigungen sind verbindlich vorgesehen. Nachweise: Berechtigungskonzept, Workflows im Ticket System, Protokolle der Zugriffsrezertifizierung, Auditberichte aus Berechtigungsreviews. Status: umgesetzt, jährlicher Review geplant.

Häufige Fehler bei der Begründung von Controls

Keine Verbindung zu Risiken und zur eigenen Organisation Häufig werden Begründungen aus Vorlagen übernommen, ohne Bezug zu den tatsächlich identifizierten Risiken. Kontrollen werden pauschal als „nicht anwendbar“ markiert, obwohl Risiken eindeutig vorhanden sind. Auch fehlende Verantwortliche oder fehlende Nachweise führen oft zu kritischen Feststellungen im Audit.

Unklare oder zukunftsgerichtete Formulierungen Formulierungen wie „wird umgesetzt“ oder „ist geplant“ sind für den Auditor eher Hinweis auf ein offenes Thema als auf eine wirksame Maßnahme. Stattdessen sollte klar beschrieben werden, was bereits eingeführt ist und wie die Wirksamkeit überprüft wird. Offene Maßnahmen gehören in den Maßnahmenplan, nicht in die SoA Begründung als erledigt.

Praktische Hilfsmittel für eine saubere SoA

Zentrale Dokumentation in Wikis oder Tabellen Eine SoA kann in Wiki Systemen oder Tabellen geführt werden. Sinnvoll sind Spalten beziehungsweise Abschnitte für Risiko, Begründung, Nachweis, Status und Verantwortlichen. Verlinkungen zur Risikomatrix und zu Richtlinien erhöhen die Nachvollziehbarkeit.

Risikomatrix und RACI als Ergänzung Die Risikomatrix liefert die Grundlage für den Bezug jedes Controls zu konkreten Risiken. Eine RACI Matrix ergänzt Verantwortlichkeiten und erleichtert die Beantwortung von Auditorenfragen zu Rollen und Zuständigkeiten.

Verknüpfung mit Managementbewertung Wenn SoA, Risikomatrix und Managementbewertung nachvollziehbar zusammenwirken, entsteht ein geschlossener Nachweis für Planung, Umsetzung und Verbesserung. Anpassungen von Kontrollen und Begründungen sollten in der Managementbewertung sichtbar werden.

Fazit zur Begründung der Controls aus Anhang A

Eine gute Control Begründung ist kurz, konkret und risikobezogen. Sie beantwortet stets drei Fragen: warum relevant, wie umgesetzt und wo nachgewiesen. Wer diese Logik durchgängig dokumentiert, vermeidet Diskussionen im Audit und stärkt die Glaubwürdigkeit seines Informationssicherheits Managementsystems.

Ausschluss von Controls aus Anhang A der ISO 27001 schlüssig begründen

Grundsatz für die Nicht Anwendbarkeit von Controls

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.

Beispiel A.7.5 Physische Zugangskontrolle zu Rechenzentren

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.

Beispiel A.6.4 Entfernung oder Rückgabe von Assets beim Ausscheiden

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.

Beispiel A.8.22 Sichere Entwicklung

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.

Beispiel A.5.28 Verschlüsselung mobiler Geräte

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.

Fazit zum Ausschluss von Controls

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.

Wichtige Punkte beim Ausschluss von Controls nach ISO 27001

Grundsätze für die Nicht Anwendbarkeit von Controls

Zulässigkeit des Ausschlusses 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.

Begründung in der Anwendbarkeitserklärung 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.

Verantwortlichkeit für Ausschlüsse 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.

Nachweise zur Begründung 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.

Auditkonsistenz zwischen Dokumenten 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.

Regelmäßige Überprüfung der Ausschlüsse 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.

Häufige Auditfehler bei Ausschlüssen 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.

Beispielhafter Ausschluss eines Controls 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.

Fazit zur Nicht Anwendbarkeit 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.

FAQ zum Ausschluss von Controls nach ISO 27001

1 Wann darf ein Control in der Anwendbarkeitserklärung ausgeschlossen werden

Ein Control darf nur dann als nicht anwendbar eingestuft werden, wenn das zugrunde liegende Risiko nachweislich nicht vorhanden ist oder durch andere Maßnahmen vollständig abgedeckt wird. Ausschlüsse dürfen nicht aus Bequemlichkeit erfolgen, sondern müssen zur Risikomatrix und zur Architektur des Systems passen.

2 Was gehört in eine Begründung für einen Ausschluss im SoA

Eine Begründung sollte mindestens enthalten, warum das Control nicht relevant ist, auf welches Risiko Bezug genommen wird und wie dieses Risiko anderweitig behandelt wird. Zusätzlich sollte der zuständige Verantwortliche und ein Hinweis auf Nachweise wie Verträge, Richtlinien oder Zertifikate genannt werden.

3 Wer entscheidet über den Ausschluss von Controls

In der Regel bereitet der Informationssicherheitsbeauftragte die Vorschläge für Ausschlüsse vor. Die endgültige Entscheidung trifft das oberste Management, häufig im Rahmen der Managementbewertung. Diese Freigabe sollte dokumentiert werden, zum Beispiel im Protokoll der Managementbewertung.

4 Welche Nachweise verlangen Auditoren bei ausgeschlossenen Controls

Auditoren erwarten nachvollziehbare Nachweise, dass das Risiko nicht besteht oder durch andere Parteien wie einen Cloud Provider übernommen wurde. Das können Verträge, Zertifikate, Sicherheitskonzepte oder interne Richtlinien sein, aus denen Verantwortung und Schutzmaßnahmen eindeutig hervorgehen.

5 Müssen Ausschlüsse regelmäßig überprüft werden

Ja. Ausschlüsse sind keine einmaligen Entscheidungen. Sie sollten mindestens einmal jährlich, idealerweise im Zuge der Managementbewertung, überprüft werden. Verändert sich der Kontext, die Technologie oder die Geschäftsstrategie, kann ein bisher nicht anwendbares Control plötzlich relevant werden.

6 Welche typischen Fehler führen bei Ausschlüssen zu Abweichungen im Audit

Häufige Fehler sind zum Beispiel nicht anwendbar ohne Begründung, fehlende Freigabe durch das Management, Widersprüche zur Risikomatrix oder Ausschlüsse, die seit Jahren nicht aktualisiert wurden. Solche Fälle werden von Auditoren oft als Abweichung gewertet.

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