Encryption is a technical control. A cryptography policy is the decision behind it. The difference shows up quickly in an audit: almost every organisation encrypts in many places, but few can explain why in those places, with which methods, and who can get at the keys if something goes wrong. Those three questions are what the policy answers.
What belongs in it
| Section | Content |
|---|---|
| Scope | Systems, data categories, locations and service providers covered |
| Use cases | Where encryption is applied: transmission, storage, transfer to third parties, backups, mobile devices |
| Approved methods | Which methods and parameters are permitted, and which are expressly no longer permitted |
| Key management | Generation, distribution, storage, rotation, revocation, destruction, recovery |
| Roles | Key owners, approvers, dual control for critical operations |
| Exceptions | Legacy systems with an expiry date, compensating controls, approval |
| Review | Interval, triggers and ownership for keeping the document current |
The exceptions section is the most honest part of such a document. Every estate that has grown over time contains systems that do not support current methods. A policy that stays silent about them is disproved by the first sample; one that carries them with an expiry date, a compensating control and a named approval passes the review.
Key custody with a cloud provider
Once data is processed by a provider, the decisive question shifts from encryption to key custody: who generates the key, where does it live, and can the provider technically use it? Encryption whose keys sit entirely with the provider protects against third parties, not against the provider, which may well be acceptable but should be a decision rather than a default.
The policy should therefore record, per processing activity, who holds the keys, what happens to them if you change provider, and how the data stays decryptable at the end of the contract or becomes irrecoverably unreadable. Where a provider offers customer-managed keys, the policy should also say who inside your organisation can revoke them, because that action is indistinguishable from a self-inflicted outage.
Choosing methods without inventing any
Developing your own cryptographic methods is not indicated in any use case. What counts are established, publicly reviewed methods in current implementations. For the selection of methods and parameters, the BSI publishes Technical Guideline TR-02102, a regularly updated recommendation that can be used as a reference. Because recommendations change over time, the policy should not fix parameters without also naming the interval at which they are checked against the current edition.
The reverse direction matters just as much. The policy should name the methods and protocol versions that may no longer be used, and set out how a migration runs when a previously approved method is considered obsolete. That capacity for an orderly migration is worth more than any single parameter choice.
Key management is the substance
Effectiveness does not hang on the algorithm; it hangs on the keys. For every key there should be an owner, a purpose, a storage location, a rotation rule and a defined procedure for loss. Two findings recur in reviews: keys or passphrases stored in the same systems whose data they protect, and the absence of a recovery procedure that is itself protected. Losing a key means losing the data: encryption is therefore an availability risk as well, and belongs in continuity planning.
Where the obligation comes from
For most organisations there is no free-standing legal duty to hold a cryptography policy, and the requirement arrives through one of three routes.
Under the GDPR, Art. 32 lists encryption as an example of a technical measure without prescribing it; what governs is appropriateness in relation to the risk. A written policy is the usual way of making that appropriateness decision traceable.
In an ISMS to ISO/IEC 27001, the use of cryptographic methods follows from risk treatment, and the decision is justified in the Statement of Applicability. There too, the policy is the bridge between the risk decision and the technical implementation.
For entities in scope of the German BSI Act, the catalogue of measures in § 30(2) sentence 2 no. 8 BSIG names policies and procedures for the use of cryptographic methods. The wording points at the policy level rather than at individual settings: what is required is a determination, not a particular algorithm. This route matters to companies outside Germany more often than they expect: it reaches a German subsidiary directly, and it reaches a foreign supplier indirectly, through what an in-scope German customer has to be able to evidence about its supply chain.
What reviewers ask
Expect five questions. Where is which data encrypted, and what determined that selection? Which methods are approved, who approved them, and when were they last reviewed? Where are the keys, and who has access? What happens if a key is lost or considered compromised? Which systems do not comply with the policy, and how is that documented?
Evidence
Useful evidence is the approved and dated policy, a register of keys in use with a named owner for each, records of key rotations and revocations, the exception list with expiry dates and approvals, the result of the last scheduled review of methods, and a documented test of the recovery procedure. That test is the only item on the list that demonstrates effectiveness rather than intent, which is why it is the one most often asked for and not produced.