ISO 27001 Anhang A 8.24: Ein praktischer Leitfaden zu Kryptografie und Schlüsselverwaltung für IT-Dienstleister

Für die meisten IT- und software -Anbieter ist die ISO 27001-Zertifizierung längst nicht mehr nur ein nettes Extra. Sie ist zu einer Voraussetzung für die Geschäftstätigkeit geworden. In Sicherheitsfragebögen für Kunden, Ausschreibungen und Risikobewertungen von Lieferanten wird zunehmend eine aktuelle Zertifizierung verlangt, bevor ein Geschäft abgeschlossen werden kann. Das bedeutet, dass ein abgelaufenes Zertifikat nicht mehr nur ein Compliance-Problem darstellt. Es ist ein Umsatzrisiko.

Die Kryptografie steht im Mittelpunkt dieses Wandels. Mit der Überarbeitung des Standards im Jahr 2022 wurden Kryptografie und Schlüsselverwaltung in einer einzigen, klar definierten Kontrollmaßnahme zusammengefasst: Anhang A 8.24, „Einsatz von Kryptografie“. Dieser Leitfaden erläutert, was sich in der Überarbeitung von 2022 geändert hat, was die Kontrollmaßnahme 8.24 konkret verlangt und wie Sie dies einem Auditor vor Ihrem nächsten Überwachungsbesuch nachweisen können.

Was hat sich in ISO/IEC 27001:2022 geändert?

Im Rahmen der Überarbeitung von 2022 wurde Anhang A neu strukturiert und in 93 Kontrollmaßnahmen unterteilt, die vier Themenbereichen zugeordnet sind. Im Bereich Kryptografie besteht die wichtigste Änderung in einer Zusammenführung: Die beiden separaten Kontrollmaßnahmen der Ausgabe von 2013 (A.10.1.1, „Richtlinie zur Verwendung kryptografischer Kontrollmaßnahmen“, und A.10.1.2, „Schlüsselverwaltung“) wurden zu einer einzigen Kontrollmaßnahme zusammengefasst: 8.24, „Verwendung von Kryptografie“.

Diese Konsolidierung ist entscheidend dafür, wie Teams ihr Kryptografieprogramm dokumentieren und nachweisen. Anstatt Richtlinien und Schlüsselverwaltung als zwei lose miteinander verbundene Anforderungen zu behandeln, erwartet Abschnitt 8.24 ein einheitliches Gesamtkonzept: einen definierten Ansatz für die Kryptografie und einen verwalteten Lebenszyklus für die dahinterstehenden Schlüssel, die miteinander verknüpft und durch Nachweise untermauert sind.

Was die Vorschrift 8.24 tatsächlich vorschreibt

Die Vorschrift 8.24 stützt sich auf zwei Säulen.

Zum einen handelt es sich um eine dokumentierte, risikobasierte Kryptografie-Richtlinie, in der zugelassene Algorithmen und Mindestanforderungen an die Schlüsselstärke festgelegt sind. Zum anderen geht es um einen kontrollierten Schlüssellebenszyklus, der die gesamte Lebensdauer eines Schlüssels abdeckt: Generierung, Verteilung, Sperrung, Umgang mit kompromittierten Schlüsseln, Wiederherstellung verlorener Schlüssel, Speicherung, Rotation, Sicherung und Vernichtung.

Der entscheidende Punkt für IT- und „ software “-Unternehmen ist, wie Auditoren dies überprüfen. Sie verifizieren 8.24 anhand von betrieblichen Nachweisen und nicht allein anhand von Richtlinienerklärungen. In der Praxis bedeutet dies: das Zertifikats- und Schlüsselinventar, Rotationsprotokolle, aus denen hervorgeht, dass das in der Richtlinie festgelegte Intervall tatsächlich eingehalten wurde, Ausgabedaten zu „ TLS “ und zur Verschlüsselungskonfiguration, HSM- oder KMS-Zugriffsprotokolle sowie Vernichtungsprotokolle mit Unterschrift. Eine gut formulierte Richtlinie, deren Einhaltung niemand nachweisen kann, wird einen Prüfer nicht zufriedenstellen. Und da sich 8.24 auf das Produkt bezieht, umfasst sein Geltungsbereich routinemäßig auch die im Produkt selbst eingebettete Kryptografie, nicht nur die interne IT-Umgebung.

Warum die Einhaltung der Kryptografie-Vorgaben der ISO 27001 für IT-Anbieter wichtig ist

Die Zertifizierung nach ISO 27001 ist technisch gesehen freiwillig. In der Praxis ist sie für Anbieter von IT- und „ software “-Lösungen jedoch zu einer de facto geschäftlichen Voraussetzung geworden. Sicherheitsfragebögen, Ausschreibungen und Lieferantenrisikobewertungen verlangen zunehmend eine aktuelle Zertifizierung als Voraussetzung für eine Geschäftsbeziehung. Daher können Lücken in Ihren kryptografischen Kontrollmaßnahmen die Beschaffung verzögern und Geschäfte kosten; dies wirkt sich auf zwei Arten auf die Beschaffung aus: Entweder taucht es direkt in einer Antwort auf einen Sicherheitsfragebogen auf, die Sie nicht belegen können, oder es wird zu einer Nichtkonformität, die das Zertifikat selbst gefährdet.

Hinzu kommt noch die zeitliche Dimension. Da es sich bei ISO 27001 um eine Norm für Managementsysteme handelt, wird 8.24 nicht nur einmal geprüft und dann vergessen.  Bei Überwachungsaudits wird das ISMS stichprobenartig geprüft, anstatt jede einzelne Kontrollmaßnahme zu testen; daher kann 8.24 in einem bestimmten Jahr zur Sprache kommen oder auch nicht. Bei der Rezertifizierung verhält es sich anders: Hier wird bestätigt, dass das System alle Anforderungen der Norm erfüllt, nicht nur die Bereiche, die bei den Überwachungsaudits stichprobenartig geprüft wurden. In der Praxis lässt sich nicht vorhersagen, in welchem Jahr die Kryptografie geprüft wird. Dieser Rhythmus belohnt Organisationen, die eine kontinuierliche, nachweisbare Kontrolle über die Kryptografie aufrechterhalten, anstatt vor jedem Audit hastig versuchen zu müssen, diese nachzurüsten.

Es ist wichtig zu wissen, wie es tatsächlich zum Verlust eines Zertifikats kommt: Eine schwerwiegende Nichtkonformität führt nicht sofort zum Erlöschen des Zertifikats. Zertifizierungsstellen legen eine bestimmte Frist fest, innerhalb derer der Mangel behoben werden muss, und eine Aussetzung oder ein Entzug erfolgt erst, wenn dieser nicht behoben wird. Das geschäftliche Risiko besteht weniger darin, dass „wir ein Audit nicht bestanden haben“, als vielmehr darin, dass „wir ein Quartal lang eine offene schwerwiegende Nichtkonformität hatten, die wir offenlegen mussten“.

Wie sich 8.24 auf konkrete kryptografische Kontrollmaßnahmen abbilden lässt

Kontrollpunkt 8.24 steht nicht für sich allein. Er steht in Zusammenhang mit einer Reihe praktischer Kontrollbereiche, von denen die Gutachter erwarten, dass sie im gesamten zertifizierten Geltungsbereich zusammenwirken.

Eine dokumentierte Richtlinie zur Kryptografie und Schlüsselverwaltung (Anhang A 8.24)

Im Kern fordert 8.24 eine themenspezifische Richtlinie, die zugelassene Algorithmen, Mindestschlüssellängen und Regeln für den Lebenszyklus festlegt. Diese Richtlinie sollte direkt mit der ISMS-Risikobewertung verknüpft sein, sodass jede kryptografische Entscheidung auf ein dokumentiertes Risiko zurückzuführen ist und nicht auf eine Präferenz.

Der Lebenszyklus kryptografischer Schlüssel (Anhang A 8.24)

Der Lebenszyklus ist der Bereich, in dem starke Kryptografie am häufigsten versagt. Prüfer erwarten eine zentralisierte Erstellung, Verteilung, Rotation und Vernichtung von Schlüsseln und Zertifikaten, einschließlich derer, die in ausgelieferten „ software “ eingebettet sind, und zwar gestützt durch einen lückenlosen Prüfpfad. Die Sperrung, der Umgang mit kompromittierten Schlüsseln, die Wiederherstellung verlorener Schlüssel, die sichere Speicherung und die Datensicherung runden das Bild ab.

Vertraulichkeit und Integrität von Daten (Anhang A 5.14, 8.20, 8.21; personenbezogene Daten gemäß 5.34)

Kryptografie dient dem Schutz von Daten. Gemäß Abschnitt 8.24 ist die Kryptografie der Mechanismus; die Kontrollmaßnahmen, die die Verpflichtung begründen, sind an anderer Stelle zu finden. Anhang A, Abschnitt 5.34 (Informationsübertragung) sowie die Abschnitte 8.20–8.21 (Netzwerksicherheit und Sicherheit von Netzwerkdiensten) regeln die Verschlüsselung während der Übertragung. Von der PKI ausgestellte Zertifikate sichern Kundendaten sowohl im Ruhezustand als auch während der Übertragung innerhalb des zertifizierten Geltungsbereichs. Für Anbieter von „ software “-Lösungen erstreckt sich dieser Geltungsbereich üblicherweise auf Multi-Tenant-SaaS-Umgebungen, in denen sich viele Kunden dieselbe Infrastruktur teilen.

Produktkryptografie (Anhang A 8.25, 8.26, 8.28)

Wenn Kryptografie in Ihren Produkten integriert ist, prüfen die Prüfer anhand des sicheren Entwicklungslebenszyklus (8.25), der Anforderungen an die Anwendungssicherheit (8.26) und der sicheren Programmierung (8.28), ob die in Ihrer Richtlinie 8.24 festgelegten Entscheidungen bezüglich Algorithmen und Schlüssellängen tatsächlich in den Quellcode einfließen. Die Lieferantenkontrollen beziehen sich auf importierte Bibliotheken; diese wiederum beziehen sich auf Ihren eigenen Code.

Sichere Authentifizierung (Anhang A 8.5)

Anhang A 8.5 bringt das Thema Authentifizierung in die Diskussion um Kryptografie ein. Die zertifikatsbasierte Authentifizierung verringert die Abhängigkeit von gemeinsamen Geheimnissen und statischen Passwörtern sowohl beim Kundenzugang als auch beim administrativen Zugriff und ersetzt Anmeldedaten, die leicht offengelegt werden können, durch Identitäten, die weitaus schwieriger zu missbrauchen sind.

Supplier and inherited cryptography (Annex A 5.21, 8.8)
Modern software inherits cryptography from libraries and third parties. Annex A 8.24 requires a key management system to handle key revocation, compromised keys. Every one of those duties is owed per key, and a per-key duty presupposes knowing which keys exist. For Annex A 8.8, an accurate asset inventory is a prerequisite for effective vulnerability management. Annex A 5.21 extends the question into the ICT supply chain, where the components are someone else’s code. Read together, the inventory is not a stated requirement; it is the only practical way to evidence four that are.

Statement of Applicability traceability (Clause 6.1.3)
Finally, Clause 6.1.3 ties it all back to governance. Centralized reporting that maps cryptographic controls to documented risk treatment decisions gives auditors a clear, traceable line from a control to the risk it addresses.

Vorbereitung auf die Prüfung: Was die Prüfer untersuchen

Wenn ein Gutachter die Stufe 8.24 erreicht, sucht er nach Beweisen und nicht nach Absichten. Die folgenden Bereiche werden von ihm systematisch untersucht:

• Eine dokumentierte Kryptografie-Richtlinie, die sowohl interne Systeme als auch ausgelieferte Produkte abdeckt und in der zugelassene Algorithmen, Mindestschlüssellängen sowie die Bedingungen, unter denen eine Verschlüsselung vorgeschrieben ist, festgelegt sind.
• Nachweise zum Lebenszyklus von Schlüsseln: Aufzeichnungen, keine Verfahren: Rotationsprotokolle, aus denen hervorgeht, dass das in der Richtlinie festgelegte Intervall eingehalten wurde, Vernichtungsprotokolle mit Unterschrift, Aktivitätsprotokolle für jeden einzelnen Schlüssel sowie Aktivierungs- und Deaktivierungsdaten.
• Erklärung zur Rückverfolgbarkeit der Anwendbarkeit, die die Einbeziehung von 8.24 begründet und diese mit der zugrunde liegenden Risikobewertung verknüpft.
• Einhaltung gesetzlicher und gerichtlicher Vorschriften, einschließlich Exportkontrollen und Überlegungen zur Datenlokalisierung.
• Eine aktuelle Übersicht über Zertifikate und Schlüssel mit Angabe der jeweiligen Inhaber und Ablaufdaten, einschließlich der in den Versionen von „ software “ eingebetteten Schlüssel.
• Prüfung der 8.24-Kontrollen durch die interne Revision, wobei die Ergebnisse im Rahmen des ISMS-Zyklus von der Geschäftsleitung überprüft werden.
• Richtlinie zur Konfigurationsübereinstimmung. Die Prüfer vergleichen die in Ihrer Richtlinie zugelassenen Algorithmen und Schlüssellängen mit den tatsächlich eingesetzten. Eine Abweichung zwischen Richtlinie und tatsächlicher Situation gilt als Nichtkonformität, selbst wenn sowohl die Richtlinie als auch die Konfiguration für sich genommen vertretbar sind.

Der rote Faden ist Eigentumsrecht und Rückverfolgbarkeit. Jede Aussage, die Sie zur Kryptografie treffen, sollte durch ein Artefakt untermauert werden, das ein Prüfer untersuchen kann.

Wie Keyfactor helfen Keyfactor

Bei Meeting 8.24 geht es letztlich um Transparenz, festgelegte Regeln und eine disziplinierte Schlüsselverwaltung in großem Maßstab. Die Plattform von Keyfactordeckt sich direkt mit den oben genannten Kontrollbereichen.

• AgileSec erstellt ein Verzeichnis der kryptografischen Komponenten, das die Lieferantenüberprüfung unterstützt, und erstellt Nachweise in Form von Anwendbarkeitserklärungen für eingebettete oder Komponenten von Drittanbietern.
• EJBCA stellt die PKI bereit, die die durch Zertifikate gesicherte Vertraulichkeit und Integrität der Daten gewährleistet, sowie ein zentralisiertes Schlüssellebenszyklusmanagement, einschließlich der in ausgelieferten „ software “ eingebetteten Schlüssel.
• Keyfactor Command sorgt für die Einhaltung der Richtlinien, bietet Transparenz über den gesamten Lebenszyklus der Schlüssel, verwaltet ein Zertifikats- und Schlüsselinventar und erstellt Rückverfolgbarkeitsberichte gemäß der „Statement of Applicability“.

Zusammen bilden diese Funktionen ein einheitliches Referenzsystem für die Kryptografie, das genau die Nachweise liefert, die ein ISO 27001-Auditor verlangt, anstatt die Teams dazu zu zwingen, diese manuell zusammenzustellen.

Fazit und nächste Schritte

Die Botschaft, die sich durch die Version 8.24 zieht, ist einheitlich: Die Kontrolle legt mehr Wert auf Eigentumsverhältnisse, Rückverfolgbarkeit und Nachweise als auf Grundsatzerklärungen. Die Zertifizierung hängt weniger davon ab, ob ein Dokument die richtigen Formulierungen enthält, sondern vielmehr davon, ob auf Anfrage nachgewiesen werden kann, wie die Kryptografie geregelt ist und wie die Schlüssel verwaltet werden.

Der nächste praktische Schritt ist ganz einfach: Überprüfen Sie vor Ihrem nächsten Audit Ihre aktuelle Kryptografie-Richtlinie und Ihren Schlüsselbestand anhand von Abschnitt 8.24 und zentralisieren Sie die entsprechenden Nachweise, anstatt sie in verstreuten Tabellenkalkulationen zu erfassen.

Möchten Sie erfahren, wie automatisierte Kryptografie und das Schlüssellebenszyklusmanagement mit Anhang A 8.24 in Einklang stehen? Fordern Sie eine Demo an.

Haben Sie Fragen zur Kryptografie im Zusammenhang mit der Norm ISO 27001? Wir haben die Antworten.

What is ISO/IEC 27001 Annex A 8.24?
Annex A 8.24, Use of Cryptography, is the ISO 27001:2022 control governing how an organization uses cryptography. It requires a documented, risk-based cryptography policy and a managed key lifecycle, verified through operational evidence rather than policy statements alone. Annex A itself states the control in a single sentence; the detailed expectations sit in ISO/IEC 27002:2022, which auditors use as the yardstick.

What changed for cryptography in the 2022 revision?
The 2022 revision restructured Annex A into 93 controls across four themes. It consolidated the 2013 edition’s separate cryptography and key management controls into a single control, 8.24.

Does 8.24 cover cryptography inside the products we ship?
Yes. For software and IT service companies, the scope of 8.24 routinely includes cryptography embedded in the product itself, not only the internal IT environment.

What does a compliant cryptography policy need to include?
It should be a topic-specific policy defining approved algorithms, minimum key lengths, and the conditions under which encryption is mandatory. It must be tied to the ISMS risk assessment and cover both internal systems and shipped products.

What key lifecycle evidence do auditors expect?
Auditors expect demonstrated procedures for key generation, secure storage, rotation, and destruction, not just a written policy. A current certificate and key inventory with named owners and expiry dates supports this.

How often is 8.24 tested?
Because ISO 27001 is a management-system standard, 8.24 is tested at annual surveillance audits and in full at the three-year recertification.

Why does ISO 27001 certification matter commercially?
Certification has become a de facto commercial prerequisite for IT and software vendors. Security questionnaires, RFPs, and supplier risk assessments increasingly require current certification, so a lapsed certificate can directly threaten revenue.

How does 8.24 relate to the Statement of Applicability?
The Statement of Applicability must justify including 8.24 and link it to the underlying risk assessment. Centralized reporting that maps cryptographic controls to documented risk treatment decisions supports auditor review under Clause 6.1.3.