ISO 27001 Anhang A: die 93 Controls in 4 Themen, gruppiert danach, wie Sie sie tatsächlich umsetzen

Anhang A der ISO/IEC 27001:2022 listet 93 Controls in vier Themen: organisatorisch (37), personenbezogen (8), physisch (14) und technologisch (34). Sie ersetzen die 114 Controls in 14 Abschnitten der Ausgabe 2013, und 11 sind neu. Die Themen sind ein Ablagesystem, kein Arbeitsplan. Sortiert nach der Art der Arbeit, die sie erfordern, verteilen sich die 93 auf sechs Pakete.

Dieser Leitfaden behandelt, was Anhang A ist, was sich seit 2013 geändert hat, sechs Arbeitspakete und ihre Reihenfolge, die vollständige Liste, was Anhang A offenlässt, und eine Checkliste.

Thema	Nummern in Anhang A	Controls	Neu in 2022	Was es abdeckt
Organisatorisch	5.1 bis 5.37	37	3	Richtlinien, Rollen, Werte, Zugang, Lieferanten, Vorfälle, Kontinuität, Recht
Personenbezogen	6.1 bis 6.8	8	0	Überprüfung, Beschäftigung, Schulung, Remote-Arbeit, Meldung von Ereignissen
Physisch	7.1 bis 7.14	14	1	Räumlichkeiten, Zutritt, Geräte, Datenträger, Versorgung
Technologisch	8.1 bis 8.34	34	7	Endgeräte, Authentifizierung, Schwachstellen, Backup, Protokollierung, Netzwerke, Entwicklung
Gesamt		93	11

Was sind die Controls in ISO 27001 Anhang A?

Anhang A ist eine Referenzliste von Informationssicherheitsmaßnahmen, jede mit einer Nummer, einem Titel und einer kurzen Maßnahmenbeschreibung. Die Nummerierung von 5.1 bis 8.34 folgt den Abschnitten 5 bis 8 der ISO/IEC 27002:2022, die die Umsetzungshinweise enthält. Auditoren zitieren sie als A.5.1 bis A.8.34.

Es ist keine Checkliste, die Sie vollständig abarbeiten müssen. Abschnitt 6.1.3 verlangt, dass Sie Controls auswählen, die Ihre Risiken behandeln, und sie mit Anhang A vergleichen, damit keines fehlt. Das Ergebnis ist die Erklärung zur Anwendbarkeit (SoA), mit einer Begründung für jeden Ausschluss. Anhang A ist nicht erschöpfend, Sie können also Controls ergänzen. Begründungen behandelt der Beitrag zu Anwendungsbereich und Erklärung zur Anwendbarkeit.

Was hat sich gegenüber Anhang A von 2013 geändert?

Die Ausgabe 2013 hatte 114 Controls in 14 Abschnitten, A.5 bis A.18. Die Ausgabe 2022 hat sie in vier Themen neu geordnet und die Zahl auf 93 gesenkt, vor allem durch Zusammenlegung. Laut der Zusammenfassung der British Standards Institution (BSI) wurden 58 Controls überarbeitet, 24 sind Zusammenlegungen älterer Controls und 11 sind neu.

Zertifikate nach der Ausgabe 2013 sind mit dem Ende der Übergangsfrist am 31. Oktober 2025 abgelaufen oder wurden zurückgezogen. Die Änderung Amd 1:2024 hat den Abschnitten 4.1 und 4.2 Formulierungen zum Klimawandel hinzugefügt und Anhang A unverändert gelassen.

Die 11 neuen Controls

Control	Titel	Arbeitspaket
5.7	Informationen über die Bedrohungslage	Nachweise
5.23	Informationssicherheit für die Nutzung von Cloud-Diensten	Lieferanten
5.30	IKT-Bereitschaft für Business-Continuity	Technik
7.4	Physische Sicherheitsüberwachung	Dokumentieren
8.9	Konfigurationsmanagement	Technik
8.10	Löschung von Informationen	Technik
8.11	Datenmaskierung	Technik
8.12	Verhinderung von Datenlecks	Technik
8.16	Überwachung von Aktivitäten	Technik
8.23	Webfilterung	Technik
8.28	Sichere Codierung	Technik

Für sie gibt es keine übernommene Musterantwort zum Abschreiben, deshalb bleiben viele Erklärungen zur Anwendbarkeit an dieser Stelle vage. SaaS-Unternehmen unterschätzen oft 5.23: Wie sie Cloud-Dienste auswählen, nutzen und wieder verlassen, macht den Großteil ihrer Infrastruktur aus.

Attribute: eine bessere Sicht als die Themen

ISO/IEC 27002:2022, nicht ISO 27001, gibt jedem Control fünf Attribute: Art der Maßnahme (präventiv, detektiv, korrektiv), Informationssicherheitseigenschaften (Vertraulichkeit, Integrität, Verfügbarkeit), Cybersicherheitskonzepte (Identifizieren, Schützen, Erkennen, Reagieren, Wiederherstellen), betriebliche Fähigkeiten und Sicherheitsdomänen. In der Praxis nutzen sie nur wenige Teams. „Alle detektiven Controls“ ist eine weit nützlichere Sicht als „das physische Thema“, wenn Sie wissen wollen, ob Sie einen Vorfall bemerken würden.

In welcher Reihenfolge setzen Sie die Controls aus Anhang A um?

Die Themen sagen einem Auditor, wo er eine Feststellung einordnet, nicht, wer die Arbeit macht, wie lange sie dauert oder was zuerst beginnt. Sortiert danach, wie ein Projekt tatsächlich vorankommt, verteilen sich die 93 auf sechs Arbeitspakete. Die Zahlen beruhen auf der Standardzuordnung in der vollständigen Liste unten, für ein kleines Software- oder Dienstleistungsunternehmen.

Arbeitspaket	Worin die Arbeit besteht	Controls	Start
1. Dokumentieren	Aufschreiben, was schon geschieht, Aufzeichnungen führen	53	Wochen 2 bis 6
2. Entscheiden	Verantwortung, Richtlinie, Klassifizierung, Zugangsregeln	5	Wochen 1 bis 3
3. Nachweise	Wiederkehrende Tätigkeiten, beurteilt nach ihrer Historie	11	Woche 1
4. Technik	Engineering und Tooling	18	Monate 2 bis 5
5. Lieferanten	Dritte erfassen, bewerten und überprüfen	6	Woche 1
6. Nicht anwendbar	Ausschlüsse mit einer Begründung, die hält	13 Kandidaten	Mit der SoA

Die Pakete 3 und 5 beginnen zuerst, obwohl sie zuletzt fertig werden. Darin liegt der ganze Trick. Die Sicht Monat für Monat steht in Wie lange ISO 27001 wirklich dauert. Für ein Unternehmen ohne eigene Sicherheitsfunktion siehe ISO 27001 ohne Sicherheitsteam.

1. Dokumentieren, was Sie bereits tun

Das größte Paket und der Grund, warum 93 weniger beängstigend ist, als es aussieht. Sie nehmen bereits neue Mitarbeitende auf, entziehen Zugänge, wenn jemand geht (meistens), erstellen Backups und beschränken, wer an die Produktion kommt. Ein großer Teil von Anhang A verlangt, dass Sie aufschreiben, was bereits geschieht: eine Austritts-Checkliste mit Datum, eine Zugangsliste mit Unterschrift der Überprüfung, ein Backup-Job mit angehängtem Testergebnis. In der Praxis erledigen zwei Wochen unspektakulärer Dokumentation zwanzig oder mehr Controls.

Die Falle ist eine Richtlinie, die ein idealisiertes Unternehmen beschreibt. Wenn Ihr Austrittsprozess darin besteht, dass jemand dem CTO eine Nachricht schreibt, dann schreiben Sie genau das auf und verbessern es, statt einen HR-Workflow zu beschreiben, den Sie nicht haben.

2. Entscheidungen, die nur Sie treffen können

Es sind wenige, und alles andere hängt von ihnen ab. Wer für Sicherheit verantwortlich ist (5.2), wozu die Richtlinie Sie verpflichtet (5.1), wo Aufgaben getrennt werden (5.3), wie Sie Informationen klassifizieren (5.12), die Regeln für den Zugang (5.15). Die größeren Entscheidungen stehen in den Abschnitten der Norm: Anwendungsbereich, Kriterien für die Risikoakzeptanz und wer das Restrisiko freigibt.

Kein Berater und kein Tool kann sie Ihnen abnehmen. Projekte bleiben stecken, weil eine Entscheidung drei Monate offen bleibt, während um sie herum Dokumente geschrieben werden. Ein Sicherheitsaudit vor dem Programm rahmt sie in wenigen Wochen.

3. Nachweisgeneratoren: ab Woche eins starten

Das Paket, bei dem die meisten danebenliegen, und der Fehler ist teuer. Dazu gehören unter anderem Zugangsüberprüfungen (5.18, 8.2), Patch-Aufzeichnungen (8.8), Wiederherstellungstests (8.13), Protokollierung (8.15), Änderungsaufzeichnungen (8.32) und Schulung (6.3). Zwei der wichtigsten sind gar keine Controls aus Anhang A: internes Audit und Managementbewertung, Abschnitte 9.2 und 9.3.

Sie werden danach beurteilt, ob sie seit Monaten laufen. In der Praxis erwarten Auditoren eine Historie, typischerweise mindestens drei Monate vor dem Stufe-2-Audit, und sie lässt sich nachträglich nicht herstellen. Deshalb gilt: Schalten Sie sie in Woche eins ein, bevor die Richtlinien fertig sind. Eine vierteljährliche Zugangsüberprüfung, die zweimal schlecht gelaufen ist, schlägt eine, die einmal perfekt in der Woche vor dem Audit lief.

4. Die technische Arbeit

Für ein Softwareunternehmen liegt hier der eigentliche Aufwand, und 17 der 18 Controls sind technologisch. Sie umfassen Endgeräte (8.1), Authentifizierung (8.5), Konfiguration (8.9), Löschung, Maskierung und Verhinderung von Datenlecks (8.10 bis 8.12), Überwachung (8.16), Netzwerktrennung und Webfilterung (8.22, 8.23), Kryptographie (8.24) und sichere Entwicklung (8.25 bis 8.29, 8.31, 8.33). Das achtzehnte ist die IKT-Bereitschaft (5.30).

Acht der elf neuen Controls landen hier. Planen Sie echte Engineering-Wochen ein: Kein Dokument erledigt dieses Paket, und es konkurriert mit Ihrer Produkt-Roadmap.

5. Lieferanten: der lange Nachlauf

Fünf Lieferanten- und Cloud-Controls (5.19 bis 5.23) plus ausgegliederte Entwicklung (8.30) wirken klein. Sie brauchen die meiste Kalenderzeit, weil jeder Schritt auf jemand anderen wartet: Bestandsaufnahme, Klassifizierung, Sicherheitsinformationen, Bewertung, Überprüfungszyklus. Ihre Lieferantenliste ist länger, als Sie denken. Beginnen Sie in Woche eins. Unter NIS2 deckt dieselbe Arbeit einen großen Teil von Artikel 21 Absatz 2 Buchstabe d zur Sicherheit der Lieferkette ab, wie in ISO 27001 und NIS2 dargestellt.

6. Die Controls, die Sie als nicht anwendbar markieren

Wenn Sie rein in der Cloud arbeiten und keinen Serverraum haben, greifen mehrere physische Controls nicht so, wie die Norm es sich vorstellt, oder Ihr Anbieter trägt sie. Wenn Sie keine Software schreiben, fallen die Entwicklungs-Controls weg. Ein Control auszuschließen ist legitim. Schief gehen Audits dort, wo eine Begründung schon bei der ersten Nachfrage zusammenbricht.

Welche 93 Maßnahmen enthält ISO 27001?

Jedes Control aus Anhang A, mit dem Titel aus ISO/IEC 27002:2022 und einem Standard-Arbeitspaket. Behandeln Sie die Liste als ersten Entwurf Ihrer Erklärung zur Anwendbarkeit, nicht als Urteil: Verschieben Sie Zeilen passend zu Ihrer Risikobeurteilung.

ISO/IEC 27001:2022 ANHANG A: 93 CONTROLS NACH ARBEITSPAKET
E entscheiden  D dokumentieren  N Nachweise  T Technik  L Lieferanten
+ neu in 2022   * oft nicht anwendbar oder vom Anbieter getragen

5 ORGANISATORISCHE MASSNAHMEN (37)
E   5.1  Informationssicherheitspolitik und -richtlinien
E   5.2  Informationssicherheitsrollen und -verantwortlichkeiten
E   5.3  Aufgabentrennung
D   5.4  Verantwortlichkeiten der Leitung
D   5.5  Kontakt mit Behörden
D   5.6  Kontakt mit speziellen Interessengruppen
N+  5.7  Informationen über die Bedrohungslage
D   5.8  Informationssicherheit im Projektmanagement
D   5.9  Inventar der Informationen und anderer damit verbundener Werte
D   5.10 Zulässiger Gebrauch von Informationen und anderen damit verbundenen
         Werten
D   5.11 Rückgabe von Werten
E   5.12 Klassifizierung von Informationen
D   5.13 Kennzeichnung von Informationen
D   5.14 Informationsübermittlung
E   5.15 Zugangssteuerung
D   5.16 Identitätsmanagement
D   5.17 Authentisierungsinformationen
N   5.18 Zugangsrechte
L   5.19 Informationssicherheit in Lieferantenbeziehungen
L   5.20 Behandlung von Informationssicherheit in Lieferantenvereinbarungen
L   5.21 Umgang mit der Informationssicherheit in der IKT-Lieferkette
L   5.22 Überwachung, Überprüfung und Änderungsmanagement von
         Lieferantendienstleistungen
L+  5.23 Informationssicherheit für die Nutzung von Cloud-Diensten
D   5.24 Planung und Vorbereitung der Handhabung von
         Informationssicherheitsvorfällen
D   5.25 Beurteilung und Entscheidung über Informationssicherheitsereignisse
D   5.26 Reaktion auf Informationssicherheitsvorfälle
N   5.27 Erkenntnisse aus Informationssicherheitsvorfällen
D   5.28 Sammeln von Beweismaterial
D   5.29 Informationssicherheit bei Störungen
T+  5.30 IKT-Bereitschaft für Business-Continuity
D   5.31 Juristische, gesetzliche, regulatorische und vertragliche
         Anforderungen
D   5.32 Geistige Eigentumsrechte
D   5.33 Schutz von Aufzeichnungen
D   5.34 Datenschutz und Schutz personenbezogener Daten (pbD)
N   5.35 Unabhängige Überprüfung der Informationssicherheit
N   5.36 Einhaltung von Richtlinien, Vorschriften und Normen für die
         Informationssicherheit
D   5.37 Dokumentierte Betriebsabläufe

6 PERSONENBEZOGENE MASSNAHMEN (8)
D   6.1  Sicherheitsüberprüfung
D   6.2  Beschäftigungs- und Vertragsbedingungen
N   6.3  Informationssicherheitsbewusstsein, -ausbildung und -schulung
D   6.4  Maßregelungsprozess
D   6.5  Verantwortlichkeiten bei Beendigung oder Änderung der Beschäftigung
D   6.6  Vertraulichkeits- oder Geheimhaltungsvereinbarungen
D   6.7  Remote-Arbeit
D   6.8  Meldung von Informationssicherheitsereignissen

7 PHYSISCHE MASSNAHMEN (14)
D   7.1  Physische Sicherheitsperimeter
D   7.2  Physischer Zutritt
D   7.3  Sichern von Büros, Räumen und Einrichtungen
D+* 7.4  Physische Sicherheitsüberwachung
D   7.5  Schutz vor physischen und umweltbedingten Bedrohungen
D*  7.6  Arbeiten in Sicherheitsbereichen
D   7.7  Aufgeräumte Arbeitsumgebung und Bildschirmsperren
D   7.8  Platzierung und Schutz von Geräten und Betriebsmitteln
D   7.9  Sicherheit von Werten außerhalb der Räumlichkeiten
D   7.10 Speichermedien
D*  7.11 Versorgungseinrichtungen
D*  7.12 Sicherheit der Verkabelung
D   7.13 Instandhaltung von Geräten und Betriebsmitteln
D   7.14 Sichere Entsorgung oder Wiederverwendung von Geräten und
         Betriebsmitteln

8 TECHNOLOGISCHE MASSNAHMEN (34)
T   8.1  Endpunktgeräte des Benutzers
N   8.2  Privilegierte Zugangsrechte
D   8.3  Informationszugangsbeschränkung
D*  8.4  Zugriff auf den Quellcode
T   8.5  Sichere Authentisierung
D   8.6  Kapazitätssteuerung
D   8.7  Schutz gegen Schadsoftware
N   8.8  Handhabung von technischen Schwachstellen
T+  8.9  Konfigurationsmanagement
T+  8.10 Löschung von Informationen
T+* 8.11 Datenmaskierung
T+  8.12 Verhinderung von Datenlecks
N   8.13 Sicherung von Informationen
D   8.14 Redundanz von informationsverarbeitenden Einrichtungen
N   8.15 Protokollierung
T+  8.16 Überwachung von Aktivitäten
D   8.17 Uhrensynchronisation
D   8.18 Gebrauch von Hilfsprogrammen mit privilegierten Rechten
D   8.19 Installation von Software auf Systemen in Betrieb
D   8.20 Netzwerksicherheit
D   8.21 Sicherheit von Netzwerkdiensten
T   8.22 Trennung von Netzwerken
T+  8.23 Webfilterung
T   8.24 Verwendung von Kryptographie
T*  8.25 Lebenszyklus einer sicheren Entwicklung
T*  8.26 Anforderungen an die Anwendungssicherheit
T*  8.27 Sichere Systemarchitektur und Entwicklungsgrundsätze
T+* 8.28 Sichere Codierung
T*  8.29 Sicherheitsprüfung bei Entwicklung und Abnahme
L   8.30 Ausgegliederte Entwicklung
T*  8.31 Trennung von Entwicklungs-, Test- und Produktionsumgebungen
N   8.32 Änderungssteuerung
T*  8.33 Testdaten
D   8.34 Schutz der Informationssysteme während Tests im Rahmen von Audits

Was lässt Anhang A offen?

Fast jedes Control ist als Ergebnis formuliert, nicht als Standard. Das ist Absicht: Dieselbe Liste muss für ein Start-up mit drei Personen und für eine Bank passen. Die Latte legen also Ihre Erklärung zur Anwendbarkeit und Ihr Auditor, nicht das, was ein Angreifer überwinden müsste. Im Rahmen des Wortlauts der Controls:

• Authentifizierung (8.5) verlangt sichere Authentifizierung im Einklang mit Ihren Zugangsregeln. Kein Control verlangt Multi-Faktor-Authentifizierung (MFA) für jedes Konto, und genau im alten Login, den noch alle nutzen, steckt dieser Unterschied.
• Protokollierung und Überwachung (8.15, 8.16) lassen sich mit einer dokumentierten Einrichtung und einer Prüfroutine erfüllen. Ein Protokoll, das niemand liest, ist ein Speicherkostenposten, kein Control.
• Backup (8.13) ist erfüllt durch Backups, die laufen und getestet werden. Ein Job, der Erfolg gemeldet hat, ist kein System, das unter Zeitdruck von Ende zu Ende wiederhergestellt wurde.
• Schwachstellenmanagement (8.8) wird an Ihrer eigenen Patch-Richtlinie gemessen. Wenn Sie „vierteljährlich“ geschrieben haben, liegt eine kritische Lücke, die elf Wochen in der Produktion bleibt, innerhalb Ihrer eigenen Richtlinie.
• Lieferantensicherheit (5.19 bis 5.22) ist erfüllt durch abgelegte Bewertungen und regelmäßige Überprüfungen. Nichts in Anhang A verlangt, dass Sie testen, ob der Lieferant tut, was im Fragebogen steht.

Das macht die Norm nicht nutzlos. Es macht sie zu einer Untergrenze. Gehen Sie zweimal durch: „Erfüllt das das Control?“, das bringt Ihnen das Zertifikat, und „Würde das jemanden aufhalten?“, das bringt Ihnen Sicherheit. Halten Sie fest, wo die Antworten auseinandergehen. Diese Liste ist kurz, unbequem und mehr wert als das Zertifikat.

Die Lücke schließen Sie mit Nachweisen, die direkt aus den Systemen gelesen werden: MFA-Status aus dem Identitätsanbieter, Patch-Alter aus den Endpoint-Tools, Wiederherstellungsergebnisse aus der Backup-Plattform. Ein Mensch prüft, was abweicht. So arbeitet die CloudSoul-Plattform, als automatisierte Plattform mit Human-in-the-Loop-Expertise. Das vollständige Programm steht auf der ISO-27001-Seite.

Checkliste für ISO 27001 Anhang A

• Bauen Sie die Erklärung zur Anwendbarkeit auf den 93 Controls der Ausgabe 2022 auf, nicht auf den alten 114.
• Begründen Sie jeden Ausschluss so, dass er eine Nachfrage übersteht.
• Starten Sie Zugangsüberprüfungen, Patch-Aufzeichnungen, Wiederherstellungstests, Protokollierung und die Bestandsaufnahme der Lieferanten in Woche eins.
• Schließen Sie die offenen Entscheidungen: Verantwortlicher, Richtlinie, Klassifizierung, Zugangsregeln, Anwendungsbereich, Risikoakzeptanz.
• Geben Sie den neuen Controls, besonders 5.23, 8.9 und 8.28, konkrete Antworten, keinen Vorlagentext.
• Machen Sie den zweiten Durchgang: Würde jedes Control jemanden aufhalten? Wo nicht, halten Sie es fest.

Quellen

• ISO/IEC 27001:2022, Informationssicherheitsmanagementsysteme, Anforderungen, Abschnitt 6.1.3 und Anhang A, ISO.
• ISO/IEC 27001:2022/Amd 1:2024, Änderungen im Hinblick auf Klimaschutzmaßnahmen, ISO.
• ISO/IEC 27002:2022, Informationssicherheitsmaßnahmen, Abschnitte 4 bis 8 (Themen, Attribute, Titel der Controls), ISO.
• IAF MD 26:2023, Übergangsanforderungen für ISO/IEC 27001:2022, IAF.
• BSI, ISO/IEC 27001:2022: Was sich geändert hat (von 114 auf 93 Controls; 24 zusammengelegt, 58 überarbeitet, 11 neu), BSI.

Häufige Fragen