C5-Themengebiet DEV: Entwicklung und Änderungen prüffähig machen

Diese Seite behandelt das Themengebiet DEV (Beschaffung, Entwicklung und Änderung von Informationssystemen) des C5:2026, Abschnitt 5.11 des Katalogs. Wie Kriterien und Unterkriterien grundsätzlich aufgebaut sind, erklärt die Seite C5-Kriterienkatalog.

Worum geht es im Themengebiet DEV?

DEV regelt, wie der Anbieter seinen Dienst und die zugehörigen Systemkomponenten sicher entwickelt, ändert und bereitstellt. Das Gebiet umfasst 15 Kriterien, DEV-01 bis DEV-15, mit 32 Basis-Unterkriterien und 10 erweiternden Zusatz-Unterkriterien; verschärfende Zusatz-Unterkriterien gibt es in DEV nicht. Fünf Kriterien sind laut Änderungshistorie des BSI neu gegenüber C5:2020: DEV-05, DEV-11, DEV-13, DEV-14 und DEV-15. Den Betrieb des Dienstes, also Patch- und Schwachstellenmanagement oder Datensicherung, regelt das Gebiet OPS.

Ausgangssituation: ein SaaS-Anbieter mit eigener Pipeline

Fiktives Beispiel, kein Kunde. Ein Anbieter betreibt ein Dokumentenmanagementsystem für Kommunalverwaltungen als SaaS. Zwölf Personen in zwei Teams entwickeln den Dienst in einem Git-System; eine CI/CD-Pipeline baut Container-Images, testet sie und rollt sie mehrmals pro Woche auf ein verwaltetes Kubernetes einer Cloud-Plattform aus. Netz, Cluster und Datenbanken beschreibt das Team als Code im selben Git-System. Eine externe Agentur entwickelt die mobile App für Sachbearbeitende. Im Produkt stecken mehrere hundert Open-Source-Bibliotheken. Mehrere Kommunen verlangen für eine Ausschreibung ein C5-Testat Typ 2.

Die Ausgangslage ist gut: Vieles, was DEV verlangt, erledigt die Pipeline schon. Was fehlt, sind meist die Regeln dahinter und die Belege, dass sie über den ganzen Prüfungszeitraum galten.

Wer ist wofür verantwortlich: Anbieter, Plattform, Kunde?

Die DEV-Kriterien gelten für alles, was der Anbieter selbst entwickelt und ändert, auch für Plattformen, virtuelle Infrastruktur und andere Systemkomponenten, nicht nur für die Anwendung (ergänzende Informationen zu DEV-01). Die Grenzen zu Plattform und Kunde sehen im Beispiel so aus:

Die eigenen Kontrollen des Anbieters prüft der Prüfer; die Kontrollen der Plattform gehen über deren Bericht und Ihre Überwachung ein. Die korrespondierenden Kriterien für Kunden sind allgemeine Hinweise des Katalogs und nicht abschließend. Welche Kundenkontrollen Ihr Dienst voraussetzt, legen Sie selbst fest und beschreiben sie als CUEC; wie das geht, steht auf der Seite Korrespondierende Kriterien.

Wie wird das Änderungsmanagement in einer CI/CD-Pipeline prüffähig?

Indem jede Stufe der Pipeline einem Kriterium zugeordnet ist und Spuren hinterlässt. Der Katalog verlangt keinen zentralen Änderungsprozess mit Änderungsbeirat; agile Verfahren sind ausdrücklich zulässig, solange sie die festgelegten Verfahren und technischen Schutzmaßnahmen einhalten (ergänzende Informationen zu DEV-03). Zwei Klarstellungen aus dem Katalog helfen beim Zuschnitt:

• Was eine Änderung ist: alles, was Konfiguration, Funktion oder Sicherheit von Systemkomponenten in der Produktion verändern kann, also Infrastruktur und Quellcode, ausdrücklich auch Netzkonfiguration und Container-Images.
• Releases zählen als eine Änderung: Fassen Sie viele Commits zu einem Release zusammen, ist das Release die Änderung im Sinne von DEV-03, nicht jeder einzelne Commit.

Kunden informieren Sie über Art und Umfang von Änderungen und daraus folgende Mitwirkungspflichten so, wie es der Vertrag vorsieht; das gehört nach DEV-03 in die Richtlinie. Bei einem Typ-2-Bericht kommen wesentliche Änderungen am internen Kontrollsystem während des Zeitraums zusätzlich in die Systembeschreibung; wie Sie diese formulieren, erklärt die Seite Wesentliche Änderungen und Ereignisse.

Wie trennen Sie Entwicklungs-, Test- und Produktionsumgebung nach DEV-12?

Physisch oder logisch, so dass aus Test und Entwicklung kein unbefugter Zugriff auf Kundendaten, keine Ausbreitung von Schadprogrammen und keine unbeabsichtigten Änderungen an der Produktion möglich sind (DEV-12.01B). Zwei Regeln aus DEV-12 sind leicht zu übersehen:

• Keine Produktionsdaten in Test oder Entwicklung, es sei denn, die Kunden haben es ausdrücklich genehmigt. Für Tests mit Kundendaten verlangt DEV-07.03B zusätzlich, die Daten vorher zu anonymisieren.
• Keine gemeinsamen Geheimnisse: Schlüssel, Zertifikate und andere Geheimnisse der Produktion werden in anderen Umgebungen nicht wiederverwendet. Ist es unvermeidbar, dokumentieren und begründen Sie die Ausnahme über den Ausnahmeprozess (SP-03) und das Risikomanagement (DEV-12.02B).

Unsere Empfehlung für das Beispiel: je Umgebung ein eigenes Konto oder Projekt auf der Cloud-Plattform, eigene Cluster für Produktion und Staging, getrennte Geheimnisspeicher und ein Pipeline-Konto, das als einziges in die Produktion schreiben darf. Das ist einfacher zu belegen als eine Trennung über Namensräume in einem gemeinsamen Cluster. Die Entwicklungs- und Testumgebungen selbst brauchen nach DEV-11 eine Risikobeurteilung und passende Schutzmaßnahmen; die nötigen Teile gehören in den Datensicherungsplan.

Beispiel-Kontrollbeschreibung zu DEV-10

So könnte die Freigabekontrolle im Beispiel aussehen. Das Muster ist eine eigene Formulierung, kein Katalogtext; das Feldschema erklärt die Seite Systembeschreibung.

Ob die Kontrolle alle zugeordneten Unterkriterien abdeckt, beurteilt der Prüfer. Ein Kriterium gilt als nicht erfüllt, wenn ein einziges Unterkriterium nicht erfüllt ist (Abschnitt 3.4.12).

Welche Nachweise der Prüfer sehen will

Vor allem Belege aus den Systemen, die ohnehin entstehen, und zwar für den ganzen Prüfungszeitraum. Für einen Typ-2-Bericht reicht es nicht, die Pipeline am Tag der Prüfung vorzuführen. Unsere Übersicht für das Beispiel:

Wie Sie solche Belege in einem Nachweisregister führen, zeigt die Seite Nachweise und Dokumentation. Bei einer Erstprüfung lässt der Katalog für Kontrollen, die noch nicht in der Produktion gelaufen sind, Nachweise aus einer Nicht-Produktionsumgebung zu, die wie die Produktion konfiguriert ist (Abschnitt 3.4.11).

Mögliche Lücken: Ursache, Wirkung, Abhilfe

Die folgenden Lücken leiten wir aus den Anforderungen des Katalogs ab. Sie sind keine Prüferfeststellungen, zeigen aber, wo eine Pipeline, die im Alltag gut funktioniert, für eine Prüfung noch nicht reichen kann.

Planen Sie die Abhilfe vor Beginn eines Typ-2-Zeitraums ein: Eine Kontrolle, die erst mitten im Zeitraum eingeführt wird, liefert für die Wochen davor keine Nachweise. Wie Sie Lücken über mehrere Themengebiete in eine sinnvolle Reihenfolge bringen, zeigt die Seite Maßnahmen priorisieren.

Alle Kriterien des Themengebiets DEV

Titel nach der deutschen Fassung 1.1.0, Zählung der Unterkriterien nach Abschnitt 5 (B = Basis, AS = verschärfend, AC = erweiternd). Die Spalte „Worum es geht“ ist unsere eigene Kurzbeschreibung, kein Katalogtext; verbindlich ist der Wortlaut der Kriterien im Katalog.

Bezug zu ISO/IEC 27001:2022 Anhang A

Haben Sie ein ISO-27001-Zertifikat, finden Sie viele DEV-Themen in Anhang A der Norm wieder. Die folgende Zuordnung ist unsere eigene, nicht amtliche Einordnung nach Thema. Das BSI hat für C5:2026 noch keine Kreuzreferenz veröffentlicht, und auch eine amtliche Tabelle zeigt nach dem Katalog nur thematische Nähe, keine Erfüllung (Abschnitt 3.3). Die Kurzbezeichnungen sind unsere, keine Titel aus der Norm. Was ein Zertifikat insgesamt für C5 bringt, steht auf der Seite C5 und ISO 27001.