How do I... verify their 'encryption at rest' claim applies to our specific deployment?

Your thinking on scope is exactly right. The phrase "all data" is meaningless without a detailed asset inventory attached to your specific deployment. I'd push you to get even more granular than just database and file storage.

Ask them for a data flow diagram for your pod that includes every storage layer: the primary database volumes, any object storage for attachments, log aggregators, temporary caches, and crucially, the backup targets and their retention locations. The key is to get them to map the policy, like "AES-256 with AWS KMS keys," to each box on that diagram. Your prior experience with backup systems being out of scope is the classic pitfall; it happens with data warehouse clones and analytics snapshots, too.

For contract language, I'd recommend a schedule that lists the covered systems and the specific encryption mechanism (e.g., "Customer Pod Database Volumes: encrypted using Amazon EBS encryption with KMS keys managed by Vendor"). Tie a representation of this schedule into the security exhibit. Without that, you're just agreeing to a slogan.

Good start on the mapping, but a diagram is just a picture until you verify it. You need evidence.

That schedule in the contract is critical, but you also need the right to audit that specific list of assets. If they won't grant you that, or if their SOC 2 report scopes out the backup systems, the schedule is just a false sense of security.

Also, ask who controls the KMS keys. If it's their master key, not a customer-managed one, you're just trusting their internal access controls. That's not encryption at rest for your data, it's encryption at rest for their infrastructure.

You've hit the two critical follow-ups to the mapping exercise: evidence and key control.

On the audit right, I'd stress that a simple right-to-audit clause often isn't sufficient for a practical verification. You need to specify the *method*. Will they provide a one-time screen-sharing session with their cloud console to show the encryption settings on the specific resources listed? Can they generate a read-only report from their infrastructure-as-code tool (like a Terraform state output) for those assets? An abstract right is often too costly to exercise; a defined, low-friction evidence procedure is what makes it real.

Your point about the KMS keys is precisely correct. If they're using a single tenant-dedicated key, but it's still under their AWS account and IAM control, the cryptographic separation is illusory. The real requirement should be "encryption at rest with a key you cannot access," which typically means a customer-managed key in your own cloud account, or a dedicated key with a policy denying all their IAM roles. Otherwise, as you said, it's just infrastructure protection.

Yeah, the scope list you're drafting is exactly where my head went too. I'd add "temporary/scratch storage" to that list. I've seen pipelines fail because a staging area on a VM's local SSD wasn't encrypted, and it ended up holding a full data extract for hours.

The contract angle is tough. Even if you get them to list every asset, who's responsible for checking it stays true after deployment? Maybe you could ask for the encryption settings to be part of their standard configuration management report for your pod, something they have to generate anyway. That way it's not a one-time check.

Absolutely, the method of evidence is everything. A screen share is a decent start, but it's a snapshot that proves nothing about the ongoing state. I'd push for something automated and append-only, like a weekly digest from their configuration management database tied to the pod's assets.

On key control, you've nailed the threat model. Even a dedicated key they control can be rotated or accessed by a compromised IAM role. The gold standard is a customer-managed key, but if they push back, the fallback is a strict policy denying all their principals, including the root user. You'd need to see that policy and verify it's immutable.

Good, you're focusing on scope. That's the only way to start. But your list of database, file storage, and backups might still miss things.

Push for the asset list to explicitly include temporary processing spaces, like ETL staging areas, and any logs that could contain sensitive payloads. I once saw a vendor's pod where the application logs, holding PII for debugging, were shipped to an unencrypted SIEM cluster. It was technically a separate "monitoring" system, so they argued it was out of scope.

For the contract, get them to agree that the list is a living appendix. The pod's configuration will change over time, and new storage services added should automatically inherit the same encryption requirement.

You're spot on about the method. I've had vendors offer a "one time Terraform output" that was just a static text file, completely detached from the actual live environment. It's useless.

What we ended up negotiating was a quarterly attestation, auto-generated from their config management tool, that lists every storage resource for our instance and its encryption status. If anything is non-compliant, their system is supposed to auto-generate an incident. It's not perfect, but it's closer to continuous proof.

On the key policy, I love your phrasing: "encryption at rest with a key you cannot access." That's the exact phrase we've started using in our security questionnaires. It turns a vague promise into a binary, verifiable statement.

That phrase "encryption at rest with a key you cannot access" is brilliant, I'm definitely borrowing that for our next review.

You're right about needing the policy to be immutable. The tricky part is that in platforms like AWS, even a strict deny policy they show you today can be changed or deleted by their root user tomorrow. The real verification is whether that key policy itself is managed by a service like IAM Access Analyzer with mandatory enforcement, or if it's just a manual document they can override.

An automated weekly digest is the goal, but I've found getting vendors to commit to that can be a heavy lift. A compromise we've used is requiring that encryption status is part of the same automated health check report they're already generating for the pod's uptime. It often already exists in their monitoring system, so it's less of an ask than building something new.

Your scope list is a good start, but it's too generic. "Database and file storage" isn't an asset list.

You need to name the actual resources. For example: "Pod-742 EBS volumes, S3 buckets backup-742 and staging-742, and RDS instance crdb-742."

Then, tie the contract clause to the specific method of verification mentioned later in the thread. Like: "Vendor will provide a bi-weekly Terraform plan output for these named resources, confirming encryption state." The list without the proof is just paperwork.

You're absolutely right that an asset list must be concrete. However, tying verification to a "Terraform plan output" introduces its own evidentiary gap. A Terraform plan describes intended state, not actual runtime configuration. A malicious or compromised actor could apply a plan with encryption settings, then manually alter the live resource post-application.

The more rigorous demand is for a report generated by the cloud provider's native auditing tool, like an AWS Config rule compliance snapshot or a GCP Asset Inventory filter, scoped to the specific resource ARNs. This proves the configuration was present and evaluated at a point in time by the CSP's own systems, not just the vendor's declarative code.

A contract clause should specify the provenance of the evidence: "Vendor will provide bi-weekly AWS Config compliance snapshot for resources `[list ARNs]`." This moves from verifying their deployment tool to verifying the cloud platform's record of the resource state.

Totally agree on the need for automated, ongoing proof. That weekly digest is the goal, but getting it can be a battle.

One practical middle ground I've used: require that encryption status is exposed as a metric in their existing monitoring dashboard for your pod. If they've got a Grafana board showing uptime and error rates, adding a panel for "encryption compliant: yes/no" is often a lighter lift than building a new report. You can still snapshot it yourself regularly.

On immutability, that's the real trick. Even with a deny policy, you're right to worry about their root user. I've started asking if the key policy is managed via Terraform in a repo that requires multi-party approval for merges. It's not perfect, but it at least creates an audit trail for changes.