Wie man die Controls (Anhang A) der ISO 27001 sauber begründet
1️⃣ Warum eine saubere Begründung entscheidend ist
Die Anwendbarkeitserklärung (Statement of Applicability – SoA) ist das Herzstück des ISMS. Sie zeigt, welche Controls aus Anhang A der ISO 27001 umgesetzt werden – und vor allem warum. Jede Begründung ist ein Nachweis für die Wirksamkeit der Risikobehandlung (Kapitel 6.1.3).
Auditoren prüfen: „Warum ist ein Control relevant oder ausgeschlossen?“ – nicht, dass es einfach nur in einer Liste steht.
2️⃣ Grundprinzipien einer nachvollziehbaren SoA-Begründung
Risikobezug:
Jede Begründung muss sich auf mindestens ein identifiziertes Risiko beziehen (ISO 27005-Verweis).
Jede Begründung muss sich auf mindestens ein identifiziertes Risiko beziehen (ISO 27005-Verweis).
Prozessbezug:
Controls sind an Prozesse gekoppelt (z. B. Asset-Management, HR-Prozesse, IT-Betrieb).
Controls sind an Prozesse gekoppelt (z. B. Asset-Management, HR-Prozesse, IT-Betrieb).
Rechtsbezug:
Controls erfüllen gesetzliche, regulatorische oder vertragliche Anforderungen (z. B. DSGVO, TISAX).
Controls erfüllen gesetzliche, regulatorische oder vertragliche Anforderungen (z. B. DSGVO, TISAX).
Verantwortlichkeit:
Zu jedem Control gehört ein Verantwortlicher (Owner) und Nachweis der Umsetzung.
Zu jedem Control gehört ein Verantwortlicher (Owner) und Nachweis der Umsetzung.
Aktualität:
Begründungen werden jährlich im Rahmen der Managementbewertung überprüft.
Begründungen werden jährlich im Rahmen der Managementbewertung überprüft.
Nachweisführung:
Jede Begründung wird durch ein oder mehrere Dokumente (Richtlinie, Verfahren, Protokoll) gestützt.
Jede Begründung wird durch ein oder mehrere Dokumente (Richtlinie, Verfahren, Protokoll) gestützt.
Merksatz: Kein Control ohne Risiko – keine Begründung ohne Nachweis.
3️⃣ Aufbau einer guten Control-Begründung
Empfohlene Struktur (ideal in Wiki.js oder SoA-Tabelle):
Control: A.8.1 – Verantwortlichkeiten für Informationssicherheit
Risiko: Unklare Zuständigkeiten führen zu Verzögerungen bei Sicherheitsvorfällen.
Begründung: Das Unternehmen hat Verantwortlichkeiten im ISMS-Handbuch definiert; Informationssicherheitsbeauftragter und Stellvertreter sind benannt, dokumentiert und geschult.
Nachweise: ISMS-Handbuch / Organigramm / Bestellurkunden / Protokolle der Schulungen.
Status: umgesetzt.
Risiko: Unklare Zuständigkeiten führen zu Verzögerungen bei Sicherheitsvorfällen.
Begründung: Das Unternehmen hat Verantwortlichkeiten im ISMS-Handbuch definiert; Informationssicherheitsbeauftragter und Stellvertreter sind benannt, dokumentiert und geschult.
Nachweise: ISMS-Handbuch / Organigramm / Bestellurkunden / Protokolle der Schulungen.
Status: umgesetzt.
Control: A.5.18 – Zugriffsrechte und Identitätsmanagement
Risiko: Unautorisierte Systemzugriffe durch unklare Berechtigungsprozesse.
Begründung: Zugriff wird zentral über AD-Gruppen gesteuert; Berechtigungsänderungen nur auf Ticketbasis nach Vier-Augen-Prinzip.
Nachweise: Berechtigungskonzept / Ticket-System-Protokolle / Auditbericht AD-Review.
Status: umgesetzt – jährlicher Review geplant.
Risiko: Unautorisierte Systemzugriffe durch unklare Berechtigungsprozesse.
Begründung: Zugriff wird zentral über AD-Gruppen gesteuert; Berechtigungsänderungen nur auf Ticketbasis nach Vier-Augen-Prinzip.
Nachweise: Berechtigungskonzept / Ticket-System-Protokolle / Auditbericht AD-Review.
Status: umgesetzt – jährlicher Review geplant.
4️⃣ Häufige Fehler bei der Control-Begründung
Copy-Paste aus Vorlagen ohne Bezug zum eigenen Risiko.
Begründungen enthalten keine Nachweise oder Verantwortlichkeiten.
Controls als „nicht anwendbar“ markiert, obwohl Risiko vorhanden ist.
Unklare Sprache („wird umgesetzt“) statt klarer Nachweis („ist umgesetzt“).
Audit-Erfahrung: 80 % der Major-Findings entstehen durch fehlerhafte oder unklare SoA-Begründungen.
5️⃣ Praktische Werkzeuge und Hilfsmittel
Wiki.js:
Zentrale Verwaltung der SoA, inkl. Versionierung und Dokumentverknüpfung.
Zentrale Verwaltung der SoA, inkl. Versionierung und Dokumentverknüpfung.
Risikomatrix (ISO 27005):
Verknüpft Risiken mit Controls → direkter Bezug für jede Begründung.
Verknüpft Risiken mit Controls → direkter Bezug für jede Begründung.
SoA-Vorlage (Excel / Online):
Spalten für Risiko, Begründung, Nachweis, Status, Verantwortlicher.
Spalten für Risiko, Begründung, Nachweis, Status, Verantwortlicher.
RACI-Matrix:
Ergänzt Verantwortlichkeiten für jedes Control – ideal für Auditorenfragen.
Ergänzt Verantwortlichkeiten für jedes Control – ideal für Auditorenfragen.
Praxis-Tipp: Verknüpfen Sie SoA, Risikomatrix und Managementbewertung – so entsteht ein geschlossener PDCA-Nachweis.
Fazit
Eine gute Control-Begründung ist kurz, konkret und risikobezogen. Sie beantwortet immer drei Fragen: Warum relevant? – Wie umgesetzt? – Wo nachgewiesen? Wer diese Logik durchgängig dokumentiert, hat im Audit keine Diskussionen, sondern Bestnoten.
SoA-Vorlage ISO 27001 anfordern →Beispiele für Begründungen von Controls (Anhang A ISO 27001)
1️⃣ Organisational Controls
Control A.5.23 – Schutz vor Schadsoftware
Risiko: Infektion durch externe E-Mails und Wechseldatenträger.
Begründung: Schadsoftware kann Betriebsunterbrechungen und Datenverluste verursachen. Der Einsatz zentral verwalteter Endpoint-Protection mit Echtzeit-Scanning, E-Mail-Sandboxing und regelmäßigen Updates ist erforderlich, um Schadcode rechtzeitig zu erkennen.
Nachweise: Antivirus-Berichte, Patch-Logs, Richtlinie Client-Schutz, Awareness-Training.
Status: umgesetzt.
Risiko: Infektion durch externe E-Mails und Wechseldatenträger.
Begründung: Schadsoftware kann Betriebsunterbrechungen und Datenverluste verursachen. Der Einsatz zentral verwalteter Endpoint-Protection mit Echtzeit-Scanning, E-Mail-Sandboxing und regelmäßigen Updates ist erforderlich, um Schadcode rechtzeitig zu erkennen.
Nachweise: Antivirus-Berichte, Patch-Logs, Richtlinie Client-Schutz, Awareness-Training.
Status: umgesetzt.
Control A.5.30 – Datensicherung
Risiko: Datenverlust bei Systemausfall oder Ransomware-Angriff.
Begründung: Die Verfügbarkeit kritischer Daten muss jederzeit gewährleistet sein. Tägliche Backups, monatliche Restore-Tests und eine Off-Site-Kopie auf immutable Storage sind eingerichtet.
Nachweise: Backup-Protokolle, Restore-Testberichte, BCM-Plan.
Status: umgesetzt – Review Q3/2025.
Risiko: Datenverlust bei Systemausfall oder Ransomware-Angriff.
Begründung: Die Verfügbarkeit kritischer Daten muss jederzeit gewährleistet sein. Tägliche Backups, monatliche Restore-Tests und eine Off-Site-Kopie auf immutable Storage sind eingerichtet.
Nachweise: Backup-Protokolle, Restore-Testberichte, BCM-Plan.
Status: umgesetzt – Review Q3/2025.
2️⃣ People Controls
Control A.6.3 – Awareness, Schulung und Training
Risiko: Mitarbeitende erkennen Phishing-Mails nicht und gefährden vertrauliche Daten.
Begründung: Regelmäßige Awareness-Schulungen sensibilisieren Beschäftigte für Informationssicherheit, Social Engineering und Datenschutz. Teilnahme ist verpflichtend und dokumentiert.
Nachweise: Schulungsnachweise, E-Learning-Berichte, Phishing-Simulations-Ergebnisse.
Status: umgesetzt – jährliche Wiederholung.
Risiko: Mitarbeitende erkennen Phishing-Mails nicht und gefährden vertrauliche Daten.
Begründung: Regelmäßige Awareness-Schulungen sensibilisieren Beschäftigte für Informationssicherheit, Social Engineering und Datenschutz. Teilnahme ist verpflichtend und dokumentiert.
Nachweise: Schulungsnachweise, E-Learning-Berichte, Phishing-Simulations-Ergebnisse.
Status: umgesetzt – jährliche Wiederholung.
Control A.6.2 – Informationssicherheitsrollen und Verantwortlichkeiten
Risiko: Unklare Zuständigkeiten führen zu verspäteter Reaktion bei Sicherheitsvorfällen.
Begründung: ISMS-Rollen (ISB, Datenschutz, BCM) sind definiert, im Organigramm dokumentiert und durch Bestellungsschreiben benannt. Vertretungsregelungen bestehen.
Nachweise: ISMS-Handbuch, Bestellurkunden, Managementbewertung.
Status: umgesetzt.
Risiko: Unklare Zuständigkeiten führen zu verspäteter Reaktion bei Sicherheitsvorfällen.
Begründung: ISMS-Rollen (ISB, Datenschutz, BCM) sind definiert, im Organigramm dokumentiert und durch Bestellungsschreiben benannt. Vertretungsregelungen bestehen.
Nachweise: ISMS-Handbuch, Bestellurkunden, Managementbewertung.
Status: umgesetzt.
3️⃣ Physical Controls
Control A.7.1 – Physische Sicherheit pro Standort
Risiko: Unbefugter Zutritt zu Server- oder Büroräumen.
Begründung: Zutritt ist nur für autorisierte Personen über elektronische Zutrittskontrolle mit Protokollierung erlaubt. Besucher müssen sich anmelden und werden begleitet.
Nachweise: Zutrittsprotokolle, Sicherheitsrichtlinie, Wartungsvertrag Zutrittssystem.
Status: umgesetzt.
Risiko: Unbefugter Zutritt zu Server- oder Büroräumen.
Begründung: Zutritt ist nur für autorisierte Personen über elektronische Zutrittskontrolle mit Protokollierung erlaubt. Besucher müssen sich anmelden und werden begleitet.
Nachweise: Zutrittsprotokolle, Sicherheitsrichtlinie, Wartungsvertrag Zutrittssystem.
Status: umgesetzt.
Control A.7.4 – Schutz vor Umweltbedrohungen
Risiko: Ausfall der Serveranlage durch Überhitzung oder Wasserschaden.
Begründung: Serverräume verfügen über Temperatur-Monitoring, Brandfrüherkennung, Klimatisierung und Wassersensoren. Wartungsverträge sichern die Funktionsfähigkeit.
Nachweise: Wartungsprotokolle, Fotos, Monitoring-Reports.
Status: umgesetzt.
Risiko: Ausfall der Serveranlage durch Überhitzung oder Wasserschaden.
Begründung: Serverräume verfügen über Temperatur-Monitoring, Brandfrüherkennung, Klimatisierung und Wassersensoren. Wartungsverträge sichern die Funktionsfähigkeit.
Nachweise: Wartungsprotokolle, Fotos, Monitoring-Reports.
Status: umgesetzt.
4️⃣ Technological Controls
Control A.8.16 – Monitoring der Systemaktivitäten
Risiko: Sicherheitsvorfälle werden zu spät erkannt.
Begründung: Alle sicherheitsrelevanten Systeme (Firewall, AD, Mail-Gateway) senden Logdaten an ein SIEM-System mit automatischer Alarmierung. Tägliche Auswertung durch IT-Security.
Nachweise: SIEM-Reports, Incident-Logs, Eskalations-Matrix.
Status: umgesetzt.
Risiko: Sicherheitsvorfälle werden zu spät erkannt.
Begründung: Alle sicherheitsrelevanten Systeme (Firewall, AD, Mail-Gateway) senden Logdaten an ein SIEM-System mit automatischer Alarmierung. Tägliche Auswertung durch IT-Security.
Nachweise: SIEM-Reports, Incident-Logs, Eskalations-Matrix.
Status: umgesetzt.
Control A.8.9 – Konfigurationsmanagement
Risiko: Fehlkonfigurationen führen zu Sicherheitslücken.
Begründung: Konfigurationen werden versioniert, Änderungen durchlaufen ein Vier-Augen-Review im Change-Prozess. Standard-Baselines sind dokumentiert und freigegeben.
Nachweise: Change-Protokolle, Konfigurations-Repository, Freigabe-Logs.
Status: umgesetzt.
Risiko: Fehlkonfigurationen führen zu Sicherheitslücken.
Begründung: Konfigurationen werden versioniert, Änderungen durchlaufen ein Vier-Augen-Review im Change-Prozess. Standard-Baselines sind dokumentiert und freigegeben.
Nachweise: Change-Protokolle, Konfigurations-Repository, Freigabe-Logs.
Status: umgesetzt.
Fazit
Jede Begründung muss nachvollziehbar zeigen, welches Risiko adressiert wird, wie die Umsetzung erfolgt und welche Nachweise existieren. Nur so bleibt die Anwendbarkeitserklärung (SoA) auditfest und lebendig – statt einer reinen Pflichtliste.
SoA-Beispielvorlage anfordern →Praxisbeispiele – Von der Begründung bis zum Abschluss-Control
Control A.5.15 – Zugriff auf Informationssysteme
Risiko: Unautorisierte Zugriffe durch ehemalige Mitarbeitende oder externe Dienstleister.
Begründung: Nachweisbare Kontrolle von Zugriffsrechten schützt vertrauliche Informationen und minimiert Missbrauchsrisiken. Jede Benutzeranmeldung erfordert eine Authentifizierung über zentrale Directory-Dienste.
Umsetzung: Joiner-Mover-Leaver-Prozess über Ticketsystem, Vier-Augen-Freigabe, wöchentlicher Export aus AD für Berechtigungsprüfung.
Nachweise: Ticket-Protokolle, AD-Review-Report, Zugriffsrichtlinie, Auditbericht Berechtigungsprüfung.
Begründung: Nachweisbare Kontrolle von Zugriffsrechten schützt vertrauliche Informationen und minimiert Missbrauchsrisiken. Jede Benutzeranmeldung erfordert eine Authentifizierung über zentrale Directory-Dienste.
Umsetzung: Joiner-Mover-Leaver-Prozess über Ticketsystem, Vier-Augen-Freigabe, wöchentlicher Export aus AD für Berechtigungsprüfung.
Nachweise: Ticket-Protokolle, AD-Review-Report, Zugriffsrichtlinie, Auditbericht Berechtigungsprüfung.
Abschluss-Control:
Das Control wurde am 15.03.2025 überprüft. Keine Abweichungen.
Verbesserungsvorschlag: Automatisierte Rezertifizierung per IAM-System bis Q4/2025.
Status: umgesetzt – jährliche Überprüfung Q1
Control A.5.23 – Schutz vor Schadsoftware
Risiko: Malware-Infektion über externe E-Mail-Anhänge.
Begründung: Schadsoftware kann Betriebsunterbrechungen, Datenverlust oder Reputationsschäden verursachen. Technische und organisatorische Schutzmaßnahmen minimieren die Eintrittswahrscheinlichkeit.
Umsetzung: E-Mail-Gateway mit Sandboxing, zentral verwaltete Endpoint-Security (ESET), automatische Signatur-Updates, monatliche Awareness-Kampagne zu Phishing-Erkennung.
Nachweise: Antivirus-Berichte, Awareness-Berichte, IT-Sicherheitsrichtlinie, Audit-Report „Malware Protection“.
Begründung: Schadsoftware kann Betriebsunterbrechungen, Datenverlust oder Reputationsschäden verursachen. Technische und organisatorische Schutzmaßnahmen minimieren die Eintrittswahrscheinlichkeit.
Umsetzung: E-Mail-Gateway mit Sandboxing, zentral verwaltete Endpoint-Security (ESET), automatische Signatur-Updates, monatliche Awareness-Kampagne zu Phishing-Erkennung.
Nachweise: Antivirus-Berichte, Awareness-Berichte, IT-Sicherheitsrichtlinie, Audit-Report „Malware Protection“.
Abschluss-Control:
Im Audit 03/2025 wurde Wirksamkeit bestätigt. Keine sicherheitsrelevanten Vorfälle im Zeitraum 2024.
Awareness-Teilnahmequote 96 %. Control gilt als wirksam – Überprüfung halbjährlich.
Status: umgesetzt
Control A.7.4 – Schutz vor Umweltbedrohungen
Risiko: Ausfall der Serverräume durch Hitze oder Wassereintritt.
Begründung: Physische Sicherheitsvorkehrungen gewährleisten Verfügbarkeit der Systeme und schützen Infrastruktur vor Umwelteinflüssen. Der Standort liegt in einer Starkregen-Zone, daher sind präventive Maßnahmen notwendig.
Umsetzung: Temperatur-Monitoring, Brandfrüherkennung, Klimaanlage mit Alarmierung, Sensorik für Feuchtigkeit. Ergebnisse fließen in monatliches Facility-Reporting ein.
Nachweise: Wartungsverträge, Fotos der Sensorik, Monitoring-Reports, BCM-Dokumentation.
Begründung: Physische Sicherheitsvorkehrungen gewährleisten Verfügbarkeit der Systeme und schützen Infrastruktur vor Umwelteinflüssen. Der Standort liegt in einer Starkregen-Zone, daher sind präventive Maßnahmen notwendig.
Umsetzung: Temperatur-Monitoring, Brandfrüherkennung, Klimaanlage mit Alarmierung, Sensorik für Feuchtigkeit. Ergebnisse fließen in monatliches Facility-Reporting ein.
Nachweise: Wartungsverträge, Fotos der Sensorik, Monitoring-Reports, BCM-Dokumentation.
Abschluss-Control:
Inspektion durch Facility-Manager 02/2025 abgeschlossen.
Klimatisierung arbeitet im Soll-Bereich. Ergänzende Maßnahme: Installation zusätzlicher Temperaturfühler geplant Q3/2025.
Status: umgesetzt – Verbesserung in Planung
Control A.8.16 – Überwachung von Systemaktivitäten
Risiko: Sicherheitsvorfälle werden zu spät erkannt oder nicht eskaliert.
Begründung: Durch zentralisiertes Monitoring über ein SIEM-System können sicherheitsrelevante Ereignisse automatisiert erkannt, analysiert und gemeldet werden.
Umsetzung: Firewall-, AD-, VPN- und E-Mail-Logs werden zentral gesammelt. Korrelation und Alarmierung über SIEM (Elastic Stack). Tägliche Sichtung durch IT-Security-Team.
Nachweise: SIEM-Reports, Incident-Protokolle, Eskalationsmatrix, Auditnachweis Log-Management.
Begründung: Durch zentralisiertes Monitoring über ein SIEM-System können sicherheitsrelevante Ereignisse automatisiert erkannt, analysiert und gemeldet werden.
Umsetzung: Firewall-, AD-, VPN- und E-Mail-Logs werden zentral gesammelt. Korrelation und Alarmierung über SIEM (Elastic Stack). Tägliche Sichtung durch IT-Security-Team.
Nachweise: SIEM-Reports, Incident-Protokolle, Eskalationsmatrix, Auditnachweis Log-Management.
Abschluss-Control:
Review 01/2025: Automatische Alarmierungen funktionieren, 2 Sicherheitsereignisse korrekt erkannt und eskaliert.
Maßnahme: Erweiterung um Cloud-Logdaten geplant bis Jahresende.
Status: umgesetzt – laufende Optimierung
Fazit
Jedes Control schließt mit einem Abschluss-Review, das Wirksamkeit und Verbesserungspotenziale dokumentiert. So entsteht eine nachvollziehbare PDCA-Verknüpfung (Plan–Do–Check–Act) zwischen Risikoanalyse, Umsetzung und Audit. Diese Vorgehensweise erfüllt die Kernforderung der ISO 27001:2022 nach einem „lebenden ISMS“.
Vollständiges Beispiel-Set anfordern →Ausschluss von Controls (Nicht-Anwendbarkeit) – So wird’s richtig begründet
Nicht jedes Control aus Anhang A ist für jede Organisation relevant. Entscheidend ist, dass der **Ausschluss nachvollziehbar** ist und keine **verbleibenden Risiken** bestehen. Eine saubere Begründung schützt vor Major-Abweichungen im Audit.
Regel: Ein Control darf nur ausgeschlossen werden, wenn das zugrundeliegende Risiko nachweislich nicht existiert oder durch andere Maßnahmen abgedeckt ist.
Beispiel 1 – A.7.5 Physische Zugangskontrolle zu Rechenzentren
Begründung (Ausschluss):
Das Unternehmen betreibt keine eigenen Serverräume oder Rechenzentren. Sämtliche Systeme werden in der Cloud (Microsoft Azure, Frankfurt Region) gehostet. Die physische Sicherheit liegt in der Verantwortung des Cloud-Anbieters.
Das Unternehmen betreibt keine eigenen Serverräume oder Rechenzentren. Sämtliche Systeme werden in der Cloud (Microsoft Azure, Frankfurt Region) gehostet. Die physische Sicherheit liegt in der Verantwortung des Cloud-Anbieters.
Risikobewertung:
Risiken aus physischem Zugriff sind an den Cloud-Provider übertragen. Verträge und Auditberichte (SOC 2 / ISO 27001 des Providers) belegen Angemessenheit der Schutzmaßnahmen.
Risiken aus physischem Zugriff sind an den Cloud-Provider übertragen. Verträge und Auditberichte (SOC 2 / ISO 27001 des Providers) belegen Angemessenheit der Schutzmaßnahmen.
Auditorischer Hinweis:
Kontrolle gilt als „nicht anwendbar“, da die Verantwortung extern nachweislich geregelt ist (ISO 27001 Kap. A.7.5).
Nachweis: Vertrag & Sicherheitszertifikat des Cloud-Providers.
Status: ausgeschlossen – dokumentiert im SoA-Kapitel A.7.5
Beispiel 2 – A.6.4 Entfernung oder Rückgabe von Assets beim Ausscheiden
Begründung (Ausschluss):
Das Unternehmen besitzt keine eigenen Hardware-Assets (BYOD-Policy). Mitarbeitende nutzen ausschließlich private Geräte mit Zugriff über gesicherte virtuelle Arbeitsumgebungen (VDI). Es erfolgt daher keine physische Rückgabe von Unternehmensgeräten.
Das Unternehmen besitzt keine eigenen Hardware-Assets (BYOD-Policy). Mitarbeitende nutzen ausschließlich private Geräte mit Zugriff über gesicherte virtuelle Arbeitsumgebungen (VDI). Es erfolgt daher keine physische Rückgabe von Unternehmensgeräten.
Risikobewertung:
Risiko „Verlust physischer IT-Assets“ entfällt, da keine Unternehmenshardware vorhanden ist. Zugriffskontrolle und Account-Deaktivierung regeln die sichere Trennung.
Risiko „Verlust physischer IT-Assets“ entfällt, da keine Unternehmenshardware vorhanden ist. Zugriffskontrolle und Account-Deaktivierung regeln die sichere Trennung.
Alternative Controls:
A.5.15 „Zugriffskontrolle“ und A.8.16 „Überwachung von Systemaktivitäten“ decken das Risiko technisch ab.
Status: ausgeschlossen – Risiko entfällt
Beispiel 3 – A.8.22 Sichere Entwicklung
Begründung (Ausschluss):
Das Unternehmen entwickelt keine eigenen Software-Anwendungen. Alle eingesetzten Systeme sind Standardprodukte, die von externen Herstellern bereitgestellt und gewartet werden.
Das Unternehmen entwickelt keine eigenen Software-Anwendungen. Alle eingesetzten Systeme sind Standardprodukte, die von externen Herstellern bereitgestellt und gewartet werden.
Risikobewertung:
Risiko „unsichere Eigenentwicklung“ besteht nicht. Die Beschaffung erfolgt ausschließlich von ISO-zertifizierten Software-Anbietern mit regelmäßigen Sicherheits-Updates.
Risiko „unsichere Eigenentwicklung“ besteht nicht. Die Beschaffung erfolgt ausschließlich von ISO-zertifizierten Software-Anbietern mit regelmäßigen Sicherheits-Updates.
Auditorische Bewertung:
Ausschluss zulässig – Risiko nachweislich nicht vorhanden.
Hinweis: Prüfung auf Lieferantenmanagement (A.5.19) zur Kontrolle der externen Softwarelieferanten.
Status: ausgeschlossen – Nachweis durch Lieferantenzertifikat
Beispiel 4 – A.5.28 Verschlüsselung mobiler Geräte
Begründung (Ausschluss):
Das Unternehmen erlaubt keine Speicherung vertraulicher Daten auf mobilen Endgeräten. Zugriff auf Unternehmensinformationen erfolgt ausschließlich über gesicherte Citrix-Sessions (keine lokale Speicherung).
Das Unternehmen erlaubt keine Speicherung vertraulicher Daten auf mobilen Endgeräten. Zugriff auf Unternehmensinformationen erfolgt ausschließlich über gesicherte Citrix-Sessions (keine lokale Speicherung).
Risikobewertung:
Verlust oder Diebstahl eines Endgeräts führt zu keinem Datenabfluss. Multi-Faktor-Authentifizierung schützt den Zugang.
Verlust oder Diebstahl eines Endgeräts führt zu keinem Datenabfluss. Multi-Faktor-Authentifizierung schützt den Zugang.
Auditkommentar:
Ausschluss zulässig, da Datenhaltung ausschließlich zentral erfolgt.
Überprüfung: Policy „Mobile Device Security“ und Logging der VDI-Zugriffe.
Status: ausgeschlossen – Risiko ausgeschlossen durch Architektur
Fazit
Ein Ausschluss von Controls ist nur zulässig, wenn das Risiko nicht existiert oder an Dritte übertragen wurde und diese Verantwortung nachweislich dokumentiert ist. Jede Nicht-Anwendbarkeit muss im SoA mit Begründung, Nachweis und Verantwortlichkeit erfasst werden.
Audit-Tipp: Auditoren prüfen nicht den Ausschluss an sich, sondern die Logik der Begründung und die Schlüssigkeit zur Risikomatrix.
Beispiel-Vorlage für SoA-Ausschlüsse anfordern →Wichtige Punkte beim Ausschluss von Controls nach ISO 27001
1️⃣ Zulässigkeit des Ausschlusses
Ein Control darf nur ausgeschlossen werden, wenn das zugrunde liegende Risiko nicht besteht oder durch andere Maßnahmen vollständig abgedeckt ist. Beispiel: keine Eigenentwicklung → A.8.22 nicht anwendbar.
Ein Control darf nur ausgeschlossen werden, wenn das zugrunde liegende Risiko nicht besteht oder durch andere Maßnahmen vollständig abgedeckt ist. Beispiel: keine Eigenentwicklung → A.8.22 nicht anwendbar.
2️⃣ Begründung im SoA
Jeder Ausschluss benötigt eine nachvollziehbare Begründung mit Bezug zu Risiko, Verantwortlichem und Nachweis. Kurz und präzise: Warum nicht relevant – wie kompensiert – wo dokumentiert.
Jeder Ausschluss benötigt eine nachvollziehbare Begründung mit Bezug zu Risiko, Verantwortlichem und Nachweis. Kurz und präzise: Warum nicht relevant – wie kompensiert – wo dokumentiert.
3️⃣ Verantwortlichkeit
Ausschlüsse werden durch den ISB vorbereitet und vom Top-Management freigegeben. Dokumentation erfolgt im Rahmen der Managementbewertung.
Ausschlüsse werden durch den ISB vorbereitet und vom Top-Management freigegeben. Dokumentation erfolgt im Rahmen der Managementbewertung.
4️⃣ Nachweise
Verträge, Zertifikate oder Richtlinien müssen belegen, dass die Verantwortung oder das Risiko anderweitig geregelt ist. Ohne Nachweis kein gültiger Ausschluss.
Verträge, Zertifikate oder Richtlinien müssen belegen, dass die Verantwortung oder das Risiko anderweitig geregelt ist. Ohne Nachweis kein gültiger Ausschluss.
5️⃣ Auditkonsistenz
SoA, Risikomatrix und Managementbewertung müssen inhaltlich übereinstimmen. Auditoren prüfen die logische Verbindung zwischen Risiko, Begründung und Entscheidung.
SoA, Risikomatrix und Managementbewertung müssen inhaltlich übereinstimmen. Auditoren prüfen die logische Verbindung zwischen Risiko, Begründung und Entscheidung.
6️⃣ Regelmäßiger Review
Ausschlüsse sind mindestens einmal jährlich zu prüfen. Ändert sich der Kontext, kann ein bisher ausgeschlossener Control wieder relevant werden.
Ausschlüsse sind mindestens einmal jährlich zu prüfen. Ändert sich der Kontext, kann ein bisher ausgeschlossener Control wieder relevant werden.
7️⃣ Häufige Auditfehler
– „Nicht anwendbar“ ohne Begründung
– Keine Freigabe durch Management
– Widerspruch zur Risikomatrix
– Keine Aktualisierung seit Jahren
– „Nicht anwendbar“ ohne Begründung
– Keine Freigabe durch Management
– Widerspruch zur Risikomatrix
– Keine Aktualisierung seit Jahren
8️⃣ Beispielhafter Ausschluss
Control: A.7.5 – Physische Zugangskontrolle
Begründung: Kein eigenes Rechenzentrum, Hosting bei zertifiziertem Provider.
Nachweis: SOC 2 / ISO 27001-Zertifikat des Cloud-Providers.
Control: A.7.5 – Physische Zugangskontrolle
Begründung: Kein eigenes Rechenzentrum, Hosting bei zertifiziertem Provider.
Nachweis: SOC 2 / ISO 27001-Zertifikat des Cloud-Providers.
Fazit: Jeder Ausschluss muss nachvollziehbar, dokumentiert und überprüft sein.
Eine gute Begründung im SoA verhindert Abweichungen und stärkt die Auditfähigkeit.
FAQ – Ausschluss von Controls nach ISO 27001
❓ Wann darf ein Control ausgeschlossen werden?
Ein Control darf ausgeschlossen werden, wenn das zugrundeliegende Risiko nachweislich nicht besteht oder durch andere Maßnahmen bereits angemessen abgedeckt ist. Beispiel: Kein eigener Serverraum → A.7.5 (Physische Sicherheit Rechenzentrum) ist nicht anwendbar.
Wichtig: Jeder Ausschluss muss begründet und im SoA dokumentiert sein – „nicht anwendbar“ allein genügt nicht.
📋 Wie muss die Begründung im SoA aussehen?
Eine gute Begründung besteht aus drei Teilen:
- 1. Warum das Control nicht relevant ist
- 2. Wie das Risiko alternativ behandelt wird (oder entfällt)
- 3. Welche Nachweise diese Entscheidung stützen
Beispiel: „A.8.22 – Sichere Entwicklung: ausgeschlossen, da keine Eigenentwicklung; Risiko entfällt; Nachweis: Lieferantenzertifikate.“
🧭 Wer entscheidet über den Ausschluss?
Ausschlüsse werden durch den Informationssicherheitsbeauftragten (ISB) vorbereitet und müssen vom Top-Management im Rahmen der Managementbewertung genehmigt werden.
Audit-Bezug: ISO 27001 Kap. 5 (Führung) und 9.3 (Managementbewertung).
🔍 Wie oft müssen Ausschlüsse überprüft werden?
Ausschlüsse sind jährlich zu prüfen, mindestens im Zuge der Managementbewertung. Wenn sich der Kontext oder die Risiken ändern (z. B. neue IT-Systeme, Cloud-Migration), kann ein bisher ausgeschlossenes Control wieder relevant werden.
Praxis-Tipp: Führen Sie eine Spalte „Review-Datum“ in Ihrer SoA, um die jährliche Bewertung zu dokumentieren.
⚠️ Welche Fehler führen zu Abweichungen im Audit?
- „Nicht anwendbar“ ohne nachvollziehbare Begründung
- Ausschluss, obwohl Risiko in der Matrix vorhanden ist
- Keine Genehmigung durch Management / keine Nachweise
- Ausschlüsse werden nicht regelmäßig überprüft
Auditoren achten besonders: auf Konsistenz zwischen SoA, Risikomatrix und Managementbewertung.
📂 Wie werden Ausschlüsse dokumentiert?
In der Spalte „Begründung / Kommentar“ der SoA-Tabelle: – Grund des Ausschlusses – ggf. alternative Maßnahmen – Nachweis (z. B. Vertrag, Zertifikat, Richtlinie) – Verantwortlicher
Praxis: Verknüpfen Sie die SoA mit Ihrer Risikomatrix im Wiki.js oder ISMS-Tool, um Ausschlüsse transparent nachzuhalten.
💡 Fazit
Ausschlüsse sind zulässig – aber nur, wenn sie begründet, dokumentiert und überprüft werden. Eine saubere Begründung schützt vor Auditabweichungen und zeigt, dass Ihr ISMS risikobasiert geführt wird.
Fragen zu Ausschlüssen stellen →