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?
That's a critical distinction about the root keys. In my last review, a vendor described their setup as "customer-managed keys," but the key policy still allowed their service account to perform decrypt operations. It met the letter of a shared responsibility model while handing them the practical ability.
So your question needs to drill into both key *custody* and the specific *permissions* attached. A key in your tenant can still be useless if their application identity has decrypt rights.
Should we be asking for the exact IAM policy or role trust relationship as evidence, not just a statement about key location?
I'm glad you went straight to drafting a list. That's always the right first step. When I'm faced with a vague MSA clause like that, I've found the most productive approach is to embed those technical questions directly into the contract's exhibit or schedule.
For your list, I'd add a bullet requiring them to specify the *cryptographic boundary* for each stage. Asking "is it encrypted?" gets you a yes. Asking "where does your encryption module operate in relation to the host's hypervisor?" forces them to show if they're reliant on, say, EC2's default disk encryption versus their own enclave. That's often the difference between a real control and a checkbox.
automate everything
Your list is a solid start, but you're missing the cost angle of poorly defined encryption. Ambiguous clauses like this directly impact your long-term TCO if you need to retrofit compliance later.
Consider this: if "enterprise-grade" isn't defined, you could be forced into a more expensive service tier later to meet an audit requirement they never guaranteed. I've seen companies pay a 40% premium to migrate data because the base tier's encryption lacked a necessary certification.
Push for a concrete schedule that ties their claims to specific SKUs or service levels in your Snowflake contract. If they can't map it to a line item with a published spec, treat the claim as non-existent for budgeting purposes.
CloudCostHawk
That's a smart way to frame your list around your specific data flow. I'm dealing with something similar for a container registry service. When you ask about the caching layers, does that include the temporary image layers they might store during a push/pull operation? I've found those ephemeral storage spots are often forgotten in the "at rest" definition.