ISO 27001 Control 8.24: Use of Cryptography

A single weak encryption key can undo years of security investment. When cryptographic controls fail — through deprecated algorithms, mismanaged keys, or inconsistent policies — organizations face data exposure they believed was impossible. The encryption existed. The keys were just never managed. Poor key management creates a false sense of security, and regulators increasingly treat cryptographic negligence as grounds for significant penalties. Control 8.24 exists to prevent exactly this.

What 8.24 Requires

ISO 27001 Annex A 8.24 requires organizations to define and implement a policy on the effective use of cryptography, including rules for encryption standards, key lengths, and key management practices that protect the confidentiality, integrity, and authenticity of information.

In practical terms, the control demands three things. First, a documented cryptography policy that specifies which encryption standards the organization uses, when cryptographic techniques must be applied, and how those decisions align with the organization’s information classification scheme. This policy should cover data at rest, data in transit, authentication mechanisms, and digital signatures — not just the obvious cases like database encryption. The scope of cryptographic controls extends further than most organizations initially assume.

Second, the control requires a complete key management lifecycle. This means documented processes for generating keys through secure random sources, distributing them through protected channels, storing them separately from the data they protect, rotating them on a defined schedule, and destroying them when they are no longer needed. Each stage needs assigned ownership, documented procedures, and audit trails.

Third, organizations must address legal and regulatory constraints on cryptographic use. Encryption export controls, cross-border data transfer laws, and lawful access obligations vary by jurisdiction and can directly affect which algorithms and key lengths are permissible.

Without these three pillars — policy, key management, and legal compliance — encryption becomes inconsistent and unverifiable. An organization might encrypt its databases but store the keys in the same repository, or use strong algorithms internally while allowing vendors to transmit data over unencrypted channels. Control 8.24 closes these gaps by demanding a governed, end-to-end approach.

Why 8.24 Matters

Consider an organization that checks every visible encryption box. Databases are encrypted at rest. TLS protects web traffic. The compliance team reports full coverage. But beneath the surface, the same encryption keys have been in use for four years. Key material sits on the same servers as the encrypted data. Three former system administrators still have access to the key store because offboarding never included cryptographic credential revocation.

This is not a hypothetical edge case — it is one of the most common patterns in organizations that fail cryptographic audits. The encryption exists, but the key management does not, and the distinction is the difference between actual security and the appearance of it. When the IBM Cost of a Data Breach Report 2025 puts the average global breach cost at $4.44 million, the financial risk of cryptographic failure becomes concrete.

The consequences extend beyond direct breach costs. Under GDPR Article 32, encryption is explicitly cited as an appropriate technical measure, and failure to implement it properly can factor into penalty calculations. PCI DSS mandates specific cryptographic protections for cardholder data, with detailed encryption requirements governing how that data must be protected at rest and in transit. Sector-specific regulations in healthcare and financial services add further requirements. An organization that cannot demonstrate effective cryptographic controls faces regulatory exposure on multiple fronts.

From an attacker’s perspective, cryptographic control gaps are among the most reliable and least detected entry points available. A compromised encryption key does not trigger the same alarms as a brute-force login attempt or a malware payload. The resulting access is often broad, persistent, and invisible to standard monitoring — an attacker with a valid key looks indistinguishable from a legitimate user. This is why 8.24 treats key management with the same rigor as the encryption itself.

What attackers exploit

Specific failure modes that attackers target when cryptographic controls are weak:

• Weak or deprecated algorithms — MD5, SHA-1, and DES remain in production environments far more often than security teams realize. These algorithms have known vulnerabilities that reduce the effort required to break encryption.
• Hardcoded encryption keys — Keys embedded directly in application source code are discoverable through code repository scanning and are nearly impossible to rotate without redeploying the application.
• No key rotation — When the same keys are used for years, every historical data access becomes a current risk if those keys are compromised.
• Keys stored alongside encrypted data — Storing encryption keys on the same system or in the same database as the data they protect eliminates the security benefit of encryption entirely.
• Missing encryption on internal data in transit — Organizations often encrypt external traffic but leave internal system-to-system communication unprotected, exposing data to lateral movement attacks.
• No certificate lifecycle management — Expired or self-signed certificates in production create both security vulnerabilities and operational disruptions.
• Inconsistent policies across environments — Different encryption standards between cloud environments and on-premises systems create exploitable gaps at the boundaries.

How to Implement 8.24

Implementation splits into two domains: what your organization does internally and how you assess the cryptographic practices of your vendors and service providers. Both matter — your encryption is only as strong as the weakest link in your supply chain, and auditors increasingly expect evidence that vendor cryptographic practices have been evaluated alongside your own.

For your organization

1. Draft a cryptography and key management policy. Start with your information classification scheme. Each classification level should map to specific cryptographic requirements — what must be encrypted, with which algorithms, at what key lengths. The policy should cover data at rest, data in transit, authentication, and digital signing.

2. Inventory cryptographic usage. Catalog every system where cryptographic controls apply. This includes databases, file storage, email, API communications, VPN connections, endpoint drives, and code signing. Many organizations discover unencrypted data flows during this inventory that were previously assumed to be protected.

3. Select encryption standards based on risk assessment. For data at rest, AES-256 is the current baseline. For data in transit, require TLS 1.2 as a minimum, with TLS 1.3 preferred. Hash functions should use SHA-256 or stronger. Document why each standard was selected and under what conditions it should be reviewed.

4. Implement key management processes. Generate keys using cryptographically secure random sources. Store keys in hardware security modules (HSMs) or dedicated secrets management platforms — never in application code, configuration files, or the same storage as encrypted data. The NIST key management guidelines provide a comprehensive framework for these decisions. Define rotation schedules based on risk: high-sensitivity keys should rotate more frequently. Document destruction procedures including verification that destroyed keys cannot be recovered.

5. Address legal requirements. Map your encryption use against the jurisdictions where you operate. Export controls may restrict the algorithms you can use in certain countries. Cross-border data transfer agreements may impose specific encryption requirements. Lawful access obligations vary significantly by region.

6. Assign ownership. Define who approves cryptographic standards, who manages keys operationally, and who audits compliance. Without clear ownership, policies decay. According to Encryption Consulting’s 2025 Trends Report, enterprise adoption of formal key management practices surged from 45% in 2020 to 75% in 2024 — a trajectory that reflects growing recognition that ownership and process matter as much as algorithm selection.

7. Integrate with related controls. Cryptographic controls do not exist in isolation. Connect your cryptography policy to information classification (5.12), access management, secure development practices (8.25), and configuration management (8.9). An ISO 27001 implementation checklist can help track these cross-control dependencies.

Tooling categories to evaluate: Hardware security modules (HSMs), secrets management platforms, certificate lifecycle management tools, and endpoint encryption solutions. Selection should be based on your key management requirements — the NIST cryptographic key management framework provides useful criteria — not the other way around.

Common implementation mistakes:

• Treating encryption as a checkbox without governing key management
• Using default or self-signed certificates in production environments
• No documented process for revoking compromised keys
• Encrypting data but storing keys in the same database or code repository
• Failing to account for encryption’s impact on monitoring and data loss prevention tools — encrypted traffic that cannot be inspected creates blind spots
• Not reviewing algorithm strength as standards evolve, leaving the organization without crypto agility

For your vendors

Assessing vendor cryptographic practices requires specific questions, concrete evidence, and a clear understanding of what evasive answers look like. A structured vendor security review process ensures nothing is missed.

Questions to include in vendor assessments:

• What encryption standards do you use for data at rest and in transit? (Expect specific algorithms and key lengths, not “industry-standard encryption.”)
• Describe your key management lifecycle — how are keys generated, stored, rotated, and destroyed?
• Do you use FIPS 140-2 or FIPS 140-3 validated cryptographic modules?
• What is your process when a key compromise is suspected or confirmed?

Evidence to request:

• Documented cryptography policy and key management procedures
• SOC 2 Type II report sections addressing encryption controls
• Penetration test results that specifically cover cryptographic controls
• Certificate management records showing rotation and renewal processes

Red flags in vendor responses:

• Vague references to “industry-standard encryption” without specifying algorithms or key lengths
• No documented key management procedures
• Inability to confirm whether key storage is separate from encrypted data
• No process for handling key compromise

Verification methods: Request the SOC 2 Type II report and review the sections relevant to encryption. Use publicly available TLS scanning tools to validate the vendor’s external certificate configurations and protocol versions. Check certificate chains for proper validation and expiration management. Where possible, verify that the vendor’s stated encryption practices align with what is observable from outside — a vendor claiming TLS 1.3 support whose public endpoints still negotiate TLS 1.0 is a clear red flag.

UpGuard continuously monitors vendor encryption posture, including TLS configurations, certificate health, and protocol versions — surfacing cryptographic weaknesses across your vendor portfolio in real time.

Audit Evidence for 8.24

Auditors assessing control 8.24 look for specific, documented artifacts that demonstrate both policy and operational compliance.

The key distinction auditors draw is between having encryption and governing it. A policy that exists but is not followed, or encryption that is deployed but not inventoried, will not satisfy an auditor reviewing 8.24. Prepare to demonstrate not just that these artifacts exist, but that they are current, reviewed on schedule, and reflect actual operational practice. Auditors will cross-reference your policy against your encryption inventory and key lifecycle records to verify consistency.

Cross-Framework Mapping

Control 8.24 maps to equivalent requirements across several major compliance frameworks. Understanding these mappings reduces duplicate effort for organizations managing multiple certifications.

The NIST 800-53 mappings (SC-12 and SC-13) provide the closest alignment, covering both cryptographic use and key management at the same level of specificity as 8.24. The other frameworks address portions of 8.24’s scope, typically focusing on encryption application without the same depth on key management governance.

Related ISO 27001 Controls

Control 8.24 does not operate in isolation. It connects functionally to several other Annex A controls, and implementing cryptography effectively requires coordination across these related requirements. Treating 8.24 as a standalone exercise will produce gaps that auditors — and attackers — will find.

Frequently Asked Questions

What is ISO 27001 8.24?

ISO 27001 Annex A 8.24 is a control that requires organizations to define and implement rules for the effective use of cryptography, including encryption standards and cryptographic key management. It covers the full scope of cryptographic application — data at rest, data in transit, authentication, and digital signatures — along with the governance and lifecycle management of the keys that underpin those protections.

What happens if 8.24 is not implemented?

Without 8.24, organizations risk data breaches through weak or inconsistent encryption, regulatory penalties under frameworks like GDPR and PCI DSS, and audit failures during ISO 27001 certification. The most common failure mode is not the absence of encryption but the absence of key management — encryption that exists without proper key governance provides a false sense of security.

How do you audit 8.24?

Auditors review the documented cryptography and key management policy, verify that an encryption inventory exists mapping systems to algorithms and key lengths, examine key lifecycle records (generation, rotation, destruction), and check for legal compliance documentation. They also look for evidence that the policy is operational — not just written — by reviewing penetration test results and endpoint encryption compliance reports.

How UpGuard Helps

Cryptographic weaknesses across your vendor portfolio do not wait for your next audit cycle. UpGuard Breach Risk continuously monitors vendor encryption configurations, certificate health, and protocol versions — surfacing cryptographic risks before they become audit findings or breach vectors.