Von der Anforderung zur Umsetzung

In den letzten Beiträgen unserer Serie haben wir die neuen Anforderungen der ISO/IEC 27001:2022 beleuchtet – von Cloud-Sicherheit über Datenmaskierung und Monitoring bis hin zu Resilienz und physischer Sicherheit. Doch die entscheidende Frage bleibt: Wie wird aus all diesen Puzzlestücken ein funktionierendes ISMS?

Die Norm zu kennen ist das eine. Sie im Unternehmen so zu verankern, dass Prozesse stabil laufen, Verantwortlichkeiten klar sind und Nachweise auditierbar vorliegen – das ist die eigentliche Herausforderung. Eine Roadmap hilft, den Weg von der Anforderung bis zur Zertifizierung greifbar zu machen.

Die Roadmap – Sechs Schritte zum Auditfähigen ISMS

Ein ISMS entsteht nicht von heute auf morgen. Aber der Weg folgt einer klaren Logik, die sich unabhängig von Branche oder Unternehmensgröße bewährt hat:

1. Rahmen abstecken Geltungsbereich, Rollen und Verantwortlichkeiten festlegen. Management und Fachbereiche ins Boot holen.
2. Gap-Analyse & SoA Abgleich mit den Controls der ISO/IEC 27001:2022 (Annex A), Abbildung in einem Statement of Applicability. Transparenz ist der erste Schritt zur Priorisierung.
3. Maßnahmenplanung Nicht alles ist gleich wichtig. Neue Anforderungen wie Cloud-Sicherheit, Monitoring oder Business Continuity greifen tief ins Tagesgeschäft und verdienen Vorrang.
4. Umsetzung & Nachweise Policies, Verfahren und Prozesse anpassen. Entscheidend sind aber nicht die Dokumente, sondern die Nachweise, dass sie im Alltag funktionieren.
5. Tests & Übungen Notfallpläne und technische Maßnahmen regelmäßig proben. Ohne Übungen bleiben Konzepte Theorie.
6. Internes Audit & Management-Review Wirksamkeit prüfen, Findings schließen, Management einbinden. Erst dann ist das ISMS bereit für das externe Audit.

Case Study – Ein Jahr ISMS-Aufbau im Mittelstand (Greenfield)

Natürlich sieht jedes ISMS-Projekt anders aus – je nach Branche, Unternehmensgröße und Ausgangslage. Manche Organisationen starten bei null, andere bringen ein seit Jahren gewachsenes System mit. Um die Roadmap greifbar zu machen, schildern wir hier einen vereinfachten, exemplarischen Projektverlauf aus dem Mittelstand. Er zeigt nicht jedes Detail, macht aber gut sichtbar, wie die einzelnen Schritte zusammenwirken und in welchem zeitlichen Rahmen sich eine Migration typischerweise bewegt.      

Ausgangslage  

Ein international tätiger Zulieferer mit 100 Mitarbeitenden hatte kein formales ISMS. Es gab vereinzelte IT-Regeln (Passwörter, Backups), aber keine dokumentierte Governance, keine Risikobewertung, keine BIA. Inzwischen waren mehrere Cloud-Dienste produktiv, Notfallpläne existierten nicht, Zutrittskontrollen liefen ohne Nachweise.  

Monat 1–2: Kick-off & Scope  

Die Geschäftsführung benennt einen ISMS-Beauftragten, Workshops definieren den Scope: Neben der Zentrale werden erstmals auch Produktionsstandorte und Cloud-Umgebungen einbezogen. Widerstand entsteht – „zu viel Bürokratie“. Nach mehreren Management-Runden wird klar: Ein enger Scope wäre einfacher, bildet das Risiko aber nicht realistisch ab.  

Monat 2–3: Gap-Analyse & SoA  

Aus Nullbasis erfolgt der Abgleich mit den Controls der ISO/IEC 27001:2022. Es entsteht ein erstes Statement of Applicability (SoA) – mit klaren Begründungen zu Anwendbarkeit/Nicht-Anwendbarkeit. Erste Stolperfalle: Einige Fachbereiche fühlen sich „überprüft“. Workshops mit gemeinsamer Priorisierung drehen die Perspektive: Hilfestellung statt Kontrolle.  

Monat 3–6: Maßnahmenentwicklung

• Cloud-Sicherheit: Rollen im Shared-Responsibility-Modell werden dokumentiert. Verträge mit Dienstleistern werden um Exit- und Löschprozesse ergänzt. Nicht ganz einfach, da ein Provider anfangs Widerstand leistet.
• Business Continuity: Eine Business Impact Analyse (BIA) wird erstmals durchgeführt. Erkenntnis: Fachbereiche geben zunächst unrealistische Recovery Time Objectives (RTO) an („ERP darf maximal 30 Minuten ausfallen“). Nach Diskussion und Priorisierung einigt man sich auf belastbare RTOs (8 Stunden für ERP, 24 Stunden für Produktionssysteme).
• Physische Sicherheit: Zutrittskontrollen werden neu aufgesetzt. Bei der  Erfassung fällt auf: Ehemalige Mitarbeitende hatten noch Zugangskarten. Ein häufiger Schwachpunkt.
• Awareness: Schulungen für Entwickler starten. Erste Use-Cases für Monitoring werden definiert, aber das Team tut sich schwer mit der Interpretation der Logdaten.  

Monat 6–9: Tests & Nachweise

• Failover-Test: Ein geplanter ERP-Ausfall wird simuliert. Ergebnis: Der Wiederanlauf dauert 7 Stunden – innerhalb der RTO, aber nur knapp. Ohne Protokollierung wäre dieser Test im Audit nicht verwertbar gewesen.
• Restore-Test: Backups werden zurückgespielt. Hier zeigt sich: Einige Datensätze fehlen, weil ein Sicherungsskript seit Monaten nicht korrekt lief. Problem wird behoben, Routineprüfungen eingeführt.
• Physische Überwachung: Wartungsprotokolle werden eingeführt. Erste Prüfung ergibt, dass mehrere Kameras seit Wochen nicht aufzeichneten – eine ungünstige, aber wertvolle Erkenntnis.
• Monitoring: System liefert erste Alarme, Eskalationsprozesse werden erprobt.  

Monat 9–12:

Internes Audit & Managementreview Das interne Audit identifiziert sieben Findings, darunter drei kritische: unklare Cloud-Rollen, fehlende Nachweise für physische Kontrollen, unklare Reaktion bei Monitoring-Alarmen. Innerhalb von 30 Tagen werden alle Punkte korrigiert. Das Managementreview bestätigt, dass das ISMS wirksam ist und Nachweise belastbar sind. Bei der  Erstzertifizierung bescheinigen die Auditoren: Anforderungen der 2022er Norm erfüllt – mit nur kleineren Nebenabweichungen.    

Fazit aus der Case Study:

• Ohne Gap-Analyse bleiben viele Schwachstellen unsichtbar.
• Ohne BIA sind Notfallpläne nicht belastbar.
• Ohne regelmäßige Prüfungen sind physische Sicherheitsmaßnahmen wertlos.
• Ohne klare Nachweise wird kein Auditor überzeugt.  

Vor allem aber: Die Stolpersteine sind normal.  

Ein ISMS ist kein linearer Plan, sondern ein Prozess mit Rückschleifen, Diskussionen und manchmal auch Widerständen. Entscheidend ist, dass die Organisation daraus lernt – und dokumentiert, wie sie mit den Erkenntnissen umgeht.

Wie lange dauert so ein Projekt wirklich?  

Der Aufwand hängt stark von Komplexität, Entscheidungsgeschwindigkeit und Verfügbarkeit der Schlüsselrollen ab. Für Greenfield-Projekte gilt erfahrungsgemäß:

• Kleiner Betrieb (50–150 MA, überschaubare IT): 6–9 Monate bis zur Erstzertifizierung.
• Typischer Mittelstand (100–500 MA, mehrere Standorte/Clouds): 9–15 Monate.
• Komplex/reguliert (z. B. viele Lieferanten, 24/7-Betrieb): 12–18+ Monate.

Unser Fazit

Damit schließt sich der Kreis unserer Blogserie. Entscheidend ist am Ende nicht die Kenntnis der Norm, sondern die strukturierte Umsetzung im Unternehmen. Genau dafür liefert eine Roadmap Orientierung – und die Praxis zeigt: Der Aufwand lohnt sich.

Wie die dhpg Sie unterstützt

Ein ISMS aufzubauen oder zu migrieren ist anspruchsvoll, insbesondere, wenn Ressourcen knapp sind oder interne Expertise fehlt.

Wir unterstützen Sie unter anderem bei:

• Gap-Analysen und SoA-Mapping,
• Business Impact Analysen und Notfallübungen,
• Cloud- und Vertragsmanagement,
• Prüfung und Umsetzung physischer Sicherheitsmaßnahmen und
• Vorbereitung auf interne und externe Audits.  

Das Besondere bei dhpg: Wir verbinden technische Expertise mit unserer Erfahrung als Wirtschaftsprüfer und Berater. Damit bekommen Sie Informationssicherheit und regulatorische Sicherheit aus einer Hand.