Ein ISMS aufzubauen ist kein Dokumentationsprojekt, sondern eine Veränderung im Betriebsmodell. Die meisten gescheiterten Projekte, die wir nachträglich sanieren, hatten zwei Symptome: Ein vollständiger Policy-Stack ohne erkennbare Wirkung im Tagesgeschäft – und eine Risikoanalyse, die niemand in der Linie versteht. Das liegt fast immer an einer fehlenden, schrittweisen Roadmap. ISO/IEC 27001:2022 verlangt die Klauseln 4–10 in einer bestimmten Reihenfolge umzusetzen; wer Punkte vorzieht, baut Korrekturschleifen ein.

Wir präsentieren eine 12-Schritte-Roadmap, die in Schweizer KMU und Mittelstand seit über zehn Jahren praxiserprobt ist. Sie deckt ab:

• Initialisierung, Scoping, Stakeholder-Mapping
• GAP-Analyse gegen alle 93 Annex-A-Controls und Klauseln 4–10
• Risikomethode, Risikobeurteilung, Risikobehandlungsplan und SoA
• Policy-Stack, Awareness und operative Umsetzung der Controls
• Internes Audit, Management Review, Vorbereitung Stage 1 und Stage 2

Die zeitliche Lage variiert nach Reifegrad, aber die Reihenfolge ist robust. Jeder Schritt liefert Artefakte, die der Auditor später konkret sehen möchte. Wir markieren am Ende jedes Blocks, welches Dokument oder welcher Nachweis entsteht.

Schritt 1 – Projektaufsetzung: Sponsor in der Geschäftsleitung, dedizierter Projektleiter (ISO-Beauftragter), Budget, Zeitachse, Kommunikationsplan. Wir empfehlen einen 12- bis 14-monatigen Erstprojektzyklus mit zweiwöchigem Steering und einer dokumentierten Kick-off-Charta. Ergebnis: Charta, RACI-Matrix.

Schritt 2 – Scope festlegen (Klausel 4): Welche Geschäftsbereiche, Standorte, Tochterfirmen, Cloud-Tenants und Produkte gehören zum ISMS? In SaaS-Unternehmen empfehlen wir, mit dem Produktstack und dem Engineering-Team zu starten – das ist die Substanz des Kundenversprechens – und Marketing/Sales/HR im Folgejahr nachzuziehen. Eine kontextualisierte Scope-Erklärung mit Ein- und Ausschlüssen ist Pflichtdokument. Ergebnis: Scope-Statement.

Schritt 3 – Interessensträger und Anforderungen (Klausel 4.2): Kunden, Aufsichtsbehörden (EDÖB, FINMA, BAG), Investoren, Mitarbeitende, Lieferanten – jede Stakeholdergruppe bringt eigene Anforderungen mit (Branchenstandards, Verträge, Gesetze). Diese Anforderungsliste wird im jährlichen Management Review aktualisiert und ist später Input für die Risikobeurteilung. Ergebnis: Stakeholder-Register inkl. Compliance-Obligations.

Schritt 4 – GAP-Analyse: Reifegrad-Assessment je Control (0 = nicht vorhanden, 1 = ad hoc, 2 = dokumentiert, 3 = umgesetzt, 4 = gemessen, 5 = optimiert). Wir prüfen alle 93 Annex-A-Controls und zusätzlich die Klauseln 4–10. Das Ergebnis ist eine farbcodierte Übersicht, die dem Steuerungsboard die Investitionsschwerpunkte zeigt. In den meisten KMU starten wir mit Durchschnittsreife 1,5 und müssen für ein erfolgreiches Zertifizierungsaudit auf mindestens 3,0 kommen. Ergebnis: GAP-Bericht mit Roadmap.

Schritt 5 – Risikomethode definieren (Klausel 6.1.2): Asset-basiert, szenario-basiert oder prozessbasiert? Für ISMS-Erstprojekte bewährt sich ein hybrider Ansatz: prozessbasiert (Pflicht: jeder Geschäftsprozess wird einmal angeschaut), ergänzt um eine asset-basierte Tiefenanalyse für die kronjuwelenhaften Systeme. Risikoskalen (3x3 oder 5x5) müssen vor der Risikobeurteilung festgelegt werden, sonst wird im Nachhinein die Skala an die gewünschte Risikolage angepasst – ein klassischer Audit-Befund. Ergebnis: Risikomethodendokument inkl. Risikoakzeptanzkriterien.

Schritt 6 – Risikobeurteilung und SoA (Klausel 6.1.3 / Annex A): Die Risikobeurteilung erzeugt das Risikoregister. Aus dem Register entsteht der Risikobehandlungsplan, in dem für jedes signifikante Risiko entschieden wird: vermeiden, reduzieren, transferieren oder akzeptieren. Daraus leitet sich das Statement of Applicability (SoA) ab: Eine Liste aller 93 Annex-A-Controls mit Anwendbarkeit (ja/nein), Begründung und aktuellem Umsetzungsstatus. Das SoA ist das meistgeprüfte Dokument im Audit und muss versioniert sein. Ergebnis: Risikoregister, Risikobehandlungsplan, SoA v1.

Schritt 7 – Informationssicherheitsziele und Policies (Klausel 6.2 / 5.2): Aus den Risiken und dem Stakeholder-Register werden messbare Ziele abgeleitet (z. B. ‚Phishing-Klickrate unter 5%‘, ‚100% Patch-Coverage kritischer Systeme innert 14 Tagen‘). Die Informationssicherheitspolitik selbst ist ein knappes, 2-seitiges, vom Vorstand unterschriebenes Dokument. Darunter ein modularer Policy-Stack (12–18 Themenpolicies, je nach Komplexität): Acceptable Use, Access Control, Krypto, Backup, Incident Response, Lieferantensicherheit etc. Ergebnis: Policy-Bibliothek, KPI-Set.

Schritt 8 – Controls operativ umsetzen (Klausel 8 / Annex A): Aus dem Risikobehandlungsplan wird ein Backlog von Massnahmen, die in Sprints (oder bei klassischen Projektorganisationen in Meilensteinen) umgesetzt werden. Typische Schwerpunkte:

• IAM und MFA (A.5.16, A.5.17, A.8.5)
• Logging und Monitoring (A.8.15, A.8.16)
• Backup und Wiederherstellung (A.8.13)
• Vulnerability Management und Patchen (A.8.8)
• Lieferantensicherheit und DPA (A.5.19–A.5.22)
• Incident Response und Krisenkommunikation (A.5.24–A.5.27)

Tooling-Entscheidungen (SIEM, EDR, MDM, IAM, GRC) werden in dieser Phase getroffen – nicht früher, sonst kauft man ohne Anforderungen. Ergebnis: implementierte Controls mit Evidenzen.

Schritt 9 – Awareness und Schulung (Klausel 7.2 / 7.3): Pflicht-Onboarding für neue Mitarbeitende, jährlicher Refresher, rollenbasierte Vertiefungen für IT, Engineering, HR, Vertrieb. Phishing-Simulationen mindestens halbjährlich. Ohne dokumentierte Teilnahmequoten von über 95% wird der Auditor nachfragen. Ergebnis: Schulungsplan und Trainingsnachweise.

Schritt 10 – Internes Audit (Klausel 9.2): Vor dem Zertifizierungsaudit muss mindestens ein vollständiges internes Audit nach einem Audit-Programm durchgeführt sein. Der Auditor muss unabhängig vom geprüften Bereich sein – in kleineren Organisationen heisst das in der Praxis: externer Auditor oder personell entkoppelter Kollege aus einer anderen Abteilung. Geprüft wird sowohl gegen die Norm als auch gegen die internen Policies. Befunde werden in Major/Minor/Observation kategorisiert und mit Korrekturmassnahmen versehen.

Schritt 11 – Management Review (Klausel 9.3): Mindestens einmal pro Zyklus tritt die oberste Leitung zusammen und prüft eine vorgegebene Agenda: Status früherer Reviews, Veränderungen in externen/internen Themen, KPI-Erreichung, interne und externe Auditfeststellungen, Incidents, Risiken, Verbesserungspotenziale, Ressourcenbedarf. Das Protokoll wird vom CEO oder COO unterzeichnet. In Audits ist dieses Protokoll das zweitwichtigste Dokument nach dem SoA. Ergebnis: Internes Auditprogramm, Auditberichte, Management-Review-Protokoll mit Beschlüssen.

Stage 1 (Document Review / Readiness Assessment): Die Zertifizierungsstelle prüft die dokumentierte Information – primär Scope, Risikomethode, Risikoregister, SoA, internes Auditprogramm, Management-Review-Protokoll. Ergebnis sind in der Regel ‚Areas of Concern‘, die bis Stage 2 adressiert sein müssen. Stage 1 dauert in KMU 1–2 Personentage und kann remote stattfinden. Es ist die Chance, vor Stage 2 zu verstehen, wo der konkrete Auditor seinen Schwerpunkt legt.

Stage 2 (Implementation Audit): Vor-Ort- oder hybrides Audit über typischerweise 3–6 Personentage je nach Grösse. Geprüft wird die Wirksamkeit – mit Interviews, Stichproben aus Logs, Demos, Begehung physischer Standorte. Findet der Auditor Major Non-Conformities, müssen diese vor der Zertifikatsausstellung geschlossen werden; Minor Non-Conformities akzeptiert er als Aktionsplan mit Frist. Nach erfolgreichem Stage 2 stellt die Zertifizierungsstelle ein dreijähriges Zertifikat aus. Ergebnis: Zertifizierungsbericht und ISO/IEC 27001:2022-Zertifikat.

Ein typischer Fehler im Erstjahr: Nach dem Zertifikat lässt die Disziplin nach. Surveillance-Audits in Jahr 1 und 2 sind streng – ohne fortgesetzte PDCA-Disziplin riskieren Sie eine Aussetzung des Zertifikats. Planen Sie deshalb das Jahr 1 nach Zertifizierung mit derselben Kapazität wie das Build-up-Jahr.

SIDD führt KMU und Mittelstand pragmatisch durch die zwölf Schritte – wahlweise als vollständige ISO-27001-Implementierung oder als modularer Coaching-Support, wenn Sie über interne Sicherheitskompetenz verfügen, aber Methodik und Erfahrung dazukaufen wollen. Für die operative ISO-Beauftragten-Rolle stellen wir bei Bedarf einen externen CISO / Informationssicherheitsbeauftragten, der Risikomethode, internes Audit, Management Review und die laufende Auditbegleitung übernimmt.

Operativ ergänzen wir die Implementierung typischerweise mit unseren Schwachstellenscans und Penetrationstests als Evidenz für Annex A.8.8 sowie mit IT-Sicherheits-Workshops als Awareness-Bausteine. Für eine erste Reifegradabschätzung Ihres aktuellen Standes erreichen Sie uns über das Kontaktformular. Wenn Sie bereits den Scope und das Zertifizierungsziel kennen, fordern Sie eine Offerte an – wir liefern innert fünf Werktagen ein Festpreisangebot inklusive 12-Monats-Roadmap.