ISO 27001 Klausel 4 — offiziell betitelt „Kontext der Organisation" — ist die erste operative Klausel der Norm. Sie verpflichtet Organisationen dazu, ihr Umfeld zu verstehen, bevor sie irgendeinen Teil ihres ISMS aufbauen.

Konkret umfasst sie vier Bereiche: die Bestimmung interner und externer Themen, die die Informationssicherheit beeinflussen (4.1), das Verständnis der interessierten Parteien und ihrer Anforderungen (4.2), die formale Definition der ISMS-Grenzen (4.3) sowie die Etablierung des ISMS als gesteuertes System (4.4).

Klausel 4 verlangt nicht, Maßnahmen umzusetzen — das kommt später. Sie verlangt, Ihr Umfeld gut genug zu verstehen, um anschließend die richtigen Entscheidungen darüber treffen zu können, welche Maßnahmen wichtig sind und warum.

Bevor Sie entscheiden können, was Sie schützen müssen, brauchen Sie Klarheit darüber, warum es wichtig ist, wer davon abhängt und wo es sich befindet. Klausel 4 stellt drei grundlegende Fragen: Welche Kräfte prägen das Informationssicherheitsumfeld Ihrer Organisation? Wer hat ein Interesse daran, wie Sie es steuern? Und was genau verpflichten Sie sich zu schützen?

Die Antworten auf diese Fragen definieren Reichweite und Ausrichtung Ihres gesamten ISMS. Eine lückenhafte oder übereilte Kontextanalyse hinterlässt Lücken, die Auditoren — und Angreifer — früher oder später finden werden.

ISO 27001 ist eine risikobasierte Norm. Klausel 4 lehnt sich direkt an ISO 31000:2018 an — konkret an deren Schritt „Kontext festlegen". Ihre Kontextanalyse ist kein Hintergrundbericht, sondern ein strukturierter Risikoinput: interne Fähigkeiten und Einschränkungen, externe Druckfaktoren und die Erwartungen von Kunden und Partnern.

Eine Ergänzung von 2024 (Amendment 1) fügte eine explizite Anforderung hinzu: Organisationen müssen prüfen, ob der Klimawandel ein relevantes Thema darstellt — Auditoren erwarten heute entweder eine Aufnahme als aktiven Faktor oder eine begründete negative Feststellung.

Interne Faktoren — typische Beispiele:

• Governance-Struktur und Risikobereitschaft der Organisation
• Bestehende IT-Infrastruktur und Altsysteme
• Mitarbeiterkompetenzen und Fluktuation
• Unternehmenskultur und informelle Abläufe
• Laufende Fusionen, Umstrukturierungen oder Wachstumsphasen
• Wie Informationen zwischen Abteilungen fließen

Externe Faktoren — typische Beispiele:

• Anwendbare Gesetze und Vorschriften: DSGVO, NIS2, branchenspezifische Regelungen
• Markt- und Wettbewerbsdynamik
• Geopolitische Risiken und Abhängigkeiten in der Lieferkette
• Technologischer Wandel einschließlich KI-bezogener Bedrohungen
• Klimabezogene Risiken (seit Amendment 1 explizit zu prüfen)

Praxisbeispiel — internes Thema:

• Thema: Legacy-ERP-System läuft auf nicht mehr unterstützter Software
• Risiko: Erhöhte Angriffsoberfläche, da keine Herstellerpatches mehr verfügbar sind
• Maßnahme: Als Risikoinput in die Klausel-6-Bewertung aufgenommen; Verantwortlicher und Überprüfungsdatum zugewiesen

Methoden, die helfen:

• SWOT: Die einfachste Möglichkeit, interne und externe Themen in einer einzigen Übersicht abzubilden — gut geeignet für Workshops mit dem Senior Management.
• PESTLE: Strukturierter Blick auf das externe Umfeld — stellt sicher, dass regulatorische oder makroökonomische Faktoren nicht übersehen werden.
• Kontext- und Themenregister: Eine gepflegte Tabelle mit jedem Thema, seinem Verantwortlichen und dem letzten Überprüfungsdatum — verwandelt eine Einmalanalyse in ein lebendes Dokument.

Dokumentierte Informationen: Klausel 4.1 verlangt kein formales Dokument. Auditoren werden diesen Bereich jedoch sondieren — entweder durch Interviews oder durch Prüfung Ihrer übrigen Unterlagen. Ein kurzes Register oder eine knappe Zusammenfassung ist dringend empfohlen.

Klausel 4.2 verlangt, dass Sie die Parteien bestimmen, die ein Interesse an Ihrem ISMS haben, und deren Anforderungen ermitteln. Die Version von 2022 ergänzte eine wichtige Präzisierung: Sie müssen auch entscheiden, welche dieser Anforderungen das ISMS tatsächlich adressieren wird — und diese Entscheidung dokumentieren.

Typische interessierte Parteien:

• Kunden und Auftraggeber: Datenschutzerwartungen, vertragliche Verpflichtungen
• Aufsichtsbehörden: Datenschutzaufsichtsbehörden (DSGVO), NIS2-Behörden, Branchenregulatoren
• Mitarbeitende: klare Richtlinien, Schutz personenbezogener Daten
• Lieferanten und Cloud-/SaaS-Partner
• Gesellschafter und Aufsichtsrat: Risikoberichterstattung, definierter Risikoappetit
• Zertifizierungsstelle: Konformität mit der Norm
• Versicherungsanbieter: Sicherheitsauflagen als Bedingung für den Versicherungsschutz

Ein wichtiger Punkt: Wenn eine regulatorische oder vertragliche Anforderung eine bestimmte Maßnahme vorschreibt, muss diese in Ihrer SoA aufgeführt und umgesetzt werden — unabhängig von Ihrer internen Risikopriorisierung. Klausel 4.2 schafft verbindliche Eingaben für Ihren Risikobehandlungsprozess.

Gute Praxis:

• Interessenträgerregister pflegen: jede Partei, ihre Anforderungen und wie diese adressiert oder begründet ausgeschlossen werden.
• Stakeholder-Matrix nach Einfluss und Interesse nutzen, um bei konfligierenden Anforderungen Prioritäten zu setzen.
• Register bei jedem Management Review aktualisieren — Klausel 9.3 nennt Änderungen bei interessierten Parteien ausdrücklich als Pflicht-Reviewinput.

Dokumentierte Informationen: Von der Norm nicht explizit gefordert, aber von Auditoren erwartet. Eine undokumentierte Analyse lässt sich unter Prüfungsdruck kaum verteidigen.

Dies ist die einzige Stelle in Klausel 4, an der eine dokumentierte Information ausdrücklich vorgeschrieben ist. Wer beim Stage-1-Audit kein schriftliches, genehmigtes Geltungsbereichsdokument vorlegen kann, riskiert eine kritische Nichtkonformität.

Der Geltungsbereich legt die Grenzen Ihres ISMS fest und sollte entlang fünf Dimensionen definiert werden:

• Personen — welche Mitarbeitenden, Rollen und Auftragnehmer im Geltungsbereich liegen
• Prozesse — welche Geschäftsprozesse mit berücksichtigten Informationen umgehen
• Technologie — Systeme, Plattformen, Cloud-Umgebungen und Netzwerke
• Informationen — welche Datenbestände geschützt werden sollen
• Standorte — Büros, Rechenzentren, Homeoffice-Umgebungen

Der Geltungsbereich muss Schnittstellen und Abhängigkeiten berücksichtigen. Ein Cloud-Hosting-Anbieter, ein ausgelagerter Lohnbuchhaltungsdienstleister oder eine gemeinsam genutzte Entwicklungsumgebung schaffen Grenzen, die explizit gemanagt werden müssen.

Ausschlüsse sind zulässig, müssen aber formal begründet werden und dürfen keine Lücken beim Schutz der im Geltungsbereich enthaltenen Informationen erzeugen. Die Klauseln 4–10 selbst können nicht ausgeschlossen werden — Ausschlüsse betreffen ausschließlich Annex-A-Maßnahmen.

Dokumentierte Informationen: Das Geltungsbereichsdokument ist die einzige Pflichtunterlage in Klausel 4. Es wird in der Anwendbarkeitserklärung referenziert und sollte versionskontrolliert sowie vom Senior Management genehmigt sein.

Klausel 4.4 ist oft der kürzeste Halt in Klausel 4 — aber Kürze sollte nicht mit geringer Bedeutung verwechselt werden. Sie verknüpft alles: Der erfasste Kontext, die identifizierten Interessenträger und der definierte Geltungsbereich müssen als einheitliches, gesteuertes System funktionieren — nicht als Ordner voller Richtlinien, die niemand liest.

Denken Sie an Klausel 4.4 als die „And-then-what?"-Klausel. Die Arbeit aus 4.1 bis 4.3 hat nur dann Wert, wenn sie aktiv beeinflusst, wie Sie Ihr ISMS betreiben, überwachen und verbessern. Keine zusätzlichen Pflichtdokumente, aber eine Prozesslandkarte oder ein RACI ist ein nützliches Evidenzinstrument.

Pflichtdokument gemäß Klausel 4:

• ISMS-Geltungsbereichsdokument (Klausel 4.3) — das einzige explizit geforderte Dokument in dieser gesamten Klausel

Empfohlene Unterlagen, die Auditoren erwarten und die Ihre Arbeit erleichtern:

• Kontext- und Themenregister: eine gepflegte Liste mit Verantwortlichen und letztem Überprüfungsdatum
• SWOT- oder PESTLE-Analyse als Nachweis, dass der Kontext systematisch erfasst wurde
• Interessenträgerregister: jede Partei, ihre Anforderungen und wie diese adressiert oder formal ausgeschlossen werden
• Stakeholder-Matrix nach Einfluss und Interesse zur Priorisierung bei konfligierenden Anforderungen
• Geltungsbereich-Dokument oder -Narrativ mit Begründung für Ein- und Ausschlüsse
• Netzwerk- oder Datenflussdiagramme als Nachweis der technologischen und physischen Grenzen
• RACI oder Prozesslandkarte, die zeigt, wie ISMS-Elemente zusammenwirken (unterstützt Klausel 4.4)