FillTrust

How to answer

Is customer data encrypted at rest?

One of the most common questions on any questionnaire, and one of the most commonly over-answered: most teams encrypt the database and forget the backups.

A model answerConfirmed in your documents

Yes. All customer data is encrypted at rest using AES-256. Encryption is applied at the storage layer across our production databases, object storage and backups, and keys are managed by our cloud provider's key management service.

FillTrust grades an answer like this confirmed in your documents when your documents support it.

Answered from
Your information security policy, and the encryption section of your SOC 2 report if you have one.
Evidence to attach
Usually nothing. If you have no SOC 2 report, a reviewer will sometimes accept a screenshot of the storage encryption setting in your cloud console.
Where it is asked
CAIQ v4.0 · CEK-03SIG LiteISO 27001 Annex A · A.8.24

Almost every questionnaire asks this, and almost every team can answer yes. What the reviewer is actually testing is not whether you have encryption, which they assume you do, but whether you know the boundary of it.

"At rest" means every place the data comes to a stop. That is more places than most teams list on the first pass: the production database, its read replicas, automated backups and snapshots, object storage holding uploads, the log pipeline if request bodies are logged, and any analytics warehouse the data is copied into. Managed cloud services encrypt most of this by default, which is why the honest answer is usually yes. But "by default" is a fact about your provider, not a fact about your configuration, and the two diverge exactly where somebody turned something off.

The second thing being tested is who holds the keys. Provider-managed keys are entirely normal and no reviewer will object; what they will object to is a claim of customer-managed keys where the console shows the default. If you have not configured a customer-managed key, say provider-managed. It is a better answer than an unsupportable one.

If your documentation covers encryption in general terms but does not enumerate the stores, that is a gap worth closing in the policy rather than papering over in the answer. The next questionnaire will ask again, and the one after that will ask for evidence.

How this one goes wrong

Specific to this question, not general advice.

  • Answering yes when only the database is encrypted. Backups, object storage, log aggregation and analytics warehouses hold the same customer data, and a reviewer who finds one of them unencrypted after you answered yes has found a misrepresentation, not a gap.
  • Naming a key length without naming what it protects. "AES-256" on its own does not say whether it covers the whole estate.
  • Claiming customer-managed keys because the provider supports them. Answer for what you have configured, not for what is available.

There are another two hundred of these in the file.

FillTrust drafts every one from your own documents and shows the passage behind each answer, including the ones it refuses to answer.

Or write this answer down once and publish it on a Trust Center of your own, which costs nothing.