CEK-18 — Key Archival

Every framework that asks this

Answer CEK-18 once and it typically satisfies the equivalent control elsewhere. Altitude and confidence vary — a domain-level anchor is a starting point to verify, not an audited equivalence.

Full provenance and NIST 800-53 mappings: the framework crosswalk.

What the reviewer is really checking

The reviewer wants to establish two distinct things, and generic answers usually cover only the first. One: is data actually encrypted, with what algorithms and protocol versions, in transit and at rest, and across which data stores, backups, and internal service-to-service traffic. Two, and the part reviewers actually care about: who controls the keys and how. The sub-questions are: What key-management system or HSM holds the keys, and where does it run? Are keys rotated, on what schedule, and can you rotate on demand after a suspected compromise? Who and what can access keys, and is that access least-privilege, logged, and separated from access to the data itself? Do you support customer-managed keys or bring-your-own-key if the buyer requires it? Are deprecated algorithms and protocol versions (TLS 1.0/1.1, SHA-1, RSA-1024) disallowed? The reviewer treats 'encrypted at rest and in transit' with nothing on key management as a non-answer, because it says nothing about the failure modes that actually leak data: a key checked into source, a shared key never rotated, or an over-broad key-access role.

What a truthful, defensible answer contains

A defensible answer covers both halves and never stops at 'encrypted.' For encryption, name the protocol versions and algorithms: transit protected by a stated minimum (for example TLS 1.2 or higher) and data at rest under a named cipher (for example AES-256), and say what scope that covers, including primary stores, backups, and internal traffic. For key management, name the KMS or HSM, state where it runs and its assurance level, describe the rotation schedule and the ability to rotate on demand, and describe key-access controls: least-privilege roles, separation from data access, and audit logging of key use. State whether customer-managed or bring-your-own keys are supported if that is a buyer requirement. Note that deprecated algorithms and protocol versions are disabled, and how you verify that. The detail that survives review distinguishes what is encrypted from how keys are governed. Do not imply hardware-backed key isolation or on-demand rotation you cannot perform; describe the actual control, including its limits.

Make it traceable

Anchor the answer to inspectable proof. Point at the encryption standard or cryptography policy that lists approved algorithms and minimum protocol versions, the key-management configuration or KMS/HSM attestation showing rotation settings and access policy, and a TLS/SSL scan (for example an external Labs-grade report) confirming deprecated protocols are disabled. Reference key-access audit logs and the role definitions that scope key use. The Promise-to-Proof line is that 'AES-256 at rest with rotated, access-controlled keys' resolves to a KMS policy a reviewer can read for the rotation period and the access grants, plus a scan confirming the transit posture, so the claim maps to configuration and logs rather than an assertion.

Answer patterns that hold up

• Name the transit protocol minimum and the at-rest cipher, and state the scope covered including backups and internal traffic.
• Name the KMS or HSM, where it runs, and its assurance level.
• State the key-rotation schedule and whether on-demand rotation after suspected compromise is possible.
• Describe key-access controls: least-privilege roles, separation from data access, and audit logging of key use.
• State whether customer-managed or bring-your-own keys are supported and whether deprecated algorithms and protocol versions are disabled.

Evidence that backs the answer

Red flags reviewers catch

• "Encrypted at rest and in transit" with nothing said about how keys are managed.
• No rotation schedule and no ability to rotate keys on demand after a compromise.
• Naming a cipher but not who or what can access the keys.
• No statement that deprecated protocols (TLS 1.0/1.1, SHA-1) are disabled.
• Keys and the data they protect accessible under the same over-broad role.

Sources

• CSA Cloud Controls Matrix v4 — Cryptography, Encryption & Key Management (CEK) domain
• NIST SP 800-53 Rev. 5 — SC-12 key establishment, SC-13 cryptographic protection, SC-28 protection at rest
• ISO/IEC 27001:2022 — A.8.24 Use of cryptography

Other Cryptography, Encryption & Key Management controls