What is a cryptography policy?
A cryptography policy is the decision behind every piece of encryption: where data is encrypted, with which methods and who can recover the keys if they are lost. For entities under the German BSI Act, § 30(2), second sentence, no. 8 BSIG requires concepts and processes for the use of cryptographic procedures. In an ISMS the policy is one of the rules covered in the guide to ISMS implementation.
What sections does a cryptography policy need?
A cryptography policy needs seven sections to cover use cases, methods, keys and exceptions in full.
| Section | Content |
|---|---|
| Scope | Systems, data types, locations and service providers included |
| Use cases | Where encryption applies: transmission, storage, sharing, backups, mobile devices |
| Approved methods | Which methods and parameters are allowed and which are no longer allowed |
| Key management | Generation, distribution, storage, rotation, revocation, destruction, recovery |
| Roles | Key owners, approvers, four-eyes procedure for critical operations |
| Exceptions | Legacy systems with a deadline, compensating controls and approval |
| Review | Cycle, triggers and responsibility for updates |
The exceptions section decides whether the document is credible. A policy that omits legacy systems without approved methods is disproved by the first sample. A policy that lists them with a deadline, compensating controls and approval reflects the actual state.
When is a cryptography policy mandatory?
A cryptography policy is mandatory for entities under the BSIG. Financial entities face their own requirements under Article 9(4)(d) DORA, controllers under Article 32(1)(a) GDPR.
| Legal basis | Who is obliged | What the provision requires |
|---|---|---|
| § 30(2), second sentence, no. 8 BSIG | Particularly important and important entities | Concepts and processes for the use of cryptographic procedures as a minimum measure |
| Article 9(4)(d) Regulation (EU) 2022/2554 (DORA) | Financial entities | Protection measures for cryptographic keys; encryption based on approved data classification and ICT risk assessment processes |
| Article 32(1)(a) Regulation (EU) 2016/679 (GDPR) | Controllers and processors | Encryption of personal data as one of the measures for a level of security appropriate to the risk |
| ISO/IEC 27001 | Organisations with a certified ISMS | Use of cryptography derived from risk treatment, justified in the Statement of Applicability |
The second sentence of § 30(2) BSIG introduces the catalogue with “must at least”. DORA ties encryption expressly to data classification, and the GDPR leaves the decision to appropriateness, which a written policy makes traceable.
Choosing methods and replacing them in an orderly way
A cryptography policy sets methods and parameters and also governs how outdated methods are replaced. As the reference for the choice, the BSI publishes Technical Guideline TR-02102. Part 1, “Cryptographic Mechanisms: Recommendations and Key Lengths”, is available as version 2026-01 (as of October 2026). Home-grown methods that have not been publicly reviewed belong in no policy.
Recommendations change with the state of cryptanalysis. Example: following progress in cryptanalysis in 2026, the BSI recommends not using the Classic McEliece key agreement scheme for new developments. The policy therefore lists the methods and protocol versions that are no longer allowed. It also sets a procedure for switching when an approved method is downgraded.
Deciding key custody with service providers
When a service provider processes the data, key custody decides what encryption protects against. The questions are who generates the key, where it is held and whether the provider can technically use it. If the key lies entirely with the provider, encryption protects against third parties, not against the provider itself.
Record for each processing activity who holds the keys and what a change of provider means. Also settle whether the data stays decryptable at the end of the contract or becomes irrecoverably unreadable.
For every key: owner, purpose, storage, rotation, loss
The effectiveness of a cryptography policy depends on the keys. For every key the policy sets five items: the owner, the purpose, the storage location, the rotation rule and the procedure for loss.
Keys and passphrases do not belong in the systems whose data they protect. Losing a key means losing the data; the recovery procedure therefore needs its own protection, and encryption belongs in contingency planning.
What evidence does an auditor expect for a cryptography policy?
An auditor expects six pieces of evidence, from the policy to the tested recovery procedure:
- the approved and dated policy,
- a register of the keys in use with a named owner,
- logs of key rotation and revocation,
- the exceptions list with deadline and approval,
- the result of the last review of the approved methods,
- a documented test of the recovery procedure.
The test and the rotation logs show effectiveness; the other items show what was decided.
The key inventory in the asset register
Rizzqo carries each key management service as a secondary asset with an owner. The register thus supplies the system level of the key register that auditors expect for a cryptography policy. Linked to the primary assets whose data its keys protect, the service inherits their confidentiality rating and their personal-data flag. This shows which information and business processes depend on a single key inventory.
The cryptography requirements from the ISO/IEC 27002 requirement catalogue appear on the assets whose category they concern. The owner answers them there, attaches the configuration or key evidence and finalises the answer with name and timestamp.