What is ISO 27001 Annex A 8.24 – Use of Cryptography?

ISO 27001 Annex A 8.24 focuses on defining and implementing rules for the effective use of cryptography to protect the confidentiality, authenticity, and/or integrity of information.

Cryptography is used throughout modern IT environments to protect information:

• While being transmitted
• While stored
• During authentication
• During application communication
• In backups
• In cloud environments
• On endpoint devices
• Between APIs and services

Simple explanation

A.8.24 means the organization should determine where cryptography is needed, define appropriate requirements, and manage encryption and cryptographic keys securely.

The objective is not simply to say:

“We use encryption.”

The organization should understand what needs protection, how it is protected, which cryptographic mechanisms are approved, and how keys are managed.

---

Why is Cryptography Important?

Without appropriate cryptographic protection, sensitive information may be exposed or modified.

For example:

User → Internet → Application

Without secure encryption, information transmitted across an untrusted network could potentially be intercepted.

With appropriate encryption:

User → Encrypted Connection → Application

Cryptography can help protect against:

• Eavesdropping
• Data interception
• Unauthorized disclosure
• Data modification
• Credential theft
• Unauthorized access
• Loss of confidentiality
• Loss of integrity

---

What does A.8.24 require?

The organization should establish rules for the effective use of cryptography.

These rules should address areas such as:

• When encryption is required
• What information requires cryptographic protection
• Approved cryptographic mechanisms
• Key management
• Key generation
• Key storage
• Key distribution
• Key rotation
• Key backup/recovery
• Key revocation
• Key destruction
• Responsibilities
• Compliance requirements

The implementation should be based on the organization’s:

• Information-security risks
• Legal requirements
• Regulatory requirements
• Contractual obligations
• Business requirements
• Technology environment

---

Where is Cryptography Commonly Used?

1. Data in transit

Examples:

• HTTPS/TLS
• Secure APIs
• VPN
• Secure email protocols
• Encrypted database connections
• Secure administrative connections

---

2. Data at rest

Examples:

• Database encryption
• Disk encryption
• Cloud storage encryption
• Backup encryption
• Laptop encryption
• Removable-media encryption

---

3. Authentication

Cryptographic mechanisms may support:

• Password protection
• Digital certificates
• MFA
• Hardware security keys
• Digital signatures
• Token-based authentication

Passwords themselves should generally be stored using appropriate password hashing mechanisms, rather than reversible encryption.

---

4. Digital signatures

Digital signatures can help establish:

• Authenticity
• Integrity
• Non-repudiation where applicable

They may be used for:

• Documents
• Software
• Certificates
• Transactions
• Code signing

---

Activities Required to Implement A.8.24

1. Identify information requiring cryptographic protection

Start by identifying sensitive information.

For example:

Information	Protection
Customer personal data	Encryption
Authentication credentials	Secure hashing/protection
Financial information	Encryption
Production database	Encryption at rest
Backups	Encryption
API communication	TLS
Administrative access	Encrypted protocols
Confidential documents	Encryption where required

Not all information necessarily requires the same cryptographic protection.

---

2. Define encryption requirements

Document when encryption is required.

For example:

• Sensitive data transmitted over untrusted networks must use secure encrypted communication.
• Sensitive data stored in production databases should be encrypted where appropriate.
• Backups containing sensitive information should be encrypted.
• Company laptops storing sensitive information should use full-disk encryption where appropriate.
• Deprecated or insecure cryptographic protocols should not be used.

Requirements should be based on risk and applicable obligations.

---

3. Define approved cryptographic mechanisms

The organization should establish an approved cryptography standard.

It may define requirements for:

• Approved protocols
• Approved algorithms
• Minimum security levels
• Certificate management
• Key lengths
• Key storage
• Key rotation
• Secure configuration

Avoid hard-coding outdated technology requirements into a policy that may quickly become obsolete.

The cryptographic standard should be periodically reviewed.

---

4. Establish key-management requirements

Encryption is only as strong as the protection of its keys.

Key management should address:

Key generation

Keys should be generated using appropriate secure mechanisms.

Key storage

Keys should not be stored insecurely in:

• Source code
• Public repositories
• Plain-text configuration files
• Shared documents
• Unprotected spreadsheets

Use appropriate key-management mechanisms such as:

• Key Management Services
• Hardware Security Modules
• Secrets-management platforms
• Cloud KMS
• Secure credential stores

Key access

Restrict who or what can access cryptographic keys.

Key rotation

Rotate keys according to risk, technology and organizational requirements.

Key revocation

Keys should be revoked when compromised or no longer trusted.

Key destruction

Keys should be securely retired or destroyed when no longer required, subject to retention and recovery requirements.

---

5. Protect cryptographic keys separately from encrypted data

Where appropriate, avoid storing encryption keys alongside the data they protect.

For example:

Database

→ Encrypted

Encryption Key

→ Managed separately through a secure key-management service

This can reduce the impact of unauthorized access to the database.

---

6. Manage digital certificates

Organizations using TLS and digital certificates should manage:

• Certificate issuance
• Certificate ownership
• Expiration dates
• Renewal
• Revocation
• Private-key protection
• Certificate inventories

Expired certificates can cause service outages.

Compromised certificates can create significant security risks.

---

7. Manage cryptographic secrets in applications

Developers should not hard-code secrets into application source code.

Avoid:

API_KEY = "secret-value"

Instead, use an approved secrets-management mechanism.

Examples include:

• Cloud secrets managers
• Vault solutions
• Environment-specific secret stores
• Managed key-management services

Access should be restricted and audited.

---

8. Consider legal and regulatory requirements

Cryptographic requirements can vary by:

• Country
• Industry
• Data type
• Customer contract
• Regulatory framework

The organization should identify applicable requirements before implementing its cryptographic policy.

---

Example – SaaS Startup

Consider a SaaS startup processing customer information through a cloud application.

The startup implements:

Data in transit

Browser → HTTPS/TLS → Application

Database

Customer information is encrypted at rest using the cloud provider’s encryption capabilities.

Backups

Production backups are encrypted.

Developer secrets

API keys and database credentials are stored in a secrets-management system rather than source code.

Administrative access

Administrative connections use secure encrypted protocols and strong authentication.

Cryptographic keys

Keys are managed through an appropriate cloud key-management service.

Certificates

TLS certificates are tracked and renewed before expiration.

The company documents these requirements in its Cryptography Standard.

This creates a practical implementation of A.8.24.

---

What Events Should Trigger Review?

Cryptographic requirements should be reviewed when significant changes occur.

Trigger	Possible Action
New application	Assess encryption requirements
New sensitive data	Review cryptographic protection
New cloud provider	Review encryption/key management
New regulatory requirement	Update cryptographic requirements
Cryptographic vulnerability	Replace affected mechanism
Certificate compromise	Revoke/replace certificate
Key compromise	Rotate/revoke affected key
Certificate nearing expiration	Renew certificate
New technology	Review cryptographic architecture
Major application change	Reassess encryption
Security incident	Review cryptographic controls
Change in customer requirements	Reassess protection

---

Startup-Focused Quick Summary

Does a startup need a dedicated cryptography team?

No.

A startup can implement A.8.24 using capabilities already available in its cloud, applications and security tools.

For example:

• HTTPS/TLS
• Database encryption
• Disk encryption
• Cloud KMS
• Secrets management
• Encrypted backups
• Secure authentication
• Certificate management

Minimum startup implementation

A startup can begin with:

1. Identify sensitive information.
2. Define when encryption is required.
3. Establish an approved cryptography standard.
4. Encrypt sensitive data in transit.
5. Encrypt sensitive data at rest where appropriate.
6. Protect encryption keys separately.
7. Use secure secrets management.
8. Manage TLS certificates.
9. Restrict access to cryptographic keys.
10. Review cryptographic mechanisms periodically.

Simple rule

Encrypt sensitive information where required, and protect the keys as carefully as the information itself.

For startups, the biggest practical mistake is often not the absence of encryption—it is poor key and secret management.

---

Example Cryptography Register

Asset / Information	Cryptography Required	Method	Key Owner	Key Management	Review
Web application	Yes	TLS	Security	Certificate/KMS	Periodic
Production database	Yes	Encryption at rest	Cloud/Security	Cloud KMS	Periodic
Backups	Yes	Encryption	IT	Backup/KMS	Periodic
Employee laptops	Risk-based	Full-disk encryption	IT	Endpoint management	Periodic
API communication	Yes	TLS	Engineering	Certificate management	Periodic
Application secrets	Yes/Protected	Secrets Manager	Engineering	Secrets platform	Periodic
Customer documents	Risk-based	Encryption	Application Owner	Approved mechanism	Periodic

---

Cryptographic Key Lifecycle

A practical key lifecycle is:

Generate

↓

Store Securely

↓

Control Access

↓

Use

↓

Monitor

↓

Rotate When Required

↓

Revoke if Compromised

↓

Archive/Destroy When Appropriate

The exact lifecycle should depend on the type of key and the organization’s requirements.

---

Cryptography Implementation Checklist

Information

• Have sensitive information types been identified?
• Are encryption requirements based on risk?
• Are data-in-transit requirements defined?
• Are data-at-rest requirements defined?

Technology

• Is HTTPS/TLS used for sensitive communications?
• Is sensitive storage encrypted where required?
• Are backups protected?
• Are endpoints appropriately encrypted?

Keys

• Are keys securely generated?
• Are keys stored securely?
• Is access restricted?
• Is key rotation defined?
• Is revocation defined?
• Is key destruction addressed?

Secrets

• Are API keys protected?
• Are database passwords protected?
• Are secrets excluded from source code?
• Is access to secrets logged where appropriate?

Certificates

• Is there a certificate inventory?
• Are expiration dates monitored?
• Are certificates renewed before expiry?
• Are private keys protected?

---

A.8.24 Audit Evidence

An auditor may request evidence such as:

Policies and standards

• Cryptography Policy
• Cryptographic Key Management Standard
• Encryption Standard
• Password/Authentication Standard
• Secrets Management Standard

Technical evidence

• TLS configuration
• Database encryption configuration
• Cloud KMS configuration
• Disk encryption configuration
• Backup encryption configuration
• Secrets-management configuration

Key management

• Key inventory
• Key rotation records
• Key access permissions
• Key lifecycle records
• Key revocation records

Certificate management

• Certificate inventory
• Certificate renewal records
• Certificate configuration
• Certificate monitoring

Application security

• Source-code scanning results
• Secrets scanning results
• Secure-development evidence
• API security configuration

---

A.8.24 Audit Checklist

Audit Question	Evidence
Is there a documented cryptography standard?	Cryptography Policy
Are encryption requirements defined?	Security Standard
Is sensitive data encrypted where required?	Configuration
Is data in transit protected?	TLS Configuration
Is sensitive data at rest protected?	Storage/Database Configuration
Are backups encrypted where required?	Backup Configuration
Are cryptographic keys protected?	KMS/Key Management
Is access to keys restricted?	IAM Configuration
Are secrets protected?	Secrets Manager
Are secrets excluded from source code?	Code Scanning
Are certificates managed?	Certificate Inventory
Are certificates renewed before expiration?	Renewal Records
Is key rotation addressed?	Key Management Records
Is key revocation addressed?	Key Lifecycle Records
Are cryptographic mechanisms periodically reviewed?	Review Records
Are obsolete/insecure mechanisms addressed?	Security Review

---

Common Mistakes

1. “We use HTTPS, so A.8.24 is complete”

HTTPS is only one part of cryptography.

Organizations should also consider:

• Data at rest
• Backups
• Keys
• Secrets
• Certificates
• Applications
• Endpoints

---

2. Storing secrets in Git

API keys, passwords and private keys should not be committed to source-code repositories.

Even private repositories require appropriate secret-management controls.

---

3. Poor key management

Encryption does not provide much protection if unauthorized people can access the encryption keys.

---

4. Using outdated cryptography

Cryptographic mechanisms should be periodically reviewed and updated when they become unsuitable or vulnerable.

---

5. No certificate management

Expired certificates can cause outages, while poorly protected private keys can create security risks.

---

6. No documented requirements

The organization may technically use encryption everywhere but cannot explain:

• Why encryption is required
• Where it is required
• What mechanisms are approved
• Who manages keys

Document the organization’s approach.

---

7. One key for everything

Using the same cryptographic key across many systems can increase the impact of a compromise.

Key-management design should consider separation and risk.

---

Practical Implementation Model

A practical A.8.24 implementation model is:

Identify Sensitive Information

↓

Assess Cryptographic Requirements

↓

Define Cryptography Standard

↓

Select Approved Mechanisms

↓

Implement Encryption

↓

Protect Keys & Secrets

↓

Manage Certificates

↓

Monitor

↓

Rotate / Revoke Where Required

↓

Review Cryptographic Controls

↓

Improve

---

Policy vs. Technical Control vs. Evidence

Element	Example
Policy	Sensitive information shall be protected using appropriate cryptographic mechanisms.
Standard	Approved protocols, algorithms and key-management requirements are defined.
Technical Control	Database encryption and TLS are configured.
Key Management	Encryption keys are stored and managed using an approved KMS.
Evidence	Configuration, access records, key-rotation records and review reports.

The auditor should be able to connect:

Information Risk → Cryptographic Requirement → Implementation → Key Management → Evidence

---

Useful Resources

Recommended documents

• Draft Cryptography Policy – [Insert Draft Document Link]
• Cryptographic Key Management Standard – [Insert Draft Document Link]
• Encryption Standard – [Insert Draft Document Link]
• Secrets Management Standard – [Insert Draft Document Link]
• Certificate Management Procedure – [Insert Draft Document Link]
• Cryptography Assessment Checklist – [Insert Draft Document Link]
• Cloud Encryption Checklist – [Insert Draft Document Link]

Related ISO 27001 controls

A.8.24 works closely with:

• A.5.15 – Access control
• A.5.17 – Authentication information
• A.5.23 – Information security for use of cloud services
• A.8.2 – Privileged access rights
• A.8.5 – Secure authentication
• A.8.9 – Configuration management
• A.8.10 – Information deletion
• A.8.11 – Data masking
• A.8.13 – Information backup
• A.8.15 – Logging
• A.8.16 – Monitoring activities
• A.8.20 – Network security
• A.8.21 – Security of network services
• A.8.22 – Segregation of networks

---

Final Takeaway

ISO 27001 Annex A 8.24 is about using cryptography effectively to protect information and managing the cryptographic mechanisms and keys that support that protection.

A practical organization should be able to answer:

What information needs cryptographic protection?
Where is encryption required?
Which cryptographic mechanisms are approved?
Who can access the keys?
How are keys generated, stored, rotated and revoked?
How are certificates and secrets managed?

For a startup, implementation can be straightforward:

Identify → Define → Encrypt → Protect Keys → Manage Certificates → Monitor → Review

The important point is that encryption alone is not the complete control.

A strong implementation manages the complete lifecycle:

Protect the information + protect the keys + manage the certificates + review the cryptography.

A.8.24 = Appropriate Cryptography + Secure Key Management + Controlled Implementation + Periodic Review.