ISO/IEC 27001:2022 · derived mapping target
A.8.24Use of cryptography
Define and apply rules for using cryptography, including how encryption keys are managed throughout their lifecycle. Good key management is as important as the encryption itself.
Mapping at a glance
A.8.24Use of cryptographyISO/IEC 27001:2022
A.8.24 is covered by 23 Sekit CSF controls. +18 more in the table below. Open in the full graph →
Mapped from the Sekit CSF
The Sekit controls that cover this requirement, lens by lens.
RCF-0018Regulatory compliance · TechnicalrelatedConfiguring system settings to meet regulatory requirements automatically touches the cryptography rules A.8.24 expects but does not itself define key management.RCF-0084Remote access · TechnicalsupportsThe remote-access facet restricts connections to encrypted VPN or zero-trust channels on enrolled devices, meeting the transmission-encryption half of A.8.24's cryptography rules.RCF-0094Encryption at rest · PolicysupportsThis policy facet requires written rules for encrypting sensitive data at rest across laptops, servers, cloud services and backups, one leg of A.8.24's cryptography scope.RCF-0095Encryption at rest · ProcesssupportsThe process facet checks on a schedule that every device and data store with sensitive information has encryption switched on, closing the gap between policy and reality.RCF-0096Encryption at rest · TechnicalsupportsThe technical facet turns on and centrally enforces storage encryption everywhere sensitive data rests, from full-disk encryption to encrypted backups.RCF-0097Encryption in transit · PolicysupportsThis policy facet sets a management-approved standard requiring encryption for sensitive data crossing any network, with named approved channels and an exception path.RCF-0098Encryption in transit · ProcesssupportsThe process facet makes encrypted channels the routine way staff send client files and system connections, not an occasional precaution.RCF-0099Encryption in transit · TechnicalsupportsThe technical facet configures every service and remote-access path to enforce encrypted protocols and switch off legacy unencrypted fallbacks.RCF-0100Key management · PolicysupportsThis policy facet defines how keys and certificates are generated, stored, rotated, recovered and retired, with a named owner for each step, the core of A.8.24's key-management demand.RCF-0101Key management · ProcesssupportsThe process facet runs key and certificate lifecycle tasks, rotation, renewal and revocation, on a defined schedule with each action recorded.RCF-0102Key management · TechnicalsupportsThe technical facet stores keys and certificates in a managed key store or vault instead of source code, scripts or shared documents, the mechanism A.8.24 expects for key protection.RCF-0163Disk encryption · PolicysupportsThis policy facet requires full disk encryption in writing on every laptop and device holding sensitive data, a specific application of the storage-encryption rule A.8.24 sets.RCF-0164Disk encryption · ProcesssupportsThe process facet turns on and verifies full disk encryption on every in-scope device and escrows recovery keys the company can retrieve.RCF-0165Disk encryption · TechnicalsupportsThe technical facet enforces disk encryption through the device management platform and reads fleet-wide encryption status rather than trusting per-device claims.RCF-0181TLS termination/hardening · PolicysupportsThis policy facet requires current TLS versions and ciphers on every company service with a named certificate owner, one channel A.8.24 asks organizations to secure.RCF-0182TLS termination/hardening · ProcesssupportsThe process facet scans public endpoints for weak TLS protocols and expiring certificates on a recurring schedule and fixes what the scan flags.RCF-0183TLS termination/hardening · TechnicalsupportsThe technical facet configures every service to accept only TLS 1.2 or later with modern ciphers and reject legacy protocol fallback.RCF-0189VPN management · TechnicalrelatedThe VPN facet enforces MFA, current protocols and encryption on remote connections, adjacent to but narrower than A.8.24's full cryptography scope.RCF-0243Immutable/offsite backups · TechnicalrelatedThe immutable-backup facet makes completed backup copies write-once and replicated offsite, protecting data integrity rather than governing the cryptography A.8.24 addresses directly.RCF-0340KMS & HSM · PolicysupportsThis policy facet defines written rules for generating, storing, rotating and retiring encryption keys with a named owner per step, matching A.8.24's key-management policy expectation.RCF-0341KMS & HSM · ProcesssupportsThe process facet handles the key lifecycle exactly as the procedure describes so key material never appears in plain text.RCF-0342KMS & HSM · TechnicalsupportsThe technical facet keeps cryptographic keys inside a managed key service or hardware-backed store rather than in code, files or tickets.RCF-0372Cross-border transfers · TechnicalrelatedThe cross-border transfer facet keeps personal data in approved regions and blocks unapproved international moves, a data-residency control beside rather than inside A.8.24's cryptography rules.
NIST CSF 2.0 counterparts
Reached through the Sekit CSF controls both map to — a mapping, not a formal equivalence.
Cyber Essentials counterparts
Evidence that proves this control
What an auditor, or Sekit's evidence engine, asks for.
Disk encryption evidence
The proof that laptops and devices handling sensitive data have full-disk encryption (BitLocker, FileVault or similar).
Encryption standards evidence
The proof that sensitive data is encrypted when stored (databases, storage) and when transmitted (encrypted connections).
From the Sekit evidence catalog
In practice
In practice, most SMEs have encryption switched on somewhere but cannot show a complete key-management lifecycle. Laptops run BitLocker or FileVault, but recovery keys sit on a shared drive instead of an escrow system, and a TLS certificate renews automatically until the one time it does not, because nobody owns the renewal. The gap auditors find most often is not encryption itself, it is key storage: API keys and certificates pasted into a config file or a wiki page instead of a managed vault, with no record of when a key was last rotated or who could recover it.
Common gaps
Full disk encryption is turned on but recovery keys are never escrowed centrally, so a lost laptop means a recovery scramble, not proof of protection.
Encryption in transit policy exists on paper, but an internal service still accepts plaintext connections nobody has ever audited.
Cryptographic keys and certificates live in application config files or a shared drive instead of a managed key vault.
Questions your auditor will ask
How are encryption keys and certificates managed through their lifecycle?
Keys and certificates are generated, stored and rotated in a managed key vault, with rotation and revocation logged and a named owner for each step.
Is full disk encryption verified across the whole device fleet, or assumed?
Verified, the device management platform reports FileVault or BitLocker status fleet-wide, and any device showing as unencrypted is flagged for remediation.
What happens to sensitive data sent outside the company network?
It travels only over encrypted channels; legacy protocols and plaintext connections are disabled at the service configuration level.
Where are the encryption keys stored, beyond the policy governing them?
In a managed key store or vault such as a cloud KMS, never in source code, scripts or shared documents.
Where regulation demands it
NIS2 Article 21 requires a documented policy and procedures for cryptography (9.1) plus periodic review of cryptographic measures (9.2).
ENS mp.com.2 requires protecting the confidentiality of communications in transit; mp.si.3 and mp.si.4 govern custody and transport of media holding data at rest.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.
Ask Sekura: “What evidence proves A.8.24?”
Also via MCP, free with account