ISO/IEC 27001:2022 stellt Anforderungen in zwei Blöcken: Die Pflichtkapitel 4 bis 10 regeln das Managementsystem – Kontext, Führung, Planung, Unterstützung, Betrieb, Leistungsbewertung und Verbesserung. Der normative Anhang A ergänzt 93 Sicherheitsmaßnahmen in vier Themenfeldern, deren Anwendbarkeit jedes Unternehmen über die Risikoanalyse bestimmt und im Statement of Applicability begründet.
Wer die Norm zum ersten Mal aufschlägt, sieht rund 30 Seiten Anforderungstext plus Anhang – und fragt sich, was davon konkret zu tun ist. Die gute Nachricht: Die Struktur ist logisch, vieles ist Ermessenssache des Unternehmens, und die Norm verlangt weniger Papier, als ihr Ruf vermuten lässt. Die schlechte: Ohne Überblick verzettelt man sich schnell in Details, die im Audit niemand sehen will.
Dieser Artikel geht alle Anforderungen der ISO/IEC 27001:2022 durch – Kapitel für Kapitel, mit den Pflichtdokumenten und den Stellen, an denen Audits erfahrungsgemäß haken. Er ersetzt nicht die Lektüre der Norm, macht sie aber deutlich leichter.
Der Aufbau: sieben Pflichtkapitel plus Anhang A
Die verbindlichen Anforderungen stehen in den Kapiteln 4 bis 10. Sie folgen der Harmonized Structure aller ISO-Managementnormen – wer ISO 9001 kennt, erkennt das Muster sofort. Keines dieser Kapitel darf ausgeschlossen werden:
| Kapitel | Inhalt | Typische Nachweise im Audit |
|---|---|---|
| 4 – Kontext | Umfeld, interessierte Parteien, Geltungsbereich | Kontextanalyse, Scope-Dokument |
| 5 – Führung | Verantwortung der Leitung, Politik, Rollen | Sicherheitsleitlinie, Rollenbeschreibung |
| 6 – Planung | Risiken und Chancen, Risikobehandlung, Ziele | Risikoanalyse, SoA, Maßnahmenplan, Sicherheitsziele |
| 7 – Unterstützung | Ressourcen, Kompetenz, Awareness, Dokumentation | Schulungsnachweise, Dokumentenlenkung |
| 8 – Betrieb | Umsetzung und Steuerung der Maßnahmen | Betriebsnachweise, wiederholte Risikoanalyse |
| 9 – Bewertung | Überwachung, internes Audit, Managementbewertung | Kennzahlen, Auditbericht, Bewertungsprotokoll |
| 10 – Verbesserung | Nichtkonformitäten, Korrekturen, KVP | Maßnahmenliste, Wirksamkeitsprüfung |
Dazu kommt der normative Anhang A mit 93 Maßnahmen (Controls) in vier Themenfeldern: 37 organisatorische, 8 personenbezogene, 14 physische und 34 technologische. Anders als die Kapitel 4 bis 10 sind die Controls einzeln abwählbar – sofern das Unternehmen den Ausschluss nachvollziehbar begründet.
Kapitel 4 und 5: Kontext und Führung
Kapitel 4 verlangt, dass das Unternehmen sein Umfeld versteht: Welche internen und externen Themen beeinflussen die Informationssicherheit – etwa Abhängigkeit von Cloud-Diensten, Fachkräftemangel oder Kundenanforderungen? Welche interessierten Parteien stellen welche Erwartungen – Kunden, Gesetzgeber, Versicherer, Banken? Daraus leitet sich der Geltungsbereich des ISMS ab: Standorte, Organisationseinheiten und Dienstleistungen, für die das System gilt. Der Scope muss als dokumentierte Information vorliegen und wird später wörtlich auf dem Zertifikat stehen.
Kapitel 5 nimmt die Geschäftsleitung in die Pflicht – und zwar persönlich. Sie muss eine Informationssicherheitsleitlinie festlegen, Rollen und Befugnisse zuweisen, Ressourcen bereitstellen und die Wirksamkeit des ISMS aktiv einfordern. Delegieren lässt sich die Koordination, nicht die Verantwortung. Auditoren prüfen das im Gespräch mit der Geschäftsführung selbst: Wer dort nur auf den IT-Leiter verweist, hat ein Problem. Praktisch reichen eine unterschriebene Leitlinie von ein bis zwei Seiten, eine klare Benennung des Informationssicherheitsbeauftragten und sichtbares Engagement – etwa die Teilnahme an der Managementbewertung.
Kapitel 6: Planung – das anspruchsvollste Kapitel
Kapitel 6 ist das Herzstück und erfahrungsgemäß der aufwendigste Teil. Es verlangt drei Dinge:
- Risikoanalyse (6.1.2): Ein definiertes Verfahren mit Kriterien für Risikoakzeptanz, das bei Wiederholung vergleichbare Ergebnisse liefert. Risiken werden identifiziert, nach Eintrittswahrscheinlichkeit und Schadensausmaß bewertet und priorisiert – jeweils mit benanntem Risikoeigentümer.
- Risikobehandlung (6.1.3): Für jedes relevante Risiko wird entschieden: vermindern, vermeiden, übertragen oder akzeptieren. Die gewählten Maßnahmen werden mit Anhang A abgeglichen – so entsteht das Statement of Applicability (SoA), das für alle 93 Controls dokumentiert, ob sie anwendbar sind, warum, und wie der Umsetzungsstand ist.
- Sicherheitsziele (6.2): Messbare Ziele auf relevanten Ebenen, etwa: Wiederherstellungszeit kritischer Systeme unter vier Stunden, Phishing-Klickrate unter fünf Prozent, alle kritischen Patches innerhalb von 14 Tagen.
Seit der Fassung 2022 verlangt Kapitel 6.3 zusätzlich, dass Änderungen am ISMS geplant erfolgen – etwa bei Umzug, neuen Cloud-Diensten oder Zukäufen. Häufigster Auditbefund in Kapitel 6: Risikoanalyse und SoA passen nicht zusammen, weil beide unabhängig voneinander gepflegt wurden.
Kapitel 7: Unterstützung – Ressourcen, Kompetenz, Dokumentation
Kapitel 7 bündelt die Voraussetzungen, damit das ISMS funktionieren kann. Das Unternehmen muss Ressourcen bereitstellen, die nötigen Kompetenzen ermitteln und nachweisen – etwa durch Schulungen des Informationssicherheitsbeauftragten – und alle Mitarbeitenden für Sicherheitsthemen sensibilisieren. Awareness heißt konkret: Jeder kennt die Leitlinie, weiß, was er zur Sicherheit beiträgt, und kennt die Folgen von Verstößen. Ein jährliches Training plus dokumentierte Unterweisung neuer Mitarbeitender ist der übliche Weg; regelmäßige Phishing-Übungen sind nicht vorgeschrieben, aber ein starker Wirksamkeitsnachweis.
Der zweite Block ist die dokumentierte Information: Dokumente müssen gelenkt sein – auffindbar, aktuell, vor unbefugter Änderung geschützt, mit klarer Freigabe. Das klingt nach Bürokratie, lässt sich aber schlank lösen: ein Ablageort mit Versionsständen, eine kurze Übersicht, wer was freigibt, und ein jährlicher Review-Termin. Die Norm schreibt ausdrücklich kein Handbuch vor. Auditoren stören sich selten an zu wenig Papier – häufiger an veralteten Dokumenten, die dem gelebten Prozess widersprechen.
Kapitel 8: Betrieb – vom Plan zur gelebten Praxis
Kapitel 8 ist kurz, aber folgenreich: Es verlangt, dass die geplanten Maßnahmen tatsächlich umgesetzt und gesteuert werden. Drei Anforderungen stecken darin. Erstens die betriebliche Planung: Prozesse mit Sicherheitsbezug laufen kontrolliert ab, auch bei ausgelagerten Leistungen – wer seine IT an einen Dienstleister gibt, muss dessen Sicherheit vertraglich und praktisch im Griff haben. Zweitens die regelmäßige Wiederholung der Risikoanalyse: in geplanten Abständen, üblicherweise jährlich, sowie anlassbezogen bei wesentlichen Änderungen wie neuen Systemen, Standorten oder nach einem Sicherheitsvorfall. Drittens die Umsetzung des Risikobehandlungsplans mit dokumentierten Ergebnissen.
Im Audit ist Kapitel 8 der Moment, in dem sich zeigt, ob das ISMS lebt: Der Auditor lässt sich die Berechtigungsvergabe am System zeigen, prüft Protokolle von Backup-Tests, fragt Mitarbeitende nach dem Meldeweg für Vorfälle. Papierlage und Realität müssen übereinstimmen – eine Richtlinie, die vorschreibt, was niemand tut, ist im Zweifel schlimmer als gar keine, weil sie die Abweichung gleich mitliefert.
Kapitel 9 und 10: Messen, auditieren, verbessern
Kapitel 9 verlangt drei Prüfmechanismen. Erstens Überwachung und Messung: Das Unternehmen definiert selbst, welche Kennzahlen es erhebt – etwa offene Schwachstellen, Schulungsquote oder Zeit bis zur Vorfallbehebung. Zweitens interne Audits in geplanten Abständen: eine unabhängige Innenprüfung des ISMS, die vor dem Zertifizierungsaudit mindestens einmal vollständig gelaufen sein muss. Der interne Auditor darf nicht seine eigene Arbeit prüfen – kleine Unternehmen lösen das über Rollentrennung oder einen externen Dienstleister. Drittens die Managementbewertung: Die Geschäftsleitung bewertet mindestens jährlich anhand vorgegebener Themen – Auditergebnisse, Vorfälle, Kennzahlen, Risikolage, Ressourcen – ob das ISMS wirksam ist, und hält Entscheidungen schriftlich fest.
Kapitel 10 schließt den Kreis: Nichtkonformitäten werden erfasst, ihre Ursachen analysiert, Korrekturmaßnahmen umgesetzt und auf Wirksamkeit geprüft. Dazu kommt die Pflicht zur fortlaufenden Verbesserung. Auditoren sehen eine gepflegte Maßnahmenliste mit erledigten Einträgen ausgesprochen gern – sie ist der beste Beleg, dass der PDCA-Zyklus tatsächlich läuft.
Die Pflichtdokumente im Überblick
Die Norm verlangt dokumentierte Information an klar benannten Stellen. Für ein schlankes ISMS bedeutet das im Kern:
- Geltungsbereich des ISMS (Kapitel 4.3)
- Informationssicherheitsleitlinie (5.2)
- Verfahren und Ergebnisse der Risikoanalyse (6.1.2)
- Risikobehandlungsplan und Statement of Applicability (6.1.3)
- Sicherheitsziele (6.2)
- Nachweise zu Kompetenzen und Schulungen (7.2)
- Nachweise aus dem Betrieb, etwa Ergebnisse der Risikobewertungen (8.1–8.3)
- Ergebnisse aus Überwachung und Messung (9.1)
- Auditprogramm und Auditberichte (9.2)
- Ergebnisse der Managementbewertung (9.3)
- Nichtkonformitäten und Korrekturmaßnahmen (10.2)
Dazu kommen Richtlinien aus den umgesetzten Anhang-A-Controls – etwa zu Zugriffskontrolle, Lieferanten, Backup oder mobilem Arbeiten. Realistisch landet ein kleines Unternehmen bei 15 bis 25 Dokumenten. Alles darüber hinaus ist freiwillig und sollte einen erkennbaren Nutzen haben – sonst produziert es nur Pflegeaufwand und Widersprüche.
Typische Stolpersteine im Zertifizierungsaudit
Aus der Auditpraxis wiederholen sich bestimmte Befunde auffällig oft:
- SoA und Risikoanalyse widersprechen sich: Controls sind als umgesetzt markiert, tauchen aber in keiner Risikobehandlung auf – oder umgekehrt.
- Internes Audit fehlt oder ist zu dünn: Ein Rundgang ohne Bericht zählt nicht. Verlangt werden Auditprogramm, Kriterien, Ergebnisse und abgeleitete Maßnahmen.
- Managementbewertung ohne Substanz: Ein Einzeiler im Protokoll reicht nicht – die Pflichtthemen aus Kapitel 9.3 müssen erkennbar behandelt sein.
- Offboarding ungeregelt: Konten ausgeschiedener Mitarbeitender sind noch aktiv – ein Klassiker, der sich in Minuten prüfen lässt.
- Lieferanten vergessen: Cloud-Dienste und externe IT-Betreuer sind im Einsatz, aber weder bewertet noch vertraglich eingebunden.
- Kennzahlen ohne Konsequenz: Es wird gemessen, aber aus schlechten Werten folgt nichts.
Der rote Faden: Fast alle Stolpersteine betreffen die Verzahnung der Anforderungen, nicht einzelne fehlende Dokumente. Wer Risikoanalyse, SoA, Maßnahmen und Prüfungen als einen zusammenhängenden Kreislauf pflegt, besteht das Audit in aller Regel ohne größere Abweichungen.
Häufige Fragen
Alle Anforderungskapitel 4 bis 10 – Ausschlüsse sind dort nicht zulässig. Flexibel ist nur der Anhang A: Seine 93 Controls werden über die Risikoanalyse auf Anwendbarkeit geprüft, und nicht zutreffende Maßnahmen dürfen mit Begründung im Statement of Applicability ausgeschlossen werden, etwa Entwicklungs-Controls bei Unternehmen ohne eigene Softwareentwicklung.
Die Norm benennt rund ein Dutzend Stellen, an denen dokumentierte Information gefordert ist – vom Geltungsbereich über die Risikoanalyse bis zu Auditberichten. Zusammen mit den Richtlinien aus den umgesetzten Anhang-A-Controls landen kleine Unternehmen realistisch bei 15 bis 25 Dokumenten. Ein umfangreiches Handbuch ist ausdrücklich nicht vorgeschrieben.
Die Kapitel 4 bis 10 beschreiben das Managementsystem: Wie Risiken ermittelt, Verantwortungen geregelt und Verbesserungen gesteuert werden. Anhang A liefert dazu den Katalog konkreter Sicherheitsmaßnahmen – von Zugriffskontrolle bis Backup. Die Kapitel gelten immer vollständig, die Controls nur soweit anwendbar. Verbunden werden beide Ebenen durch das Statement of Applicability.
Ja, darauf bestehen Auditoren üblicherweise. Kapitel 5 macht die oberste Leitung persönlich für das ISMS verantwortlich, und diese Verantwortung lässt sich nicht delegieren. Geprüft wird im Gespräch: Kennt die Geschäftsführung die wesentlichen Risiken, die Sicherheitsziele und die Ergebnisse der letzten Managementbewertung? Eine Stunde gut vorbereitete Teilnahme genügt meist.
Die Norm verlangt Wiederholungen in geplanten Abständen und zusätzlich bei wesentlichen Änderungen. Etabliert hat sich ein jährlicher Turnus, ergänzt um anlassbezogene Bewertungen – etwa bei neuen Cloud-Diensten, Standortwechseln, Zukäufen oder nach einem relevanten Sicherheitsvorfall. Wichtig ist, dass das Verfahren gleich bleibt, damit die Ergebnisse vergleichbar sind.
Ja. Kapitel 6.2 verlangt Ziele, die messbar sind (sofern praktikabel), überwacht, kommuniziert und bei Bedarf aktualisiert werden. Gut funktionieren drei bis fünf konkrete Ziele, etwa: Wiederherstellungszeit kritischer Systeme unter vier Stunden, alle kritischen Patches binnen 14 Tagen, hundert Prozent geschulte Mitarbeitende. Reine Absichtserklärungen wie „Sicherheit erhöhen“ genügen nicht.
In 4–6 Wochen zum Zertifikat – zum Festpreis.
Kostenloses Erstgespräch: Wir sagen Ihnen ehrlich, ob eine nicht akkreditierte Zertifizierung für Ihren Fall reicht – oder eben nicht.
Erstgespräch vereinbaren
Thomas KowollInhaber und Leitung Zertifizierung bei KCERT. Auditiert Managementsysteme nach ISO 9001, 14001, 45001, 27001 und 50001. Mehr über KCERT