C5:2026: was sich ändert.

• 168 Kriterien in 17 Bereichen. C5:2020 hatte 121.
• 462 Basis-Unterkriterien. Zusatzkriterien gibt es in zwei Formen: 29 „additional sharpen“ ersetzen ein Basis-Unterkriterium durch eine strengere Fassung, 132 „additional complement“ kommen obendrauf.
• Erstmals maschinenlesbar: neben PDF und Excel gibt es den Katalog als YAML.
• Ausgerichtet an ISO/IEC 27001:2022, CSA CCM v4, den EUCS-Vorarbeiten (CEN/CENELEC TS 18026) und NIS2.
• Die Transparenzangaben heißen jetzt General Conditions (GC-01 bis GC-06), vorher Basic Conditions (BC).

• Verbindlich für Typ-1-Stichtage und Typ-2-Prüfzeiträume, die am oder nach dem 01.06.2027 beginnen. Eine frühere Anwendung ist zulässig.
• Typ-2-Prüfzeiträume, die vor dem 01.06.2027 beginnen, laufen vollständig nach C5:2020. Einen Mischbetrieb gibt es nicht.
• Endet ein Typ-2-Prüfzeitraum am oder nach dem 28.02.2027, braucht die Systembeschreibung Zusatzangaben zur geplanten Umstellung auf C5:2026.

Praktisch heißt das: Bei einem jährlichen Zyklus beginnt Ihr erster Prüfzeitraum nach C5:2026 zwischen Juni 2027 und Mai 2028. Die Vorbereitung dafür fällt in die kommenden Monate, und die Zusatzangaben können schon im laufenden Bericht fällig werden.

Laut offiziellem Changelog behalten 78 Kriterien ihre ID, 51 ziehen auf eine neue ID um und 39 sind neu. INQ-01 und INQ-03 aus C5:2020 haben keinen Nachfolger. Manche Beratungen sprechen von 48 neuen Kriterien, weil sie aufgeteilte Kriterien mitzählen. Der Changelog zählt 39.

Am stärksten wachsen Kryptografie und Schlüsselmanagement (CRY, von 4 auf 19 Kriterien), Betrieb (OPS, von 24 auf 35), Asset Management (AM, von 6 auf 12), Entwicklung (DEV, von 10 auf 15) und Dienstleistersteuerung (SSO, von 5 auf 8). Identitäts- und Berechtigungsmanagement heißt jetzt IAM statt IDM.

OPS-18 legt fest, was Ihre Richtlinie zum Schwachstellen-Management regeln muss: regelmäßige Suche nach Schwachstellen, Bewertung nach CVSS, Priorisierung mit Blick auf EPSS und SSVC, Umgang mit Systemen, die bewusst nicht gepatcht werden, und die Schnittstelle zum Incident Management.

Für kritische Schwachstellen muss die Bearbeitung zeitnah nach der Entdeckung beginnen, auch außerhalb der Arbeitszeit. Für hohe Schwachstellen spätestens am nächsten Arbeitstag. Wer sich gegen eine Behebung entscheidet, braucht eine Risikobewertung, die regelmäßig überprüft wird.

Ein Detail, das zu awedit passt: Werden KI-Werkzeuge für Schwachstellenscans oder Penetrationstests eingesetzt, verlangt OPS-18 eine nachvollziehbare Dokumentation, und die Werkzeuge sollen die Fachleute unterstützen, nicht ersetzen.

OPS-25 verlangt Schwachstellenscans mindestens monatlich, in der verschärften Variante täglich, mit Abgleich gegen aktuelle Schwachstellendatenbanken wie CVE und EUVD. Die Ergebnisse fließen in die SIEM-Regeln ein, damit aktive Ausnutzung erkannt wird. Als Beispiel für Behebungsfristen nennt der Katalog: kritisch 24 bis 48 Stunden, hoch 48 bis 72 Stunden, mittel 5 Tage, niedrig 1 Monat. Das ist ein Beispiel für ein risikobasiertes Raster, keine feste Vorgabe.

In Ratgebern kursiert eine Frist von drei Stunden für kritische Patches. Im Katalog steht sie nicht.

Penetrationstests (OPS-22) laufen mindestens jährlich und bei wesentlichen Änderungen. Bei mehrjährigen Testplänen muss jede relevante Komponente spätestens alle drei Jahre getestet werden. Gefundene Schwachstellen bekommen eine Ursachenanalyse.

In C5:2020 lief Patching im Schwachstellen-Kontext mit. C5:2026 gibt ihm eigene Kriterien: OPS-27 für Richtlinien und Verfahren, OPS-28 für die Umsetzung. Gefordert sind unter anderem Tests in einer Nicht-Produktivumgebung, ein Rückfallweg auf die Vorversion, die Einbindung ins Change Management und ein Scan nach dem Patchen, der bestätigt, dass die Lücke geschlossen ist.

Neu ist OPS-29 für extern bezogene Komponenten: Updates und bekannte Schwachstellen in Drittanbieter- und Open-Source-Bibliotheken regelmäßig erkennen, bewerten, zeitnah einspielen und laufend überwachen.

Dazu kommt DEV-13: Für jede entwickelte oder integrierte Softwarekomponente wird eine Liste der Softwarekomponenten erstellt und aktuell gehalten. DEV-14 regelt die Nutzung von Drittanbieter- und Open-Source-Software, inklusive vertrauenswürdiger Bezugsquellen. Eine SBOM nennt der Katalog als möglichen Weg, nicht als Pflicht. Als Nachweis für DEV-13 und OPS-25 liegt eine gepflegte SBOM trotzdem nahe.

OPS-34 und OPS-35 sind neu. Die Richtlinie muss den gesamten Lebenszyklus abdecken: Image-Erstellung, Test und Validierung, Ablage und Abruf, Deployment, Betrieb und Außerbetriebnahme. Dazu gehören Inventarisierung der Container, Logging entlang des Lebenszyklus, Trennung von Kundendaten, Zugriff auf den Container-Host nach Rollenkonzept, Verschlüsselung, Netzwerküberwachung, geregelte Änderungen und Härtung.

Die Zusatzkriterien gehen weiter: signierte Container-Images mit sicher verwahrtem Signaturschlüssel, Laufzeitüberwachung und regelmäßige Scans der Images und ihrer Abhängigkeiten. PSS-11 regelt, was Kunden bei Images zusteht, etwa Herkunftskennzeichnung und gehärtete Images.

• Threat Intelligence (OIS-05) und Informationssicherheit im Projektmanagement (OIS-10).
• Mobiles Arbeiten (HR-07, HR-08).
• Getrennte Hardware- und Software-Inventare (AM-03, AM-04).
• Datentrennung (OPS-30, OPS-31) und Confidential Computing mit Remote Attestation (OPS-32, OPS-33).
• Kryptografie über den ganzen Schlüssel-Lebenszyklus, inklusive Krypto-Änderungsmanagement (CRY-02), externer Schlüsselverwaltung (CRY-18) und kundenverwalteter Schlüssel (CRY-19).
• Incident-Response-Pläne (SIM-02) und mehr Transparenz in der Lieferkette (SSO-03, SSO-07, SSO-08).

• Typ 1 bleibt Erstprüfungen vorbehalten. Wer die Nachweise hat, kann direkt mit Typ 2 starten.
• Neu ist eine Prüfvariante, bei der der Prüfer das Kontrollsystem selbst herleitet, für Anbieter mit schwacher Dokumentation.
• C5:2026 warnt ausdrücklich davor, die Carve-out-Methode zu nutzen, um Anforderungen zu umgehen. Das Testat Ihres Hyperscalers deckt dessen Schichten ab, nicht Ihre.
• Das Testat kommt weiterhin ausschließlich von einem Wirtschaftsprüfer. Ein C5-Zertifikat gibt es auch unter C5:2026 nicht.

1. Mapping: jedes C5:2020-Kriterium auf seine C5:2026-Entsprechung legen. Der offizielle Changelog ist die Grundlage.
2. Die 39 neuen Kriterien gegen vorhandene Evidenz prüfen, zuerst OPS, CRY, AM und DEV.
3. Evidenz über Zeit aufsetzen, wo bisher ein Stichtagsnachweis genügte: Scan-Läufe, Patch-Historie, Ticket-Verläufe, Komponentenlisten.
4. Die Systembeschreibung um die Umstellungsangaben ergänzen, wenn Ihr Typ-2-Zeitraum am oder nach dem 28.02.2027 endet.
5. Den Prüfer früh einbinden. Qualifizierte Prüfer melden Wartezeiten von 3 bis 6 Monaten.

awedit legt Ihren Stand auf C5:2026 um, Expert:innen priorisieren die Lücken, der Wirtschaftsprüfer testiert.