"AES-256 at rest" is true of a great deal of cloud software, and it says nothing about who holds the key. That second point is what security analysts are usually checking when they ask about encryption. Nearly every follow-up comes back to key ownership. The question underneath is where your product sits on the line from provider-held to customer-held keys.

What AES-256 actually tells the buyer

AES is the Advanced Encryption Standard, published by NIST as FIPS 197. It specifies AES-128, AES-192 and AES-256, all encrypting 128-bit blocks, with the number giving the key length in bits (FIPS 197). So "AES-256" names a cipher and a key size. It doesn't say which data is covered or who manages the key.

Coverage is the follow-up that catches people. A product's primary database, object storage, backups, search indexes and log archives can be separate stores, and a published at-rest claim may not cover every one. If your whitepaper names the stores, name the same ones and no more.

Provider-managed keys

Provider-managed keys are the default for a lot of SaaS. The cloud provider generates and holds the keys, and the customer gets encryption without any say over the key lifecycle. Amazon S3's default, for example, is server-side encryption with Amazon S3 managed keys (SSE-S3), using AES-256 (Amazon S3 server-side encryption). It's a real, documented control, and for many buyers it's enough.

Buyers working through a SIG or CAIQ questionnaire, the kind that usually arrives with a SOC 2 report request, sometimes blur encryption at rest with encryption in transit. At rest protects data sitting on disk or in storage; in transit protects it moving across a network, usually with TLS, whose current version, 1.3, is defined in RFC 8446. Offer the split in one sentence, give the minimum TLS version your product accepts if it's published, and go back to the question they asked.

Customer-managed keys

With customer-managed keys (CMK), the customer controls a key inside the provider's key management service, deciding who may use it and able to disable it or schedule its deletion, while the encrypted data still lives in the provider's storage. Rotation questions belong here. NIST's key-management guidance, SP 800-57 Part 1 Rev. 5, covers the key lifecycle from generation through use, rotation and destruction. If keys rotate automatically and customers can't change the interval, say exactly that. If customers choose the rotation period, say so, and name the plan it's on, since key management is sometimes sold only on a higher tier than the one the buyer is pricing.

Buyers who ask for CMK usually ask next what revoking the key does. On AWS, a disabled KMS key can't be used in any cryptographic operation until it's re-enabled (Enable and disable keys). AWS KMS doesn't store or track the data keys it has already issued, though (Data keys), so revocation stops new decryption without reaching data that was already decrypted or a data key a service still holds. How quickly your product actually stops reading the customer's data depends on its architecture, so unless it's in your whitepaper, tell the buyer you'll confirm the revocation behaviour in writing before the next call.

BYOK and HYOK

Buyers use BYOK, CMK and "customer-managed keys" as if they were one feature, and vendors often mean different things by each. Bring your own key usually means the customer generates key material outside the provider and imports it; AWS documents importing key material into KMS keys as an explicit option.

Hold your own key (HYOK) goes further, keeping the key material outside the cloud provider entirely. On AWS the closest equivalent is an external key store, backed by a key manager the customer owns and runs outside AWS. Few SaaS products expose this to their own customers, and where they do it's usually on enterprise tiers.

The trap on these options is the cloud provider's feature list. Your infrastructure team being able to use CMK in the AWS console doesn't mean your product lets end customers manage keys. A spoken "yes, you fully control the keys" that turns out, once the reviewer opens the whitepaper, to mean SSE-S3 leaves the buyer with a call note and a document that disagree on the exact point they asked about. That kind of mismatch tends to slow a review well beyond the one question, because the reviewer now has reason to recheck everything else said on the same call.