ISO 27001 pragmatisch einführen: 90-Tage-Fahrplan für den Mittelstand

Problem

Die Geschäftsleitung hat "wir machen ISO 27001" beschlossen, meist weil ein Kunde, eine Ausschreibung oder eine Konzernmutter das verlangt. Die IT-Leitung hat 20 bis 100 Mitarbeitende zu betreuen, kein eigenes GRC-Team (GRC = Governance, Risk und Compliance, also die zentrale Steuerung von Regeln, Risiken und Nachweispflichten), kein Budget für sechsstellige Beratung, und soll "mal anfangen". Zwei Fehler sind typisch: den Scope (Geltungsbereich des Zertifikats) zu groß ziehen (ganze Firma, alle 93 Annex-A-Controls gleichzeitig) oder halbherzig starten und nach sechs Monaten feststellen, dass nichts prüfbar ist. Der Weg zum Zertifikat dauert in dieser Größe realistisch 12 bis 18 Monate; die ersten 90 Tage entscheiden, ob die restliche Strecke strukturiert läuft.

Für wen ist das? Für IT-Leitung im Mittelstand, die ISO 27001 ohne großes GRC-Team einführen soll.

Kurze Antwort

Behandeln Sie die ersten 90 Tage als drei Phasen zu je 30 Tagen. Ziel ist Pre-Audit-Reife, nicht das Zertifikat. Ein kleiner, sauber abgegrenzter Geltungsbereich schlägt einen großen mit Lücken.

• Tag 1 bis 30 - Fundament: Scope, Asset-Inventar, Risiko-Register und Statement of Applicability (SoA, die Liste, welche Maßnahmen gelten).
• Tag 31 bis 60 - Regeln: zwölf gelebte Policies (Richtlinien), darunter Zugriffsverwaltung, Incident-Response (Reaktion auf Sicherheitsvorfälle), Change- und Lieferanten-Management.
• Tag 61 bis 90 - Nachweise: Evidenz sammeln, erstes internes Audit, Management-Review und Pre-Audit (Stage 1) bei einer Zertifizierungsstelle.
• Ergebnis Tag 90: pre-audit-reif, nicht zertifiziert. Stage 2 folgt zwei bis vier Monate später.
• Wichtigste Falle: Policies auf Papier, die im Alltag niemand kennt - das gibt Audit-Minuspunkte.

Tiefgang

Tag 1 bis 30: Scope, Assets, Risiken, SoA

Scope-Festlegung. Nicht die ganze Firma. Der ISMS-Scope (ISMS = Information Security Management System, das gesteuerte Regelwerk für Informationssicherheit) ist der Perimeter, für den das Zertifikat gilt. Typische Schnitte im Mittelstand: ein Produktbereich, ein Standort, ein Kundenkreis. Alles andere bleibt bewusst draußen und wird so im Scope-Statement dokumentiert. ISO/IEC 27001:2022 Abschnitt 4.3 verlangt, dass Schnittstellen zu nicht-eingeschlossenen Teilen dokumentiert werden, nicht dass alles eingeschlossen ist.

Asset-Inventar. Alle Informations-Assets (schützenswerte Werte) im Scope: Anwendungen, Datenbanken, Repositories (Code-Ablagen), Kundendaten, Endgeräte-Klassen, Identity-Systeme (Systeme zur Verwaltung von Benutzerkonten). Mit Eigentümer pro Asset (eine Person), Klassifizierung (öffentlich / intern / vertraulich / streng vertraulich) und Verarbeitungsstandort. Tabelle reicht, CMDB (Configuration Management Database, eine zentrale Bestandsdatenbank) nicht nötig.

Risiko-Register. ISO/IEC 27005:2022 lässt qualitative Methoden ausdrücklich zu. Eine 5x5-Matrix (Eintrittswahrscheinlichkeit mal Schaden) ist genug. Pro Asset zwei bis fünf Risiken mit Besitzer und Behandlungsentscheidung (akzeptieren, mitigieren, transferieren, vermeiden). Ziel: 30 bis 80 Risiken im Register.

Statement of Applicability. Die SoA listet alle 93 Controls (Maßnahmen) aus Annex A der 27001:2022, mit vier Angaben pro Zeile: anwendbar ja/nein, Begründung für Ausschluss, Umsetzungsstand, Verweis auf Policy oder Verfahren. Der Auditor beginnt mit diesem Dokument. Gegenüber ISO 27001:2013 ist die 2022er-Version auf 93 Controls kondensiert (vorher 114), neu strukturiert in vier Gruppen (Organisational, People, Physical, Technological), mit elf neuen Controls zu Threat Intelligence (Auswertung aktueller Bedrohungslagen), Cloud-Security, Data Masking (Verschleierung sensibler Daten) und mehr.

Tag 31 bis 60: Policies, die im Alltag wirken

Die Falle heißt "Papier-Policies ohne Umsetzung". Zwölf Policies reichen, wenn sie gelebt werden:

1. Informationssicherheits-Leitlinie, vom Management unterschrieben
2. Zugriffsverwaltung: Joiner-Mover-Leaver-Prozess (geregeltes Anlegen, Ändern und Entziehen von Zugängen bei Ein-, Um- und Austritt) mit Fristen
3. Passwort- und Authentifizierungs-Policy: Passkey-first (passwortlose Anmeldung als Standard), MFA-Pflicht (Mehr-Faktor-Authentifizierung, zweiter Nachweis zusätzlich zum Passwort) für Admin-Zugänge, kein SMS-TOTP (Einmalcodes per SMS gelten als unsicher)
4. Datenklassifizierung und Handling: vier Stufen, konkrete Regeln pro Stufe
5. Endgeräte-Richtlinie: Verschlüsselung verpflichtend, MDM (Mobile Device Management, zentrale Geräteverwaltung) oder gleichwertig
6. Lieferanten-Management: Register, Risikobewertung pro Kritikalität, Exit-Plan für die kritischsten
7. Change-Management: Review-Pflicht für Produktions-Änderungen, Trennung Entwicklung und Betrieb
8. Incident-Response: schriftlicher Plan mit Rollen, Eskalationsmatrix, Meldefristen. Jährliche Tabletop-Übung (Trockenübung eines Vorfalls am Tisch)
9. Backup und Wiederanlauf: RTO/RPO (maximal tolerierte Ausfallzeit bzw. tolerierter Datenverlust), Offsite-Backups, Restore-Test halbjährlich
10. Logging und Monitoring: wer loggt was, wohin, wie lange, wer liest
11. Kryptographie: erlaubte Verfahren, Schlüsselverwaltung, Zertifikats-Lebenszyklus
12. Schulung und Awareness: Onboarding, Refresher, Phishing-Tests

Jede Policy bekommt einen Besitzer, ein Review-Intervall (12 Monate Standard) und Freigabe durch die Geschäftsleitung. Versionskontrolle nicht vergessen.

Tag 61 bis 90: Nachweise, internes Audit, Pre-Audit

Eine Policy ohne Nachweis ist beim Audit nichts wert.

Evidenz-Sammlung. Pro Control: welche Artefakte belegen die Anwendung? Access-Review-Exporte (Protokolle der regelmäßigen Zugriffsprüfung), Backup-Test-Protokolle, Change-Tickets mit Reviewer-Spur, Audit-Logs (Protokolle sicherheitsrelevanter Ereignisse) mit manipulationssicherer Ablage. Evidenz ohne Zeitstempel ist kein Nachweis. Häufigste Fehlstelle: Audit-Logs fehlen oder sind nachträglich editierbar.

Erstes internes Audit. Ein interner Auditor (nicht der Policy-Autor) geht den Scope durch. Pflicht laut Abschnitt 9.2. "Keine Abweichungen gefunden" bedeutet unzureichende Unabhängigkeit.

Management-Review. Abschnitt 9.3 verlangt eine dokumentierte Geschäftsleitungs-Sitzung zu ISMS-Wirksamkeit, Audit-Ergebnissen und Ressourcenbedarf.

Pre-Audit / Stage-1-Audit. Termin bei einer DAkkS-akkreditierten Zertifizierungsstelle (DAkkS = Deutsche Akkreditierungsstelle, die offizielle Stelle, die Zertifizierer zulässt). Stage 1 ist Dokumenten-Review plus Vor-Ort-Begehung, kein Zertifikat; deckt auf, was bis Stage 2 fehlt. Tag 90 ist das realistische Ziel für Stage 1, nicht Stage 2. Danach: Stage 2 zwei bis vier Monate später, jährliche Surveillance-Audits (Überwachungs-Audits), Re-Zertifizierung alle drei Jahre.

Häufige Fallen

Scope zu groß. Kleiner Scope mit sauberer Abgrenzung ist ein gutes Zertifikat; großer Scope mit Lücken ist keins.

Papier-Policies ohne Umsetzung. Eine Policy, die beim Interview niemand kennt, ist Audit-Minuspunkte.

Audit-Logs fehlen oder sind editierbar. Der häufigste Technik-Befund. Logs müssen vollständig, zeitlich geordnet, manipulationssicher sein.

Lieferanten unter den Tisch. Cloud-Anbieter, SaaS-Tools, externe Entwickler sind Teil des Scopes. Fehlt das Register, fehlt Control A.5.19.

Abgelehnte Alternativen

TISAX. Pflichtstandard der deutschen Automobilindustrie, an ISO 27001 orientiert, mit automotive-spezifischen Profilen. Sinnvoll für OEM- oder Tier-1-Lieferanten; branchenoffen besser erst ISO 27001, dann TISAX.

BSI IT-Grundschutz. Kataloggesteuert, konkrete Bausteine, starke Anerkennung im öffentlichen Sektor und bei KRITIS (kritische Infrastrukturen). Der Aufwand ist spürbar höher als reiner ISO-27001-Weg, der Gegenwert die Akzeptanz in Behörden-Ausschreibungen. Für privatwirtschaftlichen Mittelstand oft zu schwer.

ISO 27701 als Add-on. Privacy-Erweiterung des ISMS. Erst nach dem 27001-Zertifikat angehen, nicht parallel. Ein halbfertiges ISMS mit draufgesetztem Privacy-Layer fällt bei beiden Audits durch.

Was Sie jetzt tun sollten

1. Schneiden Sie den Scope bewusst klein. Legen Sie in der ersten Woche einen Geltungsbereich fest, den Sie in 90 Tagen sauber belegen können - lieber ein Produktbereich vollständig als die ganze Firma lückenhaft.
2. Starten Sie das Asset-Inventar und Risiko-Register als einfache Tabelle. Jeder Eintrag braucht genau einen verantwortlichen Eigentümer. Verzichten Sie auf teure Tools, solange eine Tabelle reicht.
3. Schreiben Sie Policies erst, wenn der gelebte Prozess dahintersteht. Eine Richtlinie ohne Umsetzung ist im Audit wertlos. Beginnen Sie mit Zugriffsverwaltung, Incident-Response und Backup - dort hängt am meisten dran.
4. Bauen Sie von Anfang an manipulationssichere, zeitgestempelte Nachweise auf. Klären Sie früh, wie Audit-Logs vollständig, geordnet und unveränderbar abgelegt werden - das ist der häufigste Technik-Befund.
5. Holen Sie sich früh einen Stage-1-Termin bei einer DAkkS-akkreditierten Stelle. Die Terminlage bestimmt mit, wann Sie das Zertifikat realistisch erreichen, und der Stage-1-Befund zeigt Ihre Lücken vor dem entscheidenden Stage 2.

Wie Dernium hier hilft

Dernium liefert keine ISMS-Beratung und kein Policy-Tool. Dernium liefert die technischen Bausteine, an denen typische Controls hängenbleiben:

• Datei-Handling-Policy technisch durchsetzbar: Dernium Scan (Multi-Engine-Virenprüfung), Dernium Clean (Metadaten- und Schadcode-Entfernung). Control A.8.7 (Protection against malware) mit Nachweis statt Policy-Text.
• Operational Monitoring für A.8.16: Dernium Watch für externe Infrastruktur, Zertifikats-Lebenszyklus, DNSSEC (kryptografisch abgesicherte DNS-Antworten), Routing-Anomalien. Evidenz-Quelle für das interne Audit.
• Sensible Kurznachrichten außerhalb des Mail-Kanals: Dernium Note. Brauchbar für Zugangsdaten-Übergabe während Incident-Response.
• Sicherheits-Meldestelle nach A.6.8 (Information security event reporting): startfertiges security.txt nach RFC 9116 aus dem kostenlosen Dernium Generator, gepaart mit einer dedizierten Mailbox oder einem internen Ticket-System. Belegt das in ISO-27001-Audits regelmäßig nachgefragte "wie kommen Schwachstellen-Hinweise von Forschenden bei Ihnen an?".

Verifikation

• ISO/IEC 27001:2022.
• ISO/IEC 27002:2022 (93 Controls im Annex A).
• ISO/IEC 27005:2022 (Risikomanagement).
• DAkkS-Datenbank akkreditierter Zertifizierungsstellen.
• BSI IT-Grundschutz-Kompendium.

Offene Punkte

Der 90-Tage-Plan zielt auf Pre-Audit-Reife, nicht Zertifizierung. Die Reststrecke hängt vom Stage-1-Befund und der Auslastung der Zertifizierungsstelle ab; realistisch Phase 2 zwei bis vier Monate nach Phase 1, Zertifikat sechs bis acht Wochen nach Phase 2. Zweite offene Frage: die elf neuen Controls der 2022er-Revision werden unterschiedlich streng gelesen. Cloud-Security (A.5.23) und Threat Intelligence (A.5.7) sind die beiden, bei denen Mittelständler im Phase 1 am häufigsten Nachbesserungen bekommen. Wer dort früh konkrete Nachweise aufbaut, spart sich die Nacharbeit.

Häufige Fragen

Wie lange dauert es bis zum ISO-27001-Zertifikat?

Für ein Unternehmen mit 20 bis 100 Mitarbeitenden ohne eigenes GRC-Team sind 12 bis 18 Monate realistisch. Die ersten 90 Tage bringen Sie zur Pre-Audit-Reife (Stage 1). Stage 2, das eigentliche Zertifizierungs-Audit, folgt zwei bis vier Monate später, das Zertifikat dann sechs bis acht Wochen danach. Die genaue Dauer hängt stark vom Stage-1-Befund und der Terminauslastung der Zertifizierungsstelle ab.

Muss der Geltungsbereich (Scope) die ganze Firma umfassen?

Nein, und das ist einer der wichtigsten Hebel. Sie dürfen den Scope auf einen Produktbereich, einen Standort oder einen Kundenkreis begrenzen, solange Sie die Schnittstellen zu den ausgeschlossenen Teilen sauber dokumentieren. Ein kleiner, vollständig belegbarer Geltungsbereich führt zu einem gültigen Zertifikat. Ein zu großer Scope mit Lücken fällt durch.

Reichen geschriebene Richtlinien für die Zertifizierung aus?

Nein. Eine Policy zählt im Audit nur, wenn der dahinterliegende Prozess gelebt wird und sich mit zeitgestempelten Nachweisen belegen lässt. Fragt der Auditor einen Mitarbeiter und niemand kennt die Regel, gibt das Minuspunkte. Schreiben Sie deshalb erst die Richtlinie zu Prozessen, die tatsächlich laufen, und sammeln Sie von Anfang an Evidenz.

Was ist der häufigste technische Befund im Audit?

Fehlende oder nachträglich veränderbare Audit-Logs. Protokolle sicherheitsrelevanter Ereignisse müssen vollständig, zeitlich geordnet und manipulationssicher abgelegt sein. Evidenz ohne Zeitstempel gilt nicht als Nachweis. Klären Sie früh, wohin geloggt wird, wie lange aufbewahrt wird und wer die Logs auswertet.

ISO 27001 oder lieber BSI IT-Grundschutz?

Für den privatwirtschaftlichen Mittelstand ist ISO 27001 meist der pragmatischere Weg, weil der Aufwand geringer und die internationale Anerkennung hoch ist. BSI IT-Grundschutz ist kataloggesteuert, aufwendiger und vor allem dann sinnvoll, wenn Sie an Behörden-Ausschreibungen teilnehmen oder zur kritischen Infrastruktur gehören. TISAX ist die richtige Wahl, wenn Sie die deutsche Automobilindustrie beliefern.