ISO 27001 Cryptography: Encryption and Key Management

Cryptography is one of the most technically demanding controls in ISO 27001. Annex A.10 requires organisations to use cryptographic controls to protect information in line with their risk assessment. Getting it right means choosing the appropriate encryption methods, managing keys securely, and ensuring compliance with relevant regulations. This article covers everything you need to know about ISO 27001 cryptography, from policy development through to key management and cloud considerations.

Annex A.10: Cryptographic Controls

Annex A.10 of ISO 27001:2022 contains two controls:

• A.10.1.1 – Policy on the use of cryptographic controls: Develop and document a policy that governs the use of encryption across the organisation.
• A.10.1.2 – Key management: Define and implement a process for managing cryptographic keys throughout their lifecycle.

These controls are classified as “preventive” and “protective.” They are designed to reduce the likelihood of confidentiality breaches and to provide a safety net if other controls fail. However, cryptography is not a silver bullet. Weak implementation, poor key management, or non-compliance with legal requirements can render your encryption useless – or even create new risks.

Developing an Encryption Policy (A.10.1.1)

Your cryptographic policy must define when, where, and how encryption will be used. The policy should be driven by your risk assessment and data classification scheme. Not all data needs the same level of cryptographic protection.

A well-structured encryption policy covers:

• Scope: Which systems, data types, and communication channels are covered.
• Roles and responsibilities: Who owns the policy, who manages keys, and who approves cryptographic implementations.
• Approved algorithms and protocols: A list of acceptable encryption standards (e.g. AES-256, TLS 1.3, RSA-4096).
• Data classification triggers: When encryption is mandatory (e.g. all Confidential and Restricted data at rest and in transit).
• Key management requirements: High-level rules for key generation, storage, rotation, and destruction.
• Compliance references: Alignment with applicable regulations (e.g. PDPL, GDPR, PCI DSS).
• Review cycle: Frequency of policy review (typically annual).

Types of Encryption: Data at Rest and Data in Transit

ISO 27001 cryptography covers two primary states of data:

Key Management (A.10.1.2)

Key management is the most critical – and most commonly failed – control in Annex A.10. Strong encryption with weak key management is like a high-security vault with the combination taped to the door.

Your key management process must cover the full lifecycle:

• Key generation: Use approved cryptographic modules and sufficient entropy. Avoid hard-coded or predictable keys.
• Key storage: Protect keys at the same or higher level than the data they protect. Use hardware security modules (HSMs) or key vault services (e.g. Azure Key Vault, AWS KMS).
• Key distribution: Transmit keys securely using encrypted channels. Use automated key distribution where possible.
• Key rotation: Rotate keys periodically and whenever a compromise is suspected. Define rotation schedules in your policy.
• Key revocation: Have a mechanism to revoke compromised keys immediately.
• Key destruction: Securely destroy keys when no longer needed, ensuring that data encrypted with those keys is also handled appropriately.
• Key backup and recovery: Implement secure backup of keys to prevent data loss. Test recovery procedures.

Certificate Management

Public key infrastructure (PKI) certificates underpin many cryptographic controls, including HTTPS, code signing, and email encryption. Poor certificate management is a common finding in ISO 27001 audits.

Cryptographic Controls for Cloud

Cloud services require special attention because the organisation does not control the underlying infrastructure. However, the responsibility for protecting data remains with you.

Key considerations for cloud cryptography include:

• Encryption at rest: Ensure the cloud provider encrypts your data at rest. Verify whether provider-managed keys or customer-managed keys (CMK) are used.
• Encryption in transit: Enforce TLS for all connections to and from cloud services. Disable HTTP access to sensitive resources.
• Key ownership: Where possible, use customer-managed keys (CMK) or bring your own key (BYOK) so you retain control over key lifecycle.
• Key storage location: Store keys in a hardware security module (HSM) or key vault that you control, separate from your cloud provider.
• Multi-cloud key management: If you use multiple cloud providers, consider a unified key management platform to avoid fragmentation.
• Cloud provider controls: Review the provider’s certifications (ISO 27001, SOC 2) as evidence that their cryptographic controls are adequate.

Compliance Considerations

Cryptography is subject to legal and regulatory constraints in many jurisdictions. Before implementing cryptographic controls, you must consider:

• Export control laws: Some countries restrict the export of strong cryptographic products. If you operate across borders, verify that your encryption methods are legally exportable.
• National encryption regulations: Certain jurisdictions require or prohibit specific encryption standards. For example, some countries mandate the use of government-approved cryptographic algorithms.
• Data protection regulations: GDPR, Bahrain’s PDPL, and other privacy laws may require encryption of personal data. Some also require that you retain the ability to decrypt data when legally compelled.
• Lawful access requirements: Some jurisdictions require organisations to provide decrypted data upon lawful request. Your encryption architecture should accommodate this without breaking your security model.
• Industry-specific requirements: PCI DSS mandates specific encryption requirements for cardholder data. Healthcare regulations may require particular encryption standards for patient records.

Your encryption policy should reference applicable legal and regulatory requirements and specify how each is addressed. This is a key area that auditors will examine.

Common Audit Findings in Cryptography

ISO 27001 auditors frequently cite the following issues:

• No encryption policy: The organisation uses encryption ad hoc without a documented policy.
• Weak or deprecated algorithms: Use of MD5, SHA-1, RC4, TLS 1.0, or 3DES.
• Missing key management process: Keys are stored in configuration files, hard-coded in source code, or managed informally.
• No key rotation: Encryption keys remain unchanged for years without documented justification.
• Expired certificates: TLS certificates left expired, causing services to fail or users to bypass warnings.
• Unencrypted sensitive data: Discovery exercises reveal databases, backups, or file shares containing sensitive data without encryption.

Frequently Asked Questions

Which encryption algorithms does ISO 27001 require?

ISO 27001 does not prescribe specific algorithms. Your encryption policy must specify approved algorithms and protocols based on industry best practice and your risk assessment. Common approved standards include AES-256 for symmetric encryption, RSA-4096 or ECDSA for asymmetric encryption, and TLS 1.3 for data in transit.

Do I need to encrypt everything in my organisation?

No. Your risk assessment and data classification scheme determine which data requires encryption. Public information may not need encryption at all, while Restricted data should always be encrypted at rest and in transit. Applying encryption unnecessarily adds complexity and cost without corresponding security benefit.

Can I use free or open-source encryption tools?

Yes, provided they implement approved algorithms correctly and are maintained and patched. Many open-source tools (e.g. VeraCrypt, GnuPG, OpenSSL) are widely used and trusted. The key consideration is that you manage them under your ISMS: you must verify their integrity, apply security updates, and ensure they are configured correctly.

How often should I rotate encryption keys?

Rotation frequency should be defined in your encryption policy and justified by risk. Common rotation periods are annually for most keys, quarterly for high-risk systems, and immediately upon suspicion of compromise. Cloud key vaults such as Azure Key Vault offer automated key rotation, which simplifies compliance.

What is the difference between cloud provider-managed keys and customer-managed keys?

Provider-managed keys are generated, stored, and rotated by the cloud provider. You rely on their controls and certifications. Customer-managed keys (CMK) are generated and stored in a key vault that you control, though the key vault may still be hosted by the provider. Bring your own key (BYOK) takes this further by allowing you to generate keys in your own HSM and transfer them to the cloud provider. CMK and BYOK give you more control but require stronger internal key management capabilities.

Does ISO 27001 require me to use specific key lengths?

No, but industry best practice requires key lengths sufficient to withstand current and foreseeable attacks. For symmetric encryption, use at least AES-256. For RSA, use at least 2048 bits (4096 recommended). For elliptic curve cryptography (ECC), use at least Curve P-256. Document your rationale for key length selection in your encryption policy.

How Bitrixme Can Help

Implementing compliant cryptographic controls under ISO 27001 requires technical knowledge, policy development skills, and familiarity with regulatory requirements. Bitrixme provides ISMS consulting services across Bahrain and the Middle East, helping organisations design and implement cryptographic controls that meet certification standards.

We can assist with encryption policy development, key management process design, cloud cryptography architecture, and preparation for ISO 27001 certification audits. Our consultants combine information security expertise with practical implementation experience.

Contact Bitrixme today to discuss your ISO 27001 cryptography requirements. You can also reach us directly on WhatsApp for a prompt consultation.