Auditing ISO 27001 Annex A 8.24 Use of Cryptography is the technical verification of encryption protocols and key management lifecycles protecting data integrity. The Primary Implementation Requirement is the enforcement of strong algorithms and centralised KMS management, providing the Business Benefit of ensuring confidentiality and meeting regulatory data protection requirements.
ISO 27001 Annex A 8.24 Use of Cryptography Audit Checklist
This technical verification tool is designed for lead auditors to establish the efficacy of cryptographic controls in protecting data at rest and in transit. Use this checklist to validate compliance with ISO 27001 Annex A 8.24.
1. Cryptographic Policy and Standard Formalisation Verified
Verification Criteria: A documented policy exists defining the mandatory cryptographic algorithms, key lengths, and usage requirements across the organisation.
Required Evidence: Approved “Cryptographic Policy” or “Encryption Standard” specifying algorithms (e.g., AES-256) and protocols (e.g., TLS 1.3).
Pass/Fail Test: If the organisation cannot produce a formal policy defining its cryptographic baselines, mark as Non-Compliant.
2. Data-at-Rest Encryption Enforcement Confirmed
Verification Criteria: Technical controls ensure that sensitive data stored on disk, databases, and portable media is encrypted using approved algorithms.
Required Evidence: Database configuration screenshots showing TDE (Transparent Data Encryption) or MDM reports confirming 100% Full Disk Encryption (FDE).
Pass/Fail Test: If any laptop or production database containing sensitive information is found unencrypted at rest, mark as Non-Compliant.
3. Data-in-Transit Encryption Strength Validated
Verification Criteria: Cryptographic protocols protect data traversing untrusted networks, with legacy protocols (e.g., SSL 3.0, TLS 1.0) disabled.
Required Evidence: SSL/TLS scan reports (e.g., Qualys SSL Labs) showing “A” ratings and the absence of deprecated cipher suites.
Pass/Fail Test: If any public-facing application allows connections via TLS 1.1 or lower, mark as Non-Compliant.
4. KMS Integrity Verified
Verification Criteria: A centralised Key Management System or Hardware Security Module (HSM) is utilised to manage the lifecycle of cryptographic keys.
Required Evidence: Configuration logs from AWS KMS, Azure Key Vault, or an on-premise HSM showing active key management.
Pass/Fail Test: If cryptographic keys are stored in plain-text configuration files or within the same directory as the encrypted data, mark as Non-Compliant.
5. Cryptographic Key Rotation Records Identified
Verification Criteria: Master and data encryption keys are subject to a regular rotation schedule defined by the risk assessment and policy.
Required Evidence: KMS audit logs showing “Key Rotation” events within the last 12 months for critical keys.
Pass/Fail Test: If the organisation has not rotated its primary encryption keys for more than two years without a documented justification, mark as Non-Compliant.
6. Separation of Duties for Key Management Confirmed
Verification Criteria: Technical access controls prevent a single individual from possessing both the encrypted data and the associated decryption keys.
Required Evidence: IAM (Identity and Access Management) role definitions showing that ‘Database Admins’ do not have ‘Key Manager’ permissions.
Pass/Fail Test: If a single administrator has full control over both the backup files and the encryption keys required to restore them, mark as Non-Compliant.
7. Digital Signature and Integrity Verification Validated
Verification Criteria: Cryptographic signatures or hashes are utilised to ensure the integrity and non-repudiation of critical communications and software binaries.
Required Evidence: Code signing certificates, DKIM/DMARC configuration logs, or SHA-256 hash verification logs for software updates.
Pass/Fail Test: If software updates are deployed to production without cryptographic integrity verification (e.g., checking the hash), mark as Non-Compliant.
8. PKI Certificate Governance Verified
Verification Criteria: A formalised process exists for managing the lifecycle of digital certificates, including issuance, renewal, and revocation.
Required Evidence: Certificate inventory showing expiry dates and evidence of automated alerts for certificates nearing expiration.
Pass/Fail Test: If any production system is found with an expired or self-signed certificate without a documented exception, mark as Non-Compliant.
9. Cryptographic Erasure (Crypto-Shredding) Capability Confirmed
Verification Criteria: The organisation utilises the destruction of encryption keys as a primary method for the secure deletion of cloud-hosted data.
Required Evidence: Decommissioning logs showing the deletion of specific keys from the KMS corresponding to retired data volumes.
Pass/Fail Test: If data is “deleted” from a cloud provider but the associated keys remain active and accessible in the KMS, mark as Non-Compliant.
10. Cryptographic Algorithm Review and Threat Analysis Recorded
Verification Criteria: Management performs an annual review of the organisation’s cryptographic choices against emerging threats (e.g., quantum computing or new exploits).
Required Evidence: Management Review Meeting (MRM) minutes or security assessment reports evaluating algorithm strength.
Pass/Fail Test: If the organisation continues to use SHA-1 or MD5 for security-critical functions without a documented migration plan, mark as Non-Compliant.
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Policy Implementation | Tool checks if “Encryption Policy.pdf” is uploaded. | Verify Technical Baselines. A policy is words; a “Pass” requires proof that 100% of S3 buckets/SQL disks are actually encrypted. |
| Key Management | GRC tool identifies “AWS KMS” is in use. | Verify Key Ownership. Is the organisation using Customer Managed Keys (CMK) or just letting the provider hold all the power? |
| Protocol Strength | Platform identifies “SSL Certificate” exists. | Verify Cipher Suites. GRC tools often ignore the presence of weak ciphers like Triple-DES or RC4 that still allow exploitation. |
| Key Rotation | Tool marks “Pass” because rotation is ‘Enabled’ in settings. | Check Audit Logs. Many tools mark this “Pass” even if the rotation job has failed for 6 months due to API errors. |
| Separation of Duties | Tool assumes HR/IT roles are separate. | Verify Actual Access. Check if the ‘Cloud Global Admin’ has bypass rights to the HSM. GRC tools miss “Shadow Admin” privileges. |
| Certificate Renewal | Platform tracks a single website’s expiry date. | Verify Internal PKI. GRC tools miss expired internal-only certificates that can break secure internal communication. |
| Crypto-Shredding | Tool records “Data Deleted” task as ‘Done’. | Verify Key Purge. Deleting data isn’t shredding. The auditor must see the KMS log showing the key itself was destroyed. |
About the author
