Anyone else having issues comparing encryption-at-rest claims across vendors?

Your checklist is solid, but you're missing the most critical empirical test: the key revocation latency. The promise of "immediate effect on data access" is rarely backed by measurable SLAs. I script this by provisioning a volume, writing a known payload, then revoking the key via the vendor's API or KMS console while simultaneously polling the data endpoint. The time delta between a 403 and the last successful 200 is the real metric. For three major cloud block storage services last quarter, those latencies ranged from 8 seconds to over 90 seconds, which is an eternity for a security control. The whitepapers never mention that.

This is super helpful, thanks. I'm just starting to look at this for our file storage options and it's overwhelming.

>The worst are the ones who say "all data is encrypted" but can't answer who holds the key

Exactly! I got that answer twice last week. When I asked for the admin panel screenshot you mentioned, the sales call got quiet. 😅

One basic thing I've added to my list is asking for the exact encryption algorithm and key length they use. A couple have just said "industry standard AES" and stopped there. Is that a red flag, or am I being too nitpicky?

Good checklist. The admin panel screenshot requirement is key. I've had vendors send marketing docs instead, which tells you everything.

What about the backup systems they use internally? Sometimes the primary storage is encrypted with your keys, but their internal backup to cold storage reverts to their own platform keys. That's a huge scope gap.

Also, do you consider API error responses a security signal? A vague "access denied" versus a specific "KMS key revoked" log line matters for incident response.

It's not nitpicky at all. "Industry standard AES" is a red flag because it omits the mode of operation, which is arguably more important than the key length. AES-GCM and AES-CBC with proper HMAC are very different beasts for data at rest.

That said, you can sometimes find the exact details in their compliance documentation or a public SSP, rather than trusting a sales engineer. If they can't point you to that document, it's a real problem.

For a vendor's internal management, asking for the specific KMS product they use (e.g., AWS KMS, HashiCorp Vault) can also be telling. It hints at their operational maturity.

Asking for the exact algorithm isn't nitpicky, it's basic due diligence. "Industry standard AES" is a canned response because they don't want to admit it's probably AES-CBC. You need the mode.

Push for the NIST publication or RFC they follow. If they cite FIPS 140-2/3, ask for the validation certificate number and look it up - it'll list the exact implementation.

Also, key length is the least interesting part. A 256-bit key with a weak mode is worse than 128-bit with a proper authenticated mode. Their evasion on the algorithm usually means operational corners were cut elsewhere, like key rotation.

Screenshots prove nothing. They can be staged. The real test is IAM policy simulation. Can your CI/CD service account actually enforce CMK policies on a deployment, or does the vendor's system just ignore it and fall back to their key? Seen that happen.

And your "operational impact" section is backwards. Performance degradation is the goal. If there's no measurable cost to using your own keys, their encryption is probably fake or so shallow it's useless. You want a visible penalty, it means it's actually doing work.

Most of these checklists just give vendors a script to lie better.

Your checklist is a strong operational foundation, but it's missing the empirical validation layer. You've listed "immediate effect on data access" as a criterion, but have you defined a measurable SLA for "immediate" in your vendor contracts? Without a quantified maximum latency from revocation event to access denial, you're accepting a marketing promise.

I'd add a subsection under Key Management for "Revocation Latency Benchmarking." The methodology user206 mentioned is correct; you need to measure the delta yourself. My team's last procurement cycle found vendors who advertised "instant" revocation but had contractual SLAs of up to five minutes, which is functionally useless for a security incident. The architectural whitepaper never includes these systemic delays caused by persistent cache layers.

Also, your "Operational Impact" point on performance degradation is critical, but the metric should be more specific. Don't ask for a generic "degradation." Require them to provide read/write IOPS benchmarks under CMK for your specific expected volume sizes, compared to their default managed keys. A vendor that can't produce this data hasn't operationalized CMK for real workloads.

Your checklist is good as far as it goes, but it's still just a list of promises to audit. I've been burned by this.

> Screenshots of their admin panel or config are the only thing that counts.

Strong disagree. Screenshots are theatre. I've had three vendors show me a beautiful "CMK Enabled" toggle. It didn't actually change the key material used at the storage layer; it just added a billing line item. The proof is forcing a key rotation, then trying to restore a six-month-old backup encrypted under the old key. If it works without the old key, their "CMK" is a logging facade.

You need to add a criterion for "cryptographic proof of key material use." If they can't provide it, walk away.