Design an Encryption-at-Rest Strategy for a Regulated SaaS

An encryption-at-rest strategy is not "turn on encryption everywhere" — that part is easy and mostly automatic. The real work is judgment: deciding, data store by data store, which key tier the data warrants, who should be able to decrypt it, how the key rotates, and what evidence proves all of that to an auditor. The same intent — "protect the data" — produces different key decisions depending on data sensitivity, regulatory scope, and operational reality.

In this exercise you design the encryption-at-rest approach for Northwind Health, a ~250-person regulated SaaS that stores customer PII and protected health information (PHI) in AWS, with some workloads in GCP. Each scenario has one best answer; the explanation walks through the tradeoffs you will reuse when writing real key strategies. Work each the way you worked the MDM policy exercise in Phase 3: decide the control, then justify it with the evidence it produces.

The 'we use one KMS key for everything' architecture

The environment

Northwind has five data stores in scope:

A. Production PHI database — managed PostgreSQL holding patient records. Highest sensitivity; HIPAA in scope.
B. Application object storage — an S3 bucket of user-uploaded documents (some contain PII).
C. Database backups & snapshots — automated nightly snapshots of A, retained 35 days.
D. Analytics warehouse — a copy of de-identified data used by the data team; no direct identifiers.
E. Application logs — operational logs that occasionally capture PII in error payloads.

Scenario 1: Provider-managed vs customer-managed keys

Quick check

For the production PHI database (A), which key approach is most defensible, and why?

Provider-managed default encryption — the data is encrypted at rest, which satisfies the requirement

A dedicated customer-managed key (CMK) with a scoped key policy, automatic rotation, and key-use logging — so decrypt access is an explicit, reviewable permission and you can produce who-decrypted-what evidence

Hash the records so they cannot be decrypted by anyone

Encrypt it client-side with a key stored in the application config file

Scenario 2: Don't forget the backups

Quick check

The team encrypts database A with a CMK but the nightly snapshots (C) are still using default provider-managed encryption — or worse, an older snapshot set is unencrypted. Why does this matter, and what is the fix?

It does not matter — backups are internal and short-lived

Backups and snapshots are full copies of the same sensitive data and are a classic exfiltration path; they must be encrypted to the same standard (ideally the same CMK or an equivalent customer-managed key) and that coverage must be verified, because a snapshot is an unguarded side door to the PHI

Just delete all backups so there is nothing to encrypt

Encrypt the backups with a weaker key since they are only restored occasionally

Scenario 3: One key for everything vs key separation

Quick check

An engineer proposes a single CMK used to encrypt all five data stores 'to keep things simple.' What is the better design, and why?

One key for everything is ideal — fewer keys means less to manage

Use separate keys aligned to data sensitivity and access boundaries (e.g., a dedicated key for PHI in A/C, a separate key for PII object storage B, and a different key for analytics D), so decrypt access can be scoped per data set and the blast radius of a key compromise or over-broad grant is contained

Use a separate key for every individual object and row

Skip keys for the analytics warehouse since it is de-identified

Scenario 4: Rotation cadence and separation of duties

Quick check

What rotation and key-administration approach is both effective and auditable for the PHI key?

Never rotate — rotation risks breaking decryption of old data

Enable automatic key rotation on a defined cadence (envelope encryption means old data keys stay valid, so rotation does not break historical data), and separate the people who administer the key policy from those who can use the key to decrypt, with both logged

Rotate the key manually every few years when someone remembers

Give every engineer admin rights on the key so rotation is never blocked

Scenario 5: The evidence you will be asked for

Quick check

The auditor says: 'Show me that customer PHI is encrypted at rest and that access to decrypt it is controlled.' What package of evidence actually demonstrates this?

A screenshot of the database settings page showing an "Encryption: Enabled" toggle

The key inventory mapping each data store to its key, the CMK key policy showing who can administer vs decrypt, the rotation configuration, the cloud-config report showing encryption coverage across the database and its snapshots, and a sample of the key-access log showing decrypt events with timestamps and principals

A signed statement from the CTO that everything is encrypted

The AES-256 specification document proving the algorithm is strong

Putting it together: the key strategy matrix

A finished encryption-at-rest strategy is best expressed as a matrix — data stores down one axis, key decisions across the other. For Northwind it would look roughly like:

Data store	Key tier	Key separation	Rotation	Key evidence
A. PHI database	CMK (dedicated PHI key)	Admins ≠ decrypt users	Auto, defined cadence	Key policy + access log
B. PII object storage	CMK (separate key)	Scoped to app role	Auto	Coverage report + access log
C. DB backups/snapshots	Same CMK as A	Inherits A's policy	Inherits A	Coverage incl. historical snapshots
D. Analytics warehouse	CMK (separate, lower-sensitivity key)	Scoped to data team	Auto	Coverage report
E. Application logs	CMK + reduce PII at source	Scoped to logging pipeline	Auto	Coverage + log-scrubbing control

Two patterns to notice. First, the intent is identical across stores (encrypt, control decrypt access, rotate, prove it), but the key boundary changes with sensitivity and who needs access — a single key for everything would collapse those boundaries. Second, every decision is chosen for the evidence it produces: a CMK exists not just to encrypt but to make "who can decrypt this, and when" an answerable, logged question.

How to use this in practice

When you design or review an encryption-at-rest strategy as a GRC Engineer, work the same five questions for every data store: key tier (provider-managed vs CMK vs BYOK/HYOK), key separation/boundary, rotation, separation of duties on key administration, and the evidence each choice yields. Then write down the rationale for each difference — why PHI gets a dedicated CMK, why analytics gets a separate lower-sensitivity key, why backups inherit the primary's key. That documented rationale is what turns a pile of KMS keys into a defensible, auditable strategy, and it is exactly what an auditor asks for when they see two data stores keyed differently.