Encryption at Rest vs in Transit
Encryption at rest protects stored data — databases, object storage, disks, backups — so stolen media or leaked snapshots yield ciphertext. Encryption in transit protects moving data — TLS on every connection — so interception yields nothing. Every framework expects both; the questionnaire phrasing is so standard it’s practically a greeting.
What the evidence actually is
Configuration, not policy prose: storage-level encryption settings from your cloud provider (default-on for most managed services — the shared responsibility model means verifying it is still yours), TLS versions and certificate posture on public endpoints, and internal service-to-service transport. Connected integrations export these continuously; auditors sample exactly those exports.
Where the gaps actually hide
Rarely the main database — almost always the periphery: backups and snapshots in unencrypted buckets, data exports on laptops (hence MDM’s disk-encryption evidence), legacy internal services speaking plain HTTP, and third parties who receive your data onward (their posture is your vendor-review question).
Key management, the follow-up question
Sophisticated reviewers ask who holds the keys: provider-managed (default, fine for most), customer-managed KMS (better answer for regulated buyers), or bring-your-own-key (the enterprise checkbox). Know which you use and why — “whatever AWS does” is a real answer, but saying it that way costs points.
Audit Trail — An audit trail is the tamper-evident record of who did what, when, in your systems — the evidence layer every framework samples and every incident needs.
Data Classification — Data classification assigns sensitivity levels to data so controls can scale with risk — three or four tiers, applied where data lives, not in a binder.
Shared Responsibility Model — The shared responsibility model splits security duties between cloud provider and customer — and misreading the split is a classic audit and breach root cause.