A.8.24 Use of cryptography: requirements and evidence

What A.8.24 use of cryptography asks for and why audits fail on it

When an auditor or customer asks how your organization uses encryption and manages keys, the short answer is that Annex A control A.8.24 requires rules for the effective use of cryptography to be defined and implemented, and that those rules must cover cryptographic key management across the key life cycle. The control does not ask you to pick a particular algorithm or product. It asks you to decide which cryptography protects which information, how strong it must be, who owns the keys and how they are created, stored, rotated, revoked and destroyed, and then to prove those decisions are carried out. Unmanaged keys are the main risk: a key that nobody owns can be copied, left in a configuration file or kept after the system it protected is retired, and an ungoverned algorithm choice can leave weak or deprecated ciphers in service for years.

The 2013 edition handled this in two controls, A.10.1.1 (policy on the use of cryptographic controls) and A.10.1.2 (key management). The 2022 edition merges them into A.8.24, so a single written policy now has to reach both the algorithm choices and the key life cycle. Auditors usually look for the same gaps. Keys are spread across a backup tool, a web server, a cloud key service, a CI pipeline and a developer laptop, with no single inventory. No named owner signs off on key creation or retirement. Rotation happens by habit rather than by a record. Legal limits on cryptography, which sit under the related control A.5.31, are not reflected in the policy at all. Confirm with your own environment which of these apply before you describe your controls to an assessor.

Which systems, keys and third parties A.8.24 covers

A.8.24 applies wherever information is encrypted, signed or authenticated with keys, so the first job is deciding which systems and key types fall inside the ISMS scope. The cards below cover the decisions that most change the effort, from storage and transport encryption to certificates, backups and third-party key services.

Data at rest and in transit

Start by listing every store and channel that holds or carries information in scope: databases, object storage, file shares, message queues, and the network paths between users, services and sites. For each, record whether encryption is applied, which algorithms and key lengths are allowed, and who can read the keys. Auditors usually test this list against the Statement of Applicability, so gaps found here tend to be the ones they cite. Confirm each setting with the vendor documentation for your own versions.

Application-level encryption

Platform encryption at rest does not always protect fields from administrators or from the application itself. Where personal or regulated fields need protection from people with database access, decide which fields are encrypted in the application and how their keys are separated from the data. Nextcloud's server-side encryption, for example, keeps file contents encrypted with server-held keys but does not hide file names or folder structure, so that residual exposure must be recorded as a decision.

TLS certificates and internal PKI

Certificates bind keys to identities, so their issuance, renewal and revocation belong inside A.8.24. List the certificate authorities in use, whether public or private, and who may request certificates. Internal services often rely on a private CA, and the CA signing key is among the most sensitive keys in the estate. Automated renewal reduces expiry outages, but the issuer configuration and the location of the private key still need documented owners and review.

Code signing and release keys

Keys that sign software artifacts, container images and firmware protect the integrity of everything downstream, so they need the same lifecycle rules as encryption keys. Decide which pipelines may sign, where the private keys are held, and how signing keys are rotated and revoked after a suspected compromise. Build systems that hold signing keys in plain configuration are a common finding. Ask your development team to show where each release key lives and who approved its use.

Backups, endpoints and SaaS key services

Backup archives, laptop disks and keys held by SaaS or cloud key management services each carry their own key custody questions. Confirm whether backups are encrypted, who holds the decryption keys, and whether a restore can be performed if the key service is unavailable. For endpoints, record the disk encryption method and the escrow arrangement for recovery keys. For cloud and SaaS providers, document which keys the provider manages, which you hold, and how you verify their controls through contract terms and reports.

Legal restrictions and authentication secrets

Some jurisdictions restrict the import, export or use of certain cryptography, and contracts with customers or suppliers may dictate algorithms or key custody. Record these requirements under A.5.31 Legal, statutory, regulatory and contractual requirements, then trace them to the cryptographic rules that implement them. Passwords, API tokens and other authentication information under A.5.17 often sit in the same vaults as keys, so the rotation and access rules for both should be written together. Confirm applicable restrictions with counsel for each market you serve.

How an assessor tests A.8.24 use of cryptography

This table walks through the test steps an assessor typically follows for A.8.24, the evidence each step asks for, and the findings that appear most often. Read it as a checklist for what your own records must show before an audit, since the assessor reports what they find and the organization designs and owns the control.

Test step	What the assessor checks	Evidence requested	Common findings
Review the cryptography policy	That rules for cryptography exist, cover where and how it is used, and were approved by management	Approved cryptography policy, version history, approval record, review date	Policy names no owner, has no approval record, or was never reviewed after systems changed
Interview key owners	Who sets cryptographic rules, who holds keys, and who handles renewal and revocation	Named roles or RACI for key custody, renewal and emergency revocation	Key owners cannot describe the policy or confirm which systems they are responsible for
Sample systems and algorithms	Whether the algorithms and key lengths in use match the policy's approved list	Configuration exports from TLS endpoints, databases, storage encryption and VPNs	Retired algorithms or short keys still enabled on production services
Check the key inventory against real systems	Whether every key and certificate in use appears in the inventory, with an owner and location	Key and certificate inventory, discovery scan output, system-to-key mapping	Keys or certificates in production with no inventory entry or no named owner
Test rotation and renewal records	Whether keys and certificates are rotated or renewed on the schedule the policy sets	Rotation logs, renewal tickets, certificate issuance history, expiry alerts	Expired certificates with no renewal record, or rotation performed with no written trace
Test revocation and compromise handling	Whether keys can be revoked and whether a past compromise led to documented replacement	Revocation procedure, revocation records, incident tickets linked to key replacement	No revocation procedure, or revocation never tested on any key in the period
Check legal and export constraints	Whether restrictions on cryptography that apply to the organization were identified and followed	Register of cryptography-related legal or contractual requirements, sign-off by legal or compliance	Constraints from contracts or jurisdictions were never recorded against the cryptography policy
Report findings only	The assessor records nonconformities against the requirement and does not design the control	Assessor report with findings, which the organization responds to and remediates	Organizations that expect the assessor to write the policy or choose algorithms during the audit

Implementing A.8.24 cryptography rules in order

This sequence moves from written rules to working practice: an approved cryptography policy comes first, then an inventory of every key and certificate, then named owners, tooling, lifecycle rules and a first review. Each step produces a record an assessor can sample.

Define the cryptography policy and approved algorithms
Start by writing the rules for where cryptography must be used, which algorithms and key lengths are approved, which are prohibited, and when exceptions apply. Security architecture and compliance leads draft it, and the management owner approves it. Include the legal and contractual constraints on encryption that apply to your jurisdictions and customers, since A.5.31 sits alongside A.8.24. The output is an approved policy and a short standard listing approved algorithms and minimum key lengths. You know the step is done when every system owner can point to the document that tells them what to use.
Build the key and certificate inventory
Find every place cryptographic material lives: TLS certificates on load balancers and ingress, database and disk encryption keys, application signing keys, SSH keys, API secrets used for encryption, and keys held by SaaS providers. Discovery usually needs scanning plus interviews with platform and application teams, because keys often sit in config files or cloud consoles nobody reviews. The output is an inventory recording each key or certificate, its purpose, algorithm, length, location, creation and expiry dates. Confirm the inventory is complete by sampling several systems and checking they appear in it.
Assign a named owner to each key
Every entry in the inventory needs one accountable owner, a team or role rather than a shared mailbox, who approves its use and its rotation. Owners confirm the entries for their systems and sign off on any exceptions to the approved algorithms. The output is the inventory with an owner column filled in for every row, plus a record of who may create, rotate or revoke keys. Assessors commonly test this step by picking a key at random and asking who is responsible for it.
Select key storage and management tooling
Choose where keys are generated, stored and used. Options include a central secrets and key management service, a private certificate authority, or certificate automation in Kubernetes. Open-source candidates such as OpenBao, FreeIPA and cert-manager can cover parts of this need, but each has a different scope, so confirm the capabilities you require against current vendor documentation. Record the decision, the reason and the systems it covers. The output is a key management architecture note and a tool selection record. Ask any implementation partner to state in writing which parts of the tooling they will configure and which the organization will operate.
Set rotation, renewal and revocation rules
Write the procedure for how keys and certificates are rotated before expiry, what happens when a key is suspected compromised, how revocation is requested and recorded, and how destroyed keys are removed from systems and backups. Tie each rule to a type of key in the inventory and state where automation handles renewal and where a person must act. The output is a key management procedure with a rotation schedule per key class and a revocation runbook. Test one rotation and one revocation on a non-production system and keep the records.
Run and record the first review
Before the rules are treated as operating, review the policy, inventory, ownership and procedure against what is actually happening. Check that expiring certificates were renewed, that weak algorithms are flagged, and that exceptions have approvals and end dates. The reviewer records findings and assigns corrective actions with owners. The output is a dated first review record with findings, actions and sign-off from the policy owner. This record is the first evidence an auditor will ask to see, so keep it with the policy and inventory versions it reviewed.

Which self-hosted open-source tools produce cryptography evidence

Several self-hosted open-source platforms produce evidence that supports A.8.24, but each covers a different part of the key life cycle and none of them writes the cryptography policy for you. OpenBao (MPL-2.0) is the most direct fit for application data. Its transit secrets engine encrypts and decrypts data without storing it, signs and verifies data, and supports versioned encryption keys with key rotation. An assessor will want to see which applications call the engine, which key versions are in use, the rotation schedule and the audit records showing when keys were rotated. Confirm that the engine's key custody model, including how the root and unseal material are held and who can administer it, matches your own risk decisions before you rely on it as the record of key management.

FreeIPA (GPL-3.0-or-later) includes an integrated certificate authority based on Dogtag, which issues and manages certificates for hosts, services and users. This gives you an inventory of issued certificates, revocation records and an identifiable issuing authority, all of which an assessor will check against your stated algorithm and lifetime rules. cert-manager (Apache-2.0) fills a narrower role for workloads in Kubernetes or OpenShift. It creates TLS certificates from issuers such as ACME (Let's Encrypt), a CA key pair, HashiCorp Vault, CyberArk or self-signed certificates, stores them in Kubernetes Secrets and renews them before they expire. Its configuration and issuer resources are useful evidence, but the certificates it issues are only as trustworthy as the issuer behind them, so confirm which issuer your policy allows.

Nextcloud (AGPL-3.0-only) provides server-side encryption for file contents at rest on local and external storage, with keys kept on the server. That is a useful control for document storage, but it has a documented limit: file names and folder structure are not encrypted. Record that limit in your cryptography rules and your risk treatment, and check whether any sensitive information appears in file names. Across all four tools, treat the outcome as a decision to confirm with your architects and, where needed, your assessor: the algorithms, key lengths, key custody and key ownership must be set in your own policy first, and each tool should then be tested against that policy in your environment.

Evidence that passes an A.8.24 review

An assessor testing A.8.24 looks for a written rule set, a current picture of the keys and certificates it governs, and proof that those rules were followed over time. The six artifacts below connect policy to operation, so each one should be traceable to the one before it. Keep them current between audits with scheduled reviews and automated exports rather than rebuilding them before the audit.

Approved cryptography policy

The policy states which algorithms and key lengths are permitted, which are prohibited, where encryption is mandatory (data at rest, data in transit, backups) and who approves exceptions. An assessor checks that it has an owner, a version history and an approval date, and that it matches what the systems actually do. Review it on a fixed schedule and after any significant change to the standards you rely on, such as a deprecated algorithm. Confirm the legal and contractual constraints named under A.5.31 are reflected in it.

Key and certificate inventory

A register lists every cryptographic key and certificate in scope, with its purpose, system, algorithm, key length, named owner, creation date and expiry. Unowned or undocumented keys are the most common gap assessors find. Reconcile the inventory against discovered certificates and key stores at a set interval, and flag any entry without an owner. Automated discovery reduces manual upkeep but does not replace a named human accountable for each entry.

Rotation and renewal logs

Logs show that keys and certificates were rotated or renewed before expiry, and that the rotation followed the policy interval. For transit encryption keys, versioned keys make rotation history inspectable. Confirm that renewal automation records each event with a timestamp and outcome, and that failed renewals produce alerts. Assessors often sample a few expired or near-expiry items and ask for the renewal trail behind them.

Revocation and destruction records

When a key is compromised, retired or no longer needed, the organization must show it was revoked or destroyed and that no active system still depends on it. Keep records of the reason, the approver, the date, the affected systems and the destruction method. Check that backups and replicas containing the key material were handled as well. Missing records here suggest keys may still be live without anyone knowing.

Encryption configuration exports

Configuration exports prove that encryption settings in production match the policy, not just the design document. Examples include server-side encryption settings, TLS minimum versions, disk encryption status and database encryption flags. Export them on a schedule and store them with timestamps so drift can be seen over time. Note the limits of each platform: for instance, Nextcloud server-side encryption does not encrypt file names or folder structure, and that gap belongs in the record.

Key management access records

Access logs for the key management system show who requested, used, exported or administered keys, and when. Assessors check that privileged access to key stores is restricted, reviewed and logged, and that key administrators are separated from routine users where practical. Forward these logs to central logging so they cannot be altered by the administrators they record. Review them periodically and document the review, not just the export.

What meeting A.8.24 costs in money and effort

This table breaks down the cost components of meeting A.8.24 Use of cryptography, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to scope internal work against outside help, and to check that a quote covers each line. No figures are given because none were supplied for this control.

Cost component	One-time or recurring, and who is paid	What drives it up or down
Tooling and licenses	Recurring for commercial key management or HSM services, paid to the vendor. Open-source options such as OpenBao, FreeIPA and cert-manager carry no license fee but still need hosting and staff time.	Number of key stores, certificate issuers and tenants. Ask whether the quote includes support subscriptions and whether licenses scale per node, per key or per certificate.
Engineering time to design key management	One-time, paid as internal staff time or to an implementation partner under a written scope. Covers the key hierarchy, custody model, rotation design and the algorithm and key-length policy.	Number of systems and key types in scope, and whether keys are already centralized. Mature environments with an existing internal CA usually need less design work.
Build and rotation automation	One-time build, then recurring maintenance. Paid to internal engineers or a partner, and sometimes to the vendor for upgrades.	Count of certificates and secrets that rotate automatically versus by hand. Automated renewal through tools such as cert-manager lowers ongoing effort but adds Kubernetes or platform dependencies to maintain.
Hosting and operations of self-hosted services	Recurring, paid through infrastructure accounts and internal operations time. Covers high availability for key stores, backups of key material and patching.	Choice of managed versus self-hosted key services, geographic redundancy, and the custody model. Self-hosting removes license spend but moves availability and recovery work to your team.
Policy and legal review	One-time review with recurring updates, paid to internal legal, compliance or outside counsel. Covers export and national restrictions on cryptography, which A.5.31 also addresses.	Number of jurisdictions where data is stored or processed and the presence of contractual cryptography clauses with customers.
External review of cryptographic design	Periodic and optional, paid to a specialist testing firm. Useful for checking key handling, algorithm choices and implementation flaws before the audit.	Complexity of custom cryptographic code and of the key hierarchy. Using vetted libraries and standard protocols generally reduces the scope of the review.
Evidence upkeep	Recurring internal time to export key inventories, rotation logs, algorithm policy versions and access reviews for the auditor.	Number of keys and whether evidence is generated automatically from audit logs or collected by hand each cycle.
Auditor sampling time	Recurring, paid to the independent certification body or auditor during each audit. The auditor samples keys, certificates and policy records. The auditor does not design or fix your controls.	Number of sampled systems and the clarity of your key inventory. A complete, current inventory generally shortens sampling and follow-up questions.

What stays in-house and what an implementation partner or auditor does

Your organization owns A.8.24. The policy on cryptographic use, the choice of approved algorithms and key lengths, the key owners and the risk decisions about exceptions all sit with your people, because an assessor will ask who approved the rules and who answers for them. An implementation partner can draft material, but the approvals, signatures and ongoing accountability must be yours.

Cryptography policy: Define which algorithms, key lengths and protocols are approved, and which are retired, for data at rest, in transit and in signing.
Key owners: Name an accountable owner for each key class, including who may generate, rotate, revoke and destroy keys.
Risk decisions: Record and approve any exception, such as a legacy system that cannot yet meet the approved algorithm list.
Legal review: Confirm with counsel which export, import or national restrictions on cryptography apply to your locations and suppliers, and link them to A.5.31.
Operating reviews: Review key inventories, rotation results and certificate expiry reports on a schedule you set and can show.

Before engaging anyone, confirm that a named employee can explain each cryptographic rule and approve changes to it.

Questions buyers ask about A.8.24 before hiring help

How much effort does A.8.24 take, and what drives it?

A.8.24 asks the organization to define rules for using cryptography and to implement them, including key management across the key life cycle. Effort depends mostly on how many systems encrypt data, how many keys and certificates exist, and whether keys are already managed centrally. An organization with a clear inventory of encrypted data stores, TLS endpoints and key holders usually has far less work than one that must first find where cryptography is used. Ask any partner to estimate effort from a written inventory of systems in scope rather than from the control title.

Can a small team run A.8.24 without a partner?

Often yes, if the team has at least one engineer who understands TLS, certificates and key storage and can own the policy decisions. The hard part is usually not the writing but keeping the key inventory current and proving that rotation and revocation happen as documented. A small team should check whether it can produce a list of keys, their owners, their rotation dates and the records of those rotations without manual reconstruction before an audit. If it cannot, outside help is more likely to pay off.

How long does the A.8.24 work take?

The duration depends on the size of the estate, how much cryptography is already documented, and how many teams must agree on algorithms and key ownership. Work tends to run longer when key management is spread across cloud accounts, application teams and vendors. Ask for a timeline that lists the discovery, policy approval, tooling and evidence phases separately, and ask what each phase depends on from your side. Any date you are given should follow from a written scope agreed before work starts.

What does the work need from our organization?

The organization owns the control, so it must name the people who make the decisions. Typically this includes a control owner for the cryptography policy, a key custodian for each key store, an application owner for each system that encrypts data, and someone who can approve the approved algorithm list. The work also needs read access to configuration, key management and certificate systems, and time from those owners to confirm what is actually in use. Without these named people, the policy will describe practices nobody follows.

Can a partner write our cryptography policy?

A partner can draft the policy, the algorithm and strength rules and the key management procedures, but the organization must review, approve and adopt them. The policy should reflect your legal and contractual obligations, which A.8.31 requires you to identify, so your legal and compliance staff need to confirm those points. Ask the partner to show how each rule maps to a system you run and to a piece of evidence you can produce. A policy that no one has tested against the live estate will not survive an assessment.

What should a partner's work on A.8.24 leave behind?

A well-scoped engagement should leave a cryptography policy, a key inventory, documented key life cycle procedures and records that show the procedures ran. It may also include configuration of tools such as a secrets engine or certificate manager, depending on what is agreed in writing. Ask whether the deliverables are owned by your organization and whether they can be maintained by your own staff after handover. Keep in mind that a partner prepares these items and evidence; it does not provide an assurance opinion.

How do we check an auditor or certification body before relying on it?

Only an accredited certification body can issue an ISO/IEC 27001 certificate, so start by confirming the body is accredited for ISO/IEC 27001 and that its certificates appear in the IAF CertSearch database, which ISO points to for checking accredited certificates. Ask which standards the body applies to its audits, and confirm it applies ISO/IEC 27006-1:2024 to your audit, as IAF MD 29:2024 required by 31 March 2026. Request the auditor's competence records and make sure the auditor you use is independent of any consultant who helped you prepare.

How DeployOpen prepares cryptography controls and evidence

DeployOpen plans and implements self-hosted open-source platforms that handle encryption, key management and certificate issuance inside your own infrastructure. We prepare the cryptography rules, key life cycle configuration and evidence that A.8.24 Use of cryptography calls for, while your organization owns the policy and the control decisions and an independent certification body issues any certificate.

How we scope

The written scope lists which systems, data stores and key holders fall under the cryptography rules and which are excluded.
Scope also records the algorithms and key lengths in use, the key life cycle stages covered and the legal restrictions your team wants reviewed.
Engagements are fixed-scope, so deliverables and timelines for the cryptography work are agreed in writing before any build begins.

How we build

We configure self-hosted key management, such as an OpenBao transit engine with versioned keys and scheduled rotation, inside your environment.
We set up certificate issuance with FreeIPA's integrated certificate authority or cert-manager, depending on your platform and issuer choices.
We enable encryption at rest where the platform supports it, and document any gaps, such as Nextcloud not encrypting file names or folder structure.

How we hand over

You receive documentation of the cryptography rules, the key life cycle procedures, and the configuration state of each system in scope.
Evidence packs include key inventories, rotation logs, certificate records and test results that show the configured controls operate as documented.
Your staff are walked through how to run key rotation, revocation and certificate renewal so the controls remain operated after handover.

How we support

Ongoing support, upgrades and continuous testing of the cryptography configuration are available as a retainer.
Retainers can cover periodic review of algorithm choices and key rotation evidence ahead of your internal audit or certification audit.
Your organization decides whether to request an independent audit, and the certification body, not DeployOpen, assesses and certifies the result.

A.8.24 Use of cryptography