Annex A 8.24: Use Of Cryptography

To meet the annex a 8.24: use of cryptography requirement, you must define where cryptography is required, standardize approved algorithms and key management, and prove encryption is consistently implemented and monitored across systems and third parties. Operationalize it by publishing a cryptography standard, integrating it into engineering and procurement workflows, and retaining evidence that keys, certificates, and crypto configurations are governed. ¹

Key takeaways:

• Document a cryptography standard that states what must be encrypted, with what methods, and who approves exceptions. ²
• Treat key management as the control’s center of gravity: lifecycle, storage, access, rotation, revocation, and logging. ³
• Build audit-ready evidence through recurring configuration checks, key/cert inventories, and exception registers tied to defined scope. ²

Annex A 8.24 is where many ISO 27001 programs become real for operators: you cannot “policy” your way through cryptography. Auditors look for a clear decision framework for when encryption is mandatory, proof that engineering teams consistently apply it, and governance around the keys that make encryption meaningful. The fastest path is to translate 8.24 into a small set of enforceable standards and repeatable checks.

This requirement page is written for a Compliance Officer, CCO, or GRC lead who needs to drive implementation across security, engineering, IT operations, and procurement without turning the program into a research project. You will see a practical interpretation of the control, who it applies to, step-by-step execution, and the evidence set that typically closes audit questions quickly. The goal is simple: reduce ambiguity, reduce exception volume, and make cryptography measurable.

Citations below reference only the provided sources for ISO 27001 and the Annex A control index. ¹

Requirement: Annex A 8.24 (Use of Cryptography) — practical interpretation

Plain-English interpretation: You must identify which information needs cryptographic protection and implement encryption and cryptographic controls correctly across the lifecycle (design, build, deploy, operate). That includes governance: approved cryptographic methods, key management, and evidence that encryption is actually in place and maintained. ⁴

What auditors commonly want to see for 8.24:

• A written, approved cryptography standard (not just a high-level policy). ²
• A mapping from information/asset classes to crypto requirements (for example, “customer data at rest in production databases must be encrypted”). ³
• Key and certificate management processes that prevent “encryption theater” (encrypted data with unmanaged keys is still fragile). ³
• Operational checks that show encryption stays enabled after changes, migrations, restores, and vendor transitions. ²

Regulatory text

Provided excerpt: “ISO/IEC 27001:2022 Annex A control 8.24 implementation expectation (Use Of Cryptography).” ¹

Operator meaning (what you must do):

1. Define where cryptography is required to protect confidentiality, integrity, and authenticity of information. ³
2. Standardize cryptographic approaches (approved algorithms/protocols, approved libraries/services, and configuration baselines). ²
3. Control keys and certificates through documented lifecycle management and restricted access. ³
4. Retain evidence that cryptographic requirements are implemented and operating as intended across scoped systems and third parties. ²

Who it applies to (entity and operational context)

Entity scope: Any organization operating an ISMS under ISO/IEC 27001, especially service organizations that store, process, transmit, or administer sensitive customer or internal data. ³

Operational scope (where 8.24 shows up):

• Cloud infrastructure and SaaS platforms: object storage, managed databases, backups, snapshots, block storage, and messaging services.
• Endpoints and collaboration tooling: full-disk encryption, mobile device encryption, and encrypted containers where applicable.
• Network transport: TLS for user access, service-to-service traffic, admin access, and APIs.
• Software delivery: secrets in CI/CD, encryption for artifacts and registries if they store sensitive content.
• Third parties: vendors processing your data; managed services holding your backups; certificate authorities; key management services; payment processors.

What you actually need to do (step-by-step)

Step 1: Set cryptography scope from information classification

Create a one-page mapping that answers: “For each data/asset class, what cryptographic controls are mandatory?” Tie this to your information classification and asset inventory so it is enforceable. ³

Minimum decisions to document:

• Encryption required at rest (where and for which environments).
• Encryption required in transit (external and internal connections).
• Requirements for integrity/authenticity (signing, hashing, code signing, token signing) where relevant.
• Allowed exceptions and the approval path.

Step 2: Publish a cryptography standard (enforceable, testable)

Write a “Cryptography Standard” that security and engineering can implement without interpretation battles. Include:

• Approved cryptographic services (for example, managed KMS/HSM vs. app-managed keys).
• Approved protocols for transport (TLS expectations).
• Requirements for storage encryption (database, object store, backups, endpoints).
• Prohibited practices (examples: hard-coded keys, sharing private keys, storing keys in source control).
• Exception process with time bounds and compensating controls, tracked in a register.

Keep it short, but specific enough to test in configuration reviews. ²

Step 3: Centralize key management (define ownership and lifecycle)

Auditors probe key management because it is where control failures become incidents. Define:

• Key owners (service owner) and key custodians (platform/security).
• Key creation and storage requirements (prefer centralized key management systems).
• Access controls (who can decrypt; separation of duties for key admins vs. app admins).
• Rotation and revocation triggers (employee departure, suspected compromise, vendor offboarding, certificate expiry).
• Logging/monitoring expectations for key use and admin events.

Make this a runbook plus an access-control model that matches your IAM reality. ³

Step 4: Build cryptography into delivery workflows (so it stays on)

You need controls that survive engineering velocity:

• Architecture review gates: Confirm encryption decisions for new systems and data stores.
• Infrastructure-as-code checks: Validate encryption flags are enabled (storage, database, queue, backup).
• CI checks for secrets: Detect keys/certs in repos and block merges when found.
• Change management hooks: Require revalidation of encryption after migrations or major version upgrades.

Your goal is drift resistance: encryption should not quietly turn off during changes. ²

Step 5: Extend requirements to third parties (contract + verification)

For third parties that store or process your data:

• Add contract clauses requiring encryption at rest/in transit and proper key management (including who controls keys).
• Request assurance evidence (SOC reports, ISO certificates, or targeted due diligence responses).
• Validate technical options (customer-managed keys, key separation, certificate management, data deletion on offboarding).

Track third-party exceptions the same way you track internal exceptions. ³

Step 6: Evidence-driven operation (recurring checks + exceptions)

Turn 8.24 into a recurring evidence pack:

• Quarterly (or on your assessment cadence) export an inventory of data stores and confirm encryption settings.
• Export KMS/certificate inventories; review for stale, orphaned, or over-permissioned keys.
• Review exception register for expired exceptions and overdue remediation.

Daydream can help here by mapping Annex A 8.24 to a documented control, scheduling recurring evidence capture, and keeping artifacts tied to scope changes so audits do not become scavenger hunts. ⁴

Required evidence and artifacts to retain

Retain evidence that proves both design and operating effectiveness:

Governance artifacts

• Cryptography policy/standard (approved, versioned).
• Key management procedure/runbook.
• Exception register (approved exceptions with rationale and compensating controls).
• Data classification-to-crypto requirements mapping.

Technical evidence (samples are fine, but define sampling logic)

• Screenshots/exports showing encryption enabled on representative production data stores and backups.
• TLS configuration evidence for key entry points (load balancers, API gateways, admin consoles).
• KMS/HSM inventory export: keys, aliases, rotation status, access policies.
• Certificate inventory: expirations, issuance authority, renewal process evidence.
• Logging/monitoring evidence for key administrative actions and unusual decrypt activity where available.

Third-party evidence

• Contract language or security addendum clauses for encryption/key handling.
• Due diligence responses or assurance reports addressing encryption and key management. ³

Common exam/audit questions and hangups

Auditors and customers often ask:

• “Show me which systems are in scope and how you decided encryption requirements for each.”
• “Do you encrypt backups and snapshots, or only the primary database?”
• “Who can access decryption keys? Show role assignments and approvals.”
• “How do you prevent developers from embedding keys in code?”
• “How do you handle certificate lifecycle and avoid outages from expiry?”
• “How do you manage crypto exceptions, and how do they get closed?” ²

Frequent implementation mistakes (and how to avoid them)

1. Policy-only cryptography. Fix: publish a standard with testable requirements and link it to build/change workflows. ²
2. Encrypting data but ignoring keys. Fix: define key ownership, access controls, rotation/revocation triggers, and retain KMS evidence. ³
3. Forgetting non-production environments. Fix: state where lower environments can differ, and document compensating controls for masked or synthetic data. ³
4. No exception discipline. Fix: enforce time-bound exceptions with re-approval and evidence of remediation progress. ²
5. Third-party blind spot. Fix: contract for encryption and verify key ownership and offboarding handling during due diligence. ³

Risk implications (why operators care)

If 8.24 is weak, you increase exposure to:

• Data disclosure from misconfigured storage, exposed backups, or intercepted traffic.
• Ransomware blast radius when attackers access unencrypted datasets or steal keys.
• Customer trust failures when you cannot answer “what’s encrypted, where, and with whose keys” during security reviews. ³

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and governance)

• Name owners: Security (standard), Platform (KMS/certs), Engineering (app crypto), Procurement (third-party terms).
• Draft and approve the Cryptography Standard and Key Management Procedure.
• Create the data classification-to-crypto requirements mapping.
• Stand up an exceptions register and approval workflow. ²

By 60 days (implement controls where drift happens)

• Build inventories: keys, certificates, and scoped data stores.
• Add build/change hooks: IaC checks for encryption flags, repo scanning for secrets, and architecture review prompts.
• Update third-party templates: security addendum clauses for encryption and key handling; add due diligence questions. ³

By 90 days (evidence, monitoring, and audit packaging)

• Produce your first recurring evidence pack: encryption settings samples, KMS exports, certificate inventory, and exception review minutes.
• Test incident paths: key compromise response, certificate emergency renewal, vendor offboarding with key/cert rotation.
• In Daydream, map Annex A 8.24 to the control narrative and schedule evidence capture so the next audit is retrieval, not reinvention. ²

Frequently Asked Questions

Does Annex A 8.24 require encryption everywhere?

It requires you to define where cryptography is necessary and implement it consistently for scoped information and systems. Document where encryption is mandatory and how exceptions are approved and tracked. ²

Is “encryption at rest” enough to satisfy the requirement?

Usually no, because auditors will also ask about encryption in transit and key management. Treat keys and certificates as first-class assets with lifecycle controls and evidence. ³

What’s the minimum key management evidence to keep?

Keep a key inventory export, access control evidence (roles/policies), and records showing rotation/revocation expectations and exceptions. Add proof of logging for key admin actions where available. ³

How do we handle third parties that won’t support customer-managed keys?

Document the risk decision, require encryption and strong internal key controls contractually, and track the exception with compensating controls. Make offboarding and key rotation expectations explicit. ³

What do auditors mean by “approved cryptography”?

They want a defined standard: which cryptographic approaches are permitted, which are prohibited, and who can approve deviations. The standard must be specific enough to test against configurations. ²

How can GRC reduce evidence collection effort for 8.24?

Standardize the evidence pack (inventories, configuration exports, exception register) and collect it on a recurring schedule tied to scope. Tools like Daydream help keep artifacts mapped to Annex A 8.24 and ready for assessors. ²

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISMS.online Annex A control index

3. ISO/IEC 27001 overview

4. ISMS.online Annex A control index; ISO/IEC 27001 overview