Von ISO 27001 zu ISO 27002: Der Weg zur Praxis

Das verlorene Verständnis: Was ISO 27001 nicht tut

Viele Unternehmen unterschreiben ein Zertifikat und glauben, ihre Informationssicherheit sei gelöst. Das ist ein Missverständnis, das auf einer einfachen Verwechslung beruht:

ISO 27001 ist eine Norm, die sagt: „Diese 14 Anforderungen müssen erfüllt sein."

ISO 27002 ist ein Standard, der sagt: „So könnten diese 14 Anforderungen erfüllt werden."

Der Unterschied ist entscheidend. ISO 27001 ist präskriptiv (vorschreibend). ISO 27002 ist deskriptiv (beschreibend). Ein zertifiziertes Unternehmen hat seine Kontrollmechanismen dokumentiert, aber nicht automatisch richtig implementiert.

Ein Auditor prüft: „Habt ihr Zugriffskontrolle dokumentiert?" Die Antwort: „Ja, wir haben eine Policy."

Ein praktizierender Security-Manager prüft: „Funktioniert die Zugriffskontrolle?" Die Antwort ist oft: „Naja, theoretisch ja…"

Dies ist die Schlucht zwischen Zertifizierung und operative Realität. ISO 27002 ist eine Brücke.

Struktur und Umfang: Annex A vs. ISO 27002:2022

Die drei Ebenen verstehen

Jedes ISO-27001-System hat eine interne Logik, die sich über drei Ebenen erstreckt:

ISO 27001 ist eine Checkliste. ISO 27002 ist ein Handbuch. Und die Realität ist ein laufendes Projekt.

Zahlenfrage: 14 Anforderungen vs. 93 Controls

ISO 27001:2022 sieht 14 hohe Anforderungen vor (Annex A). Jede Anforderung hat mehrere Unter-Controls. Insgesamt sind es 93 „Objectives" (vorher waren es 114 in der 2013er Version, aber die sind konsolidiert worden).

ISO 27002:2022 nimmt diese 93 Objectives und fügt für jede ein ausführliches Kapitel hinzu. Ein durchschnittliches ISO-27002-Kapitel zu einer Kontrolle könnte so aussehen:

• Purpose (Wozu diese Kontrolle?)
• Guidance (Wie implementiert man sie konkret?)
• Implementation considerations (Worauf achten?)
• Other considerations (Fallstricke, häufige Fehler)
• Relationship to other controls (Wie interagiert sie mit A.5.3, A.8.1, etc.?)

Das ist der Unterschied zwischen „Habt ihr ein Access-Management-System?" und „Wie werden temporäre Zugriffe genehmigt, nach wie langer Inaktivität revoziert, und wer überprüft monatlich, dass keine Zombie-Accounts existieren?"

Das Control-Mapping: Annex A konkret

Ein Beispiel: A.5, Organization of Information Security

ISO 27001 sagt: Es muss eine Organisationsstruktur für ISMS geben.

ISO 27002 sagt: Diese Struktur könnte folgende Rollen haben:

Das ist nicht vorgeschrieben, aber es ist ein bewährtes Modell.

Warum dieses Mapping kritisch ist

Viele Audits scheitern nicht, weil ein Control nicht existiert. Sie scheitern, weil die Verantwortlichkeiten unklar sind oder weil Controls nicht überprüft werden.

Ein praktisches Beispiel: ISO 27001 verlangt, dass Incident Management prozeduralisiert ist (A.8.35). Ein Auditor fragt:

• Gibt es ein Incident-Ticket-System? ✓
• Ist die Eskalationsprozedur dokumentiert? ✓
• Wie oft wertet ihr die Incidents aus? → Große Pause. Keine systematische Auswertung vorhanden.

Das ist ein typisches Finding: Die Control existiert, aber die Überprüfungslogik nicht.

Die vier Themen-Cluster der ISO 27002:2022

Die Neufassung 2022 hat die 93 Controls in vier Themen-Cluster gruppiert. Wer das Mapping zwischen Annex A und ISO 27002 versteht, erkennt die Cluster-Logik:

• A.5 Organizational controls (37 Controls): Policies, Rollen, Lieferantenmanagement, Information Classification, Incident Response. Hier sitzen die meisten Governance-Themen.
• A.6 People controls (8 Controls): Screening, Vertraulichkeitsvereinbarungen, Awareness, disziplinarische Verfahren. Reduziert von 14 auf 8 Controls (Konsolidierung).
• A.7 Physical controls (14 Controls): Zutrittskontrolle, Schreibtisch-Policy, sichere Entsorgung, Versorgungssicherheit.
• A.8 Technological controls (34 Controls): Endpoint-Schutz, Verschlüsselung, Logging, Web-Filtering, sichere Entwicklung. Größter Cluster.

Vier neue Controls wurden 2022 ergänzt, die in der 2013er-Version nicht existierten: A.5.7 Threat Intelligence, A.5.23 Information security for cloud services, A.5.30 ICT readiness for business continuity und A.8.23 Web filtering. Wer von 2013 migriert, muss diese vier separat dokumentieren und im SoA aufnehmen.

Reifegradmodell: Vier Stufen pro Control

ISO 27002 selbst kennt kein formales Reifegradmodell, aber die Praxis nutzt Stufen, die sich an CMMI orientieren. Sinnvoll ist eine vierstufige Bewertung pro Control:

Ein typisches Audit nach Stage-2-ISO-27001-Zertifizierung erwartet mindestens Stufe 2 für alle anwendbaren Controls und Stufe 3 für die zehn kritischsten. Stufe 4 ist Reifestufe für rezertifizierte Häuser nach drei bis fünf Jahren ISMS-Betrieb.

4-Wochen-Praxis-Plan: Vom Annex-Eintrag zur Wirksamkeit

Für die Migration von einem dokumentierten Annex-Eintrag zu einem nachweislich wirksamen Control hat sich folgendes Schema bewährt:

1. Woche 1: Gap-Analyse. Aktuelle Implementierung gegen ISO 27002-Guidance prüfen. Welche Punkte aus der Implementation-Guidance sind heute schon abgedeckt, welche fehlen vollständig, welche existieren formal aber ohne Substanz?
2. Woche 2: Verantwortlichkeit zuordnen. Pro Control mindestens einen benannten Owner und einen Stellvertreter. Dokumentation in RACI-Matrix oder im ISMS-Tool. Owner verantwortet die jährliche Wirksamkeitsprüfung.
3. Woche 3: Metriken definieren. Was ist messbar? Wie oft wird gemessen? Wer wertet aus? Beispiel A.8.35 (Incident Management): Anzahl Tickets pro Monat, durchschnittliche Zeit bis Erstreaktion, Anteil Major Incidents mit dokumentierter Root-Cause-Analyse.
4. Woche 4: Erste Wirksamkeitsprüfung. Stichprobenartig drei Controls mit der Implementation-Guidance der ISO 27002 abgleichen. Findings in einem internen Audit-Report dokumentieren. Diese Praxis vor dem Stage-2-Audit wiederholen.

Wer dieses Schema für alle 93 Controls durchzieht, braucht realistisch sechs bis neun Monate. Aber jede einzelne Iteration produziert einen sichtbaren Reifegrad-Sprung, und das Audit nach Stage 2 wird nicht zur Überraschung.

Typische Fehler beim Übergang von ISO 27001 zu ISO 27002

In Beratungsprojekten zeigen sich drei wiederkehrende Muster, die zwischen Zertifikat und operativer Sicherheit eine Lücke entstehen lassen.

1. Kopierte Policies ohne Anpassung. Viele Unternehmen übernehmen die Implementation-Guidance der ISO 27002 wortgleich in ihre Policy-Dokumente. Das Ergebnis sind generische Texte ohne Bezug zur konkreten Organisation. Eine Policy zu A.5.10 (Acceptable use of information assets) muss konkret beschreiben, welche Systeme im Unternehmen welchen Einsatzregeln unterliegen, nicht abstrakt das Konzept erklären. Der Auditor erkennt copy-paste sofort an fehlenden Personennamen, Tool-Bezeichnungen und unternehmensspezifischen Klassifikationen.

2. SoA als reine Auswahlliste. Das Statement of Applicability (SoA) ist nach ISO 27001 Abschnitt 6.1.3 Pflichtdokument. Viele SoAs erschöpfen sich in einer Tabelle mit Spalten für „anwendbar ja/nein" und „begründet". Die ISO 27002 verlangt darüber hinaus, dass jede Control eine dokumentierte Wirksamkeitsmessung erhält. Wer im SoA nur Anwendbarkeit dokumentiert, verfehlt den Zweck der Kontrolle, die im laufenden Betrieb funktionieren soll.

3. Fokus auf 2013er-Controls. Bestandsunternehmen, die ihr ISMS noch aus der ISO 27001:2013-Welt führen, übersehen häufig die vier neuen Controls der 2022er-Fassung. Threat Intelligence (A.5.7), Cloud-Sicherheit (A.5.23), ICT-Readiness für Business Continuity (A.5.30) und Web Filtering (A.8.23) müssen aktiv in das ISMS integriert werden, nicht erst beim Re-Zertifizierungs-Audit.