ISMS aufbauen: Schritt-für-Schritt-Anleitung nach ISO 27001:2022

Ein Informationssicherheits-Managementsystem (ISMS) nach ISO/IEC 27001:2022 ist kein Dokumentationsprojekt, sondern ein Steuerungssystem mit 93 Controls aus Anhang A, einem verbindlichen Statement of Applicability, einem Risikomanagement-Prozess nach Klausel 6 und einem kontinuierlichen Verbesserungszyklus nach Klausel 10. Wer ein ISMS aufbaut, koordiniert über 12 bis 18 Monate hinweg eine Kette aus Geltungsbereich, Stakeholder-Analyse, Risikobewertung, Maßnahmenplanung, Implementierung, internem Audit und Zertifizierungsaudit. Die internationale Übergangsfrist zur neuen Normfassung läuft bis Oktober 2026, danach werden nur noch Zertifikate nach ISO/IEC 27001:2022 anerkannt, und nur diejenigen Unternehmen behalten ihr Zertifikat, die rechtzeitig auditiert wurden.

Dieser Beitrag beschreibt zehn operative Phasen, die jeweils mit klaren Artefakten, Verantwortlichkeiten und realistischen Zeitachsen hinterlegt sind. Er richtet sich an Informationssicherheitsbeauftragte (ISB), IT-Leiter, Compliance-Verantwortliche und Geschäftsführer, die ein ISMS erstmalig einführen oder den Übergang auf die 2022er Fassung vollziehen. Im Mittelpunkt steht die operative Frage, wie der Aufbau ohne Insellösungen funktioniert. Statt einer reinen Normbeschreibung zeigen wir, welche Vorlagen, Berichtslinien und Schnittstellen wirklich gebraucht werden, und wie CIVAC als Compliance-Plattform und Officer-as-a-Service den Aufbau in einem System bündelt, damit Audit-Spuren, Risikoregister und Maßnahmenpläne nicht in Excel-Dateien verloren gehen, sondern versioniert und reproduzierbar dokumentiert sind.

Die ISO/IEC 27001:2022 verlangt in Klausel 4 die Bestimmung des Kontextes der Organisation, der relevanten interessierten Parteien und des Anwendungsbereichs des ISMS. Diese Phase entscheidet, wie viel Aufwand das gesamte Projekt erzeugt und welche Geschäftsprozesse, Standorte und IT-Systeme zertifiziert werden. Ein zu weiter Scope erzeugt unnötige Last und überfordert die internen Ressourcen, ein zu enger Scope wird in der Auditpraxis kritisch hinterfragt und kann zu Findings führen, die das Erstaudit verzögern oder gefährden.

Operativ erfolgt die Geltungsbereichs-Definition als schriftliches Dokument mit drei Abschnitten. Erstens organisatorische Abgrenzung: welche Geschäftsbereiche, Tochtergesellschaften und Standorte sind inkludiert. Zweitens technische Abgrenzung: welche IT-Systeme, Plattformen, Cloud-Dienste, Netzwerksegmente fallen in den Scope. Drittens Schnittstellen: welche externen Dienstleister, Auftragsverarbeiter und Kunden berühren den Scope. Die Klausel 4.3 verlangt explizit eine Begründung für Ausschlüsse, die im Statement of Applicability später wieder aufgegriffen wird und auditrelevant bleibt.

Die Stakeholder-Analyse identifiziert Anforderungen, die für das ISMS relevant sind. Kunden mit ISMS-Anforderungen in Verträgen, Regulatoren mit Berichtspflichten wie NIS-2 oder DORA, Aufsichtsbehörden, Datenschutzaufsichten und interne Stakeholder wie Vorstand, Betriebsrat und Auditkomitee. Jede Anforderung wird als Eintrag im Stakeholder-Register dokumentiert, mit Quelle, Frequenz, Verantwortlichem und der konkreten Folge für das ISMS, etwa ein zusätzliches Reporting, eine spezifische Kontrollanforderung oder eine Vertragsklausel mit Audit-Recht für den Auftraggeber.

Im CIVAC-Workspace existiert eine Vorlage für die Geltungsbereichsdokumentation und das Stakeholder-Register, abgeleitet aus dem ISO-Klauselbaum. Der Informationssicherheitsbeauftragte arbeitet im selben System wie die Geschäftsleitung, sodass Freigaben mit Datum und Unterschrift ablaufen und der spätere Auditor die Versionierung lückenlos nachvollziehen kann, ohne dass eine separate Dokumentenmanagement-Abstimmung erforderlich wird oder Parallelablagen entstehen.

Klausel 5.2 verlangt eine durch die Geschäftsleitung formal verabschiedete Informationssicherheits-Leitlinie. Sie ist keine Detailregelung, sondern ein einseitiges bis dreiseitiges Dokument, das Zweck des ISMS, die strategischen Ziele, das Bekenntnis zur ständigen Verbesserung und die Verantwortlichkeit der Leitung benennt. Inhaltlich enthält sie die Mindestbestandteile aus Klausel 5.2 und referenziert auf nachgelagerte Richtlinien, ohne deren Inhalte zu duplizieren oder zu vorwegnehmen.

Die Verantwortlichkeiten werden in Klausel 5.3 geregelt. Die Geschäftsleitung benennt eine zentrale Rolle für das ISMS, in der Regel den ISB oder Chief Information Security Officer (CISO). Die schriftliche Bestellurkunde dokumentiert Aufgabenrahmen, fachliche Weisungsfreiheit, Berichtslinie an die Geschäftsleitung und Eskalationsrechte. Bestellurkunde, unterschrieben, abgelegt, belegbar. Daneben werden Rollen für Risiko-Eigentümer, Maßnahmenverantwortliche und interne Auditoren definiert, jeweils mit klaren Vertretungsregelungen.

Ein häufiger Fehler ist die alleinige Bestellung des IT-Leiters als ISB. Klausel 5.3 verlangt zwar keine organisatorische Trennung, in der Praxis erzeugt die Personalunion einen Interessenkonflikt zwischen Sicherheits-Anforderung und Betriebs-Realität, insbesondere bei knappen Budgets. Bessere Praxis ist ein eigenständiger ISB mit Berichtslinie an die Geschäftsleitung, der die IT-Sicherheit fachlich steuert, ohne der IT-Linie unterstellt zu sein. Aufsichtsbehörden achten in Stage-2-Audits gezielt auf diese strukturelle Trennung.

CIVAC stellt vorgefertigte Leitlinien-Templates und Bestellurkunden bereit, die mit den 93 Controls nach ISO/IEC 27001:2022 referenziert sind. Der dual-model-Ansatz greift hier konkret. Lizenzieren Sie den Workspace für Ihre internen Beauftragten oder lassen Sie unsere Beauftragten bestellen, wenn die fachliche Unabhängigkeit aus eigenen Reihen nicht abbildbar ist, etwa in mittelständischen Strukturen mit personeller Engstelle in der IT-Leitung und ohne dediziertes Sicherheits-Budget für eine eigene Stelle.

Klausel 6.1 fordert ein systematisches Risikomanagement. Das Vorgehen muss dokumentiert sein, regelmäßig durchgeführt werden und reproduzierbare Ergebnisse liefern. Praktisch durchlaufen ISMS-Projekte vier Schritte. Erstens Identifikation der Werte (Assets), zweitens Identifikation der Bedrohungen und Schwachstellen, drittens Risikoanalyse mit Eintrittswahrscheinlichkeit und Auswirkung, viertens Risikobewertung gegen vorher festgelegte Akzeptanzkriterien. Die Methodik selbst ist Pflichtdokument und wird zu Beginn von Stage 1 vom Auditor geprüft, ebenso wie die Konsistenz der angewandten Bewertungsskalen.

Die Werteliste umfasst Informationen, Anwendungen, Infrastruktur, Personal, physische Werte und Lieferanten. Eine pragmatische Größe ist ein Register mit 50 bis 200 Werten je nach Unternehmensgröße. Jeder Wert erhält einen Eigentümer, eine Vertraulichkeits-, Integritäts- und Verfügbarkeits-Bewertung sowie eine Verknüpfung zu den Geschäftsprozessen, die er stützt. Cloud-Dienste und Auftragsverarbeiter werden als eigene Werte geführt, um die Lieferkettenanalyse später vorzubereiten und um Auditpfade zu den Verträgen herstellbar zu machen, einschließlich der Auftragsverarbeitungsverträge nach Art. 28 DSGVO.

Die Bedrohungsanalyse stützt sich häufig auf Kataloge wie die BSI-Gefährdungsübersicht oder ISO/IEC 27005. Üblich sind 30 bis 50 Bedrohungskategorien, die mit den Werten kombiniert ein Bedrohungs-Wert-Mapping ergeben. Die Schwachstellenanalyse ergänzt die Sicht aus Audit-Berichten, Penetrationstests, Vulnerability-Scans und Vorfallsdaten der letzten 24 Monate, sodass empirische Erkenntnisse einfließen und die Risikoanalyse nicht nur auf Annahmen, sondern auf realen Vorfällen basiert.

Die Risikobewertung erfolgt typischerweise als Matrix mit Eintrittswahrscheinlichkeit und Auswirkung, jeweils auf vier- oder fünfstufiger Skala. Akzeptanzkriterien werden vor der Bewertung festgelegt, etwa Risiken oberhalb der Stufe acht müssen behandelt werden. Im Workspace wird das Risikoregister versioniert geführt, die Risiko-Eigentümer erhalten Quartals-Erinnerungen über die Berichtslinie, und Audit-Vorlagen aus dem CIVAC-Bestand decken die Klausel 6.1-Anforderung normsicher ab.

Klausel 6.1.3 verlangt eine Entscheidung pro Risiko: Vermeiden, Verringern, Übertragen oder Akzeptieren. Wer verringern wählt, wählt aus den 93 Controls in Anhang A der ISO/IEC 27001:2022 jene aus, die das Risiko angemessen senken. Die neue Normfassung gruppiert die Controls in vier Themen: Organisatorisch (37), Personenbezogen (8), Physisch (14) und Technologisch (34). Wer die Übersicht behält, behält das Projekt im Griff, gerade beim Übergang von der 2013er Fassung mit ihren 114 Controls und elf neuen Controls in der aktuellen Fassung.

Das Statement of Applicability (SoA) ist das zentrale Audit-Dokument. Es führt für jedes der 93 Controls auf, ob es anwendbar ist, ob es implementiert ist, mit welcher Begründung es ausgeschlossen wird (falls zutreffend), und welche Risikobehandlung es adressiert. Auditoren beginnen Stage-1-Audits regelmäßig mit dem SoA, weil sich aus ihm der gesamte ISMS-Reifegrad ableiten lässt. Ein unvollständiges oder inkonsistentes SoA ist der häufigste Grund für Findings im Erstaudit, insbesondere wenn Begründungen für Ausschlüsse fehlen oder Implementierungsstand und Risikoregister nicht übereinstimmen.

Der Risikobehandlungsplan ergänzt das SoA mit Maßnahmen, Fristen, Verantwortlichen und Restrisiko-Bewertungen. Maßnahmen sind konkret formuliert, nicht abstrakt: nicht Zugriffskontrolle verbessern, sondern Multi-Faktor-Authentifizierung für alle privilegierten Konten bis 30.06., verantwortlich IT-Operations, mit messbarem Wirksamkeitsnachweis. Restrisiken werden vom Risiko-Eigentümer formal akzeptiert und im Risikoregister mit Datum und Unterschrift dokumentiert, sodass im Audit nachvollziehbar ist, wer welches Restrisiko bewusst akzeptiert hat und mit welcher schriftlichen Begründung.

CIVAC liefert SoA-Vorlagen mit der vollständigen Control-Liste der 2022er Fassung, ergänzt um Querverweise zu BSI-Grundschutz und NIS-2-Pflichtmaßnahmen. So entsteht eine konsolidierte Sicht auf Compliance-Anforderungen, statt parallel geführter Excel-Dateien für jede Norm. Audit-fest, dokumentiert, § 27001-fest, und Stage-1-vorbereitet.

Die ISO/IEC 27001:2022 verlangt dokumentierte Information an mehreren Stellen, ohne ein starres Dokumentationsformat vorzuschreiben. Pflicht sind unter anderem der Geltungsbereich, die Informationssicherheits-Leitlinie, die Risikomethodik, die Ergebnisse der Risikobewertung, der Risikobehandlungsplan, das Statement of Applicability, die Sicherheitsziele und die Nachweise der Wirksamkeitsmessung nach Klausel 9. Diese Dokumente bilden das Skelett, das im Audit als Erstes geprüft wird, und sie sind die Eintrittskarte zur eigentlichen Wirksamkeitsprüfung in Stage 2.

Hinzu kommen Richtlinien und Verfahrensanweisungen, die aus den Controls abgeleitet werden. Typische Pflichtdokumente sind eine Zugriffskontrollrichtlinie (A.5.15), eine Kryptografie-Richtlinie (A.8.24), eine Lieferantenrichtlinie (A.5.19), eine Incident-Management-Richtlinie (A.5.24), ein Business-Continuity-Konzept (A.5.30) und eine Asset-Management-Richtlinie (A.5.9). Die genaue Liste ergibt sich aus dem SoA und den Risiken. Eine generische Übernahme aus Mustersammlungen führt fast immer zu Findings, weil die unternehmensspezifische Realität fehlt und das Audit-Gespräch die Diskrepanz schnell offenlegt.

Operative Nachweise sind genauso wichtig wie Richtlinien. Auditoren fragen nicht nur danach, ob eine Richtlinie existiert, sondern ob sie gelebt wird. Beispiele: Wer überprüft Berechtigungen wann, wo werden Schulungs-Teilnahmen dokumentiert, wo liegen die Incident-Tickets der letzten 12 Monate, wie wurden Lieferanten-Audits durchgeführt, welche CAPA-Tickets sind offen. Ohne diese Nachweise bleibt das ISMS Papier, und Stage 2 wird zur unangenehmen Erfahrung.

Im Workspace wird die Dokumentenpyramide rollenbasiert geführt. Leitlinie, Richtlinien, Arbeitsanweisungen und Aufzeichnungen sind versioniert, freigegeben und mit den 93 Controls verknüpft. Der Prüfer ruft an, der Nachweis liegt bereit. Verlinkt mit dem Risikoregister und dem Maßnahmenplan entsteht ein lückenloser Pfad von der Norm-Anforderung über die Risikobewertung bis zur konkret umgesetzten Maßnahme, einschließlich Eskalationspfad an die Geschäftsleitung und Wirksamkeitsmessung pro Quartal.

Klausel 7.2 und 7.3 verlangen Kompetenz und Bewusstsein für alle Personen, die unter der Kontrolle der Organisation arbeiten und Tätigkeiten ausführen, die die Informationssicherheit beeinflussen. In der Praxis bedeutet das ein dreistufiges Schulungskonzept. Allgemeines Awareness-Training für alle Mitarbeitenden, Rollen-spezifische Vertiefung für besonders sensible Funktionen, Vertiefungs-Schulung für ISMS-relevante Rollen wie Risiko-Eigentümer und interne Auditoren. Jede Stufe wird in Inhalten, Frequenz und Wirksamkeitsmessung separat geplant, mit klarer Verantwortlichkeit.

Inhaltlich umfasst das Awareness-Training mindestens die Themen Passwortsicherheit, Phishing-Erkennung, sichere Mobile-Device-Nutzung, Datenklassifizierung, Meldewege bei Vorfällen, Clean-Desk-Verhalten und das Verhalten am Arbeitsplatz, einschließlich Home-Office und mobilen Endgeräten. Die Schulung erfolgt jährlich oder bei Eintritt, Wirksamkeit wird durch Wissenstests, Phishing-Simulationen oder Stichproben gemessen. Reine Klick-durch-Module ohne Test gelten als unzureichend und werden im Audit beanstandet.

Für besonders kritische Rollen wie Administratoren, Entwickler, Personal mit Zugang zu Geheimnissen oder Personal in Berührung mit personenbezogenen Daten sind vertiefte Schulungen erforderlich. Inhalte sind sichere Konfiguration, Patch-Management, sichere Softwareentwicklung nach OWASP-Logik, sicherer Umgang mit kryptografischen Schlüsseln, Datenschutz-spezifische Inhalte und die Konsequenzen bei Verstößen, einschließlich arbeitsrechtlicher Maßnahmen und disziplinarischer Eskalationspfade. Schulungsnachweise werden personenbezogen archiviert.

Die Wirksamkeit wird nach Klausel 9.1 gemessen. Kennzahlen sind Schulungsquote, Phishing-Klickrate, Wissenstest-Bestehensquote, Zeit bis zur Meldung von Phishing-Mails. Im CIVAC-Workspace werden Schulungsteilnahmen und Wirksamkeitsmessungen rollenbasiert geführt. Die Berichtslinie an die Geschäftsleitung enthält monatlich die Awareness-Kennzahlen, sodass Klausel 9.1 kontinuierlich erfüllt ist. Andere führen Compliance wie einen Aktenschrank, hier wird sie wie Software geführt, mit klaren Schwellenwerten, Eskalationslogik und automatisiertem Quartalsbericht für die Management-Bewertung. Externe Schulungsanbieter lassen sich anbinden, sodass nur ein Lernmanagement-System gepflegt wird.

Klausel 8 verlangt die Umsetzung des Risikobehandlungsplans und die operative Steuerung der Informationssicherheit. Dies ist die zeitaufwendigste Phase und dauert in der Regel sechs bis neun Monate. Die Maßnahmen aus dem SoA werden Schritt für Schritt eingeführt, beginnend mit den höchsten Risiken und den Quick-Wins, die ohne Großprojekt umsetzbar sind, etwa Multi-Faktor-Authentifizierung, Mindest-Passwortlängen, Aktualisierung von Passwortregeln nach NIST SP 800-63B oder die Härtung exponierter Server-Konfigurationen.

Operative Steuerung bedeutet, dass Maßnahmen messbar sein müssen. Beispiele sind die Patch-Quote für kritische Systeme innerhalb 14 Tagen, die Berechtigungsreview-Frequenz pro Quartal, die Backup-Wiederherstellungszeiten in regelmäßigen Tests oder die Lieferanten-Audit-Frequenz pro Jahr. Jede Maßnahme wird in einem KPI-Dashboard geführt, idealerweise mit Soll- und Ist-Werten und einer Eskalation, wenn die Ziele verfehlt werden, ergänzt um eine Kommentar-Spur zu Ursachen und die Verknüpfung zum verantwortlichen Maßnahmen-Eigentümer.

Outsourcing-Beziehungen sind ein eigener Komplex. Klausel A.5.19 bis A.5.23 regelt Lieferantenmanagement und Cloud-Dienste. Praktisch bedeutet das, dass Verträge mit Auftragsverarbeitern eine Informationssicherheits-Klausel enthalten, Lieferanten regelmäßig auditiert werden und Notfallpläne die Abhängigkeit von kritischen Dienstleistern berücksichtigen. NIS-2 verschärft die Anforderungen, wenn der Auftraggeber wesentlich oder wichtig im Sinne des BSI-Gesetzes ist, mit erweiterten Lieferketten-Verpflichtungen und einer eigenen Berichtspflicht bei Vorfällen in der Lieferkette.

Im Workspace werden Maßnahmen, Lieferanten-Auflagen und KPIs in einem System geführt. Verknüpfungen zwischen Maßnahme, Control und Risiko sind durchgängig sichtbar, sodass im Audit der Pfad nachvollziehbar bleibt. Die Berichtslinie liefert der Geschäftsleitung monatlich den Status, ohne dass jemand Excel-Folien zusammenstellen muss, ergänzt um automatische Eskalation bei Schwellwert-Überschreitung und farbliche Markierung kritischer Maßnahmen.

Klausel 9.2 verlangt vor dem Zertifizierungsaudit ein vollständiges internes Audit, das alle Klauseln und alle anwendbaren Controls aus dem SoA abdeckt. Ein internes Audit wird durch unabhängige interne Auditoren oder durch externe Auditoren durchgeführt, die fachlich qualifiziert und organisatorisch unabhängig sind. Auditplan, Auditkriterien und Auditberichte sind dokumentierte Information und werden in Stage 1 als Erstes vom Auditor angefordert, ergänzt um die Nachweise zur Schließung der internen Audit-Findings.

Die Management-Bewertung nach Klausel 9.3 erfolgt mindestens jährlich auf Leitungsebene. Inputs sind unter anderem die Ergebnisse interner Audits, Vorfälle, Beschwerden, Risikobewertungen, Wirksamkeitsmessungen, Kunden-Feedback und Änderungen in den interessierten Parteien. Outputs sind dokumentierte Entscheidungen zur Verbesserung, Ressourcenbedarf und Anpassung der Sicherheitsziele. Die Sitzungsprotokolle sind ein Pflichtnachweis im Audit, fehlende Protokolle sind ein klassisches Finding, das das Erstaudit verzögern kann.

Klausel 10 verlangt kontinuierliche Verbesserung. Konkret werden Abweichungen aus internen Audits, externen Audits, Vorfällen oder Wirksamkeitsmessungen in einem CAPA-System (Corrective and Preventive Actions) geführt. Jede Abweichung erhält eine Ursachenanalyse, eine Korrekturmaßnahme, eine Frist, einen Verantwortlichen und einen Wirksamkeitsnachweis. CAPA-Tickets sind die häufigste Quelle für Erstaudit-Findings, wenn sie unvollständig oder ohne Wirksamkeitsbeleg vorliegen, etwa nur Schließdatum ohne Wirksamkeitsbeleg oder ohne Re-Test der ursprünglichen Abweichung.

CIVAC führt internes Audit, Management-Bewertung und CAPA in einem System. Auditplan und Auditberichte werden aus den 490 einsatzbereiten Audit-Vorlagen abgeleitet und mit dem SoA verknüpft. Die Berichtslinie an die Geschäftsleitung enthält die Tagesordnung der Management-Bewertung mit Vorbereitungs-Materialien, sodass die Klausel 9.3-Sitzung nicht improvisiert werden muss, sondern strukturiert und auditfest dokumentiert abläuft. Quartals-Reviews und CAPA-Schlussberichte sind aus dem System exportierbar, die Geschäftsleitung sieht den Fortschritt ohne Excel-Mappe.

Phase 9 ist das Zertifizierungsaudit. Es erfolgt in zwei Stufen. Stage 1 ist eine Dokumentenprüfung mit Vor-Ort-Termin, in der der Auditor das SoA, die Risikomethodik, die Leitlinien und die Auditplanung prüft. Stage 2 ist das Hauptaudit über typischerweise drei bis fünf Tage, in dem die Wirksamkeit der Controls vor Ort und in Interviews bewertet wird. Findings werden in drei Kategorien geführt: Hauptabweichung, Nebenabweichung, Beobachtung, jeweils mit Korrekturfrist.

Nach erfolgreichem Stage 2 stellt die Zertifizierungsstelle das Zertifikat aus, gültig drei Jahre mit jährlichen Überwachungsaudits. Re-Zertifizierungsaudits erfolgen nach Ablauf der drei Jahre. Bei Hauptabweichungen muss der Mangel innerhalb einer festgelegten Frist behoben und nachgewiesen werden, bevor das Zertifikat erteilt wird. Die Übergangsfrist auf die 2022er Fassung endet im Oktober 2026, danach sind nur noch Zertifikate nach ISO/IEC 27001:2022 anerkannt und 2013er Zertifikate verlieren ihre Gültigkeit.

Phase 10 ist die Daueraufgabe. Das ISMS lebt durch Wiederholung. Jährlich erfolgen das interne Audit, die Management-Bewertung, die Risiko-Reviews und die Aktualisierung des SoA. Quartalsweise erfolgen Kennzahlen-Reportings an die Geschäftsleitung und Reviews der Berechtigungen. Monatlich werden Vorfälle und CAPA-Tickets gepflegt. Das ISMS ist kein Endprodukt, sondern ein Steuerungssystem, das mit dem Unternehmen wächst und im Idealfall auch im Tagesgeschäft sichtbar bleibt.

Aus dem Lesen einen Auftrag machen. CIVAC ist Compliance-Plattform und Officer-as-a-Service. Lizenzieren Sie den Workspace für Ihre internen Beauftragten oder lassen Sie unsere Beauftragten bestellen. Schreiben Sie an info@civac.de oder nutzen Sie das Kontaktformular auf civac.de. Wir besprechen Geltungsbereich, Vorerfahrung und Zielzeitachse, anschließend erhalten Sie einen Modellvorschlag. Bestellurkunde, unterschrieben, abgelegt, belegbar. Wer den externen Informationssicherheitsbeauftragten wählt, gewinnt Zeit und behält die Verantwortung.