ISO 27002:2022 im Jahr 2026: 93 Maßnahmen, 4 Gruppen, Attribute und Umsetzungshinweise

Was ISO 27002 ist: das Verhältnis zu 27001

Der vollständige Titel lautet Information security, cybersecurity and privacy protection - Information security controls ^[1]. Der Name ist hier informativ: Das Dokument stellt keine nachzuweisende Anforderung, sondern beschreibt, woraus jede Maßnahme besteht und wie sie sich umsetzen lässt.

Das Verhältnis zu ISO 27001 lässt sich auf eine Unterscheidung bringen. ISO 27001 bestimmt, wie ein Informationssicherheits-Managementsystem aufzubauen und zu erhalten ist, und ihr Anhang A zählt 93 Maßnahmen in je einem Satz auf. ISO 27002 nimmt dieselbe Liste und ergänzt für jede Position Zweck, Umsetzungshinweise und Kontext. Zertifiziert wird ausschließlich 27001; ein Zertifikat über die "Konformität mit ISO 27002" gibt es nicht.

Eine Kleinigkeit gehört sogleich geklärt, weil viele Dokumente sie verwischen. Die Nummerierung mit dem Präfix A - A.5, A.6, A.7, A.8 - stammt aus Anhang A der ISO 27001. ISO 27002 selbst nummeriert dieselben Maßnahmen als Kapitel 5 bis 8, ohne Präfix. Die Zuordnung ist eins zu eins, in der Praxis meinen also beide Konventionen dasselbe; in der internen Dokumentation bleibt man aber besser bei einer. Im Folgenden verwenden wir die Notation aus Anhang A, weil sie in polnischen Umsetzungen häufiger ist.

Woher sie stammt

Die Norm wurzelt in der britischen BS 7799 aus den neunziger Jahren. 2000 gelangte ihr erster Teil als ISO/IEC 17799 zur ISO, 2005 folgte eine Anpassung an die frisch erschienene ISO/IEC 27001:2005, und 2007 wurde sie zu ISO/IEC 27002 umnummeriert, um in die 27000er-Reihe zu passen. Die Ausgabe 2013 brachte eine erhebliche inhaltliche Aktualisierung, die Ausgabe 2022 den unten beschriebenen Umbau der Struktur.

Status und Platz in der Regulierung

Die Norm ist international, gemeinsam von ISO und IEC erarbeitet und vollständig freiwillig. Keine Vorschrift schreibt ihre Anwendung vor. Eine Ausnahme ist jedoch erwähnenswert, weil sie oft ungenau dargestellt wird: Die polnische KRI-Verordnung nennt in § 19 Absatz 3 PN-ISO/IEC 27002 als eine der Normen, deren Anwendung die Anforderungen an ein Informationssicherheits-Managementsystem als erfüllt gelten lässt. Das ist eine Konformitätsvermutung, kein Gebot.

Weder das polnische KSC-Gesetz noch die NIS2-Richtlinie enthält einen solchen Verweis - sie nennen Sicherheitsbereiche, keine Normen. ISO 27002 ist dort als Beweismaterial in einer Kontrolle nützlich, nicht als Rechtsgrundlage.

Wofür sie in der Praxis dient

Am häufigsten als Umsetzungsanleitung: Ein Team nimmt eine Maßnahme aus Anhang A, liest das entsprechende Kapitel der 27002 und entwirft daraus das eigene Verfahren. Der zweite typische Einsatz ist das Audit, in dem die Norm der Bezugspunkt für die Beurteilung ist, ob eine Maßnahme sauber umgesetzt oder nur beschrieben wurde. Der dritte ist die Lückenanalyse, denn ein Katalog von 93 Positionen liefert eine fertige Prüfliste für den Abgleich mit der Wirklichkeit. Daneben dient die Norm als Schulungsmaterial und als gemeinsames Vokabular gegenüber Dienstleistern, wo der Verweis auf eine konkrete Maßnahmennummer präziser ist als eine beschreibende Vertragsklausel.

Änderungen in der Ausgabe 2022

Der Umbau von 2022 gab die thematische Gliederung zugunsten einer Gliederung danach auf, wer oder was die Maßnahme umsetzt. Die vorige Ausgabe gruppierte 114 Maßnahmen in vierzehn Kapiteln zu Zugriffskontrolle, Kryptografie, physischer Sicherheit und so fort. Die heutige hat vier Gruppen: organisatorisch (37 Maßnahmen), personell (8), physisch (14) und technologisch (34).

Der Wechsel von 114 auf 93 bedeutet nicht, dass auf etwas verzichtet wurde. Keine Maßnahme wurde gestrichen - ein Teil wurde zusammengeführt, weil er dasselbe Thema von zwei Seiten betraf, ein Teil neu formuliert. Praktisch heißt das, dass eine von der Ausgabe 2013 migrierende Organisation nicht suchen muss, was fehlt, sondern nur die alten Positionen auf die neuen abzubilden hat.

Elf neue Maßnahmen

Die neuen Positionen antworten darauf, was sich zwischen 2013 und 2022 in der Praxis geändert hat: Cloud, Arbeit mit Daten in großem Maßstab und ein reiferer Umgang mit Erkennung.

1. A.5.7 Bedrohungsaufklärung - Gewinnung und Nutzung von Informationen über Bedrohungen.
2. A.5.23 Informationssicherheit bei der Nutzung von Cloud-Diensten. Die Maßnahme selbst ist kurz; die Entfaltung steht in ISO/IEC 27017 ^[9], ein unabhängiger Maßnahmenkatalog für die Cloud ist die Cloud Controls Matrix ^[12].
3. A.5.30 Bereitschaft der IKT für die Betriebskontinuität.
4. A.7.4 Überwachung physischer Bereiche.
5. A.8.9 Konfigurationsmanagement.
6. A.8.10 Löschen von Informationen, sobald sie nicht mehr gebraucht werden.
7. A.8.11 Datenmaskierung.
8. A.8.12 Verhinderung von Datenabfluss.
9. A.8.16 Überwachung von Aktivitäten in Systemen und im Netz.
10. A.8.23 Webfilterung.
11. A.8.28 Sichere Programmierung.

Vier davon - Bedrohungsaufklärung, Überwachung von Aktivitäten, Verhinderung von Datenabfluss und sichere Programmierung - werden am häufigsten übergangen, weil sie einen laufenden Prozess und kein Dokument verlangen.

Attribute als zweite Beschreibungsachse

Die zweite Neuerung sind Attribute, also Metadaten je Maßnahme in fünf Dimensionen: Typ der Maßnahme, geschützte Eigenschaft der Information, Funktion im Sinne des NIST CSF, operative Fähigkeit und Sicherheitsdomäne. Sie ändern den Inhalt der Maßnahmen nicht, erlauben aber verschiedene Sichten auf den Katalog - etwa alles herauszufiltern, was der Erkennung dient, oder zu zählen, welcher Anteil des Portfolios die Lieferkette betrifft. Einzelheiten weiter unten.

Aufbau einer Maßnahme: Aussage, Zweck, Hinweise

Jede der 93 Maßnahmen ist nach demselben Schema beschrieben, aus vier Teilen und einer Attributtabelle. Die Einheitlichkeit ist gewollt: Die Auditorin weiss, wo zu suchen ist, und das umsetzende Team kann denselben Aufbau in der eigenen Dokumentation übernehmen.

Der erste Teil ist die Maßnahme selbst - ein normativer Satz, was zu tun ist. Für A.8.13 zu Sicherungskopien lautet er: "Backups of information, software and systems shall be maintained and regularly tested in accordance with the agreed topic-specific policy on backup". Dieser Satz wandert meist unmittelbar in die Erklärung zur Anwendbarkeit.

Der zweite ist der Zweck, der erklärt, wovor die Maßnahme schützt. Bei Sicherungen ist er knapp: "To enable recovery from loss of data or systems". Der dritte, umfangreichste, sind die Umsetzungshinweise. Bei A.8.13 umfassen sie Umfang und Häufigkeit der Sicherung, Aufbewahrungsdauer, Wiederherstellungstests, Schutz vor Veränderung, Aufbewahrung außerhalb des Hauptstandorts, Verschlüsselung sowie die Dokumentation von Verfahren und Rollen. Der vierte Teil, weitere Informationen, liefert Kontext und Verweise auf andere Normen.

Diese Struktur erklärt, warum ISO 27001 allein zur Umsetzung nicht reicht. Der Satz über Sicherungen klingt selbstverständlich, bis jemand beantworten muss, was "regelmäßig getestet" heißt und wie sich das belegen lässt.

Attribute: fünf Beschreibungsdimensionen

Attribute sind eine nicht verlangte, aber sehr praktische Ergänzung. Die Norm schlägt fünf Dimensionen vor, eine Organisation kann eigene hinzufügen.

Typ der Maßnahme

Unterscheidet vorbeugende, aufdeckende und korrigierende Maßnahmen. Die Einteilung ist nicht ausschließlich: Eine Sicherungskopie beugt Datenverlust vor und erlaubt zugleich, die Folgen eines Vorfalls zu beseitigen, trägt also zwei Typen zugleich. Ein sinnvolles Portfolio hat alle drei - ein Übergewicht vorbeugender Maßnahmen ohne aufdeckende beschreibt eine Organisation, die nicht erfährt, was an ihr vorbeigegangen ist.

Geschützte Eigenschaften der Information

Die klassische Trias: Vertraulichkeit, Integrität und Verfügbarkeit. Diese Dimension ist in einer Durchsicht oft die lehrreichste, weil sie die übliche Schieflage zugunsten der Vertraulichkeit auf Kosten der Integrität sichtbar macht - Verschlüsselung und Zugriffskontrolle gibt es meist reichlich, Mechanismen zur Erkennung unbefugter Veränderung deutlich weniger.

Cybersicherheitskonzepte nach NIST CSF

Eine Abbildung auf die Funktionen des NIST Cybersecurity Framework ^[4]: Identifizieren, Schützen, Erkennen, Reagieren und Wiederherstellen. Dadurch lässt sich dasselbe Maßnahmenportfolio der Leitung in CSF-Sprache zeigen, ohne zwei getrennte Register zu führen.

Operative Fähigkeiten

Die detaillierteste Dimension mit fünfzehn Kategorien, die den Arbeitsbereichen eines Teams entsprechen: Steuerung, Verwaltung von Werten, Informationsschutz, Personalsicherheit, physische Sicherheit, System- und Netzsicherheit, Anwendungssicherheit, sichere Konfiguration, Identitäts- und Zugriffsverwaltung, Bedrohungs- und Schwachstellenmanagement, Kontinuität, Sicherheit der Lieferantenbeziehungen, Recht und Konformität, Ereignismanagement sowie Informationssicherheitsnachweis. Diese Dimension eignet sich am besten, um Maßnahmen Verantwortlichen zuzuordnen.

Sicherheitsdomänen

Vier strategisch angelegte Domänen: Steuerung und Ökosystem, Schutz, Abwehr und Widerstandsfähigkeit. Sie bewähren sich in der Berichterstattung auf Leitungsebene, wo das Verhältnis zwischen ihnen mehr zählt als einzelne Positionen.

Der praktische Wert der Attribute zeigt sich bei drei Aufgaben: dem Filtern des Katalogs nach einer gewählten Perspektive, der Berichterstattung über die Abdeckung nach Domänen und der Abbildung auf andere Modelle, darunter die CIS Controls ^[5]. In jedem dieser Fälle ersetzen die Attribute eine von Hand gepflegte Übersetzungstabelle, die in Organisationen meist nach der ersten Durchsicht veraltet.

A.5 Organisatorische Maßnahmen (37)

Die größte Gruppe, mit dem, was eine Organisation auf Ebene der Regeln festlegt und durchsetzt: Richtlinien, Rollen, Klassifizierung von Informationen, Zugriffskontrolle, Lieferantenbeziehungen, Vorfallbearbeitung, Betriebskontinuität und Rechtskonformität. Die Übersicht behält die Reihenfolge der Norm bei.

A.5.1 bis A.5.8 Richtlinien, Rollen und Steuerung

• A.5.1 Richtlinien für Informationssicherheit - eine übergeordnete Richtlinie sowie themenspezifische, etwa zur Kryptografie oder zur Zugriffskontrolle. Siehe Informationssicherheitsrichtlinie.
• A.5.2 Rollen und Verantwortlichkeiten - namentlich zugewiesen, nicht an eine Abteilung.
• A.5.3 Aufgabentrennung - Trennung von Aufgaben, deren Verbindung unentdeckten Missbrauch ermöglicht.
• A.5.4 Verantwortung der Leitung - Pflicht der Leitung, die Regeln durchzusetzen.
• A.5.5 Kontakt zu Behörden - festgelegte Kontakte, auch zum CSIRT und zur Datenschutzbehörde.
• A.5.6 Kontakt zu Interessengruppen - Teilnahme am Fachaustausch.
• A.5.7 Bedrohungsaufklärung (neu) - Gewinnung, Analyse und Nutzung von Bedrohungsinformationen.
• A.5.8 Informationssicherheit im Projektmanagement - Sicherheitsanforderungen von Projektbeginn an.

A.5.9 bis A.5.14 Werte und Informationen

• A.5.9 Verzeichnis der Informationen und zugehörigen Werte - mit Verantwortlichen.
• A.5.10 Zulässige Nutzung - Regeln für die zulässige Nutzung der Werte.
• A.5.11 Rückgabe von Werten - bei Wechsel oder Ende der Zusammenarbeit.
• A.5.12 Klassifizierung von Informationen - nach Schutzbedarf.
• A.5.13 Kennzeichnung von Informationen - entsprechend der Klassifizierung.
• A.5.14 Informationsübertragung - Regeln für die Weitergabe nach aussen und innen.

A.5.15 bis A.5.18 Zugriffskontrolle

• A.5.15 Zugriffskontrolle - Regeln für die Vergabe von Zugriff.
• A.5.16 Identitätsverwaltung - über den gesamten Lebenszyklus.
• A.5.17 Authentisierungsinformationen - Umgang mit Kennwörtern und anderen Anmeldedaten.
• A.5.18 Zugriffsrechte - Vergabe, Überprüfung und Entzug.

A.5.19 bis A.5.23 Lieferkette

• A.5.19 Informationssicherheit in Lieferantenbeziehungen.
• A.5.20 Informationssicherheit in Lieferantenverträgen.
• A.5.21 Informationssicherheit in der IKT-Lieferkette - Risiko weiterer Glieder der Kette.
• A.5.22 Überwachung, Überprüfung und Änderungsmanagement von Lieferantenleistungen.
• A.5.23 Informationssicherheit bei der Nutzung von Cloud-Diensten (neu).

A.5.24 bis A.5.30 Vorfälle und Kontinuität

• A.5.24 Planung und Vorbereitung der Vorfallbearbeitung.
• A.5.25 Bewertung und Entscheidung über Sicherheitsereignisse.
• A.5.26 Reaktion auf Sicherheitsvorfälle - gemäß Verfahren.
• A.5.27 Lernen aus Sicherheitsvorfällen.
• A.5.28 Sammlung von Beweismitteln.
• A.5.29 Informationssicherheit während einer Störung.
• A.5.30 Bereitschaft der IKT für die Betriebskontinuität (neu). Siehe ISO 22301.

A.5.31 bis A.5.37 Konformität und Dokumentation

• A.5.31 Rechtliche, gesetzliche, regulatorische und vertragliche Anforderungen.
• A.5.32 Rechte des geistigen Eigentums, einschließlich Softwarelizenzen.
• A.5.33 Schutz von Aufzeichnungen vor Verlust und Veränderung.
• A.5.34 Privatheit und Schutz personenbezogener Daten - der Berührungspunkt zur DSGVO, für die Cloud entfaltet in ISO/IEC 27018 ^[10].
• A.5.35 Unabhängige Überprüfung der Informationssicherheit.
• A.5.36 Einhaltung von Richtlinien, Regeln und Normen - Prüfung, ob die eigenen Regeln befolgt werden.
• A.5.37 Dokumentierte Betriebsverfahren.

A.6 Personelle Maßnahmen (8)

Die kleinste Gruppe, mit dem gesamten Beschäftigungszyklus - von der Prüfung einer Bewerberin bis zu den Pflichten, die nach dem Ausscheiden fortbestehen. Ihre Umsetzung verlangt fast immer die Zusammenarbeit mit der Personalabteilung, was oft der schwierigste Teil ist.

• A.6.1 Personalprüfung - Prüfung von Identität, Referenzen, Erfahrung und Qualifikation, soweit rechtlich zulässig und der Rolle angemessen.
• A.6.2 Beschäftigungsbedingungen - Sicherheitspflichten im Vertrag samt Vertraulichkeitsverpflichtung.
• A.6.3 Bewusstsein, Aus- und Weiterbildung - Schulungen bei Einführung und regelmäßig, mit dokumentierter Teilnahme. Siehe Security Awareness.
• A.6.4 Disziplinarverfahren - Vorgehen gegenüber Personen, die Regeln verletzt haben.
• A.6.5 Pflichten nach Beendigung oder Wechsel - Rückgabe von Werten, Entzug von Rechten, fortbestehende Vertraulichkeit.
• A.6.6 Vertraulichkeitsvereinbarungen - mit Beschäftigten, Mitarbeitenden und Dienstleistern.
• A.6.7 Fernarbeit - Regeln für Arbeit außerhalb des Standorts, Absicherung von Geräten und Verbindung.
• A.6.8 Meldung von Sicherheitsereignissen - ein Meldeweg, der einfach genug ist, damit ihn jemand nutzt.

A.7 Physische Maßnahmen (14)

Die Gruppe umfasst drei Schichten: Sicherheitsbereiche und Zutrittskontrolle, die Widerstandsfähigkeit der Räume gegenüber Umgebungseinflüssen sowie den Schutz von Geräten und Datenträgern - auch wenn sie den Standort verlassen. In Organisationen mit externem Rechenzentrum erbringt der Dienstleister einen Teil dieser Maßnahmen, was zu dokumentieren und nicht zu unterstellen ist.

• A.7.1 Physische Sicherheitsbereiche - festgelegte Grenzen geschützter Zonen.
• A.7.2 Physischer Zutritt - Zutrittskontrolle, etwa per Karte oder Biometrie.
• A.7.3 Sicherung von Büros, Räumen und Einrichtungen.
• A.7.4 Überwachung physischer Bereiche (neu) - Videoüberwachung, Alarme, Zutrittsprotokoll.
• A.7.5 Schutz vor physischen und umgebungsbedingten Bedrohungen - Brand, Wasser, Stromausfall.
• A.7.6 Arbeiten in Sicherheitsbereichen.
• A.7.7 Aufgeräumter Arbeitsplatz und gesperrter Bildschirm.
• A.7.8 Aufstellung und Schutz von Geräten - Platzierung, die Einsicht und Beschädigung erschwert.
• A.7.9 Sicherheit von Werten außerhalb des Standorts, auch bei Notebooks.
• A.7.10 Datenträger - Verwaltung über den gesamten Lebenszyklus.
• A.7.11 Versorgungseinrichtungen - Strom, Kühlung und weitere unterstützende Medien.
• A.7.12 Sicherheit der Verkabelung - Schutz von Strom- und Datenleitungen.
• A.7.13 Wartung von Geräten - Service ohne Verlust der Kontrolle über die Daten.
• A.7.14 Sichere Entsorgung oder Wiederverwendung von Geräten - Außerbetriebnahme samt endgültiger Datenlöschung.

A.8 Technologische Maßnahmen (34)

Die zweitgrößte Gruppe und zugleich die, die sich am leichtesten halb umsetzen lässt. Sie umfasst Endgeräte und Rechte, den Schutz vor Schadsoftware und Schwachstellen, Protokollierung und Überwachung, Kryptografie, Netzsicherheit und den gesamten Softwareentwicklungszyklus.

A.8.1 bis A.8.6 Geräte, Rechte und Kapazität

• A.8.1 Endgeräte der Nutzenden. Siehe Hardening.
• A.8.2 Privilegierte Zugriffsrechte - Begrenzung und Aufsicht über privilegierte Konten.
• A.8.3 Beschränkung des Informationszugriffs.
• A.8.4 Zugriff auf Quellcode.
• A.8.5 Sichere Authentisierung, auch mehrfaktorig.
• A.8.6 Kapazitätsmanagement.

A.8.7 bis A.8.14 Schutz, Sicherungen und Widerstandsfähigkeit

• A.8.7 Schutz vor Schadsoftware.
• A.8.8 Umgang mit technischen Schwachstellen. Siehe Schwachstellenscan.
• A.8.9 Konfigurationsmanagement (neu) - Steuerung der Konfiguration und Erkennung von Abweichungen.
• A.8.10 Löschen von Informationen (neu) - nach Wegfall des Bedarfs.
• A.8.11 Datenmaskierung (neu), besonders in Nicht-Produktivumgebungen.
• A.8.12 Verhinderung von Datenabfluss (neu).
• A.8.13 Sicherung von Informationen - Sicherungskopien samt Wiederherstellungstest.
• A.8.14 Redundanz der Verarbeitungseinrichtungen.

A.8.15 bis A.8.19 Protokollierung und Überwachung

• A.8.15 Protokollierung.
• A.8.16 Überwachung von Aktivitäten (neu) - Beobachtung und Erkennung von Anomalien. Siehe SOC 24/7.
• A.8.17 Zeitsynchronisation, ohne die die Korrelation von Protokollen sinnlos wird.
• A.8.18 Nutzung privilegierter Hilfsprogramme - Kontrolle von Werkzeugen, die Schutzmaßnahmen umgehen.
• A.8.19 Installation von Software auf Produktivsystemen.

A.8.20 bis A.8.24 Netz und Kryptografie

• A.8.20 Netzsicherheit.
• A.8.21 Sicherheit von Netzdiensten.
• A.8.22 Trennung von Netzen.
• A.8.23 Webfilterung (neu).
• A.8.24 Einsatz von Kryptografie, samt Schlüsselverwaltung.

A.8.25 bis A.8.34 Entwicklung und Test

• A.8.25 Sicherer Entwicklungszyklus.
• A.8.26 Sicherheitsanforderungen an Anwendungen.
• A.8.27 Grundsätze sicherer Architektur und Entwicklung.
• A.8.28 Sichere Programmierung (neu).
• A.8.29 Sicherheitstests in Entwicklung und Abnahme. Siehe Penetrationstests.
• A.8.30 Ausgelagerte Entwicklung - Aufsicht über extern vergebene Entwicklung.
• A.8.31 Trennung von Entwicklungs-, Test- und Produktivumgebungen.
• A.8.32 Änderungsmanagement.
• A.8.33 Testinformationen - Schutz der für Tests genutzten Daten.
• A.8.34 Schutz von Informationssystemen bei Audittests.

Verhältnis zu NIST CSF, CIS Controls und OWASP

ISO 27002 steht nicht für sich und wird in der Praxis fast immer neben anderen Modellen genutzt. Es lohnt sich zu verstehen, worin sie sich unterscheiden, denn der Versuch, das eine durch das andere zu ersetzen, endet in doppelter Arbeit.

Das NIST Cybersecurity Framework 2.0 ^[4] arbeitet auf höherer Ebene. Es ordnet Sicherheit in sechs Funktionen - Steuern, Identifizieren, Schützen, Erkennen, Reagieren und Wiederherstellen - und steigt nicht zur Umsetzungsanleitung hinab. Deshalb ergänzen sich beide gut: das CSF als Rahmen für das Gespräch mit der Leitung, ISO 27002 als ausführende Schicht. Die Abbildung dazwischen steckt in den Attributen der Norm und muss nicht von Hand entstehen.

Die CIS Critical Security Controls ^[5] gehen den umgekehrten Weg - sie sind technischer und ausdrücklich priorisiert, mit einer Einteilung in Umsetzungsgruppen. Das Center for Internet Security veröffentlicht eine Abbildung seiner Maßnahmen auf ISO 27002, sodass eine Organisation CIS als Reihenfolge des Handelns und ISO als Struktur der Dokumentation nutzen kann.

Die OWASP Top 10 ^[6] hat einen weit engeren Zuschnitt: Sie ist eine Liste der schwerwiegendsten Kategorien von Schwachstellen in Webanwendungen und kein Katalog organisatorischer Maßnahmen. In ISO 27002 entspricht sie ungefähr dem, was unter A.8.28 und die benachbarten Maßnahmen des Entwicklungszyklus fällt. OWASP als Alternative zu ISO 27002 zu behandeln ist ein häufiges Missverständnis - es ist ein Werkzeug für eine andere Aufgabe.

NIST SP 800-53 ^[11] ist der umfangreichste der genannten Kataloge mit über tausend Positionen samt Erweiterungen. Er entstand für die US-Bundesverwaltung und ist außerhalb dieses Kontexts oft überdimensioniert, taugt aber als Quelle für Einzelheiten dort, wo die ISO-Hinweise knapp sind.

Eine reife Organisation wählt meist nicht ein Modell, sondern weist jedem eine Rolle zu: ISO 27001 und 27002 als Grundlage des Managementsystems und einer etwaigen Zertifizierung, das NIST CSF als Berichtssprache, die CIS Controls als Reihenfolge der Umsetzung, OWASP für die Anwendungsebene und die Rechtsakte - KSC, NIS2, DSGVO - als Pflichten, die keines dieser Modelle ersetzt.

Umsetzung in der Praxis

Den gesamten Katalog von null umzusetzen dauert in einer mittelgroßen Organisation meist neun bis achtzehn Monate - eine Beobachtung aus unseren Projekten, keine Kennzahl aus der Norm. Die Reihenfolge zählt hier mehr als das Tempo, denn ein Teil der Maßnahmen ist Voraussetzung dafür, dass die nächsten sinnvoll wirken. Man kann etwa den Zugriff auf Informationen nicht vernünftig begrenzen, die niemand klassifiziert hat.

Ein stufenweises Vorgehen bewährt sich. Zuerst entsteht das Fundament: Richtlinie, Rollen, Verzeichnis der Werte, Klassifizierung von Informationen und Grundregeln der Zugriffskontrolle. Dann kommt der laufende Schutz - Mehr-Faktor-Authentisierung, Aufsicht über privilegierte Konten, Schutz vor Schadsoftware, Schwachstellenmanagement, Sicherungen und Schulungen. Die dritte Stufe ist die Erkennungsfähigkeit: Protokollierung, Überwachung, Bedrohungsaufklärung und Beobachtung physischer Bereiche. Die vierte umfasst Reaktion und Wiederherstellung, also Vorfallbearbeitung und Betriebskontinuität. Die letzte betrifft die Bereiche mit dem höchsten Reifebedarf: Lieferantensteuerung, Sicherheit im Entwicklungszyklus, Datenmaskierung und Verhinderung von Datenabfluss.

Innerhalb einer Stufe sollte die Reihenfolge aus der Risikoanalyse folgen und nicht aus der Vollständigkeit der Liste. Die Methodik der Risikoeinschätzung ordnet ISO/IEC 27005 ^[8], Hinweise zur Einführung des Managementsystems selbst gibt ISO/IEC 27003 ^[7]. Neben dem Risiko sind auch die ohnehin zu erfüllenden regulatorischen Pflichten und die Abhängigkeiten zwischen Maßnahmen sinnvolle Kriterien.

Die Verantwortungsteilung deckt sich selten mit der Gruppeneinteilung der Norm, und das ist die häufigste Quelle von Stockungen. Die Koordination liegt meist bei der Person, die das Managementsystem verantwortet, doch personelle Maßnahmen brauchen die Personalabteilung, physische die Verwaltung, technologische das IT-Team und die zu Lieferanten und Konformität die Rechtsabteilung. Ohne Festlegung der Verantwortlichen zu Beginn bleibt das Vorhaben bei den Positionen stehen, die niemand als seine ansieht.

Die häufigsten Umsetzungsfehler

Die folgenden Probleme wiederholen sich in Audits unabhängig von der Größe der Organisation.

1. Alle 93 Maßnahmen ohne Risikoanalyse umsetzen. Teuer und oft am Ziel vorbei. Die Norm verlangt keine Vollständigkeit - sie verlangt begründete Entscheidungen, und die Erklärung zur Anwendbarkeit ist der Ort dieser Begründung.
2. Die Richtlinie existiert, die Maßnahme wirkt nicht. Die klassische Lücke zwischen Dokumentation und Praxis. Eine Auditorin prüft Nachweise der Wirksamkeit, nicht die Genehmigung eines Dokuments.
3. Arbeit allein mit Anhang A der ISO 27001. Beschreibungen in einem Satz genügen weder, um eine Maßnahme zu entwerfen, noch, um sie im Audit zu verteidigen.
4. Die 2022 ergänzten Maßnahmen übergehen. Am häufigsten fehlen Bedrohungsaufklärung, Überwachung von Aktivitäten, Datenabflussschutz und sichere Programmierung - also jene, die einen Prozess und kein Dokument verlangen.
5. Die Lieferkette nur formal behandeln. Eine Vertragsklausel ohne tatsächliche Prüfung des Dienstleisters erfüllt A.5.19 bis A.5.22 nicht.
6. Sicherungen ohne Wiederherstellungstest. A.8.13 verlangt regelmäßiges Testen und nicht nur das Anfertigen von Kopien. Es ist die am häufigsten festgestellte Abweichung dieser Gruppe.
7. Keine Aufgabentrennung in kleinen Organisationen. Vergibt eine Person Rechte, nutzt sie und prüft die Protokolle, wird keine dieser Handlungen unabhängig kontrolliert. Die Lösung ist oft, die Kontrolle aus dem IT-Team herauszunehmen, statt eine weitere Person einzustellen.
8. Überwachung auf die technische Schicht begrenzt. A.8.16 erfasst auch Anomalien im Verhalten der Nutzenden, etwa untypische Anmeldungen oder einen plötzlichen Anstieg von Downloads.
9. Werkseinstellungen trotz A.8.9. Ohne Bezugspunkt lässt sich keine Abweichung vom Sollzustand erkennen.
10. A.5.34 losgelöst vom Datenschutzrecht. Ein Schutz personenbezogener Daten, der nur in der Systemdokumentation beschrieben ist, ohne Verfahren für Betroffenenanträge und ohne Folgenabschätzung, hält einer Kontrolle der Aufsichtsbehörde nicht stand.