Struktur-Gerüst für die Kontextanalyse nach ISO 27001 für KMU

Von /
Abstraktes futuristisches Netzwerk mit leuchtenden Daten- und Dokument-Symbolen, das die Struktur einer Kontextanalyse nach ISO 27001 für KMU visualisiert.
Digitale Visualisierung von Informationssicherheits-Strukturen, Daten und Dokumenten

Praxis-Gerüst für Deine Kontextanalyse nach ISO 27001

In meinem letzten Beitrag habe ich beschrieben, wie wichtig es für Dich als kleines oder mittleres Unternehmen (KMU) ist, den Kontext der Organisation gemäß ISO 27001 zu verstehen – also die internen und externen Faktoren, die interessierten Parteien und den Geltungsbereich Deines Informationssicherheits-Managementsystems (ISMS).

In diesem Folgeartikel bekommst Du nun ein konkretes Struktur- und Dokumentations-Gerüst, mit dem Du diese Themen systematisch bearbeiten kannst. Es ist als Orientierungshilfe gedacht – keine starre Vorlage, sondern ein anpassbares Modell, das Du passend zu Deinem Unternehmen, Deiner Branche und Deinen Anforderungen einsetzen kannst.

Im Folgenden findest Du:

Damit legst Du – basierend auf dem im letzten Beitrag dargestellten Konzept – den Schritt von der Theorie zur Umsetzung und schaffst eine solide Ausgangsbasis für Dein ISMS.

Vorschlag: Struktur und Aufbau der notwendigen Daten, Kategorien und Dokumente für eine Kontextanalyse

Ausgehend vom vorherigen Beitrag und auf Grundlage bewährter Vorgehensweisen schlage ich dir folgendes Schema vor, das du in deinem Unternehmen zur Umsetzung verwenden kannst. Diese Struktur hilft dir, die Daten systematisch zu erfassen, zu dokumentieren und später für Risikoanalyse, Maßnahmenplanung etc. sinnvoll zu nutzen.

1. Daten & Kategorien

Im Rahmen der Kontextanalyse solltest du Daten zu folgenden Kategorien erfassen:

A. Organisatorischer Rahmen / Unternehmensprofil

  • Unternehmensname, Rechtsform, Branche, Größe (Mitarbeiterzahl, Standorte)
  • Geschäftszweck, Vision, Mission, strategische Ziele
  • Produkte und Dienstleistungen (was wird angeboten)
  • Kernprozesse und Wertschöpfungsketten
  • Organisatorische Struktur, Führungs- und Verantwortungsstrukturen
  • Mitarbeiterstruktur, Qualifikationen, Sicherheitsbewusstsein
  • Infrastruktur: IT-Systeme, Anwendungen, Betriebsmittel, Standorte, Home-Office/Remote-Arbeit

B. Interne Faktoren (Stärken/Schwächen)

  • Identifikation wichtiger Informationswerte (Assets): z. B. Kundendaten, geistiges Eigentum, Betriebsdaten, Systeme, Prozesse
  • Schutzziele dieser Werte: Vertraulichkeit, Integrität, Verfügbarkeit (CIA-Triade)
  • Bestehende Sicherheitsprozesse, Richtlinien, Kontrollen
  • Risiken und Schwachstellen im internen Umfeld (z. B. veraltete Systeme, geringe Dokumentation, unklare Verantwortlichkeiten)
  • Ressourcen: Budget, Personal, Fachkenntnisse, Technologie
  • Unternehmenskultur, Werteverständnis, Verhalten der Mitarbeitenden (z. B. Sicherheitsbewusstsein)

C. Externe Faktoren (Chancen/Risiken)

  • PESTLE-Faktoren:
    • Politisch: Gesetze, Regulierungen, Branchenvorgaben
    • Wirtschaftlich: Marktentwicklung, Wettbewerbsdruck, Lieferketten, Kostenstruktur
    • Sozial/Kulturell: Erwartungen von Kunden, Mitarbeitenden, Öffentlichkeit
    • Technologisch: Neue Technologien, Bedrohungslandschaft, Cloud, IoT, Abhängigkeiten
    • Rechtlich: Datenschutz (z. B. DSGVO), Compliance-Vorgaben, Vertragsanforderungen
    • Umwelt/Ökologisch: Klimarisiken, Nachhaltigkeitsanforderungen, Standortbedingungen
  • Stakeholder-Anforderungen von außen: Kundenanforderungen, Lieferantenanforderungen, Versicherungen, Investoren
  • Externe Partnerschaften, Dienstleister, Lieferantenbeziehungen (Abhängigkeiten)
  • Markt- und Wettbewerbsbedingungen: Zertifizierungen, Normanforderungen, Branchenstandards

D. Interessierte Parteien (Stakeholder)

  • Liste aller relevanten Parteien (intern & extern)
  • Für jede Partei: Erwartungen, Anforderungen, Einfluss auf ISMS, Bedeutung (Priorität)
  • Schnittstellen und Abhängigkeiten (z. B. Dienstleister, externe IT)
  • Potenzielle Konflikte zwischen Stakeholder-Erwartungen

E. Geltungsbereich (Scope) des ISMS

  • Definition des organisatorischen Bereichs: Standorte, Abteilungen, Prozesse, IT-Systeme
  • Definition der Informationswerte und Datentypen, die eingeschlossen sind
  • Ausgeschlossene Bereiche und Begründung
  • Externe Schnittstellen / Dienstleister, die relevant sind
  • Darstellung der Grenze: „Was gehört dazu?“ vs. „Was nicht?“

F. Dokumentation & Aktualisierung

  • Dokumentation der Analyse (intern, extern, Stakeholder, Scope)
  • Review-Mechanismus (z. B. jährliche Überprüfung, bei Änderungen)
  • Verantwortlichkeiten für Pflege der Kontextanalyse
  • Änderungsprotokoll: wann analysiert, wer beteiligt, welche Änderungen gemacht

2. Dokumente und Aufbau

Ich empfehle folgende Dokumente zu erstellen und zu pflegen:

Dokument 1: „Kontext der Organisation – Analysebericht“

Inhalt:

  • Unternehmensprofil (siehe A)
  • Zusammenfassung der internen Faktoren (Stärken/Schwächen)
  • Zusammenfassung der externen Faktoren (Chancen/Risiken)
  • Ergebnis einer SWOT-Matrix (Stärken/Schwächen vs. Chancen/Risiken und abgeleitete Strategien)
  • Wichtigste Informationswerte und Schutzziele
  • Wesentliche Abhängigkeiten (z. B. Dienstleister, Lieferkette)
  • Schlüsselprozesse, Systeme, Standorte

Dokument 2: „Stakeholder-Matrix“

Inhalt:

  • Tabelle mit: Stakeholder | Kategorie (intern/extern) | Erwartung/Anforderung | Einfluss auf ISMS | Priorität | Maßnahmen / Hinweise
  • Regelmäßige Aktualisierung und Status (z. B. letzte Überprüfung, nächste Überprüfung)

Dokument 3: „Scope-Statement ISMS“

Inhalt:

  • Beschreibung der Organisation und deren Geltungsbereich
  • Aufzählung der Standorte, Abteilungen, Prozesse, IT-Systeme, Datentypen
  • Ausnahmen mit Begründung
  • Schnittstellen zu externen Dienstleistern
  • Zuständigkeiten und Verantwortlichkeiten
  • Datum, Version, Freigabe

Dokument 4: „PESTLE/Umfeldanalyse“ (optional als Anhang)

Inhalt:

  • Detailanalyse der externen Faktoren unter den PESTLE-Kategorien
  • Relevanzbewertung (z. B. hoch/mittel/niedrig)
  • Auswirkungen auf Informationssicherheit
  • Referenz auf Dokument 1

Dokument 5: „Review-Log Kontextanalyse“

Inhalt:

  • Datum der Analyse / Revision
  • Wer beteiligt war
  • Welche Änderungen vorgenommen wurden (z. B. neue Stakeholder, geänderter Scope, neue Gesetze)
  • Nächster geplanter Überprüfungstermin

3. Strukturierung der Daten in einem System

Damit die Daten gut nutzbar sind, würde ich dir folgendes Struktur- und Datenmodell vorschlagen:

  • Hauptordner „Kontext_ISMS“
    • Unterordner „Unternehmensprofil“ → Datei Unternehmensprofil.docx
    • Unterordner „Interne_Faktoren“ → Datei Interne_Faktoren.xlsx (Tabelle mit Asset-Liste, Schwachstellen, Ressourcen)
    • Unterordner „Externe_Faktoren“ → Datei PESTLE_Analyse.xlsx
    • Unterordner „Stakeholder“ → Datei Stakeholder_Matrix.xlsx
    • Unterordner „Scope“ → Datei Scope_Statement.docx
    • Unterordner „Review_Protokolle“ → Datei Review_Log.xlsx / .docx
    • Unterordner „Zusammenfassungen“ → Datei Kontextanalyse_Bericht.pdf
  • Tabellen / Datenfelder:
    Für Tabellen (z. B. Stakeholder_Matrix, Interne_Faktoren) sollten folgende Spalten genutzt werden:

    • ID
    • Kategorie (z. B. Prozess, System, Standort)
    • Beschreibung (des Stakeholders)
    • Relevanz (des Stakeholders auf das ISMS, z.B. hoch/mittel/niedrig)
    • Anforderung (oder Erwartung des Stakeholders)
    • Maßnahme(n)
    • Priorisierung
    • Verantwortlich
    • Letzte Überprüfung
    • Status (z. B. in Bearbeitung / abgeschlossen)

4. Vorgehensweise / Ablauf

  • Workshop/Interview mit Geschäftsleitung, IT, Fachabteilungen zur Erhebung interner Faktoren
  • Workshop/Analyse zur Erhebung externer Faktoren (mit PESTLE-Rundgang)
  • Identifikation und Bewertung der Stakeholder
  • Erstellung der Tabelle und Dokumentation
  • Definition des Scope auf Basis der Analyse
  • Genehmigung des Scope durch die Geschäftsleitung
  • Jahres- oder Halbjahres-Review festlegen
  • Integration der Kontextanalyse-Daten in das weitere ISMS (z. B. Risikoanalyse, Maßnahmenplanung, Audit)

5. Hinweise und Tipps

  • Halte die Dokumentation praxisnah und verständlich – vermeide Norm-Floskeln ohne Bezug zur eigenen Organisation.
  • Achte darauf, nicht nur technische Aspekte zu betrachten – Organisation, Kultur, Prozesse und Mitarbeitende sind genauso wichtig.
  • Der Scope sollte ausreichend vollständig sein und keine wesentlichen Abhängigkeiten ausschließen. Gleichzeitig darf er aber nicht überdimensioniert sein, sonst wird das ISMS schwer handhabbar.
  • Die Kontextanalyse ist kein einmaliges Projekt, sondern ein lebendiges Dokument – sie muss gepflegt, überwacht und bei Änderungen angepasst werden.
Nach oben scrollen