Skip to main content
INS // Insights

AWS KMS Encryption Evidence for SOC 2

Updated August 2026 · 6 min read

AWS KMS encryption evidence for SOC 2 is not a screenshot of "encryption at rest enabled" on one RDS console. Auditors sampling data protection want key ownership, who can kms:Decrypt, whether rotation is on for customer-managed keys, and whether grants proliferated.

This is AWS infrastructure with a compliance narrative — sibling to Config conformance packs and organization CloudTrail. Rutagon does not hold a SOC 2 report to lend you. We build the key design and the evidence queries.

What "Encrypted" Must Mean in the System Description

For each in-scope datastore:

  • CMK vs AWS-owned key (AWS-owned is weaker evidence of your control)
  • Key policy principals (roles, not *)
  • Encryption in transit separately (TLS) — KMS does not prove TLS
  • Backup copies use the same or a documented key

KMS key policies are the authorization plane. A wide key policy is standing data access. We treat key policy reviews like privileged access reviews.

{
  "Sid": "AllowAppRoleDecrypt",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111111111111:role/prod-api" },
  "Action": ["kms:Decrypt", "kms:DescribeKey"],
  "Resource": "*",
  "Condition": {
    "StringEquals": { "kms:EncryptionContext:service": "prod-api" }
  }
}

Encryption context conditions are how you stop a stolen role from decrypting every database snapshot in the account.

Rotation and Grants

  • Automatic rotation on CMKs used for in-scope data (AWS documents yearly rotation for CMKs). Evidence: GetKeyRotationStatus export over the window.
  • Grants (CreateGrant) are easy to forget. A grant can outlive the engineer who created it. Inventory grants; alarm on CreateGrant from non-pipeline roles.

CloudTrail Decrypt volume is not automatically a finding. Decrypt from a new role in a new region is.

Evidence Pack

/kms/{observation}/
  key-inventory.csv
  rotation-status.json
  key-policy-snapshots/
  grants.csv
  cloudtrail-creategrant.csv

Config rules (kms-cmk-not-scheduled-for-deletion, rotation) are detective. Snapshots of policies are the Type II story.

Discuss encryption architecture that survives sampling → rutagon.com/contact · 907-841-8407 · contact@rutagon.com.

How We Inventory Keys Without a Console Safari

The first deliverable in a KMS evidence engagement is not a slide. It is a table: key ARN, manager vs customer-owned, region, rotation flag, aliases, and the list of services that actually call Decrypt (from CloudTrail, not from tribal knowledge). AWS-owned keys that encrypt RDS are still encrypted; they just give you less policy surface to show a customer-controlled CMK. We document that choice in the system description instead of quietly mixing key classes.

We also snapshot key policies into git at the start of the observation window. Mid-window policy edits without a change ticket are how Type II samples get ugly. If a team needs a new principal, it goes through the same pipeline as any other IAM change: PR, review, apply, then a new policy snapshot. That is boring on purpose.

Multi-account orgs add a second failure: a CMK in account A used by a role in account B via a grant that nobody listed. Grants are first-class inventory. Orphan grants from a decommissioned ECS task role are standing decrypt rights. We alarm on CreateGrant from principals that are not the deploy role.

Encryption Context as an Access Control

Envelope encryption without encryption context is a blunt Decrypt. Context conditions (service=prod-api, env=prod) let you prove the same role cannot decrypt a snapshot tagged for a different app. We treat missing context on in-scope data keys as a finding in the diagnostic, not as a nice-to-have.

S3 Bucket Keys and RDS encryption settings are cost and operations choices. They do not replace a readable key policy. We enable Bucket Keys after the policy is tight so the first change in the window is not a dual-change of policy plus bucket-key.

NIST SP 800-57 is public guidance on key management life cycle; we use it as a vocabulary for rotation and destruction, not as a claim that we run a federal key-management program. The commercial SOC 2 story is: you can show who can decrypt in-scope data, that rotation is on where you said it is, and that deletion of keys is a controlled event.

AWS KMS encryption evidence we keep after the observation window

SOC 2 Type II is a period, not a screenshot. AWS KMS encryption evidence has to show the same story on day 1 and day 90: which customer-managed keys protect in-scope data stores, who can call Decrypt and CreateGrant, and whether rotation was on for the keys you claimed were rotating. We export ListKeys / ListAliases / GetKeyRotationStatus into the log-archive account and hash the JSON. If a principal is added mid-window, the next snapshot diffs. That diff is the change ticket, not a hallway conversation.

A recurring production miss is encrypting RDS with an AWS-owned key and then telling the auditor you “use KMS.” Technically true, evidence-weak. If the system description says customer-controlled CMKs, the snapshot must show KeyManager=CUSTOMER on those ARNs. If you intentionally use AWS-owned keys for a class of data, write that down. Mixing classes without a sentence is how sampling becomes an argument.

NIST’s SP 800-57 vocabulary (generation, distribution, rotation, destruction) is useful for the narrative. We do not claim a federal key-management program. We claim you can show decrypt rights, rotation flags, and deletion as controlled events. CloudTrail RetireGrant and ScheduleKeyDeletion belong in the same Athena saved query as Decrypt.

Multi-Region keys and replica keys add a second inventory. A replica in us-west-2 with a looser key policy than us-east-1 is a standing decrypt path. We include replica ARNs in the table even when the app never fails over. Grants created by AWS services (EBS, RDS) are expected; grants created by a human IAM user are a finding until federated.

Remote delivery does not change the control. It does mean the evidence bucket and the Athena workgroup have to be operable without a console cowboy in a single region. Break-glass decrypt is a named role, hardware MFA, ticket, and a 24-hour grant TTL — not kms:* on the admin permission set.

Frequently Asked Questions

Is SSE-S3 enough for SOC 2?

Sometimes, for low-sensitivity buckets, if the system description matches. Customer-managed keys give you policy and rotation evidence. Do not switch keys in the observation window without a change ticket.

Do we need a dedicated KMS key per microservice?

Per trust boundary, not necessarily per service. Too many keys become unreviewable. Too few keys become a blast radius. We design around account + data class.

What about S3 Bucket Keys?

They reduce KMS cost. They do not replace key policy design. Enable them after the policy is tight, not instead of tightening.

Can we use AWS managed keys for RDS and still pass?

Often yes if the rest of access control holds. CMKs are stronger evidence of customer control. Choose explicitly in the system description; do not mix silently.

Will you attest encryption for our auditor?

We produce architecture and evidence pipelines. Attestation is the CPA firm's job. We do not issue SOC 2 reports.