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

---

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:

1. reagiert (Korrektur, Folgen begrenzen),
2. die Ursache analysiert,
3. geprüft, ob ähnliche Schwachstellen an anderer Stelle existieren,
4. die Korrekturmaßnahme umgesetzt und
5. 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