C5 domain DEV: making development and changes audit-ready

This page covers the DEV domain (Procurement, Development and Modification of Information Systems) of C5:2026, section 5.11 of the catalogue. How criteria and subcriteria are structured in general is explained on the page C5 criteria catalogue.

What is the DEV domain about?

DEV sets out how the provider develops, changes and deploys its service and the related system components securely. The domain comprises 15 criteria, DEV-01 to DEV-15, with 32 basic subcriteria and 10 complementing additional subcriteria; there are no sharpening additional subcriteria in DEV. According to the BSI change history, five criteria are new compared with C5:2020: DEV-05, DEV-11, DEV-13, DEV-14 and DEV-15. The operation of the service, such as patch and vulnerability management or backup, is covered by the OPS domain.

Starting point: a SaaS provider with its own pipeline

Fictitious example, not a client. A provider runs a document management system for local authorities as SaaS. Twelve people in two teams develop the service in a Git system; a CI/CD pipeline builds container images, tests them and rolls them out several times a week to a managed Kubernetes on a cloud platform. The team describes network, cluster and databases as code in the same Git system. An external agency develops the mobile app for case workers. The product contains several hundred open source libraries. Several local authorities require a C5 type 2 attestation for a tender.

The starting position is good: much of what DEV requires is already done by the pipeline. What is usually missing are the rules behind it and the evidence that they applied over the whole audit period.

Who is responsible for what: provider, platform, customer?

The DEV criteria apply to everything the provider develops and changes itself, including platforms, virtual infrastructure and other system components, not only to the application (supplementary information on DEV-01). In the example, the boundaries with platform and customer look like this:

The auditor tests the provider’s own controls; the platform’s controls come in through its report and your monitoring. The complementary customer criteria are general notes in the catalogue and are not exhaustive. Which customer controls your service assumes is for you to decide, and you describe them as complementary customer controls (also called complementary user entity controls, CUEC); how to do that is explained on the page Complementary customer criteria.

How does change management in a CI/CD pipeline become audit-ready?

By mapping every stage of the pipeline to a criterion and making it leave a trail. The catalogue does not require a centralised change management process with a change advisory board; agile methods are expressly permitted as long as they adhere to the defined procedures and technical safeguards (supplementary information on DEV-03). Two clarifications from the catalogue help with the scoping:

• What a change is: anything that can change the configuration, functionality or security of system components in production, that is, infrastructure and source code, and expressly also network configuration and container images.
• Releases count as one change: If you combine many commits into a release, the release is the change within the meaning of DEV-03, not each individual commit.

You inform customers about the type and scope of changes and any resulting obligations to cooperate as the contract provides; under DEV-03 this belongs in the policy. For a type 2 report, significant changes to the system of internal control during the period are also included in the system description; how to word them is explained on the page Significant changes and events.

How do you separate development, test and production environments under DEV-12?

Physically or logically, so that test and development allow no unauthorised access to customer data, no spread of malware and no unintended changes to production (DEV-12.01B). Two rules from DEV-12 are easy to overlook:

• No production data in test or development unless the customers have explicitly approved it. For tests with customer data, DEV-07.03B additionally requires the data to be anonymised beforehand.
• No shared secrets: keys, certificates and other secrets of production are not reused in other environments. If this is unavoidable, document and justify the exception via the exception process (SP-03) and risk management (DEV-12.02B).

Our recommendation for the example: a separate account or project on the cloud platform for each environment, separate clusters for production and staging, separate secret stores and a pipeline account that is the only one allowed to write to production. This is easier to evidence than separation via namespaces in a shared cluster. Under DEV-11 the development and test environments themselves need a risk assessment and appropriate safeguards; the necessary parts belong in the backup plan.

Example control description for DEV-10

This is how the approval control could look in the example. The template is our own wording, not catalogue text; the field scheme is explained on the page System description.

Whether the control covers all mapped subcriteria is for the auditor to assess. A criterion counts as not met if a single subcriterion is not met (section 3.4.12).

What evidence the auditor wants to see

Above all, records from the systems that are created anyway, and for the whole audit period. For a type 2 report it is not enough to demonstrate the pipeline on the day of the audit. Our overview for the example:

How to keep such records in an evidence register is shown on the page Evidence and documentation. For an initial engagement, the catalogue allows evidence from a non-production environment configured like production for controls that have not yet operated in production (section 3.4.11).

Possible gaps: cause, effect, remedy

We derive the following gaps from the requirements of the catalogue. They are not auditor findings, but they show where a pipeline that works well day to day may not yet be enough for an audit.

Plan the remedy before a type 2 period starts: a control that is only introduced in the middle of the period provides no evidence for the weeks before. How to put gaps across several domains into a sensible order is shown on the page Prioritising measures.

All criteria of the DEV domain

Titles as in the English version 1.0.1, number of subcriteria counted per section 5 (B = basic, AS = sharpening, AC = complementing). The column “What it covers” is our own short description, not catalogue text; the wording of the criteria in the catalogue is binding.

Relationship to ISO/IEC 27001:2022 Annex A

If you hold an ISO 27001 certificate, you will find many DEV topics in Annex A of the standard. The following mapping is our own, unofficial classification by topic. The BSI has not yet published a cross-reference for C5:2026. The catalogue refers to the BSI website for it (section 3.3). So far the table there covers C5:2020 only, and the BSI says the table for C5:2026 is “scheduled for publication in the near future” (as of 6 November 2026). According to the catalogue, even an official table only shows thematic proximity, not fulfilment of the criteria (section 3.3). The short labels are ours, not titles from the standard. What a certificate brings for C5 overall is covered on the page C5 and ISO 27001.