C5 domain CRY: making encryption and keys audit-ready

This page covers the CRY domain (Cryptography and Key Management) of C5:2026, section 5.8 of the catalogue. How criteria and subcriteria are structured in general is explained on the page C5 criteria catalogue.

What is the CRY domain about?

CRY requires cryptography to be used appropriately and effectively to protect the confidentiality, authenticity or integrity of information (objective in section 5.8). The domain has 19 criteria with 32 basic subcriteria, one sharpening and five complementing additional subcriteria. It falls into three parts; the grouping is our reading aid:

• Policy and governance (CRY-01 to CRY-03): a cryptography policy with nine minimum aspects, change management for cryptographic systems and a review of the practice at least annually.
• Protection of data (CRY-04, CRY-05): encryption for transmission over public networks and for storage of customer data.
• Key lifecycle (CRY-06 to CRY-19): generation, rotation, certificates, provisioning, storage, archiving, transitions, compromise, deactivation, pre-shared keys, continuity, documentation, external key management and customer managed keys.

The third part has largely been restructured: the BSI split the former criterion CRY-04 from C5:2020 into ten criteria, and six further criteria are new without a predecessor, among them CRY-02, CRY-03, CRY-18 and CRY-19. If you have a “key management” control under C5:2020, you therefore have to distribute it across the new criteria.

As the benchmark, CRY-01.02B names the technical guideline BSI TR-02102 or suitable NIST guidelines such as the FIPS 140 and SP 800 series. The cryptography policy has to be checked against these guidelines regularly, and deviations are recorded in a risk assessment.

Starting point: a SaaS provider before its first audit

Fictitious example, not a client. A provider runs a platform through which tax advisory firms and their clients exchange documents and upload receipts. The service runs on the infrastructure of a large cloud service provider, with a managed database, object storage and the platform’s key management service. Large firms can bring their own keys. For internal services the provider runs its own certificate authority; it obtains public certificates automatically from a recognised certificate authority.

Before the project, the situation looks like this:

• The platform’s storage encryption is switched on everywhere; which keys exist, who manages them and when they are rotated is written down nowhere.
• For several subdomains the provider uses a wildcard certificate whose private key sits on three systems.
• A planned shutdown of older TLS versions would affect interfaces of some firms’ software; the firms do not know about it yet.
• No document governs what to do with a compromised key.

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

The platform supplies the tools, the provider is responsible for how they are used. For six criteria the catalogue names duties of the customers (CRY-02, CRY-04, CRY-05, CRY-08, CRY-18, CRY-19). Our classification for the example:

CRY-18.01B applies “in the case that external key management systems (KMS) are integrated into the service”. Whether the platform’s key management service counts as an “external key management system” in this sense is something you define in the scope and justify in the system description; our recommendation is to agree this with the auditor early on. Carve-out and inclusive are explained on the page C5 scope. Whether and when the provider’s staff may access keys or customer data is governed by CRY-05.02B with reference to IAM-07; see the page C5 IAM.

And post-quantum cryptography?

In C5:2026 it is a complementing additional criterion, not part of the basic criteria: CRY-01.01AC to CRY-01.03AC require a PQC strategy with an inventory of the mechanisms in use, transition plans and review at least annually. In the basic criteria, the cryptography policy has to consider crypto-agility (CRY-01.01B no. 9), that is, describe how mechanisms can be substituted efficiently during their lifetime. The core of a post-quantum migration is a crypto inventory and a migration plan.

Example control description for CRY-07

CRY-07 requires a fixed rotation schedule: “The cloud service provider has established a schedule for rotating cryptographic keys that aligns with the requirements for cryptographic key rotation established in CRY-01.” If the provider deliberately does not rotate after a risk assessment, it has to communicate this transparently to the customers (CRY-07.01B). Our example control (own wording, not catalogue text; the rotation intervals are example values, not catalogue requirements):

Whether the control fully covers CRY-07 is for the auditor to judge; for a type 2 report the auditor also tests whether it was effective over the whole period.

What evidence the auditor wants to see

For CRY the most important evidence is a complete key inventory and the logs of key management. Examples from the scenario:

How to manage this evidence per subcriterion and due date is shown on the page Evidence and documentation.

Possible gaps: cause, effect, remedy

The following gaps follow from the wording of the criteria and the scenario. If a single subcriterion is not met, the criterion counts as not met, and the auditor reports the deviation (sections 3.4.12 and 3.4.13).

Which gaps actually block the audit and in which order you close them is settled by prioritising measures across all domains.

All criteria of the CRY 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.

Customer managed and externally managed keys (CRY-18, CRY-19) are also a question of sovereignty; the BSI has published further criteria on this with C3A.

Relationship to ISO/IEC 27001:2022 Annex A

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.