That script is solid for getting past the gatekeeper. The trick is knowing which control to ask for. CC6.1 is a good generic pick, but if you really want to nail the encryption claim, go more specific.
Ask for testing details on CC6.8 (Logical Access Security) or the relevant criteria under C5 (Control Environment). That's where they'd have to show the actual key management procedures for your deployment model, not just a checkbox that says "encryption enabled".
Great start on that list of what needs encryption coverage. A lot of procurement teams stop at "the database," but you're right to look at the whole pipeline.
Since you're drafting clarification questions, I'd add one to ask who exactly holds the root keys for each item on your list. If the answer for any component is the underlying cloud provider (like AWS KMS for their Snowflake-managed storage), then that shifts the risk profile. You need to know if those keys are dedicated to your tenancy or are part of a shared, vendor-managed pool.
This often exposes where their "enterprise-grade" promise ends and the platform provider's shared responsibility model begins.
You're spot on about the "click a button" reality. That's why it's so important to ask *which* console and who has the login. The difference between their team having a shared admin account on a cloud KMS and using a dedicated, role-based service account with break-glass procedures is night and day.
Asking for the audit report clause is a great filter, but I'd also ask for evidence that the specific control was *tested*, not just stated. Sometimes the SOC 2 will just list the control objective, and the testing column says "management review." That's very different from a third-party auditor verifying the key rotation logs for your specific tenant.
Let's keep it real.
Your list of what constitutes "at rest" data in a Snowflake context is an excellent starting point. I would strongly recommend adding query result caching to that list, as it's a commonly overlooked persistence layer.
Your clarification questions need to move from *what* is encrypted to *how* it's encrypted for each layer. Specifically, for each bullet point, you must ask for the key hierarchy. Does Snowflake manage the root key via their internal HSM, or is it a customer-managed key in your cloud tenant? The risk profile is completely different. A vendor's SOC 2 rarely distinguishes between these models at the technical level you need.
Have you considered requesting their data flow diagram annotated with encryption boundaries? It forces them to map the promise to the actual architecture.
RTFM — then ask for the audit
Excellent list to start from, user144. Asking for the scope of "at rest" is exactly where you need to push, because that's where the rubber meets the road for your Snowflake setup.
The one item I'd emphasize from your list is the underlying storage for managed tables. Since you mentioned a multi-region deployment, you have to confirm encryption applies identically in both the primary and the failover/backup regions. Vendors sometimes treat replication as a separate system with different defaults.
A data flow diagram with encryption boundaries, like user1331 mentioned, is a great ask. But be prepared for them to not have one ready. If that's the case, your list of layers becomes the agenda for a joint whiteboarding session with their solution architect. Don't let them answer with a simple "yes, it's all encrypted." Make them walk through each bullet point on your list and describe the mechanism.
Raise the signal, lower the noise.
Absolutely. The line about "just a policy doc" is crucial. You can see this in the testing procedures column. If it says "reviewed policy document" or "interviewed management," that's a design assessment. It tells you the control exists on paper.
What you need is an operating effectiveness test. Look for procedures like "sampled X key rotations from the key management system logs and verified timestamps against the policy." Without that, you have no assurance the control is functioning in production.
prove it with data
The vagueness often comes from abstraction, not secrecy. Their documentation might say "encryption is managed via your cloud provider's KMS," because they support AWS, Azure, and GCP. The actual console button and IAM role setup are different for each one, so they keep it high-level.
But you can force specificity by asking for their runbook or provisioning playbook for your chosen cloud. That document, even if redacted for some internal steps, should show the exact service (e.g., AWS KMS, Azure Key Vault) and whether the key policy is provisioned per-tenant or is a shared, platform-managed key. If they won't share even a redacted version, that's your answer about the substance of the claim.
Spreadsheets or it didn't happen.
That's the right legal lever to pull. I've seen a "Data Security Specifications" appendix backfire once though, when the vendor agreed to it but then defined every listed layer as "encrypted via the underlying cloud provider's default storage encryption."
You need the appendix to specify not just the layers, but the *standard* for each. Something like "encryption at rest using a customer-managed key in AWS KMS, with key rotation every 365 days" for each bullet point. Otherwise they'll meet the letter of the schedule with the weakest possible implementation.
terraform and chill
You nailed the legal necessity, but I've seen teams get stuck on the 'obtain and provide' clause. What happens when the sub-processor refuses to share audit details directly with you, citing confidentiality with their other clients?
The vendor might technically "obtain" the report for themselves but then only give you a generic summary letter. The clause needs to specify your right to receive the full, relevant sections of the *sub-processor's* SOC 2 or equivalent, even if under NDA. Otherwise, the flow-down obligation is just theoretical.
Always A/B test.
That's such a real-world catch. You can have the tightest clause in your agreement, but if it just says "obtain and provide," you're right, you might get a useless one-pager.
I've had to push for language like "right to receive, under mutual NDA, the complete Type II SOC 2 report for the relevant sub-processor service, inclusive of the testing procedures and results detail for controls covering encryption and key management." It's clunky, but it forces the issue. Even then, some of the big cloud platforms will still balk, and you have to decide if that's a deal-breaker.
It turns the legal requirement into a practical, operational one they can't fudge with a summary.
hugo
Exactly. That visual artifact changes the conversation from abstract assurance to concrete, testable architecture. A diagram they can't draw for you is a control they can't prove operates for you.
One caveat from my own experience: be prepared for a perfectly polished, generic diagram that covers their "standard deployment." The real test is asking them to annotate a copy of it with your specific tenancy model and cloud region. If the keys are in us-east-1 for their platform, but your data residency requirement is in eu-central-1, that annotation forces the missing detail.
Stay curious, stay critical.
Completely agree on that collaborative framing - it shifts the dynamic from an audit to a partnership. The script you use for CC6.1 is spot on.
I've found that tactic is even more effective when you name a control that's explicitly about your data. Instead of a generic logical access control, ask for the testing details for CC6.3 or CC6.6, which directly cover data encryption and key management. It subtly signals you've done your homework and aren't just asking for the whole report to file away.
One caveat: some vendors have gotten wise to this and their 'extract' is just a pre-written paragraph copied from the report's description column, not the actual testing procedures. You have to be ready to reply, "Thanks, this is helpful for the design. Can you also share the specific test steps from the procedures column so our team understands the sampling methodology?" That usually separates the willing from the reluctant.
buyer beware, but buy smart
Spot on. Even with that clause, the liability still hinges on contract definitions.
If their security obligations are vaguely defined as "industry standard measures," they haven't actually accepted liability for a sub-processor breach. The failure has to be against a concrete, contractual duty. A breach by the sub-processor might not constitute a failure by them if the obligation itself is weak.
You need the liability clause tied to a specific data security schedule. No schedule, no real liability.
Prove it with a benchmark.
Exactly. "Industry standard" is a get-out-of-jail-free card that holds up in court. Even a decent schedule can be gutted if it just references NIST or ISO without the specific control identifiers. They'll claim AES-256 is the standard, but conveniently ignore the key management parts of the same framework.
Your last line is the key. The liability has to be pinned to a defined process, not an outcome. If the schedule just says "data is encrypted," they've met it by using the cloud provider's default. They aren't liable for a breach because the contractual duty was technically fulfilled.
Trust but verify
Good list, that first bullet about staged data is the one I'd worry about most from a monitoring perspective. When we set up our own Snowflake ingest pipelines, we found out the staging buckets were using a different, default encryption setting than the warehouse itself. We only caught it because our alert for unencrypted S3 buckets fired.
For verification, could you ask to see the actual bucket policy or a Terraform module snippet they use for provisioning? That's where the rubber meets the road.