Setzen Sie einen 12-Wochen-Plan im 30/60/90-Tage-Format ein, wenn Sie Executive Sponsorship haben, eine dedizierte ISMS-Leitung und bereits grundlegende Sicherheitskontrollen vorhanden sind. Diese Struktur bringt Sie schnell zu auditfähigen Artefakten (Projektcharter, Gap-Analyse, Risikobeurteilung und Statement of Applicability). Ohne diese Voraussetzungen sollten Sie stattdessen 4 bis 12 Monate einplanen. In jedem Fall bleiben die ersten Deliverables unverändert: ein unterzeichneter Projektcharter, ein dokumentierter Anwendungsbereich, eine klauselweise Gap-Analyse und ein initialisiertes Risikoregister.
Zusammenfassung:
- Organisationen mit einer vollzeitlich tätigen ISMS-Leitung und starker Executive-Unterstützung können die ISO-27001-Zertifizierung in 12 Wochen erreichen, sofern Kontrollen bereits vorhanden sind.
- Für Organisationen, die bei null beginnen oder über einen geringen Kontroll-Reifegrad verfügen, verlängert sich der Projektzeitplan auf vier bis zwölf Monate, wobei der Schwerpunkt auf dem Aufbau der Grundlagen und der Sensibilisierung liegt.
- Zu den wichtigsten Meilensteinen gehören ein unterzeichneter Projektcharter, ein dokumentierter Anwendungsbereich, eine klauselweise Gap-Analyse und eine genehmigte Informationssicherheitsrichtlinie – alle innerhalb der ersten 30 Tage abzuschließen.
- Risikobeurteilung und Statement of Applicability erfordern konsistente, einfache Methoden, Asset-Klassifizierung, Bedrohungsidentifikation und detailliertes Control-Mapping, das sich durch die Wochen 31 bis 60 zieht.
- Eine Beschleunigung des Prozesses birgt das Risiko von Nachweislücken und Scope Creep; daher sind striktes Time-Boxing, vorgefertigte Vorlagen und die parallele Ausführung von Aufgaben unerlässlich, um die Auditbereitschaft ohne Qualitätseinbußen aufrechtzuerhalten.
Inhaltsverzeichnis
- Welcher ISO-27001-Projektzeitplan ist für Ihre Organisation der richtige?
- Voraussetzungen und eine Planungs-Checkliste, bevor Sie die Uhr starten
- Tag 1 bis 30: Die Grundlagenphase – Woche für Woche
- Tag 31 bis 60: Risikobeurteilung, SoA und Kernverfahren
- Tag 61 bis 90: Implementierung, Schulung und Zertifizierungsvorbereitung
- Ein 12-Wochen-Zeitplan, den Sie in Ihren eigenen Plan übernehmen können
- Wie Personal und Budget in der Praxis aussehen
- Wie Sie beschleunigen, ohne das Audit zu gefährden
- Was ISO-27001-Projekte scheitern lässt – und was zuerst zu beheben ist
- Budget und Zeitplan mit realen Zahlen planen, nicht mit Schätzungen
- Quellen
Welcher ISO-27001-Projektzeitplan ist für Ihre Organisation der richtige?
Die ehrliche Antwort hängt weniger von der Unternehmensgröße ab als von drei Faktoren: wie viel dedizierte Zeit Ihre ISMS-Leitung einbringen kann, wie stark der Executive-Rückhalt vorhanden ist, um schnelle Entscheidungen zu treffen, und wie ausgereift Ihre bestehenden Kontrollen bereits sind. Organisationen mit einer ISMS-Leitung im Umfang von 0,5 bis 1,0 VZÄ, einem wöchentlichen Steering-Meeting und einer Person mit Entscheidungsbefugnis für die Risikobehandlung können realistisch innerhalb von 90 Tagen einen zertifizierungsreifen Zustand erreichen. Alle anderen sollten einen längeren Zeitraum einplanen.
Ein 12-Wochen-Fast-Track funktioniert nur, wenn Sie nicht bei null beginnen. Wenn bereits Zugangskontrollen, ein Patch-Management-Prozess und eine Art Asset-Inventar vorhanden sind, komprimieren Sie Dokumentations- und Formalisierungsarbeit – und bauen keine Sicherheitsmaßnahmen von Grund auf neu auf. Das ist ein grundlegend anderes Projekt als eines, bei dem Sie gleichzeitig MFA, Endpoint-Schutz und Lieferantenrisikomanagement einrichten und eine Informationssicherheitsrichtlinie entwerfen.
Die Phasenstruktur selbst ändert sich kaum zwischen einem 90-Tage-Sprint und einem 9-Monats-Rollout. Sie durchlaufen dieselben drei Phasen:
- Grundlagenphase – Scoping, Governance und Gap-Analyse gegenüber ISO 27001:2022 und Annex A
- Entwicklungsphase – Risikobeurteilung, Control-Mapping und Statement of Applicability
- Implementierungsphase – Einführung von Kontrollen, Schulung der Mitarbeitenden, Durchführung eines internen Audits und Vorbereitung auf die Zertifizierung
Was sich ändert, ist der Anteil paralleler versus sequenzieller Aufgaben und die eingeplanten Puffer für Iterationen.
Der häufigste Blocker ist nicht technischer, sondern organisatorischer Natur. Projekte geraten ins Stocken, wenn niemand das Risikoregister verantwortet, wenn der Anwendungsbereich mitten im Projekt ausgeweitet wird, weil jemand darauf besteht, eine neue Geschäftseinheit einzubeziehen, oder wenn Abteilungsleiter das ISMS als IT-Initiative statt als organisationsweites Vorhaben betrachten. Jeder dieser Faktoren kann aus einem straffen 90-Tage-Plan einen 6-monatigen Kraftakt machen – bei gleichem tatsächlichem Arbeitsaufwand.
Voraussetzungen und eine Planungs-Checkliste, bevor Sie die Uhr starten
Bevor Sie ein einziges Verfahren schreiben oder eine Gap-Analyse durchführen, müssen vier Dinge geklärt sein. Das Überspringen dieser Phase ist der häufigste Grund, warum ISO-27001-Projekte ihren Zeitplan überschreiten.
- Executive Sponsorship schriftlich absichern. Ein Projektcharter sollte den Executive Sponsor, die ISMS-Leitung, die Budgetverantwortung und eine RACI-Matrix benennen, die für jeden wesentlichen Workstream festhält, wer Verantwortlich, Rechenschaftspflichtig, Konsultiert und Informiert ist. Legen Sie einen Steering-Committee-Rhythmus fest – wöchentlich beim Fast-Track, zweiwöchentlich oder monatlich beim längeren Rollout.
- Anwendungsbereich und Ausschlüsse explizit definieren. Halten Sie schriftlich fest, welche Geschäftsbereiche, Standorte, Systeme und Dritte innerhalb der ISMS-Grenze liegen – und ebenso wichtig: welche nicht. Eine vage Anwendungsbereichsbeschreibung ist der Ursprung von Problemen beim Zertifizierungsaudit Monate später.
- Die Norm beschaffen und ein Dokumenten-Repository einrichten. Kaufen Sie ISO 27001:2022 und ISO 27002:2022 direkt und verlassen Sie sich nicht auf Zusammenfassungen. Richten Sie ein zentrales Repository (SharePoint, Confluence oder ein dediziertes GRC-Tool) ein, bevor Sie mit der Dokumentenerstellung beginnen – nicht danach.
- Baseline-Awareness-Training für das Kernteam durchführen. Jeder, der am Projekt beteiligt ist – nicht nur die ISMS-Leitung –, muss die Annex-A-Struktur und den Zweck eines Statement of Applicability verstehen, bevor Woche 1 beginnt.
Die technische Mindestbasis für einen realistischen Fast-Track umfasst Zugangskontrollrichtlinien, eine Form von Protokollierung, einen Patch-Rhythmus und eine Asset-Liste – auch wenn diese unvollständig ist. Wenn nichts davon vorhanden ist, ist eine 12-Wochen-Roadmap nicht realistisch. Planen Sie 6 bis 12 Monate ein und behandeln Sie die Wochen 1 bis 4 als den Zeitraum, in dem Sie diese Basis aufbauen – anstatt sie zu dokumentieren.
Praxis-Tipp: Richten Sie Ihr Dokumenten-Repository und die Zugriffsberechtigungen vor dem Kickoff-Meeting ein, nicht während Woche 1. Teams verlieren ganze Tage mit Diskussionen darüber, wer diesen Ordner bearbeiten darf – Diskussionen, die niemals hätten stattfinden sollen.
Tag 1 bis 30: Die Grundlagenphase – Woche für Woche
Die ersten 30 Tage bestimmen die Richtung für alles, was danach kommt. Wer diese Phase schlampig angeht, verbringt die Wochen 5 bis 12 damit, Scope- und Governance-Probleme zu beheben, statt Kontrollen aufzubauen.
- Woche 1: Kickoff und Governance. Formellen Kickoff durchführen, Charter finalisieren, RACI-Matrix zuweisen, Dokumenten-Repository einrichten und initiales ISO-27001-Awareness-Training für das Kernprojektteam durchführen.
- Woche 2: Kontext und Anwendungsbereich. Organisatorischen Kontext dokumentieren, interessierte Parteien (Behörden, Kunden, Versicherer) identifizieren, formelle Anwendungsbereichsbeschreibung erstellen und mit einem ersten Asset-Register beginnen, das Personen, Systeme und Daten erfasst.
- Woche 3: Gap-Analyse. Klauselweise Bewertung gegenüber den Managementklauseln von ISO 27001:2022 und allen Annex-A-Kontrollen durchführen. Eine strukturierte, time-geboxt durchgeführte Gap-Analyse mit einer einfachen Rot/Amber/Grün-Bewertung verhindert, dass dieser Schritt zu einem offenen Audit wird, das einen ganzen Monat in Anspruch nimmt.
- Woche 4: Richtlinie und Executive-Freigabe. Informationssicherheitsrichtlinie entwerfen, Rollen und Verantwortlichkeiten für das ISMS definieren, messbare Sicherheitsziele festlegen und formelle Executive-Freigabe für all dies einholen.
Bis Tag 30 sollten Sie einen unterzeichneten Charter, eine dokumentierte Anwendungsbereichsbeschreibung, eine abgeschlossene Gap-Analyse mit RAG-bewerteten Befunden und eine genehmigte Informationssicherheitsrichtlinie in Ihrem Repository haben. Das ist die Abnahmekriterien. Fehlt eines dieser vier Dokumente oder befindet es sich noch im Entwurfsstadium, gehen Sie noch nicht in die Risikobeurteilung über. Schließen Sie zuerst die Grundlage ab.
Roadmaps, die auf einer 90-Tage-/12-Wochen-Struktur aufbauen, funktionieren für KMU mit dedizierten Ressourcen und vorhandenen Basiskontrollenmaßnahmen, aber größere oder weniger reife Organisationen benötigen in der Regel 4 bis 12 Monate, um dasselbe Terrain ordentlich abzudecken. Ein längerer Zeitplan ist keine Schande; wer eine Gap-Analyse überstürzt, um ein willkürliches 30-Tage-Ziel zu erreichen, schiebt dieselben ungelösten Probleme nur in die Wochen 5 bis 8, wo sie schwerer zu beheben sind.
Tag 31 bis 60: Risikobeurteilung, SoA und Kernverfahren
In dieser Phase findet der größte Teil der intellektuellen Schwerarbeit statt – und hier fallen nachlässige Abkürzungen beim externen Audit am härtesten auf.
Beginnen Sie mit der Entwicklung einer Risikobewertungsmethode, die einfach genug ist, damit jedes Teammitglied sie konsistent anwenden kann. Eine 5×5-Wahrscheinlichkeits-/Auswirkungs-Matrix mit klar definierten Bewertungskriterien funktioniert für die meisten Organisationen. Dieser Schritt wird häufig überkompliziert: Auditoren interessieren sich weniger für methodische Raffinesse als dafür, ob Sie Ihre eigene Methode konsistent angewendet haben.
Anschließend:
- Assets nach Schutzbedarf und Geschäftskritikalität klassifizieren – auf Basis des in Woche 2 begonnenen Registers.
- Realistische Bedrohungen und Schwachstellen je Asset-Kategorie identifizieren, nicht je einzelnem Asset, um das Register handhabbar zu halten.
- Jedes Risiko nach Ihrer Methode bewerten und eine Behandlungsoption festlegen: akzeptieren, mitigieren, transferieren oder vermeiden.
- Jedes behandelte Risiko einer spezifischen Annex-A-Kontrolle (oder einer eigenen Kontrolle, falls keine passt) zuordnen und für jede ausgeschlossene Annex-A-Kontrolle eine einzeilige Begründung verfassen.
Diese Mapping-Übung erzeugt Ihr Statement of Applicability, das als Hauptindex dient, mit dem Auditoren jede Entscheidung zu einer dokumentierten Begründung zurückverfolgen. Die Entwicklung einer dokumentierten Risikobewertungsmethode und die Erstellung eines SoA, das Risiken auf Annex-A-Kontrollen abbildet, steht im Zentrum des gesamten Zertifizierungsprozesses – nicht als nachträglicher Gedanke am Ende.
Sobald der SoA entworfen ist, priorisieren Sie Verfahren für die Kontrollen mit den höchsten Risikobewertungen: Zugriffskontrolle, Incident Response und Backup/Recovery stehen typischerweise ganz oben. Schreiben Sie jedes Verfahren von Anfang an mit integrierter Nachweiserfassung. Wenn ein Verfahren quartalsweise Zugriffsüberprüfungen vorsieht, sollte es auch festlegen, wo die Freigabe der Überprüfung abgelegt wird.
Praxis-Tipp: Entwerfen Sie Verfahren und Nachweisvorlagen gemeinsam, nicht nacheinander. Ein Verfahren ohne passende Nachweisvorlage ist eine Richtlinie, die niemand sechs Monate später beweisen kann, dass sie eingehalten wurde.
Tag 61 bis 90: Implementierung, Schulung und Zertifizierungsvorbereitung
In dieser Phase entwickelt sich das ISMS vom Dokumentierten zum Nachweisbaren. Auditoren zertifizieren keine Unterlagen – sie zertifizieren Nachweise dafür, dass die Unterlagen die Realität widerspiegeln.
Beginnen Sie mit der Implementierung von Kontrollen in der Reihenfolge, die Ihr Risikobehandlungsplan vorgegeben hat, und bauen Sie die Nachweiskette dabei auf – anstatt sie nachträglich zu rekonstruieren:
- Technische und verfahrensbezogene Kontrollen aus dem Behandlungsplan einführen und dabei Abschlussdaten und Verantwortliche für jede Kontrolle festhalten.
- Nachweisordner oder ein GRC-Tool einrichten, das am SoA ausgerichtet ist, sodass jede Kontrolle einem konkreten Nachweis zugeordnet ist.
- Rollenbasierte Schulungen einführen – allgemeines Awareness-Training für alle, vertiefte technische Schulung für Administratoren und Entwickler – und unterzeichnete Anwesenheitsnachweise aufbewahren.
- Schulungsabschluss gegen eine Frist verfolgen; unvollständige Schulungsnachweise sind ein routinemäßiger Befund bei Stage-1-Audits.
Wenn Kontrollen in Betrieb sind und Nachweise gesammelt werden, wechseln Sie zu internem Audit und Management Review:
- Internen Audit-Scope definieren, der alle im SoA beanspruchten Annex-A-Kontrollen abdeckt – keine Stichproben.
- Audit-Plan und -Zeitplan erstellen, idealerweise mit einer Person außerhalb der zu auditierenden Abteilung, um Unabhängigkeit zu wahren.
- Jede festgestellte Nichtkonformität protokollieren, einen Verantwortlichen für die Korrekturmaßnahme benennen und eine Behebungsfrist setzen.
- Einen formellen Management Review mit Eingaben aus Audit-Ergebnissen, Risikoregisterstatus und Zielerreichung einberufen und getroffene Entscheidungen dokumentieren.
- Das vollständige Dokumentationspaket – Richtlinien, Risikoregister, SoA, Verfahren, Schulungsunterlagen, Audit-Berichte – für die externe Auditorprüfung zusammenstellen.
Nachweisrückverfolgbarkeit ist für Auditoren wichtiger als ausgefeilte Richtliniensprache. Eine Protokollierungsrichtlinie mit drei Monaten tatsächlicher Zugriffsüberprüfungs-Freigaben dahinter wird jedes Mal eine tadellos formulierte Richtlinie ohne Belege übertreffen.
Ein 12-Wochen-Zeitplan, den Sie in Ihren eigenen Plan übernehmen können
Hier ist, wie sich die drei Phasen Woche für Woche aufschlüsseln, mit dem Deliverable, das jede Woche liefern muss.
| Woche | Schwerpunkt | Wichtigstes Deliverable |
|---|---|---|
| 1 | Kickoff, Charter, RACI, Repository-Einrichtung | Unterzeichneter Projektcharter |
| 2 | Kontext, interessierte Parteien, Anwendungsbereich, Asset-Register (v1) | Dokumentierte Anwendungsbereichsbeschreibung |
| 3 | Klauselweise Gap-Analyse gegenüber Annex A | RAG-bewerteter Gap-Analyse-Bericht |
| 4 | Richtlinienentwurf, Rollen, Ziele, Executive-Freigabe | Genehmigte Informationssicherheitsrichtlinie |
| 5 | Entwicklung der Risikobewertungsmethode und Asset-Klassifizierung | Dokumentierte Risikobewertungsmethode |
| 6 | Bedrohungsidentifikation und Risikobewertung | Entwurf Risikoregister |
| 7 | Risikobehandlungsentscheidungen und Control-Mapping | Entwurf Statement of Applicability |
| 8 | Verfahrensentwurf für höchst priorisierte Kontrollen | Verfahren für Zugriffskontrolle und Incident Response |
| 9 | Kontrollenimplementierung und Nachweisvorlagen | Nachweiserfassungsrahmen in Betrieb |
| 10 | Schulungs-Rollout (allgemein und rollenbasiert) | Unterzeichnete Schulungsabschlussnachweise |
| 11 | Durchführung des internen Audits | Interner Audit-Bericht mit Befunden |
| 12 | Management Review und Dokumentationspaket | Zertifizierungsreifes Nachweispaket |
Die Wochen 3, 7 und 11 sind die Meilenstein-Checkpoints, die als Go/No-Go-Gates behandelt werden sollten. Wenn die Gap-Analyse, der SoA-Entwurf oder die Befunde des internen Audits an einem dieser Punkte schwach aussehen, ist das das Signal, vor dem Weitergehen Puffer einzubauen – nicht danach.
Wie Personal und Budget in der Praxis aussehen
Die meisten Projektpläne unterschätzen den Zeitaufwand, weil sie ISO 27001 als eine Dokumentationsübung und nicht als operationale Veränderung betrachten. Es ist beides, und die operative Hälfte dauert länger.
Für einen 12-Wochen-Fast-Track sieht ein realistisches Personalmodell wie folgt aus:
- ISMS-Leitung: 50 bis 100 % ihrer Arbeitszeit während der gesamten 12 Wochen; diese Rolle kann kein Nebenprojekt sein.
- Executive Sponsor: 2 bis 4 Stunden pro Woche für Steering-Meetings und schnelle Risikobehandlungsentscheidungen.
- IT-Leitung: 25 bis 40 % ihrer Arbeitszeit, am stärksten in den Wochen 5 bis 10, wenn Kontrollen implementiert werden.
- Personal- und Facility-Vertreter: einige Stunden pro Woche für Schulungs-Rollout und physische Sicherheitskontrollen.
- Abteilungsvertreter: jeweils 2 bis 5 Stunden pro Woche während der Gap-Analyse- und Risikobeurteilungsphasen.
Kleine Organisationen (unter 50 Mitarbeitende) können dies häufig fast vollständig mit internem Personal plus einem Teilzeit-Berater für die initiale Risikobewertungsmethode und das interne Audit abwickeln. Mittelgroße und größere Organisationen kombinieren in der Regel interne Verantwortung mit einem externen Berater für die Gap-Analyse und einem zertifizierten Leitauditor für die Stage-1-Vorbereitung, da interne Auditoren, die die Kontrollen ihrer eigenen Abteilung prüfen, ein Unabhängigkeitsproblem schaffen.
Zu beachtende Kostentreiber: Berater-Tagessätze für Gap-Analyse und Audit-Unterstützung, Audit-Gebühren der Zertifizierungsstelle (in der Regel aufgeteilt auf Stage 1 und Stage 2) sowie etwaige Tooling-Kosten für eine GRC-Plattform. Eine rollenweise Aufschlüsselung der ISO-27001-Verantwortlichkeiten lohnt es sich zu prüfen, bevor Sie Ihre Personalannahmen festlegen, da die Unterschätzung der IT-Lead-Zeit einer der häufigsten Budgetfehler ist.
Praxis-Tipp: Budgetieren Sie Berater-Stunden separat von internen Mitarbeiterstunden in Ihrem Projektplan. Die Vermischung verschleiert die tatsächlichen Kosten externer Unterstützung, bis die Rechnung eintrifft.
Wie Sie beschleunigen, ohne das Audit zu gefährden
Kompression ist möglich, aber nur in Grenzen – und jede Abkürzung hat einen Trade-off, den es laut auszusprechen gilt, bevor Sie ihn eingehen.
- Die Gap-Analyse auf ein striktes 2- bis 3-Wochen-Fenster begrenzen und RAG-Priorisierung erzwingen statt exhaustiver Dokumentation jedes Befunds. Das ist der wirkungsvollste Beschleunigungshebel.
- Vorgefertigte SoA-Vorlagen und Control-Mapping-Bibliotheken verwenden, statt Begründungen für alle 93 Annex-A-Kontrollen auf der grünen Wiese zu formulieren.
- Risikobeurteilung und Verfahrensentwurf parallel durchführen statt sequenziell, sobald Ihre Risikobewertungsmethode feststeht.
- Toolgestützte Nachweiserfassung nutzen (automatisierte Protokollerfassung, Ticketsystem-Exporte) statt manueller Screenshot-Zusammenstellung.
Der Trade-off ist real: Zu aggressive Kompression verlagert das Audit-Risiko nach vorne – Nachweislücken tauchen beim Stage-1-Audit auf statt intern erkannt zu werden. Stärkere Abhängigkeit von externen Beratern zur Einhaltung eines engen Zeitplans erhöht auch die Kosten pro Woche, selbst wenn der Kalender kürzer wird. Behandeln Sie Beschleunigung als etwas, das Sie durch vorhandene Reife verdienen, nicht als etwas, das Sie durch bloßen Projektmanagement-Aufwand erzwingen.
Was ISO-27001-Projekte scheitern lässt – und was zuerst zu beheben ist
Projekte, die ins Stocken geraten, scheitern fast nie aus technischen Gründen. Sie scheitern, weil Nachweise inkonsistent sind, der Anwendungsbereich drei Wochen nach Beginn still und leise ausgeweitet wird oder niemand sagen kann, wer das Risikoregister tatsächlich verantwortet, sobald die anfängliche Aufbruchsstimmung nach dem Kickoff verflogen ist. Ich habe Teams gesehen, die tadellose Richtlinien entworfen haben und dann zwei Wochen vor Stage 1 feststellten, dass niemand die Schulungs-Freigabeblätter aufbewahrt hatte, deren Existenz jene Richtlinien versprochen hatten.
Wenn Sie nur eine Priorisierungsregel aus diesem gesamten Plan mitnehmen, dann diese: Bauen Sie SoA-Rückverfolgbarkeit und nachweisbare Kontroll-Evidenz auf, bevor Sie irgendetwas anderes polieren. Eine grobe Richtlinie, die durch sechs Monate realer Zugriffsüberprüfungsprotokolle gestützt wird, besteht ein Audit, das eine makellose Richtlinie ohne Nachweiskette nicht bestehen wird. Auditoren sind darauf trainiert, Fäden zu ziehen – und ein losgelöster Faden bei einer Kontrolle lässt sie bei der nächsten noch härter ziehen.
Stellen Sie vor Stage 1 sicher, dass Sie einem Auditor folgende Unterlagen ohne Hektik übergeben können: einen aktuellen SoA mit begründeten Ausschlüssen, ein Risikoregister mit Behandlungsentscheidungen und Datumsangaben, Schulungsnachweise, die dem in Ihrer Richtlinie festgelegten Rhythmus entsprechen, und mindestens einen abgeschlossenen internen Audit-Zyklus mit geschlossenen Korrekturmaßnahmen. Alles andere in Ihrem Dokumentationspaket ist weniger wichtig als diese vier.
— Martin
Budget und Zeitplan mit realen Zahlen planen, nicht mit Schätzungen
Die meisten ISO-27001-Projektpläne scheitern in der Budgetierungsphase, nicht in der Umsetzungsphase – weil das Management einen Zeitplan auf Basis einer generischen Vorlage genehmigt hat, statt auf Zahlen, die spezifisch für Ihre Unternehmensgröße, Branche und vorhandene Sicherheitsreife sind.
Das Readiness-Assessment von Ismscalculator erstellt in wenigen Minuten eine maßgeschneiderte Kosten- und Aufwandsschätzung, die an Unternehmen Ihrer Größe und Branche benchmarkt ist – damit Sie keinen 12-Wochen-Zeitplan vor Ihrem CFO mit nichts als einem Blogbeitrag als Grundlage verteidigen müssen. Führen Sie einen Reifegrad-Check über alle vier ISO/IEC 27001:2022 Control-Themen durch, exportieren Sie den resultierenden Zeitplan als anpassbares Gantt-Diagramm, das Ihr Steering Committee tatsächlich reviewen kann, und speichern Sie mehrere Szenarien, wenn Sie einen Fast-Track gegen einen phasenweisen Rollout abwägen. Wenn Sie nur eine schnelle Einschätzung benötigen, bevor Sie Projektressourcen bereitstellen, liefert der 2-Minuten-Readiness-Check Führungskräften ein schnelles Signal, um einen Charter zu genehmigen, ohne auf ein vollständiges Beratungsengagement warten zu müssen. Starten Sie mit dem Readiness-Assessment, speichern Sie Ihre Schätzung und bringen Sie sie als Ausgangsbasis in Ihr erstes Steering-Committee-Meeting ein, von der alle arbeiten.
Quellen
Die ISO-27001-Implementierungs-Roadmap von GLOCERT International legt die 30/60/90-Tage-Struktur dar, auf der dieser Artikel aufbaut, einschließlich realistischer Zeitplanvariationen nach Organisationsgröße. Der Implementierungs-Roadmap-Leitfaden von Copla behandelt time-geboxt durchgeführte Gap-Analysen und RAG-Bewertungen ausführlicher. Der ISACA-Journalbeitrag zur Planung und Implementierung von ISO 27001 bleibt eine der klarsten Erläuterungen dafür, wie Risikobeurteilung mit dem SoA zusammenhängt. Speziell zur Nachwesvorbereitung bietet die Risikobeurteilungs-Checkliste von tekRESCUE ein praktisches Acht-Schritte-Framework, das es wert ist, mit der eigenen Methode abgeglichen zu werden. Wenn Sie einen längeren Überblick darüber möchten, wie ein vollständiger Zeitplan von Anfang bis Ende aussieht, sind die Implementierungs-Timeline-Aufschlüsselung und die 80-schrittigen Zertifizierungs-Checkliste von Ismscalculator beide darauf ausgelegt, direkt mit dem obigen Plan kombiniert zu werden.
- ISO 27001 Implementation Roadmap: 30-60-90 Day & 12-Week Plan
- Planning for and Implementing ISO 27001