Use of cryptography

Updated: 2026-02-17

Plain English Translation

Cryptography involves scrambling sensitive data so it is unreadable to unauthorized users, both when stored and when transmitted across networks. To meet this control, organizations must create rules defining when and how encryption is used. Crucially, they must also actively manage the cryptographic keys—the digital passcodes used to encrypt and decrypt the data—throughout their entire lifecycle to prevent them from being lost, stolen, or misused.

Executive Takeaway

Defining rules for cryptography and actively managing encryption keys prevents sensitive data from being compromised during a breach.

ImpactHigh
ComplexityHigh

Why This Matters

  • Serves as the ultimate fail-safe for data protection; even if attackers bypass access controls, strong encryption renders stolen data useless without the keys.
  • Fulfills mandatory compliance requirements across virtually all major privacy frameworks and regulations (e.g., GDPR, HIPAA, PCI DSS).

What “Good” Looks Like

  • A comprehensive Cryptography Policy dictates approved algorithms (e.g., AES-256, TLS 1.2+), with policy versioning and attestations tracked in tools like WatchDog Security's Policy Management.
  • Keys are managed through automated Cloud KMS or HSMs with enforced annual rotation and strict access controls, with configuration checks and evidence capture supported by tools like WatchDog Security's Posture Management and Compliance Center.

ISO 27001:2022 control A.8.24 is a technological requirement that mandates organizations define and implement rules for the effective use of cryptography. This ISO 27001 A.8.24 cryptography control ensures organizations actively secure data confidentiality and integrity using encryption, and formally manage the cryptographic keys required to do so.

Writing an ISO 27001 cryptography policy template involves documenting the organization's approach to encryption. It should specify approved cryptographic algorithms, minimum key lengths, required TLS versions, and detail the complete cryptographic key lifecycle management process to ensure consistency across the business. Tools like WatchDog Security's Policy Management can help maintain controlled versions, route approvals, and track policy acceptance for audit readiness.

A cryptographic key management policy must outline the entire lifecycle of a key. This includes secure key generation, storage, distribution, rotation, suspension, revocation, and secure destruction. It must also establish strict access controls, identifying exactly who or what systems are permitted to access the keys.

Following key rotation policy best practices, organizations typically rotate encryption keys at least annually. However, the exact frequency should be dictated by the organization's risk assessment, the volume of data encrypted by a single key, and the specific requirements of the cloud provider or KMS being used.

An HSM (Hardware Security Module) is not strictly required for every organization. When evaluating HSM vs KMS for key management, a standard cloud Key Management Service (KMS) is sufficient for most businesses. HSMs are typically reserved for highly regulated environments, such as banking or government, that require dedicated, tamper-evident hardware.

The cryptographic key lifecycle refers to the phased management of a key from its creation to its permanent deletion. It ensures that keys are generated using strong random number generators, stored securely, rotated before they are compromised, revoked if a breach is suspected, and finally destroyed so old data cannot be maliciously decrypted.

Organizations leverage native cloud Key Management Services (KMS), such as AWS KMS or Azure Key Vault, to centrally generate and protect keys. To meet compliance, organizations often employ BYOK (bring your own key) compliance strategies or Customer-Managed Encryption Keys (CMEK) to maintain absolute control over the key lifecycle independently from the cloud provider.

Acceptable algorithms must align with industry standards, such as those published by NIST. For encryption at rest and in transit ISO 27001 compliance, organizations commonly use AES-256 for symmetric encryption, RSA 2048-bit or higher for asymmetric encryption, and TLS 1.2 or TLS 1.3 for securing network communications.

Evidence for ISO 27001 cryptography control typically includes an approved Cryptography Policy, configuration screenshots showing encryption enabled on databases and storage buckets, and active TLS configuration standards for compliance. Auditors will also request evidence that keys are actively managed, such as logs showing an annual key rotation event. Tools like WatchDog Security's Compliance Center can map A.8.24 to required evidence and centralize collection workflows. When sharing artifacts with auditors, WatchDog Security's Secure File Sharing can apply access controls and audit logs to the evidence package.

Access to encryption keys must be heavily restricted using the principle of least privilege, typically managed through strict IAM roles. Additionally, organizations must ensure they understand how to store and protect encryption keys against accidental loss by configuring secure backup mechanisms, ensuring encrypted data remains recoverable during a disaster.

A common challenge is losing visibility into where sensitive data lives across cloud, endpoints, and SaaS, which leads to inconsistent encryption coverage. Tools like WatchDog Security's Asset Inventory can help centralize system ownership and tagging so encryption requirements and key management expectations can be applied consistently.

Cryptography programs often fail in execution because policies, exceptions, and evidence are scattered across tickets, docs, and cloud consoles. Tools like WatchDog Security's Compliance Center can help map A.8.24 requirements to specific evidence requests, track gaps, and keep audit-ready documentation in one place.

ISO-27001 A.8.24

"Rules for the effective use of cryptography, including cryptographic key management, shall be defined and implemented."

VersionDateAuthorDescription
1.0.02026-02-17WatchDog Security GRC TeamInitial publication