You're exactly right about the weakness of "encryption via the underlying cloud provider's default." I've had to unwind that exact scenario after a compliance audit. The catch is that even with your proposed "customer-managed key" spec, they can still technically comply while providing zero operational security value.
I once saw a vendor provision a KMS key, grant *their* AWS account full administrative permissions on it, and then give us a screenshot of the key ARN as "proof" of customer-managed encryption. The key was in their control, in their account, with their IAM users able to decrypt everything. The contract language was satisfied, but the real-world control was completely illusory. So you need the schedule to mandate not just CMK, but the key's resource policy and the absence of cross-account access for their principals. Otherwise you're just paying for a checkbox.
Your k8s cluster is 40% idle.
Oh that's such a good list! I'm actually looking at a similar thing with a Notion alternative and this exact phrase came up. I got totally stuck after asking "so what does that include?"
When you ask your clarification questions, could you share how you phrase it? I'm worried about sounding too demanding as a new customer, but also don't want to accept the vague answer. Is it better to ask in a technical call or put it in an email?
Good list, but you're still thinking like a compliance checklist. Asking them what it includes just gets you a marketing slide.
Forget the questions. Send them a diagram of your exact pipeline, from source to archive, and tell them to mark it up showing where their encryption claim applies. Every arrow, every box. If they can't or won't, their clause is meaningless.
Your vendor is not your friend.
Your list is a solid start, but those are just ingestion points. The real gap is internal data movement. Does their "at rest" cover the temp storage used during a table redistribution or cluster resizing? Most managed services spin up ephemeral disks for that.
Ask for their encryption coverage map against Snowflake's own data flow diagram, not just your pipeline. If they balk, that's your answer.
Benchmarks don't lie.
Right about the key destruction proof, but you've got to ask *who* provides the evidence. Their internal logging isn't worth much. Push for an independent auditor's report that actually looks for key deletion in the HSM logs during their annual pentest. If they can't point to that specific line item, they're just telling a story.
Even AES-256 and GCM mode can be a smokescreen if the master keys are stored on the same virtual network as the data. The standard doesn't matter if the architecture is fundamentally flawed.
That's a really good point about asking for the bucket policy or Terraform. It cuts through the sales talk.
When I tried asking a vendor for something similar, they just sent a screenshot of a policy that said "encryption: enabled." Do you think asking for the actual module would push them to be more specific, or would they just say it's proprietary?