Marcus Webb had been VP of Engineering at Thornfield Logistics for six years, and he'd tell anyone who asked that the company took security seriously. Every external connection ran over TLS 1.2 or better. The customer database had column-level encryption on driver license numbers, banking details, and dispatch GPS histories. The nightly backups were AES-256 encrypted before they left the data center. On paper — and in the vendor security questionnaires Thornfield filled out for its Fortune 500 shipping clients — the company looked like a model citizen of modern cryptography.
Then, in March, a contract developer who had left the company four months earlier used credentials that were never revoked to pull three of those "encrypted" backup archives from an S3 bucket. He didn't need to break AES-256. He didn't need a nation-state's supercomputer. He needed the master encryption key, which had been sitting — in plaintext — inside a config.yml file that had been committed to a shared internal Git repository eighteen months earlier during a rushed disaster-recovery drill and never rotated, never removed, and never scoped down. The encryption was real. The key management was nonexistent. The distinction cost Thornfield $6.2 million: forensic investigation, breach notification to 340,000 individuals across four states, two years of credit monitoring, a state attorney general inquiry, and the loss of two logistics contracts whose master service agreements required "demonstrated encryption key governance" that Thornfield could not, in that moment, demonstrate.
This is the scenario ISO/IEC 27001:2022 Control 8.24, Use of Cryptography, exists to prevent. Encryption is a well-understood, largely solved mathematical problem. Key management is where almost every real-world cryptographic failure actually happens — and it's precisely the part that a checkbox approach to "we use encryption" skips. Control 8.24 requires organizations to define and implement rules for the effective use of cryptography, including cryptographic key management, across the entire estate: what gets encrypted, with what algorithms and strengths, when data is encrypted in transit versus at rest, how keys are generated, distributed, stored, rotated, revoked, and destroyed, and how certificates and public key infrastructure are governed. Get the policy and the key lifecycle right, and encryption becomes a real control. Skip them, and you have Thornfield's problem: expensive cryptographic theater.
"I've audited organizations with beautiful encryption dashboards showing one hundred percent of volumes encrypted at rest, and then I ask where the keys live, and the room goes quiet. Control 8.24 isn't asking whether you encrypt. It's asking whether you can prove you control who can decrypt." — Priya Nandakumar, Lead ISMS Auditor, Ashford Compliance Partners
Who This Is For
This article is written for the people who own Control 8.24 in practice: CISOs and information security managers building or refreshing a cryptography policy, security architects and platform engineers responsible for key management systems and PKI, ISMS managers preparing Statement of Applicability justifications and internal audit evidence, and compliance leads translating "we use encryption" into an auditable, governed control. You'll walk away with a complete cryptography policy structure, an illustrative algorithm and key-strength reference table, an at-rest versus in-transit encryption framework, a full key management lifecycle (with a visual you can hand to a diagram tool), certificate and PKI governance guidance, HSM/KMS and cloud key management comparisons, and the audit evidence a certification body will expect to see.
What Control 8.24 Actually Requires
Control 8.24 sits in the Technological Controls theme of Annex A (8.1–8.34) and reads, in essence: rules for the effective use of cryptography, including cryptographic key management, shall be defined and implemented. Two things stand out immediately, and both are frequently misread.
First, ISO 27001 does not mandate specific algorithms, key lengths, or products. There is no clause anywhere in the standard that says "thou shalt use AES-256" or "thou shalt use RSA-2048." What the standard requires is that your organization has defined, risk-based rules — documented, approved, and consistently applied — for when and how cryptography is used, and that those rules are actually followed. ISO 27002:2022's implementation guidance for 8.24 discusses topics like a cryptography policy, key management, encryption of data at rest and in transit, and use of cryptographic controls to protect confidentiality, integrity, authenticity, and non-repudiation — but it deliberately leaves algorithm and key-length choices to the organization, because those choices change over time (as computing power grows and cryptanalysis advances) in a way a fixed international standard cannot chase clause by clause.
Second, and more consequential in practice: "cryptography" in 8.24 is not synonymous with "encryption," and it is emphatically not synonymous with "turning on a setting." The control has two co-equal halves. The first half is the cryptography policy: what needs protecting, with what class of algorithm, at what strength, in what circumstances. The second half — and the half organizations chronically underinvest in — is cryptographic key management: the full lifecycle of the keys and certificates that make the algorithm meaningful. An encryption algorithm without a governed key is not a control. It is, as Thornfield discovered, an expensive assumption. Auditors assessing 8.24 will ask to see both halves, and a mature ISMS treats key management with the same rigor it applies to privileged access rights — because functionally, a cryptographic key is a privileged credential, often the single most privileged one in the environment.
Control 8.24 also connects directly to classification decisions made upstream. You cannot write a sensible cryptography policy without already knowing what data exists and how sensitive it is — which is why 8.24 leans so heavily on the outputs of asset management and information classification. Classification tells you what needs cryptographic protection; 8.24 tells you how that protection is implemented, governed, and kept alive over time.
The Cryptography Policy: What Belongs in It
A cryptography policy is a standalone document (or a clearly delineated section of a broader technical security policy) that a certification auditor can read cover to cover and understand exactly what your organization has decided, and why. It is not a copy-pasted list of algorithm names. It is a set of decisions, scoped to your actual risk profile, your regulatory obligations, and your technology estate.
Policy Section | What It Must Cover | Common Failure Mode |
|---|---|---|
Purpose and scope | What systems, data classes, and business units the policy governs | Scope is vague ("all sensitive data") with no mapping to the classification scheme |
Roles and responsibilities | Who approves algorithm choices, who owns key management, who can approve exceptions | No named owner; "IT" is listed, which auditors reject as too vague |
Data classification triggers | Which classification levels (per 5.12) mandate encryption at rest, in transit, or both | Policy exists but isn't tied to the classification scheme, so enforcement is inconsistent |
Approved algorithms and minimum strengths | A living reference table of approved ciphers, hash functions, and minimum key/curve sizes | Table is written once at ISO project kickoff and never updated as algorithms age out |
Prohibited/deprecated algorithms | Explicit list of what is no longer acceptable (e.g., MD5, SHA-1, DES, RC4, TLS 1.0/1.1) | No deprecation list, so legacy weak crypto lingers indefinitely on legacy systems |
Key management requirements | Reference to (or inclusion of) the full key lifecycle: generation, distribution, storage, rotation, revocation, destruction | Policy says "keys must be managed securely" with zero operational detail |
Certificate and PKI governance | Who issues, renews, and revokes certificates; approved certificate authorities; expiry monitoring | No centralized certificate inventory; renewals are reactive, discovered via outages |
Use of cryptographic controls for integrity/authenticity | Digital signatures, message authentication codes, code signing requirements | Policy only addresses confidentiality, ignoring integrity and non-repudiation use cases |
Legal, regulatory, and export considerations | Jurisdictional restrictions on cryptography use, export, and import | Multinational deploys crypto libraries without checking import/export licensing |
Exception process | How a business unit requests and documents a deviation, with compensating controls | Exceptions granted verbally in meetings, never logged or time-boxed |
Review cycle | Frequency of policy review (commonly annual, or upon material algorithm/threat change) | Policy hasn't been reviewed since the initial certification cycle |
The policy should explicitly state that ISO 27001 does not prescribe specific algorithms — your organization is making risk-informed choices, typically anchored to established practitioner guidance (such as NIST publications or the recommendations of the receiving payment card or banking regulator) rather than inventing cryptography in-house. Home-grown or "proprietary" algorithms are a common finding in weaker ISMS implementations; auditors and penetration testers alike treat undisclosed proprietary ciphers as a red flag, not a differentiator.
"The first thing I ask a client's engineering lead is: 'show me the list of algorithms you've banned.' If they can rattle off MD5, SHA-1, and DES without hesitation, I know the policy is alive. If I get a blank stare, I know the policy is a PDF nobody opened after the audit." — Devon Achebe, Principal Security Architect, Ferrowatch Consulting
Approved Algorithms and Key Strengths (Illustrative Reference)
ISO 27001 does not mandate any specific algorithm, mode, or key length — that decision belongs to your organization, informed by current cryptanalytic consensus, regulatory guidance, and the sensitivity of what's being protected. The table below reflects widely adopted practitioner baselines as of the mid-2020s. Treat it as a starting template for your own policy annex, not as an ISO requirement, and revisit it at every policy review cycle since "acceptable" key strength shifts as computing power and cryptanalysis advance.
Purpose | Common Algorithm Choices | Illustrative Minimum Strength | Notes |
|---|---|---|---|
Symmetric encryption (data at rest/in transit) | AES (GCM or CBC with HMAC) | AES-256 for high-sensitivity data; AES-128 acceptable for lower-sensitivity workloads | GCM mode preferred where authenticated encryption is needed |
Asymmetric encryption / key exchange | RSA, Elliptic Curve (ECDH/ECDSA) | RSA 3072-bit or higher; ECC 256-bit (P-256) or higher | ECC generally preferred for performance at equivalent security margin |
Digital signatures | RSA-PSS, ECDSA, EdDSA | Matches asymmetric key strength above | Used for code signing, document signing, certificate signing |
Hashing (integrity, password storage support) | SHA-256, SHA-384, SHA-512 | SHA-256 minimum; SHA-1 and MD5 prohibited | Password storage should use a dedicated slow hash (bcrypt, scrypt, Argon2), not a raw hash function |
Transport encryption | TLS 1.2 (minimum), TLS 1.3 (preferred) | Strong cipher suites only; disable legacy renegotiation | SSL and TLS 1.0/1.1 treated as prohibited/deprecated |
VPN and network tunnel encryption | IPsec (AES-256-GCM), WireGuard | Aligned with symmetric encryption baseline | Referenced alongside network segmentation controls |
Message authentication | HMAC-SHA256 or higher | 256-bit key | Used to verify integrity/authenticity of transmitted data |
Password/secret hashing | Argon2id, bcrypt, scrypt | Tuned work factor reviewed annually | Not interchangeable with general-purpose hash functions above |
A cryptography policy that lists only "AES" or "we use strong encryption" without minimum key sizes and approved modes is a common finding auditors flag as insufficiently specific. Equally, some organizations over-specify and lock themselves into an algorithm that becomes obsolete mid-certification-cycle; the fix is a policy structure that separates the principle (approved algorithm families and minimum strengths) from the implementation detail (specific library versions), so the policy survives longer than any single technology refresh.
Encryption at Rest vs. Encryption in Transit: When Each Applies
One of the most common gaps in a cryptography policy is treating "encryption" as one undifferentiated requirement. In practice, data at rest and data in transit face different threat models, different implementation mechanisms, and different failure modes — and your policy should say, explicitly, which classification levels trigger which requirement.
Dimension | Encryption at Rest | Encryption in Transit |
|---|---|---|
Threat addressed | Physical theft, unauthorized storage/media access, insider access to underlying storage | Interception, eavesdropping, man-in-the-middle on the network path |
Typical mechanisms | Full-disk encryption, database transparent data encryption (TDE), column/field-level encryption, encrypted object storage | TLS 1.2/1.3, IPsec VPN tunnels, SSH, encrypted messaging protocols |
Where keys typically live | KMS/HSM, separate from the encrypted volume or database | Ephemeral session keys negotiated per connection (e.g., TLS handshake) |
Common trigger in policy | Classification level "Confidential" or higher; regulated data categories (PII, cardholder data, health data) | Any transmission crossing an untrusted network segment or the public internet |
Related control | ||
Common audit finding | Backups and snapshots left unencrypted even when the primary volume is encrypted | Internal service-to-service traffic left in plaintext because "it's inside the firewall" |
Verification method | Storage/volume encryption status reports, database TDE configuration audit | TLS scan results, cipher suite enumeration, certificate inventory |
The internal-traffic blind spot deserves special emphasis: a large share of the cryptographic gaps I find during ISO 27001 gap assessments are not on the public-facing edge — those get scanned constantly — but in east-west traffic between internal services, where teams assume network segmentation alone is sufficient. It usually isn't, and it explicitly is not a substitute for a defined 8.24 rule; segmentation and encryption are complementary controls documented separately, one under network security and one under 8.24.
A second frequent finding: backups. Organizations encrypt the production database but forget that the nightly backup, the disaster-recovery replica, and the developer's "temporary" export to a shared drive all constitute the same regulated data at rest, and all fall under the same policy trigger. Thornfield's incident, described at the top of this article, was precisely this pattern — the backup was encrypted, but the key protecting it was not treated with equivalent rigor.
The Cryptographic Key Management Lifecycle
If the cryptography policy is the "what and when," key management is the "how" — and it is the half of Control 8.24 that auditors scrutinize hardest, because it's where real-world breaches concentrate. A key that is well-generated but poorly stored, or well-stored but never rotated, or rotated but never properly revoked when an employee departs, undermines the entire cryptographic investment. ISO 27002's guidance on 8.24 explicitly calls out key management as covering the full lifecycle: generation, distribution, storage, rotation/change, archival, revocation, and destruction.
flowchart LR
A[Key Generation] --> B[Key Distribution]
B --> C[Key Storage]
C --> D[Key Usage / Operational]
D --> E[Key Rotation]
E --> C
D --> F[Key Revocation]
F --> G[Key Archival]
G --> H[Key Destruction]
F --> H
style A fill:#2b6cb0,color:#fff
style H fill:#c53030,color:#fffLifecycle Stage | What Should Happen | Evidence an Auditor Will Ask For |
|---|---|---|
Generation | Keys generated using a certified random number generator, within an HSM or KMS wherever feasible, at the approved strength | Key generation procedure, RNG/HSM certification reference (e.g., FIPS 140-2/3) |
Distribution | Keys transmitted only over authenticated, encrypted channels; never emailed or committed to source control | Key distribution procedure, secrets-management tooling configuration |
Storage | Keys stored separately from the data they protect, with strict access control and no plaintext key material at rest | HSM/KMS access logs, key vault configuration, segregation-of-duties evidence |
Usage/operational | Keys used only by authorized systems/services under least-privilege access | Access control lists tied to key usage, service-account key permissions |
Rotation | Keys rotated on a defined schedule or upon trigger events (suspected compromise, personnel change, algorithm deprecation) | Key rotation schedule/log, automated rotation tooling configuration |
Revocation | Compromised or retired keys immediately revoked and associated certificates/tokens invalidated | Revocation log, incident tie-in for compromise-triggered revocations |
Archival | Keys needed for legal/audit retrieval of historical encrypted data retained securely, separate from active keys | Archival key inventory, retention schedule aligned to records retention policy |
Destruction | Keys securely destroyed when no longer needed, following a documented and verifiable method | Key destruction log, certificate of destruction (for HSM-based keys) |
Two lifecycle stages generate the most audit findings in practice: rotation and destruction. Rotation fails when it exists on paper as an annual calendar reminder but no technical enforcement exists — nobody actually rotates the key, because rotating it requires re-encrypting large data volumes and nobody budgeted the engineering time. Destruction fails because organizations archive everything indefinitely "just in case," including keys that should have been destroyed years ago, which quietly expands the blast radius of any future compromise. A mature ISMS treats key destruction with the same discipline as secure disposal applies to physical media — deliberate, logged, and verifiable.
"Key rotation is the flossing of information security. Everyone agrees it matters. Almost nobody does it consistently until something forces the issue." — Renata Souza Lima, Director of Cloud Security, Baymark Financial Group
Certificate and PKI Management
Digital certificates are the most visible, most operationally fragile piece of most organizations' cryptographic estate — and expired certificates cause more self-inflicted outages than almost any other single infrastructure failure. Control 8.24's key management expectations extend fully to certificates: they are, functionally, a public key bound to an identity by a trusted signature, and they require the same generation-to-destruction governance as any other cryptographic key material.
PKI Governance Area | What Good Practice Looks Like | Common Gap |
|---|---|---|
Certificate authority (CA) selection | Approved list of internal and external CAs; internal CA hardened and access-restricted | Ad hoc self-signed certificates issued by individual engineers with no central record |
Certificate inventory | Centralized, automatically discovered inventory of every certificate in use, with expiry dates | Inventory exists only for public-facing certificates; internal service certificates untracked |
Issuance and approval | Defined request/approval workflow tied to a named business owner per certificate | Anyone with CA access can issue a certificate for any domain/service |
Renewal | Automated renewal or advance-notice alerting (30/60/90 days) tied to an owner who will act | Renewal discovered only when the certificate has already expired and something breaks |
Revocation | Certificate Revocation Lists (CRL) or OCSP responders kept current; revocation tied to key compromise procedures | Revoked certificates never propagate; relying systems still trust them |
Private key protection | Certificate private keys generated and stored in HSM or protected key store, never shared across environments | Same certificate/private key pair reused across dev, test, and production |
Root CA protection | Root CA kept offline, air-gapped, used only to sign intermediate CAs | Root CA credentials stored on a general-purpose administrative workstation |
Certificate governance is a natural extension of your broader access and identity story. Where privileged access rights govern who can act as an administrator, certificate governance governs who can act as a trusted identity on the network — a code-signing certificate, a service-to-service mutual-TLS certificate, or a client certificate authenticating a partner integration. Treat certificate issuance authority as a privileged capability, log it, and review it on the same cadence as other privileged access reviews.
HSM, KMS, and Cloud-Native Key Management
Where keys actually live is a strategic decision, not a default. Most mid-size and enterprise organizations choose among three broad models, often blending them across on-premises and cloud estates.
Approach | Description | Strengths | Considerations |
|---|---|---|---|
Hardware Security Module (HSM) | Dedicated, tamper-resistant physical or cloud-hosted appliance that generates and stores keys, performs cryptographic operations without exposing key material | Highest assurance; often required for payment card and financial regulatory scenarios; FIPS 140-2/3 validated options available | Higher cost, operational overhead, capacity planning for cryptographic throughput |
Cloud Key Management Service (KMS) | Cloud-provider-managed service for key generation, storage, rotation, and access control (e.g., major public cloud KMS offerings) | Fast to deploy, integrates natively with cloud storage/database encryption, built-in audit logging | Shared responsibility model — provider secures the infrastructure, customer must configure access policy and rotation correctly |
Self-managed key vault/software KMS | Organization-run key management software, often used in hybrid or air-gapped environments | Full control over configuration, useful where cloud KMS is unavailable or contractually restricted | Requires internal expertise to harden, patch, and operate at the same assurance level as a managed offering |
A frequent architectural mistake — and one worth calling out explicitly because it's exactly what happened at Thornfield — is storing keys in the same location, same access boundary, or same backup set as the data they protect. If a single compromised credential can retrieve both the encrypted data and the key that decrypts it, encryption has added complexity without adding security. The separation-of-duties principle that underpins access control policy applies with particular force here: the people and systems that can read encrypted data should not, by default, be the same people and systems that administer the keys protecting it.
Cloud migrations introduce a specific decision point worth documenting explicitly in the policy: whether the organization uses provider-managed keys (the cloud provider holds and rotates the key), customer-managed keys within the provider's KMS (the organization controls the key policy but the provider hosts it), or customer-supplied/bring-your-own-key models (the organization retains the key material entirely outside the provider). Each model shifts the compliance and operational burden differently, and your Statement of Applicability justification for 8.24 should reflect which model applies to which data classification tier, consistent with how you've scoped supplier and cloud service relationships elsewhere in the ISMS.
Legal, Export, and Regulatory Considerations
Cryptography is one of the few technical domains where national law directly constrains what an organization is permitted to build, use, and transmit across borders — and this is the kind of illustrative regulatory landscape a cryptography policy should acknowledge, without ISO 27001 itself dictating specific legal outcomes.
Consideration | Illustrative Example | Why It Matters to 8.24 |
|---|---|---|
Export controls | Cryptographic software/hardware historically subject to export licensing regimes in several jurisdictions | Multinational deployments of encryption tooling may require legal review before cross-border distribution |
Import restrictions | Some countries restrict or require registration/licensing for strong cryptography imported for commercial use | Relevant to organizations opening offices or data centers in new jurisdictions |
Data localization/sovereignty | Certain regulated sectors or jurisdictions require encryption keys to remain within national borders even if data is processed elsewhere | Shapes the choice between provider-managed and customer-managed cloud KMS models |
Lawful access / key disclosure | Some jurisdictions have legal mechanisms compelling disclosure of keys or plaintext under specific circumstances | Legal counsel should confirm applicability before assuming absolute key secrecy in all scenarios |
Sector-specific mandates | Payment card, banking, and health regulators frequently specify minimum cryptographic expectations | Referenced as compensating/aligned requirements, not as ISO 27001 mandates themselves |
The policy section on legal and regulatory considerations should be reviewed by legal counsel, not drafted solely by engineering — and it should explicitly reference how 8.24 supports, rather than replaces, sector regulation. For example, PCI DSS Requirements 3 and 4 specify detailed cryptographic and key-management expectations for cardholder data, and GDPR treats encryption as an explicitly named safeguard that can reduce breach-notification obligations and demonstrate "appropriate technical measures." A well-run ISMS documents these cross-references directly in the Statement of Applicability justification for 8.24, and in the equivalent SOC 2 control mapping where the organization pursues both frameworks.
"Clients ask me whether ISO 27001 certification means they're GDPR compliant. It doesn't, and I say so every time — but a properly implemented Control 8.24, with real key management behind it, is exactly the kind of 'appropriate technical measure' a GDPR regulator wants to see documented." — Helena Kowalczyk, Data Protection and Security Consultant, Northbridge Advisory
Post-Quantum Cryptography: An Emerging Consideration
No credible ISO 27001 article on cryptography in the mid-2020s can skip the post-quantum question, and no credible one should overstate it either. Large-scale, cryptographically relevant quantum computers capable of breaking current asymmetric algorithms (RSA, ECC) do not exist in production today. But the risk timeline that matters to security leaders isn't "when will a quantum computer exist" — it's "harvest now, decrypt later": adversaries capturing encrypted traffic or archived data today, betting they'll be able to decrypt it once sufficiently powerful quantum computers arrive, which matters enormously for any data with a long confidentiality shelf life (health records, long-term financial records, state secrets, intellectual property).
Practical steps worth reflecting in a forward-looking cryptography policy, without overcommitting to unproven timelines:
Maintain cryptographic agility — architect systems so algorithms can be swapped without a full re-platform, rather than hard-coding a single cipher suite everywhere.
Track standardization progress from recognized bodies publishing post-quantum algorithm standards, and pilot hybrid classical/post-quantum key exchange in high-sensitivity, long-shelf-life use cases.
Inventory which data assets have a confidentiality requirement extending 10+ years, since these are the highest-priority candidates for early post-quantum migration planning.
Avoid vendor hype cycles — treat post-quantum readiness as a roadmap item tracked in risk treatment planning, not an urgent 8.24 non-conformity, unless your sector regulator has issued a specific mandate.
Post-Quantum Readiness Signal | Maturity Indicator |
|---|---|
Cryptographic inventory | Organization can list every algorithm, key length, and library version in use across the estate |
Agility architecture | Cipher suites and algorithms are configurable, not hard-coded, in core systems |
Long-shelf-life data identified | High-confidentiality-duration data assets are flagged in the classification scheme |
Vendor roadmap awareness | Security team tracks post-quantum roadmap commitments from key technology vendors |
Pilot programs | At least one hybrid classical/post-quantum pilot underway for the highest-sensitivity use case |
Metrics and Audit Evidence
An auditor assessing Control 8.24 wants to see a defined policy, a documented key lifecycle, and — critically — evidence that both are operating, not just written. The metrics below are illustrative starting points; calibrate targets to your own environment and risk appetite.
Metric | Illustrative Target | Evidence Source |
|---|---|---|
Percentage of classified "Confidential"+ data encrypted at rest | 100% | Storage/database encryption configuration reports |
Percentage of external network traffic using TLS 1.2+ | 100% | TLS/cipher suite scan results |
Certificates approaching expiry with no renewal action (30-day window) | 0 | Certificate inventory/monitoring dashboard |
Keys overdue for scheduled rotation | 0 | Key management system rotation log |
Cryptographic exceptions without documented compensating controls | 0 | Exception register |
Time to revoke a compromised key/certificate | Under defined SLA (e.g., 4 hours for high-severity) | Incident response and key revocation logs |
Percentage of key management access reviewed in the last 12 months | 100% | Access review records tied to KMS/HSM administrator roles |
Deprecated algorithms/protocols still detected in the environment | 0 | Vulnerability/configuration scan results |
For certification purposes, keep this evidence organized and retrievable: a current cryptography policy with version history and approval sign-off; a key management procedure with lifecycle stages mapped to responsible roles; a certificate inventory with expiry tracking; rotation and revocation logs; exception records; and evidence of a recent internal review or audit of the cryptographic estate. Auditors consistently reward organizations that can produce this evidence in minutes rather than days — it signals the control is embedded in operations, not assembled for the audit.
Common Mistakes Organizations Make with Control 8.24
Mistake | Why It Happens | Consequence | Fix |
|---|---|---|---|
Treating "encryption enabled" as the whole control | Compliance teams check a configuration box without examining key governance | Encryption exists but provides false assurance, as in Thornfield's incident | Document and audit the full key lifecycle, not just the encryption toggle |
Storing keys alongside the data they protect | Convenience, tight deadlines, lack of separate key management tooling | A single compromised credential defeats both data access and decryption | Separate key storage (HSM/KMS) from data storage, enforce segregation of duties |
No deprecation list for weak algorithms | Policy written once and never revisited | Legacy systems continue running MD5, SHA-1, or SSL/TLS 1.0 indefinitely | Maintain an explicit prohibited/deprecated algorithm list, reviewed annually |
Manual, undocumented key rotation | Rotation requires re-encrypting data, which is treated as too disruptive to schedule | Keys live far longer than intended, increasing compromise exposure window | Automate rotation where possible; treat rotation debt as a tracked risk item |
Certificates managed by individual teams with no central inventory | Organic growth, no centralized PKI ownership | Expired certificates cause outages; forgotten certificates become attack surface | Centralize certificate discovery and ownership under one accountable function |
No policy on internal/east-west traffic encryption | Assumption that network segmentation is "enough" | Lateral movement inside the network exposes plaintext sensitive data | Extend the in-transit encryption trigger to internal segments carrying regulated data |
Ignoring backups and archives in the encryption scope | Backups treated as a separate operational concern from production data | Unencrypted or weakly-keyed backups become the actual point of compromise | Apply the same classification-driven encryption rule to backups, archives, and exports |
No documented exception process | Pressure to ship features faster than crypto implementation allows | Undocumented, unreviewed weak-crypto exceptions accumulate silently | Formal, time-boxed exception process with compensating controls and expiry |
Home-grown or undisclosed proprietary algorithms | Belief that secrecy of the algorithm adds security | Untested algorithms are frequently weaker than reviewed public standards | Use publicly vetted, widely reviewed algorithms; avoid "security through obscurity" |
Root CA or master keys accessible from general-purpose systems | Lack of dedicated secure infrastructure for the most sensitive key material | A single workstation compromise can cascade into full PKI or data compromise | Isolate root CA/master key operations on dedicated, access-restricted infrastructure |
Case Study: Meridian Health Analytics — From Encryption Theater to Governed Cryptography
Meridian Health Analytics, a fictional healthcare data analytics firm processing de-identified and identifiable patient records for 60 hospital systems, entered its ISO 27001 gap assessment believing Control 8.24 was already handled — every database had encryption at rest enabled by default through its cloud provider. The gap assessment found otherwise: the organization's cloud KMS was configured with provider-managed keys for every workload regardless of data sensitivity, meaning Meridian itself had no ability to independently revoke access to its most sensitive identifiable health records if a cloud administrator credential were compromised. There was no cryptography policy document, no certificate inventory (17 internal services were later found running self-signed certificates nobody could attribute to an owner), and no key rotation schedule of any kind.
Over a five-month remediation program, Meridian's security team built a tiered cryptography policy aligned to its existing data classification scheme, migrated its highest-sensitivity identifiable health data to customer-managed keys in a dedicated KMS namespace with quarterly rotation, deployed a centralized certificate inventory tool that cut its untracked-certificate count from 17 to zero, and documented a formal key destruction procedure tied to its data retention schedule. The organization passed its Stage 2 certification audit with zero major non-conformities on Control 8.24 and one minor observation (rotation automation for a legacy on-premises system, remediated within 60 days). Leadership reported the exercise also resolved a long-standing client concern: three hospital system contracts had been stalled pending "demonstrated encryption key governance" language nearly identical to the clause that cost Thornfield its contracts — Meridian closed all three within the following quarter.
Case Study: Castlebridge Savings — A Certificate Outage Becomes an Audit Finding
Castlebridge Savings, a fictional regional credit union, discovered the cost of ungoverned PKI in the worst possible way: a client-facing mobile banking certificate expired at 2 a.m. on a Saturday, taking online banking offline for eleven hours while an on-call engineer who had never handled a certificate renewal tried to locate the private key, the CA account credentials, and anyone who remembered how the original certificate had been issued three years earlier. The outage itself cost an estimated $180,000 in support costs, SLA penalties to a payment processing partner, and reputational damage measured in a spike of account-closure requests.
When Castlebridge's internal auditor investigated for the next ISO 27001 surveillance audit, the certificate incident became Exhibit A in a broader finding: the credit union had no centralized certificate inventory, no defined renewal ownership, and — more seriously — could not demonstrate that its cryptography policy's key management requirements extended to certificates at all. The finding was raised as a major non-conformity requiring a corrective action plan within 90 days. Castlebridge's remediation centered on three moves: appointing a named PKI owner within the security engineering team, deploying automated certificate discovery and expiry alerting across all environments, and rewriting the cryptography policy to explicitly define certificates as in-scope key material subject to the same lifecycle rigor as encryption keys. The corrective action was closed and verified within the 90-day window, and Castlebridge has had zero certificate-related outages in the two years since.
Case Study: Vantage Metrics — Turning Key Management Into a Sales Differentiator
Not every 8.24 story is a recovery from failure. Vantage Metrics, a fictional B2B SaaS analytics platform serving financial services clients, treated cryptographic key management as a competitive differentiator from the start of its ISO 27001 program. The company built a multi-tenant architecture where each enterprise client could optionally bring its own encryption key (BYOK) into a dedicated HSM-backed namespace, fully separate from Vantage's own infrastructure keys, with client-controlled revocation that could instantly render that client's data unreadable to Vantage's own engineers in an emergency.
During due-diligence reviews with prospective banking clients, Vantage's sales engineering team walked prospects through the key management lifecycle diagram and certificate inventory dashboard as a standard part of the security review — turning what is, for most vendors, a defensive audit exercise into a proactive sales asset. Vantage's own reporting attributed a measurable acceleration in enterprise deal cycles (deals involving a dedicated security review closed roughly 3 weeks faster on average once the crypto governance walkthrough was added to the standard sales security packet) directly to being able to answer the "where do our keys live and who controls them" question definitively, on the first call, with documentation in hand.
"The prospects who ask the hardest questions about our key management are exactly the clients we want. Being able to answer immediately, with an actual lifecycle diagram instead of a hand-wave, has closed more deals than any marketing page we've ever built." — Idris Falade, Head of Security Engineering, Vantage Metrics
Governance: Who Owns What in Cryptographic Key Management
Control 8.24 fails most often not from a lack of technical capability but from a lack of clear ownership. The RACI structure below is illustrative — adapt role titles to your organizational structure — but the principle of a single accountable owner for cryptographic governance, distinct from the many teams that consume cryptographic services, should hold in any organization pursuing certification.
Activity | CISO/Security Lead | Security Architect / Crypto Owner | Platform/Infrastructure Engineering | Application Development Teams | Internal Audit |
|---|---|---|---|---|---|
Cryptography policy approval | Accountable | Responsible | Consulted | Consulted | Informed |
Approved algorithm/key-strength list maintenance | Consulted | Responsible/Accountable | Consulted | Informed | Informed |
Key generation and storage configuration | Informed | Accountable | Responsible | Consulted | Informed |
Certificate issuance and renewal | Informed | Accountable | Responsible | Consulted | Informed |
Key rotation execution | Informed | Consulted | Responsible/Accountable | Informed | Informed |
Exception approval | Accountable | Responsible | Consulted | Consulted | Informed |
Audit evidence compilation | Consulted | Responsible | Consulted | Informed | Accountable (verification) |
"The organizations that pass 8.24 cleanly on the first attempt are never the ones with the fanciest HSM. They're the ones where one named person can answer, without hesitation, 'who is allowed to touch our keys, and how would we know if they didn't follow the rules.'" — Priya Nandakumar, Lead ISMS Auditor, Ashford Compliance Partners
A Simple Cryptography Maturity Model
Use this maturity model to have an honest internal conversation about where your organization actually sits before your next audit, not where you'd like an auditor to believe you sit.
Maturity Level | Characteristics |
|---|---|
Level 1 — Ad hoc | Encryption applied inconsistently; no written policy; keys managed informally by whoever set up the system |
Level 2 — Documented | Cryptography policy exists but is not consistently enforced; key rotation and certificate renewal are manual and reactive |
Level 3 — Managed | Policy enforced through configuration standards; centralized key/certificate inventory exists; rotation is scheduled but partially manual |
Level 4 — Automated | Key rotation, certificate renewal, and deprecated-algorithm detection are automated; exceptions are formally tracked and time-boxed |
Level 5 — Optimized | Cryptographic agility is architected in; post-quantum readiness roadmap exists; key governance metrics are reported to leadership and reviewed continuously |
Most organizations entering their first ISO 27001 certification cycle sit at Level 1 or 2. Certification requires reaching a defensible Level 3 at minimum — a documented policy, a functioning inventory, and evidence of consistent enforcement. Level 4 and 5 are differentiators, not certification requirements, but they are where the Vantage Metrics story above becomes possible.
How Control 8.24 Relates to Other Annex A Controls
Cryptography rarely operates in isolation — it is the enforcement mechanism for decisions made in several other parts of the ISMS, and auditors will expect to see these relationships reflected in your documentation, not treated as unrelated silos.
Related Control | Relationship to 8.24 |
|---|---|
Classification levels determine which data requires encryption at rest, in transit, or both | |
Governs who can access encrypted data and, separately, who can administer the keys protecting it | |
Endpoint encryption (full-disk) and secure authentication mechanisms often rely on the same cryptographic primitives governed by 8.24 | |
TLS and VPN encryption in transit are implemented within the network architecture but governed under the 8.24 cryptography policy | |
Deprecated/weak cryptographic protocols are tracked and remediated as part of the vulnerability management process | |
Backup encryption configuration and key protection are a direct extension of the at-rest encryption policy | |
Key and certificate access, rotation, and revocation events should be logged and monitored like any other privileged activity | |
Key compromise triggers a defined incident response path, including emergency revocation and re-keying | |
Secure coding practices govern how developers correctly call cryptographic libraries rather than implementing cryptography themselves | |
Information transfer (control 5.14 — planned article) | Governs encryption expectations when information is transferred to external parties, closely coupled to the in-transit rules in this article |
Privacy and protection of PII (control 5.34 — planned article) | Encryption is one of the primary technical safeguards used to satisfy privacy-by-design obligations for personal data |
Cryptography as a Business Enabler, Not Just a Compliance Line Item
It's tempting to treat Control 8.24 as a technical checkbox buried in Annex A — encryption is, after all, largely invisible when it's working correctly. But the case studies above tell a different story. Meridian Health Analytics closed three stalled hospital contracts once it could demonstrate real key governance. Vantage Metrics turned its key management lifecycle into a standard part of its sales security packet and measurably shortened enterprise deal cycles. Castlebridge Savings converted an embarrassing outage into a permanently fixed governance gap rather than a repeat incident. In each case, the organizations that treated 8.24 as genuine risk management — not just a policy PDF — turned a compliance obligation into a trust signal their customers, partners, and regulators could actually verify.
That's the strategic reframe worth carrying into your own ISMS: a cryptography program with a real policy, a governed key lifecycle, and clean audit evidence isn't overhead. It's one of the fastest, most concrete ways to answer the question every serious enterprise buyer, banking partner, and regulator eventually asks — "if your systems were compromised tomorrow, could you prove our data was actually unreadable?" Organizations that can answer that question with a diagram, an inventory, and a log file win deals that organizations answering with "we use encryption" quietly lose.
If you're building or refreshing this control now, don't start from a blank page. Pull the Information Security Policy Template as a starting structure for your cryptography policy section, use the Annex A — All 93 Controls at a Glance cheat sheet to see exactly how 8.24 sits alongside the other Technological Controls you're implementing in parallel, and run your current state through the ISO 27001 Gap Analysis Tool to see precisely where your key management lifecycle has holes before an external auditor finds them for you. If you're earlier in the certification journey and still assembling your core documentation set, the ISO 27001 Mandatory Documents Checklist will show you exactly where the cryptography policy fits among everything else you need, and The Complete ISO 27001 Implementation Guide walks through sequencing this control against the rest of your Annex A implementation program. PentesterWorld's consulting team has walked organizations of every size through exactly this exercise — from a first cryptography policy draft to a fully governed key management lifecycle an auditor signs off on the first time. If your last conversation about encryption ended with "I think it's on" rather than a documented answer, that's the conversation worth having with us next.