Mein Weg in die ISO 27001

Ich habe mich in den letzten Monaten ziemlich intensiv mit ISO 27001 beschäftigt, weil ich meine persönlichen Zertifizierungen vorantreiben wollte.
Meine ersten Gedanken waren auswendig lernen - Prüfung - fertig.

Aber das hat sich so nicht bestätigt.

Wenn man sich etwas tiefer mit der Norm beschäftigt, merkt man ziemlich schnell, dass die Grundideen dahinter absolut sinnvoll und logisch sind.
Viele Dinge wirken zwar auf den ersten Blick wie reine Formalitäten, haben aber in der Praxis einen echten Mehrwert.
Gerade in kleinen oder mittelständischen Unternehmen.

ISO 27001 kann hier, richtig angewandt, ziemlich viel Struktur bringen:
für die persönliche Orientierung, aber auch für die praktische Arbeit beim Kunden.
Das wirkt alles erst bürokratisch, aber am Ende sortiert es genau die Punkte, die sonst gerne jahrelang liegen bleiben.

Auch in der persönlichen Weiterbildung in der IT-Security, egal ob sie eine Zertifizierung anstreben oder „nur“ ihr Wissen sortieren wollen: Die Norm gibt eine gemeinsame Sprache und einen klaren Rahmen vor. Und das macht dann in Zukunft auch die Zusammenarbeit mit potentiellen Kunden deutlich einfacher.

Was ich aber als echte Gefahr sehe, sind zwei Dinge:

Blindes Abarbeiten von Templates, nur damit irgendwas irgendwo steht.
Teure ISMS-Tools, die für kleine Firmen kaum Mehrwert liefern

In vielen Fällen reicht eine ganz normale, sauber gepflegte Dokumentenablage völlig aus.
Und Templates kann man einmal kaufen oder bekommt sie im Rahmen eines Beratungsprojekts ohnehin.

Bevor wir in die Details von ISO 27001 einsteigen

Ich will kurz darauf eingehen, worum es bei ISO 27001 eigentlich geht – oder genauer gesagt:
was mir persönlich geholfen hat, den Überblick zu behalten.

Danach kommen die konkreten Inhalte - ⚠️ Achtung Wall of Text

ISO 27000 & ISO 27001 kurz erklärt

ISO 27001 ist der internationale Standard für Informationssicherheits-Managementsysteme (ISMS).
Im Kern geht es darum:

Ein System aufzubauen, mit dem man Informationssicherheit planvoll, nachvollziehbar und risikobasiert umsetzt – passend zur Organisation, nicht als Selbstzweck.

ISO 27000 ist die zugehörige Familie, z. B.:

Begrifflichkeiten und Vokabular
Leitfäden wie ISO 27002
Ergänzungen wie ISO 27701 (Datenschutz)
Audit-Leitfäden (ISO 19011)

1. Verantwortlichkeiten & Governance (ISO 27001:2022 – A.5.x)

Ohne klar geregelte Verantwortlichkeiten gibt es kein funktionierendes ISMS – und ganz generell keine funktionierende Informationssicherheit.
Damit steht und fällt jedes Security-Level.

Mindestanforderungen:

Eine kurze Informationssicherheitsleitlinie (1–2 Seiten)
→ A.5.1 Policies
Einen benannten Verantwortlichen für Informationssicherheit (nicht zwingend Vollzeit)
→ A.5.2 Roles
Eine strukturierte Risikoanalyse (leichtgewichtig reicht völlig)
→ A.5.4 Risk management
Minimal dokumentierte Kernprozesse: Incident, Change, Access

Diese Punkte bilden die Grundlage für alle weiteren Bausteine der Informationssicherheit.

2. Asset-, Patch- & Vulnerability-Management (A.8.x)

Das ist der Bereich, der in der Praxis am meisten Sicherheitsrisiko reduziert – und gleichzeitig einer der häufigsten blinden Flecken.

Was notwendig ist:

Eine vollständige Asset-Liste (Server, Cloud, Endgeräte, Daten)
→ A.8.1 Inventory
Einen Patch- und Update-Prozess (monatlich oder risikobasiert)
→ A.8.8 Technical vulnerabilities
Dokumentierte Baseline-Konfigurationen (z. B. Adminrechte, Firewalls, MFA)
→ A.8.9 Configuration management
Logging & Monitoring mindestens grob definiert
→ A.8.16 Monitoring activities

Ohne diese Basis ist jedes andere Sicherheitskonzept nur Kosmetik.
Viele Sicherheitsvorfälle entstehen genau hier: unklare Assets, fehlende Updates, schlechtes Hardening.

3. Incident Response & Security Monitoring (A.5.24–A.5.28)

Ein stabiler Incident-Response-Prozess verhindert Eskalationen und sorgt dafür, dass Sicherheitsvorfälle schnell erkannt, bewertet und sauber behandelt werden.

Bestandteile:

Incident-Response-Policy (Definition Event/Incident, Meldewege)
Klare Rollen & Eskalationswege
→ A.5.24 Information security incident management planning and preparation
Standardisierter IR-Prozess
Identify → Contain → Eradicate → Recover → Review
→ A.5.26 Response to information security incidents
Incident-Log bzw. Ticketing-Nachweis
→ A.5.27 Learning from information security incidents
Beweissicherung (Log-Sicherung, Berechtigungen)
→ A.5.28 Collection of evidence

Auch hier gilt: Einfach anfangen, strukturiert ausbauen.

4. Sicherer Entwicklungsprozess & Lieferkette (A.5.19–A.5.20 & A.8.25–A.8.29)

*(Für Softwareunternehmen besonders wichtig)_

Ein sauberer, dokumentierter Entwicklungsprozess ist für Softwarefirmen der entscheidende Faktor – und oft auch die härteste Kundenanforderung, etwa im Energie- oder Industriesektor.

Wichtige Elemente:

Ein leichtgewichtiger SDLC mit:
Plan → Dev → Review → Test → Deploy
→ A.8.25 Secure development lifecycle
Secure Coding-Vorgaben (z. B. Code-Reviews, Secrets-Handling, Dependency-Updates)
→ A.8.28 Secure coding
Security Testing (automatisiert reicht)
→ A.8.29 Security testing
Trennung von Dev/Test/Prod
→ (Hinweis: Die genaue Formulierung sollte mit ISO/IEC 27002:2022 abgeglichen werden, da ich hier nicht 100 % sicher bin.)
Third-Party Risk Check (SaaS, Libraries, Hersteller)
→ A.5.19 Supplier relationships
Sicherheitsanforderungen in Verträgen
→ A.5.20 Supplier agreements

ISMS – Grundlagen

Ein ISMS (Informationssicherheits-Managementsystem) ist der Rahmen,
mit dem eine Organisation Informationssicherheit planvoll, nachvollziehbar und kontinuierlich verbessert umsetzt.

Ziele: Vertraulichkeit, Integrität, Verfügbarkeit
Schutzobjekte: Informationen, Systeme, Prozesse, Menschen, Reputation
Elemente: Policies, Prozesse, Verfahren, Rollen, Nachweise
Maßnahmen: technisch, organisatorisch, physisch, personell
Ansatz: risikobasiert + prozessorientiert
Logik: PDCA-Zyklus (Plan–Do–Check–Act)

ISMS

Grundlagen

Ein ISMS (Informationssicherheits-Managementsystem) ist ein Satz zusammenhängender Elemente einer Organisation, mit dem Richtlinien, Ziele, Prozesse, Verfahren, Regelungen sowie zugehörige Ressourcen festgelegt werden, um die Ziele der Organisation zu erreichen – hier: angemessene Informationssicherheit.

Im Kern geht es um den Schutz von:

Informationen mit Wert für die Organisation
Geräten, Einrichtungen, Software und Services
Menschen und ihren Qualifikationen
Ruf und Ansehen des Unternehmens

Dafür braucht es:

Regeln und Vorgaben (Policies, Prozesse, Verfahren)
Rollen und Verantwortlichkeiten (z. B. ISB/CISO, Prozessverantwortliche)
geeignete Maßnahmen in vier Kategorien:
- technisch
- organisatorisch
- physisch
- personell
  (präventiv, detektiv, korrektiv)

Typische ISMS-Outcome-Artefakte

ISMS-Handbuch / ISMS-Wiki

Informationssicherheitsrichtlinie (Policy)

Rollen- und Verantwortlichkeitsmatrix

Prozess- und Verfahrensbeschreibungen

Übersicht „Schutzobjekte & Schutzziele“

Prozessorientierung

ISO 27000, ISO 20000 und ISO 9000 folgen einem prozessorientierten Ansatz:
Nicht die Organigramm-Struktur steht im Mittelpunkt, sondern die Abläufe (z. B. Incident-Management, Change-Management, Access-Management).

Outcome

High-Level-Prozesslandkarte

Liste ISMS-relevanter Kernprozesse

Plan-Do-Check-Act

Das ISMS ist als dynamisches System gedacht. Schützenswerte Assets, Risiken und Anforderungen ändern sich – deshalb gilt der PDCA-Zyklus:

Plan – Ziele setzen, Risiken analysieren, Maßnahmen planen
Do – Maßnahmen umsetzen
Check – Konformität, Effektivität und Effizienz prüfen
Act – Verbesserungen und Korrekturen ableiten und umsetzen

Outcome

Visualisierung des PDCA-Zyklus

Übersicht laufender Verbesserungsmaßnahmen

Verknüpfung PDCA ↔ ISMS-Prozesse

4. Maßnahmen und Spezifikationen

Ab Abschnitt 4 beginnt der eigentliche normative Kern von ISO 27001.
Die Anforderungen aus den Abschnitten 4–10 bilden zusammen mit Anhang A die Grundlage für Audits.

4. Kontext der Organisation

4.1 Verstehen der Organisation

Die Organisation muss ihr Umfeld verstehen: politische, rechtliche, kulturelle, soziale, technische, ökonomische und regionale Aspekte, sowie wichtige Trends und externe Beziehungen.
Das ISMS soll sich in bestehende Strukturen einfügen und real umsetzbare Prozesse schaffen – keine „Papierwelt“.

Outcome

Dokument „Kontext der Organisation“ (interne/externe Themen)

Grundlage für Scope-Definition und Risikomanagement

4.2 Verstehen der Erfordernisse interessierter Parteien

Relevante Stakeholder (z. B. Kunden, Aufsichtsbehörden, Lieferanten, Mitarbeitende) und deren Anforderungen an Informationssicherheit müssen identifiziert und bewertet werden. Außerdem ist zu klären, welche dieser Anforderungen das ISMS konkret adressiert.

Outcome

Stakeholder Analyse

Liste interessierter Parteien

Zuordnung ihrer Anforderungen

Kennzeichnung „im ISMS berücksichtigt / außerhalb Scope“

4.3 Festlegen des Anwendungsbereichs des ISMS (Scope)

Der Scope des ISMS legt fest, welche Standorte, Prozesse, IT-Systeme und Organisationseinheiten im Geltungsbereich liegen – inklusive Schnittstellen zu anderen Firmen und Dienstleistern. Die Ergebnisse aus 4.1 und 4.2 fließen hier ein.

Outcome

Scope Statement

Beschreibung des Geltungsbereichs (was ist drin, was ist draußen)

benannte Standorte, Systeme, Prozesse

definierte Schnittstellen und Abgrenzungen

Freigabe durch die oberste Leitung

4.4 ISMS

Die Organisation muss ein ISMS aufbauen, verwirklichen, aufrechterhalten und fortlaufend verbessern – entsprechend den Anforderungen der Norm.

Outcome

ISMS-Beschreibung

Kurzbeschreibung, wie das ISMS aufgebaut ist (Dokumentenstruktur, Rollen, Hauptprozesse)

Verweis auf ISMS-Handbuch / -Wiki

Übersicht „Bausteine des ISMS“

5. Führung

Führung und Verpflichtung

Die oberste Leitung trägt die Verantwortung dafür, dass Informationssicherheit:

zur Unternehmensstrategie passt,
Ziele und Politik klar definiert sind,
ausreichend Ressourcen bereitstehen,
Informationssicherheit im Unternehmen vermittelt und gelebt wird,
das ISMS wirksam ist und fortlaufend verbessert wird.

Outcome

Beschluss / Entscheidung zum ISMS (Management-Commitment)

Protokolle aus Managementmeetings mit ISMS-Bezug

Zuordnung der IS-Ziele zu Unternehmenszielen

Politik (Informationssicherheitspolitik)

Die Leitung muss eine IS-Politik festlegen, die:

zum Zweck der Organisation passt,
Rahmen für Sicherheitsziele bietet,
die Verpflichtung zur Einhaltung von Anforderungen und zur Verbesserung enthält,
dokumentiert, intern kommuniziert und – soweit sinnvoll – extern verfügbar ist.

Outcome

Informationssicherheitspolitik

1–2 Seiten, von der obersten Leitung freigegeben

beschreibt Ziele, Schutzziele, Geltungsbereich und Rollen

Nachweis der Veröffentlichung und Kommunikation

Rollen, Verantwortlichkeiten und Befugnisse

Rollen für Informationssicherheit (z. B. ISB/CISO, Prozessowner, Systemverantwortliche) müssen klar zugewiesen werden – inklusive Verantwortlichkeiten, Befugnissen und Berichtspflichten Richtung Management.

Outcome

Rollen- und Verantwortlichkeitsmatrix (inkl. Vertretungsregelungen)

Organigramm mit ISMS-Rollen

formale Benennung des ISB/CISO

6. Planung

6.1 Risiken und Chancen

Die Organisation muss Risiken und Chancen für:

das ISMS selbst,
die Zielerreichung und
unerwünschte Effekte auf Informationssicherheit

identifizieren und planen, wie damit umgegangen wird.

Outcome

Übersicht „Risiken & Chancen für das ISMS“

Maßnahmenliste zur Behandlung dieser Managementsystem-Risiken

6.1.2 Informationssicherheitsrisikobeurteilung

Es sind Kriterien festzulegen (z. B. Risikotoleranz, Bewertungsmethoden), dann:

Risiken bzgl. Vertraulichkeit, Integrität, Verfügbarkeit identifizieren,
Risikoeigentümer bestimmen,
Folgen und Eintrittswahrscheinlichkeiten bewerten,
Risiken priorisieren.

6.1.3 Informationssicherheitsrisikobehandlung

Auf Basis der Risikobeurteilung werden:

Behandlungsoptionen gewählt (vermeiden, verringern, übertragen, akzeptieren),
geeignete Maßnahmen festgelegt (intern oder aus externen Quellen),
alle Risiken mit Anhang A abgeglichen („Have we missed anything?“),
die Erklärung zur Anwendbarkeit (SoA) erstellt,
ein Risikobehandlungsplan aufgebaut
und Restrisiken durch Risikoeigentümer freigegeben.

Outcome

Erklärung zur Anwendbarkeit (SoA)

Liste aller Controls aus Anhang A

Entscheidung „anwendbar/nicht anwendbar“ mit Begründung

Verweis auf umsetzende Maßnahmen / Dokumente

Risikobehandlungsplan

Maßnahmen je Risiko

Verantwortliche, Termine, Status

Dokumentierte Akzeptanz von Restrisiken

6.2 Informationssicherheitsziele & Planung

Informationssicherheitsziele müssen:

zur IS-Politik passen,
messbar sein,
auf Risiken, Anforderungen und Ergebnisse der Risikobeurteilung Bezug nehmen,
überwacht, kommuniziert und bei Bedarf aktualisiert werden.

Für die Umsetzung ist zu planen:

was getan wird,
welche Ressourcen nötig sind,
wer verantwortlich ist,
bis wann es erledigt ist,
wie der Erfolg gemessen wird.

Outcome

Zieleregister Informationssicherheit (inkl. KPIs)

Verknüpfung von Zielen mit konkreten Maßnahmenprojekten

Rückbezug der Zielerreichung in der Managementbewertung

6.3 Planung von Änderungen

Änderungen am ISMS sind geplant durchzuführen, damit keine neuen Risiken entstehen oder bestehende verschärft werden.

Outcome

Änderungsprotokoll für ISMS (Versionierung, Changelog)

Bewertung der Auswirkungen geplanter Änderungen

dokumentierte Freigabe durch Verantwortliche

7. Unterstützung

7.1 Ressourcen

Die Organisation muss die erforderlichen Ressourcen für Einführung, Betrieb und Verbesserung des ISMS ermitteln und bereitstellen (Zeit, Geld, Tools, Personal).

Outcome

Dokumentation der Ressourcenermittlung

Stellenbeschreibungen mit ISMS-Anteilen

Budgetfreigaben / Investitionsentscheidungen

7.2 Kompetenzen

Es ist festzulegen:

welche Kompetenzen für ISMS-Rollen erforderlich sind,
wie sichergestellt wird, dass Personen qualifiziert sind (Ausbildung, Schulung, Erfahrung),
welche Maßnahmen für fehlende Kompetenzen geplant werden,
wie Kompetenzen nachgewiesen werden.

Outcome

Rollenbeschreibungen inkl. Kompetenzanforderungen

Schulungs- und Zertifikatsübersicht

Trainings-/Weiterbildungsplan

7.3 Bewusstsein

Mitarbeitende sollen wissen:

dass es eine IS-Politik gibt,
welchen Beitrag sie zur Wirksamkeit des ISMS leisten,
welche Folgen Verstöße haben können.

Outcome

Awareness-Kampagnen (Präsentationen, E-Learnings, Onboarding)

Teilnahme-/Durchführungsnachweise

7.4 Kommunikation

Es ist festzulegen:

worüber kommuniziert wird,
wann,
mit wem,
auf welchem Weg
– intern wie extern (z. B. Kunden, Lieferanten, Behörden, bei Vorfällen).

Outcome

Kommunikationsplan (Thema, Zeitpunkt, Zielgruppe, Kanal, Verantwortliche)

Nachweise tatsächlich erfolgter Kommunikation (Berichte, Mails, Statusupdates)

7.5 Dokumentierte Information

Dokumente und Aufzeichnungen des ISMS müssen:

definiert (Inhalt, Umfang),
erstellt und aktualisiert (Kennzeichnung, Format, Freigabe),
und gesteuert werden (Zugriff, Schutz, Versionierung, Aufbewahrung).

Outcome

Dokumentenlenkungsrichtlinie

zentrale Dokumentenliste (Register) mit Version, Owner, Status

Freigabe- und Versionshistorie der ISMS-Dokumente

8. Betrieb – Do

8.1 Betriebliche Planung und Steuerung

Die Organisation muss die für das ISMS relevanten Prozesse planen, steuern und dokumentieren – inkl. Kriterien und Kontrollen. Das gilt auch für ausgelagerte Prozesse bei Dienstleistern.

Outcome

Operative Prozessbeschreibungen (z. B. Incident-, Access-, Backup-, Change-Management)

Übersicht ausgelagerter Prozesse inkl. Verantwortlichkeiten

Nachweise der Umsetzung (Tickets, Protokolle, Change-Records)

8.2 Informationssicherheits-Risikobeurteilung

Die Risikobeurteilung ist:

in geplanten Abständen
und bei wesentlichen Änderungen (z. B. neue Anwendungen, Standorte, Services)

zu wiederholen.

Outcome

regelmäßig aktualisierte Risikobewertungen

Versionierung und Historie der Risikoregister

definierte Trigger für Neubewertungen

8.3 Informationssicherheits-Risikobehandlung

Die geplanten Maßnahmen zur Risikobehandlung müssen tatsächlich umgesetzt und nachverfolgt werden.

Outcome

aktueller Umsetzungsstatus des Risikobehandlungsplans

Nachweise zu umgesetzten Maßnahmen (Configs, Policies, Logs, Testberichte)

9. Bewertung der Leistung – Check

9.1 Überwachung, Messung, Analyse und Bewertung

Es sind KPIs / Security-Metriken zu definieren, die:

Prozesse und Maßnahmen abdecken,
nach klaren Methoden erhoben und ausgewertet werden,
Verantwortlichkeiten und Zeitpunkte der Messung festhalten.

Outcome

KPI-/Metrics-Katalog Informationssicherheit

regelmäßige Berichte (z. B. quartalsweise)

Management-Entscheidungen auf Basis dieser Kennzahlen

9.2 Internes Audit

In regelmäßigen Abständen sind interne Audits durchzuführen, um:

Normkonformität und
Wirksamkeit des ISMS

zu bewerten.

Wichtig dabei:

Auditprogramm, -kriterien und -umfang planen,
Unabhängigkeit und Objektivität der Auditoren sicherstellen,
Ergebnisse dokumentieren und berichten.

Outcome

Auditprogramm (1–3 Jahre)

Auditpläne, Checklisten, Berichte

Maßnahmenlisten aus Feststellungen inkl. Nachverfolgung

9.3 Managementbewertung

Die oberste Leitung bewertet das ISMS regelmäßig anhand festgelegter Inputs (z. B. Audit-Ergebnisse, KPI-Trends, Rückmeldungen von Stakeholdern, Status der Maßnahmen).

Outcome

Protokoll der Managementbewertung

Beschlüsse der Leitung (z. B. Ressourcen, Prioritäten, Richtungsentscheidungen)

Ableitung von Verbesserungs- und Korrekturmaßnahmen

10. Verbesserung – Act

10.1 Fortlaufende Verbesserung

Die Organisation muss das ISMS fortlaufend hinsichtlich Eignung, Angemessenheit und Wirksamkeit verbessern.

Outcome

gesteuerter Umgang mit Verbesserungs- und Korrekturmaßnahmen

Dokumentation im Verbesserungs- oder Maßnahmenregister

10.2 Nichtkonformität und Korrekturmaßnahmen

Bei Nichtkonformitäten wird:

reagiert (Korrektur, Folgen begrenzen),
die Ursache analysiert,
geprüft, ob ähnliche Schwachstellen an anderer Stelle existieren,
die Korrekturmaßnahme umgesetzt und
deren Wirksamkeit überprüft.
Falls nötig, wird das ISMS angepasst.

Outcome

Beschreibung der Nichtkonformität

Korrektur- und Korrekturmaßnahmen

Wirksamkeitsnachweise

aktualisierte ISMS-Dokumente bzw. Prozesse

Zusammenfassung

Der Scope legt fest, was das ISMS abdeckt.
Die IS-Politik und das Risikomanagement bilden den Kern der Steuerung.
Die oberste Leitung ist verantwortlich für Richtung, Ressourcen und Priorisierung.
Mit Audits, Kennzahlen und Managementbewertungen wird die Wirksamkeit überprüft.
Über Korrektur- und Verbesserungsmaßnahmen wird das ISMS kontinuierlich weiterentwickelt.

Gesamt-Outcome ISO 27001

funktionierendes, nachweisbares ISMS

klare Artefakte: Scope, SoA, Risiko- & Maßnahmenregister, Policies, Prozesse, Nachweise

Zertifizierungsfähigkeit (falls gewünscht) und reproduzierbare Steuerung von Informationssicherheit