ISO 27001 controls
Encryption is easy to switch on; the keys are where audits are won
Annex A control 8.24, use of cryptography, asks you to set rules for where and how cryptography is used, including how keys are managed through their life. Most cloud services encrypt by default, so the audit questions move elsewhere: who decides, who holds the keys, and what happens when one must be replaced.
Back to ISO 27001 services01 · The policy
Start with a short cryptography policy
A topic policy that answers where, what and who.
A cryptography policy is one of the topic-specific policies that sit under the main information security policy. It should be short enough that an engineer can follow it while designing a feature. It ties encryption to your classification scheme (control 5.12), so the rule for confidential data is clear without a meeting.
- Where encryption is required. By data class and by data state: in transit, at rest, and in backups.
- Approved choices. The categories of algorithm and protocol you accept, and who keeps that list current.
- Key management. Who may create, hold, use, rotate and destroy keys, and with which tools.
- Legal limits. Rules on export, import or use of cryptography in countries where you operate, tracked under control 5.31.
- Exceptions. How a system that cannot meet the policy is approved and reviewed.
02 · Approved choices
Approved algorithms and protocols, as categories
Name classes of mechanism, and keep the list current.
The policy does not need a cipher-suite list that goes stale in a year. It needs categories and a rule for keeping them current. A workable approach is to accept only widely reviewed, current mechanisms from public standards, reject anything your chosen reference marks as deprecated, and assign someone to recheck the list at each policy review. Never allow home-grown cryptography.
- Symmetric encryption
- One shared key, used for bulk data at rest and inside secure channels.
- Public-key cryptography
- Key pairs, used for key exchange, signatures and certificates.
- Hashing
- One-way digests for integrity checks; for passwords, use a dedicated slow password-hashing function.
- Secure transport
- A current version of a standard protocol such as TLS, configured from the provider's hardened defaults.
Public references such as NIST guidance and the cryptography sections of the OWASP Application Security Verification Standard are useful anchors for which mechanisms are current.
03 · Where it applies
Where encryption applies
Each data state has its own threat and its own control.
| Data state | Typical threat | Usual control | Evidence |
|---|---|---|---|
| In transit, public | Interception between users and your service | TLS on every endpoint, old versions disabled | External scan of endpoints, load balancer settings |
| In transit, internal | Lateral movement and sniffing inside the network | TLS or mutual TLS between services, encrypted database connections | Service configuration, network policy |
| At rest | Stolen disks, snapshots or storage exposure | Storage and database encryption with managed keys | Cloud configuration export, posture tool report |
| In backups | A copy leaving your control | Encrypted backups with keys stored separately | Backup settings, key location |
| On endpoints | Lost or stolen laptops and phones | Full-disk encryption enforced by device management | Device compliance report |
| In use | Memory access on shared infrastructure | Confidential computing or field-level encryption, where the risk justifies it | Design record explaining the choice |
04 · Key lifecycle
The key lifecycle
Generate, store, use, rotate, retire.
Generate
Create keys with an approved tool and enough randomness.
- What happens
- Use a key management service or hardware security module
- You get
- A key with a known owner and purpose
- Good practice
- Keys never generated on a developer laptop
- Watch for
- Hard-coded keys in source
Store and use
Keep keys out of the data they protect.
- What happens
- Restrict who and what may use each key
- Log key use
- You get
- An access policy per key
- Good practice
- Separation between key administrators and data users
- Watch for
- Keys in environment files or tickets
Rotate
Replace keys on a schedule and on suspicion.
- What happens
- Set a rotation period by key type
- Rotate at once if a key may be exposed
- You get
- Rotation records
- Good practice
- Automatic rotation where the service allows it
- Watch for
- A key nobody dares rotate because nothing is documented
Retire and destroy
Remove keys you no longer need, carefully.
- What happens
- Disable, then destroy after retention ends
- You get
- A destruction record
- Good practice
- Checked that no backup still needs the key
- Watch for
- Destroying a key that old backups depend on
A small company
- Cloud provider key management with provider-managed or customer-managed keys
- A secrets manager for application credentials
- Managed certificates with automatic renewal
- A one-page policy and a key inventory in the asset register
A large company
- Hardware security modules for root and signing keys
- Customer-managed or customer-supplied keys for sensitive tenants
- A certificate management platform with discovery and expiry alerts
- A key custodian role and dual control for the most sensitive operations
Certificates are keys with a public label and an expiry date. An expired certificate causes outages; a forgotten one can be misused. Keep an inventory, automate renewal where you can, alert well before expiry, and know how to revoke one quickly.
05 · Evidence
What an auditor samples, and the usual mistakes
Policy, inventory, settings and rotation records.
- The cryptography policy. Approved, current, linked to classification.
- Key and certificate inventory. What exists, who owns it, when it rotates or expires.
- Configuration samples. Encryption settings on a few in-scope stores and endpoints.
- Key access. Who can administer and use the sampled keys.
- Rotation and renewal history. Evidence that rotation happens as the policy says.
- Relying on defaults without a record. Default encryption may be fine, but the policy must say so and you must show it is on.
- Secrets in code. API keys and private keys committed to repositories, including old history.
- No rotation plan. Keys that have never changed, and no way to change them without downtime.
- Certificate surprises. Outages from expiries nobody was tracking.
- Over-broad key access. Every engineer can use the production data key.
Sources: ISO/IEC 27001:2022 Annex A controls 5.12, 5.31 and 8.24 (cited by number and name only); NIST SP 800-57 Part 1 on key management; NIST SP 800-53 Rev. 5 controls SC-8, SC-12, SC-13 and SC-28; the OWASP Application Security Verification Standard, cryptography requirements. The data-state table is our own.
Questions about cryptography and keys
Is cloud default encryption enough for ISO 27001?
Often, if your policy accepts it and you can show it.
Many services encrypt at rest by default with provider-managed keys. That can meet your policy for most data. Record the decision, and consider customer-managed keys where your risk assessment or contracts call for more control.
How often should keys be rotated?
As your policy sets, by key type, and at once on suspicion.
The standard does not fix a period. Set rotation per key type using guidance such as NIST SP 800-57, automate it where possible, and rotate immediately if a key may have been exposed.
Do we need a hardware security module?
Not by default. It depends on risk and contracts.
A cloud key management service is enough for most organisations. A hardware security module is common for payment, signing and high-assurance use, or where a customer or regulator asks for one.
Who should own the cryptography policy?
Usually the security lead, with engineering input.
The security owner writes and maintains it. Engineering leads review it, because they apply it daily, and top management approves it like other topic policies.
Know where your keys are before an auditor asks.
An ISO 27001 gap analysis reviews your cryptography policy, key inventory and encryption settings against control 8.24.