Statement of Applicability: Vorlage und Muster

Die Erklärung zur Anwendbarkeit – im Auditalltag fast immer SoA genannt, nach Statement of Applicability – ist das einzige Dokument, das ein Auditor vor der Zertifizierung garantiert liest. Sie ist die Brücke zwischen deiner Risikobewertung und den 93 Maßnahmen aus Anhang A: Für jede einzelne musst du sagen, ob sie bei euch gilt, warum, und wo das nachzulesen ist. Auf dieser Seite findest du die vollständige Spaltenstruktur, 14 fertige Begründungssätze zum Übernehmen und die Ausschlüsse, die im Audit durchgehen – und die, die es nicht tun.

Das Wichtigste in Kürze

• Die SoA ist nach ISO/IEC 27001, Klausel 6.1.3 d) ein Pflichtdokument. Ohne sie gibt es kein Zertifikat – sie ist nicht optional und nicht ersetzbar.
• Sie listet alle 93 Controls aus Anhang A der Fassung 2022 auf, nicht nur die umgesetzten. Auch ein Ausschluss muss dort stehen, mit Begründung.
• Anhang A ist seit 2022 in vier Themen gegliedert: 37 organisatorische, 8 personenbezogene, 14 physische und 34 technologische Maßnahmen.
• Eine belastbare SoA hat mindestens sieben Spalten. Der Kern sind zwei getrennte Angaben, die oft vermischt werden: anwendbar ja/nein und umgesetzt ja/teilweise/nein.
• Jede Zeile braucht eine Rückverbindung zur Risikobewertung oder zu einer gesetzlichen bzw. vertraglichen Anforderung. Eine Begründung wie „Best Practice“ ist der häufigste Auditbefund.
• Ausschlüsse sind zulässig, wenn die Voraussetzung im Unternehmen fehlt – etwa Control 8.28 zu sicherer Programmierung bei einer Organisation ohne eigene Entwicklung. Unzulässig ist ein Ausschluss, der nur Aufwand vermeidet.
• Stand August 2026: Es gibt keine neue Ausgabe der ISO/IEC 27001. Gültig ist die Fassung 2022 samt Amendment 1:2024 („Climate Action Changes“), das die Klauseln 4.1 und 4.2 um den Klimawandel ergänzt, aber kein Control hinzufügt. Die Übergangsfrist von der Fassung 2013 endete am 31. Oktober 2025.
• Die SoA ist ein lebendes Dokument: Sie wird versioniert, von der Leitung freigegeben und bei jeder Änderung der Risikolage nachgezogen – nicht einmal vor dem Audit geschrieben.

Was die Norm tatsächlich verlangt

Der Text der Norm ist an dieser Stelle knapp, und genau daraus entstehen die meisten Missverständnisse. Klausel 6.1.3 beschreibt die Risikobehandlung. Buchstabe c) verlangt den Abgleich der gewählten Maßnahmen mit Anhang A, um zu prüfen, ob etwas Notwendiges übersehen wurde. Buchstabe d) verlangt daraufhin die Erklärung zur Anwendbarkeit mit drei Bestandteilen: den erforderlichen Maßnahmen, der Begründung für ihre Einbeziehung, dem Umsetzungsstatus und der Begründung für den Ausschluss jeder nicht angewandten Maßnahme aus Anhang A.

Daraus folgen zwei Dinge, die in der Praxis regelmäßig falsch gemacht werden.

Erstens ist Anhang A kein Katalog, aus dem man sich bedient. Die Reihenfolge ist umgekehrt: Zuerst entstehen aus der Risikobewertung die notwendigen Maßnahmen, danach dient Anhang A als Gegenprobe. Wer mit der Anhang-A-Liste anfängt und sie abarbeitet, bekommt eine SoA, die formal vollständig ist und trotzdem nicht zu den eigenen Risiken passt. Auditoren erkennen das an einem einfachen Muster: Alle 93 Controls sind anwendbar, alle sind umgesetzt, und nirgends steht eine Risiko-ID.

Zweitens sind „anwendbar“ und „umgesetzt“ zwei verschiedene Fragen. Ein Control kann anwendbar und noch nicht umgesetzt sein – das ist kein Mangel, solange die Lücke im Risikobehandlungsplan mit Termin und Verantwortlichem steht. Wer beides in eine Spalte presst, verliert genau die Information, die im Überwachungsaudit interessant ist. Die Zertifizierung setzt kein zu 100 % umgesetztes Anhang A voraus; sie setzt voraus, dass du weißt, wo du stehst.

Die Maßnahmen selbst sind in ISO/IEC 27002:2022 ausführlich beschrieben; Anhang A der 27001 enthält nur die Kurzfassung. Für die Formulierung der Begründungen ist die 27002 die deutlich hilfreichere Quelle, weil sie zu jedem Control den Zweck nennt – und der Zweck ist das, was du in der Begründung aufgreifen solltest.

Die Spalten einer belastbaren SoA

Die Norm schreibt keine Tabellenform vor. Sie schreibt Inhalte vor, und eine Tabelle ist die praktikabelste Form dafür. Die folgende Struktur deckt die Normanforderung vollständig ab und hält gleichzeitig die Informationen bereit, nach denen im Audit gefragt wird.

Spalte	Inhalt	Pflicht?
1 · Nummer	Control-Nummer nach Anhang A, z. B. 5.15	faktisch ja
2 · Bezeichnung	Name der Maßnahme, z. B. „Zugangssteuerung“	faktisch ja
3 · Anwendbar	Ja / Nein – gilt die Maßnahme im Geltungsbereich?	ja
4 · Begründung	Warum einbezogen oder ausgeschlossen – mit Bezug auf Risiko, Gesetz, Vertrag oder fehlende Voraussetzung	ja
5 · Umsetzungsstatus	Umgesetzt / teilweise / geplant / nicht umgesetzt	ja
6 · Nachweis	Verweis auf Richtlinie, Verfahren, System oder Aufzeichnung	nein, aber entscheidend
7 · Verantwortlich	Rolle, nicht Person – z. B. „Leitung IT“	nein
8 · Risiko-ID	Verknüpfung zur Zeile im Risikoregister	nein, aber der stärkste Beleg

Zu Spalte 6 eine Warnung: Ein Nachweis ist ein konkreter Verweis, kein Themenwort. „Passwortrichtlinie, Version 2.1, Abschnitt 4″ ist ein Nachweis. „IT-Sicherheit“ ist keiner. Wenn du beim Ausfüllen merkst, dass du nur ein Themenwort hinschreiben kannst, fehlt in Wahrheit das Dokument – die SoA deckt das zuverlässig auf. Für die typischen Belege haben wir jeweils eine eigene Seite mit Mustertext: Passwortrichtlinie, Berechtigungskonzept und Datensicherungskonzept decken zusammen einen erheblichen Teil der technischen Controls ab.

Mustertext: Kopf der Erklärung zur Anwendbarkeit

Vor der Tabelle steht ein Kopfteil, der den Geltungsbereich und die Freigabe festhält. Er wird oft weggelassen – und dann fehlt im Audit der Beleg, dass die Leitung die Auswahl der Maßnahmen tatsächlich genehmigt hat, wie Klausel 6.1.3 f) es verlangt. Ersetze die Platzhalter in eckigen Klammern.

14 Begründungen, die im Audit tragen

Die Spalte „Begründung“ ist die Stelle, an der die meisten SoA-Dokumente auseinanderfallen. Typisch sind Einträge wie „Best Practice“, „Anforderung der Norm“ oder schlicht „ISO 27001″. Alle drei sind zirkulär: Sie begründen die Maßnahme mit der Norm, die die Begründung verlangt.

Eine tragfähige Begründung nennt eine von vier Quellen – Risiko, Gesetz, Vertrag oder Geschäftsanforderung – und zwar so konkret, dass man sie nachprüfen kann. Die folgenden Formulierungen kannst du übernehmen und die Platzhalter ersetzen.

Einbeziehung: Begründung aus einem Risiko

• „Behandelt Risiko R-[Nr.] (unbefugter Zugriff auf Kundendaten durch verwaiste Konten), Bruttobewertung hoch. Maßnahme reduziert die Eintrittswahrscheinlichkeit.“
• „Behandelt Risiko R-[Nr.] (Datenverlust durch Ransomware). Wirkt auf die Auswirkung, nicht auf die Eintrittswahrscheinlichkeit; ergänzt Maßnahme 8.7.“
• „Erforderlich zur Erkennung der in R-[Nr.] beschriebenen Angriffsmuster; ohne diese Maßnahme bleibt das Risiko unentdeckt und damit unbehandelbar.“
• „Trägt zur Behandlung mehrerer Risiken bei (R-[Nr.], R-[Nr.], R-[Nr.]) und ist deshalb als übergreifende Maßnahme eingestuft.“

Einbeziehung: Begründung aus Recht oder Vertrag

• „Gesetzliche Anforderung: Art. 32 DSGVO verlangt Maßnahmen zur Sicherstellung der Vertraulichkeit; die Maßnahme ist Teil der Umsetzung.“
• „Gesetzliche Anforderung: § 30 Absatz 2 Nummer [x] BSIG. Die Organisation ist als [wichtige Einrichtung] betroffen.“
• „Vertragliche Anforderung aus dem Rahmenvertrag mit [Kunde], Anlage [x], Ziffer [x]. Nachweispflicht besteht jährlich.“
• „Anforderung aus dem Auftragsverarbeitungsvertrag mit [Kunde] gemäß Art. 28 DSGVO; die Maßnahme ist dort als technische und organisatorische Maßnahme zugesagt.“

Ausschluss: tragfähige Begründungen

• „Nicht anwendbar: Die Organisation entwickelt keine Software. Es existieren weder Entwicklungsumgebungen noch eigener Quellcode im Geltungsbereich.“ (typisch für 8.25 bis 8.31)
• „Nicht anwendbar: Im Geltungsbereich werden keine personenbezogenen Daten für Test- oder Entwicklungszwecke verwendet, da keine Testumgebung mit Echtdaten betrieben wird.“ (8.11)
• „Nicht anwendbar: Die Organisation betreibt keine eigenen Rechenzentrumsflächen. Sämtliche Serversysteme werden bei [Anbieter] betrieben; die zugehörige Verantwortung ist in Control 5.23 abgebildet und über den Nachweis [Zertifikat, Bericht] belegt.“ (typisch für Teile von 7.x)
• „Nicht anwendbar: Es bestehen keine Entwicklungs- oder Auslagerungsverhältnisse für Software; sämtliche eingesetzte Anwendungen sind Standardprodukte ohne kundenspezifische Anpassung.“ (8.30)
• „Nicht anwendbar: Der Geltungsbereich umfasst keine Verarbeitung in Ländern außerhalb des EWR; ein Transfer findet nicht statt.“
• „Nicht anwendbar: Die Organisation beschäftigt keine Personen mit Zugang zu [X]; die Rolle existiert im Organigramm nicht.“

Das gemeinsame Muster: Ein tragfähiger Ausschluss beschreibt eine Tatsache über die Organisation, die überprüfbar ist. Ein untragfähiger Ausschluss beschreibt eine Entscheidung über den Aufwand.

Welche Ausschlüsse im Audit scheitern

Formulierung im Entwurf	Warum sie scheitert	Was stattdessen geht
„Zu aufwendig für unsere Größe“	Beschreibt eine Aufwandsentscheidung, keine fehlende Voraussetzung	Maßnahme aufnehmen, verhältnismäßig umsetzen und den Umfang in der Begründung beschreiben
„Wird durch unseren Dienstleister abgedeckt“	Verantwortung lässt sich auslagern, Rechenschaft nicht	Anwendbar setzen, Umsetzung über den Dienstleister beschreiben und den Nachweis benennen
„Für uns nicht relevant“	Behauptung ohne prüfbaren Grund	Den konkreten Grund nennen: welche Voraussetzung fehlt
„Noch nicht umgesetzt“	Verwechselt Anwendbarkeit mit Umsetzungsstand	Anwendbar: ja, Status: geplant, mit Termin im Risikobehandlungsplan
„Kein Risiko erkannt“	Meist ein Beleg dafür, dass die Risikobewertung unvollständig ist	Risikobewertung nachziehen, dann neu entscheiden

Der zweite Fall ist der interessanteste, weil er so plausibel klingt. Wer seine gesamte Infrastruktur bei einem Hyperscaler betreibt, hat für viele physische Controls tatsächlich keine eigene Umsetzung. Der Ausschluss ist trotzdem falsch: Die Maßnahme ist anwendbar, sie wird nur von jemand anderem erbracht. Richtig ist deshalb „anwendbar: ja, umgesetzt durch [Anbieter], Nachweis: [Zertifikat / Prüfbericht, Stand]“. Damit steht auch gleich in der SoA, dass jemand diesen Nachweis regelmäßig anfordern muss – was zur Steuerung von Dienstleistern gehört und in Control 5.22 ausdrücklich verlangt wird.

Die 93 Controls im Überblick

Seit der Fassung 2022 ist Anhang A nicht mehr nach 14 Kapiteln, sondern nach vier Themen gegliedert. Die Zahl der Maßnahmen sank von 114 auf 93 – nicht, weil Anforderungen entfielen, sondern weil verwandte Controls zusammengefasst wurden. Elf Maßnahmen kamen neu hinzu.

Thema	Nummern	Anzahl	Worum es geht
A.5 Organisatorisch	5.1 – 5.37	37	Richtlinien, Rollen, Klassifizierung, Zugangssteuerung, Lieferanten, Vorfälle, Compliance
A.6 Personenbezogen	6.1 – 6.8	8	Einstellung, Vertragsklauseln, Schulung, Disziplinarverfahren, Beendigung, Fernarbeit, Meldewege
A.7 Physisch	7.1 – 7.14	14	Sicherheitsbereiche, Zutritt, Versorgung, Verkabelung, Wartung, Entsorgung, aufgeräumter Arbeitsplatz
A.8 Technologisch	8.1 – 8.34	34	Endgeräte, privilegierte Rechte, Kryptografie, Protokollierung, Netzwerke, Entwicklung, Tests

Bei den elf neuen Maßnahmen lohnt sich ein zweiter Blick, weil sie in Bestands-ISMS oft die einzigen echten Lücken sind. Zwei Beispiele: 8.10 Löschung von Informationen verlangt, dass nicht mehr benötigte Daten tatsächlich verschwinden – belegt wird das mit einem Löschkonzept, das Fristen und Startzeitpunkte festlegt. 5.23 Informationssicherheit bei der Nutzung von Cloud-Diensten verlangt einen geregelten Weg für Auswahl, Betrieb und Ausstieg – die Ausstiegsseite wird dabei fast immer vergessen.

Wenn du noch am Anfang stehst und die Risikobewertung erst aufbauen musst, ist unser Generator für die Risikobewertung der schnellste Einstieg: Er erzeugt die Risikoliste, aus der die Spalte „Risiko-ID“ später gefüllt wird. Wie die Zertifizierung insgesamt abläuft und was sie kostet, steht im Artikel zum ISO-27001-Zertifikat.

Zehn ausgefüllte Zeilen als Muster

Die meisten Vorlagen im Netz liefern eine leere Tabelle mit 93 Zeilen. Das Schwierige ist aber nicht die Tabelle, sondern der Ton der Einträge. Die folgenden zehn Zeilen stammen aus dem fiktiven Geltungsbereich eines Softwarehauses mit 60 Beschäftigten, eigener Entwicklung und Betrieb bei einem Cloud-Anbieter. Sie zeigen, wie knapp eine gute Begründung sein darf – und wo sie ausführlich werden muss.

Nr.	Maßnahme	Anw.	Begründung	Status	Nachweis
5.1	Richtlinien für Informationssicherheit	Ja	Grundlage des ISMS; zusätzlich Anforderung aus Rahmenvertrag [Kunde], Anlage 3	Umgesetzt	Leitlinie Informationssicherheit v3.0
5.7	Bedrohungsinformationen	Ja	Behandelt R-014 (verzögerte Reaktion auf bekannte Schwachstellen). 2022 neu aufgenommen, vorher nicht geregelt	Teilweise	Verfahren Schwachstellenmanagement v1.1; CERT-Bund-Abo
5.15	Zugangssteuerung	Ja	Behandelt R-003 und R-004 (unbefugter Zugriff, verwaiste Konten), Bruttobewertung hoch	Umgesetzt	Berechtigungskonzept v2.2, Abschnitt 4
5.23	Sicherheit bei Cloud-Diensten	Ja	Sämtliche Produktivsysteme laufen bei [Anbieter]; behandelt R-021 (Ausfall des Anbieters) und R-022 (Datenabfluss beim Ausstieg)	Teilweise	Cloud-Richtlinie v1.0; Ausstiegsplan offen, Termin Q4
6.3	Schulung und Sensibilisierung	Ja	Behandelt R-009 (Phishing). Zusätzlich gesetzliche Anforderung: § 30 Abs. 2 Nr. 7 BSIG	Umgesetzt	Schulungskonzept v1.4; Teilnahmeliste 2026
7.4	Physische Überwachung	Ja	Betrifft ausschließlich die Büroräume [Ort]; Serverräume bestehen nicht. 2022 neu aufgenommen	Umgesetzt	Zutrittsprotokoll; Vereinbarung mit Betriebsrat vom [Datum]
7.7	Aufgeräumter Arbeitsplatz und Bildschirm	Ja	Behandelt R-011 (Einsichtnahme durch Besucher und Reinigungspersonal in Großraumbüros)	Umgesetzt	Clean-Desk-Richtlinie v2.0; GPO Bildschirmsperre 10 min
8.10	Löschung von Informationen	Ja	Gesetzliche Anforderung: Art. 17 DSGVO. Behandelt zusätzlich R-018 (Datenbestände ohne Löschfrist)	Geplant	Löschkonzept in Erstellung, Termin [Datum], verantwortlich [Rolle]
8.11	Datenmaskierung	Nein	Nicht anwendbar: In Test- und Entwicklungsumgebungen werden ausschließlich synthetische Datensätze verwendet; ein Import von Produktivdaten ist technisch unterbunden	–	Verfahren Testdatenbereitstellung v1.0
8.28	Sichere Programmierung	Ja	Eigenentwicklung im Geltungsbereich; behandelt R-006 (Schwachstellen im eigenen Code). 2022 neu aufgenommen	Teilweise	Coding-Guideline v0.9; Code-Review verpflichtend, SAST offen

Drei Details lohnen den zweiten Blick. Bei 5.23 steht der offene Ausstiegsplan ausdrücklich in der Spalte Nachweis – das ist unangenehm, aber genau richtig: Ein Auditor, der die Lücke selbst findet, bewertet sie strenger als eine, die dokumentiert und terminiert ist. Bei 7.4 verweist der Nachweis auf die Betriebsvereinbarung, weil physische Überwachung mitbestimmungspflichtig ist; wer das übergeht, hat ein arbeitsrechtliches statt eines Sicherheitsproblems. Und 6.3 zeigt den Normalfall, dass eine Maßnahme zwei Quellen hat: ein eigenes Risiko und eine gesetzliche Pflicht. Beide gehören in die Begründung, weil bei Wegfall des einen der andere Grund bestehen bleibt.

Aus der Praxis: die vier Fehler, die im Audit auffallen

1. Die SoA entsteht zuletzt. Sie wird in der Woche vor dem Audit aus der Anhang-A-Liste heraus geschrieben, statt aus der Risikobehandlung zu folgen. Das Ergebnis ist erkennbar: Alle Controls anwendbar, alle umgesetzt, keine einzige Risiko-ID. Ein Auditor braucht dafür keine zwei Minuten, weil das Muster in jedem zweiten Erstaudit auftaucht.

2. Der Geltungsbereich wird im Kopfteil nicht wiederholt. Dann ist unklar, worauf sich „nicht anwendbar“ bezieht – auf das Unternehmen oder auf den zertifizierten Ausschnitt. Bei Unternehmen mit mehreren Standorten ist das der Unterschied zwischen einem sauberen Ausschluss und einer Abweichung.

3. Der Nachweis verweist auf ein Dokument, das es nicht gibt. In der Spalte steht „Richtlinie mobiles Arbeiten“, und im Dokumentenlenkungssystem findet sich nichts. Das ist kein Formfehler, sondern der Beleg, dass die Maßnahme nicht umgesetzt ist. Wer die SoA ehrlich ausfüllt, findet diese Lücken vor dem Auditor – das ist ihr eigentlicher Nutzen und der Grund, sie früh zu schreiben.

4. Die Version passt nicht zur Risikobewertung. Die SoA verweist auf Risikobewertung Version 1.2, im ISMS liegt Version 2.0. Beide Dokumente werden separat gepflegt, und niemand zieht das jeweils andere nach.

Eine Einschätzung, die nicht jeder teilt: Für kleine Organisationen halte ich Tabellenkalkulationen für die SoA nicht für einen Notbehelf, sondern für die bessere Wahl. Der Vorteil einer GRC-Software liegt in der automatischen Verknüpfung von Risiko, Maßnahme und Nachweis – der Preis dafür ist, dass die Pflege an das Werkzeug gebunden ist und beim Anbieterwechsel oft ein Export übrig bleibt, den niemand mehr lesen kann. Bei unter 50 Beschäftigten überwiegt der Preis den Vorteil. Kritisch ist ohnehin nicht das Werkzeug, sondern ob jemand die Verantwortung für die Pflege hat.

In welcher Reihenfolge du vorgehst

1. Geltungsbereich festschreiben. Ohne klaren Geltungsbereich lässt sich Anwendbarkeit nicht beurteilen.
2. Risiken bewerten und behandeln. Aus den Behandlungsentscheidungen entstehen die Maßnahmen.
3. Rechtliche und vertragliche Anforderungen sammeln. DSGVO, branchenspezifische Vorgaben, Kundenverträge – und bei Betroffenheit die Pflichten aus dem BSIG. Ob dein Unternehmen darunterfällt, klärt der NIS2-Betroffenheitscheck.
4. Anhang A als Gegenprobe durchgehen. Für jedes Control: Ist es durch Schritt 2 oder 3 abgedeckt? Fehlt etwas?
5. Tabelle füllen. Erst Anwendbarkeit und Begründung, dann Status und Nachweis.
6. Lücken in den Risikobehandlungsplan überführen. Alles, was „teilweise“ oder „geplant“ ist, braucht Termin und Verantwortlichen.
7. Von der Leitung genehmigen lassen und die Genehmigung dokumentieren.

Schritt 4 ist der zeitaufwendigste. Er dauert bei einer Organisation mit 50 bis 100 Beschäftigten erfahrungsgemäß mehrere Arbeitstage, wenn er ernsthaft gemacht wird – und ein bis zwei Stunden, wenn man die Liste nur abhakt. Der Unterschied zwischen beiden Varianten wird erst im Audit sichtbar, dann aber vollständig.

Häufige Fragen

Müssen wirklich alle 93 Controls in der SoA stehen?

Ja. Klausel 6.1.3 d) verlangt die Begründung für den Ausschluss jeder nicht angewandten Maßnahme – das setzt voraus, dass alle aufgeführt sind. Eine SoA, die nur die umgesetzten Controls listet, ist unvollständig und wird im Audit beanstandet. Der Aufwand für die ausgeschlossenen Zeilen ist gering, weil sich Begründungen für ganze Gruppen oft wiederholen.

Wie oft muss die SoA aktualisiert werden?

Die Norm nennt kein Intervall. Üblich und im Audit akzeptiert ist eine jährliche Überprüfung im Rahmen der Managementbewertung, zusätzlich anlassbezogen bei Änderungen des Geltungsbereichs, der Risikolage, der Rechtslage oder der eingesetzten Technik. Wichtig ist weniger die Frequenz als der Nachweis, dass die Überprüfung stattgefunden hat – also eine Änderungshistorie mit Datum und Prüfer.

Darf die SoA an Kunden herausgegeben werden?

Technisch ja, sinnvoll meist nein. Die SoA enthält den vollständigen Umsetzungsstand einschließlich der Lücken – das ist eine präzise Landkarte der eigenen Schwachstellen. Üblich ist stattdessen, das Zertifikat plus eine Zusammenfassung der Maßnahmen herauszugeben. Verlangt ein Kunde ausdrücklich die SoA, kann eine gekürzte Fassung ohne die Spalten Nachweis und Status ein Kompromiss sein.

Was ist der Unterschied zwischen SoA und Risikobehandlungsplan?

Die SoA beantwortet „welche Maßnahmen gelten bei uns und warum“, der Risikobehandlungsplan beantwortet „wer setzt was bis wann um“. Die SoA ist ein Zustandsbild, der Plan ein Arbeitsplan. Beide sind Pflichtdokumente und verweisen aufeinander: Jede Zeile der SoA mit dem Status „geplant“ oder „teilweise“ muss sich im Plan wiederfinden.

Gilt die SoA auch bei einer Zertifizierung nach BSI IT-Grundschutz?

Nicht in dieser Form. Der IT-Grundschutz arbeitet mit Bausteinen und dem IT-Grundschutz-Check, der eine vergleichbare Funktion erfüllt, aber anders aufgebaut ist. Wer beide Wege vergleicht, findet die Unterschiede im Artikel zu BSI-Grundschutz und ISO 27001.

Weiterführende Seiten

• ISO 27001 Zertifikat – Ablauf, Aufwand und Nutzen der Zertifizierung
• Risikobewertung Informationssicherheit – kostenloses Werkzeug für die Risikoliste
• Richtlinien-Bibliothek – alle Mustertexte im Überblick
• ISMS einführen – Aufwand, Kosten und typische Fehler

Stand: August 2026. Dieser Beitrag ersetzt keine Rechtsberatung und keine Auditvorbereitung durch eine akkreditierte Zertifizierungsstelle. Maßgeblich ist der Wortlaut der ISO/IEC 27001 in der jeweils gültigen Fassung.