ISO-27001-Readiness: Was wirklich dazugehört

ISO/IEC 27001 wird häufig als Technologie-Checkliste missverstanden. Das ist sie nicht. Der Standard zertifiziert ein Managementsystem — ein ISMS: den fortlaufenden Prozess, mit dem eine Organisation ihre Informationssicherheitsrisiken identifiziert, entscheidet, was sie dagegen tut, und nachweist, dass diese Entscheidungen tatsächlich umgesetzt werden. Firewalls und Verschlüsselung kommen darin vor — aber nur als Ergebnisse dieses Prozesses. Dieses Verständnis rahmt die Readiness-Arbeit neu: Die Frage eines Auditors lautet selten „Haben Sie X?" und fast immer „Woher wissen Sie, dass X funktioniert?".

Den ISMS-Scope bewusst festlegen

Die erste echte Entscheidung ist der Scope: welche Teile der Organisation, welche Services, welche Standorte und welche Informationswerte das ISMS abdeckt. Zu breit gescoped verpflichten Sie sich, jeden Winkel des Unternehmens auditieren zu lassen — auch die ohne Kundendaten und ohne Appetit auf Prozesse. Zu eng gescoped wird das Zertifikat irreführend: Kunden lesen „ISO 27001 zertifiziert", während der Service, den sie tatsächlich nutzen, außerhalb der Grenze liegt. Ein verteidigbarer Scope folgt den Daten: die Systeme, die die Informationen speichern oder verarbeiten, die Ihren Kunden wichtig sind, plus alles mit administrativem Zugriff darauf. Schreiben Sie das Scope-Statement früh; jede folgende Entscheidung hängt daran.

Die Risikobewertung ist der Motor

Alles in einem ISMS führt auf die Risikobewertung zurück. Die Mechanik ist geradlinig: Informationswerte inventarisieren, für jeden identifizieren, was schiefgehen könnte — Verlust von Vertraulichkeit, Integrität oder Verfügbarkeit — und jedes Risiko gegen selbst definierte Kriterien für Eintrittswahrscheinlichkeit und Auswirkung bewerten. Entscheidend ist, dass die Bewertung Ihre ist: Ein generisches, aus einem Template kopiertes Risikoregister übersteht keinen Auditor, der fragt, warum Ransomware für ein SaaS-Unternehmen genauso scored wie für eine Fabrik.

Jedes Risiko bekommt dann eine Behandlungsentscheidung — mit Kontrollen mitigieren, transferieren, vermeiden oder akzeptieren, mit Freigabe von jemandem, der akzeptieren darf. Diese Entscheidungen speisen das Statement of Applicability (SoA): das Dokument, das Ihre gewählten Kontrollen gegen das Referenzset des Standards mappt und jede Aufnahme und jeden Ausschluss begründet. Das SoA ist das meistgelesene Dokument im Audit; behandeln Sie es entsprechend.

Annex A in der Revision 2022

Der aktuelle Standard ISO/IEC 27001:2022 hat die Referenzkontrollen in 93 Kontrollen über vier Themen umstrukturiert: organisatorisch (37 — Richtlinien, Lieferantenmanagement, Incident Management, Rechtskonformität), Menschen (8 — Screening, Schulung, Disziplinarprozess, Remote-Arbeit), physisch (14 — Gebäude, Ausrüstung, Medien) und technologisch (34 — Zugriffskontrolle, Kryptographie, Logging, Backup, sichere Entwicklung). Die Revision 2022 ergänzte zudem Kontrollen, die direkt auf modernen Betrieb mappen: unter anderem Threat Intelligence, Cloud-Service-Sicherheit, Konfigurationsmanagement, Data Leakage Prevention und Web-Filtering.

Zwei Dinge bringen Teams hier zu Fall. Annex A ist ein Referenzset, keine To-do-Liste — Sie implementieren die Kontrollen, die Ihre Risikobewertung verlangt, und begründen den Rest im SoA als nicht anwendbar. Und die meisten Engineering-Organisationen entdecken, dass sie viele der technologischen Kontrollen bereits betreiben; was fehlt, ist die dokumentierte Richtlinie darüber und die Evidenzspur darunter.

Evidenz ist eine Kultur, kein Endspurt

Der Unterschied zwischen einem reibungslosen und einem elenden Audit ist, ob Evidenz als Nebenprodukt normaler Arbeit existiert. Access Reviews in Tickets festgehalten. Onboarding- und Offboarding-Checklisten tatsächlich abgehakt. Change Management sichtbar in Pull Requests und Pipeline-Logs. Backup-Restores nach Plan getestet, mit aufbewahrtem Testergebnis. Log-Retention und Alerting im Monitoring-Stack demonstrierbar — dieselbe Infrastruktur, auf der ein SIEM-System aufbaut, leistet Doppeldienst als Audit-Evidenz.

Teams, die Evidenz als vierteljährlichen Sammelsprint behandeln, fabrizieren in der Woche vor dem Audit Screenshots — was Auditoren sofort erkennen. Teams, die Evidenz in ihr Tooling verdrahten — Tickets, CI, IaC, Exporte des Identity Providers — nehmen die Anforderungsliste kaum wahr. Die zweite Haltung ist, nicht zufällig, auch die, in der die Kontrollen tatsächlich funktionieren.

Der Audit-Zyklus

Zertifizierung ist kein Einzelereignis. Das Erst-Audit kommt in zwei Stufen: Stage 1 prüft Ihre Dokumentation — Scope, Risikobewertung, SoA, Pflichtrichtlinien — und bestätigt die Audit-Reife; Stage 2 testet, ob das ISMS tatsächlich funktioniert — durch Interviews, stichprobenartige Records und Walkthroughs. Das Zertifikat gilt dann drei Jahre, mit Überwachungsaudits in den Zwischenjahren und voller Rezertifizierung am Zyklusende. Intern verlangt der Standard mindestens jährlich ein eigenes Audit-Programm und ein Management-Review — keine Formalitäten, sondern der Ort, an dem eine ehrliche Organisation ihre Nichtkonformitäten vor dem externen Auditor findet.

Planen Sie aus dem Stand realistische Kalenderzeit ein: typischerweise mehrere Monate, um das ISMS aufzubauen und operative Evidenz erzeugen zu lassen — Auditoren brauchen Historie, keine Absichten.

Wo wir stehen

Graf Clouds betreibt selbst ein ISO/IEC-27001-konformes ISMS — unsere ISO-27001-Dokumentation ist öffentlich einsehbar — die obige Anleitung spiegelt also Praktiken, die wir auf unseren eigenen Betrieb anwenden, keine Theorie. Wenn Sie sich auf die Zertifizierung vorbereiten und Unterstützung bei Scoping, Risikobewertung oder dem Aufbau der technischen Kontrollen und Evidenz-Pipelines hinter Annex A wollen, begleitet unser SecOps-Team die Readiness-Arbeit Ende-zu-Ende.

Gegen Ihre Accounts geprüft? Unser AWS Security Assessment deckt 98 Punkte ab, gemappt auf ISO 27001, SOC 2, NIS2 und DORA — Festpreis, Evidenz inklusive.