CIS AWS Foundations v1.2 2.7: CloudTrail should have encryption at-rest enabled

The cis aws foundations v1.2 2.7: cloudtrail should have encryption at-rest enabled requirement exists for a simple reason: CloudTrail logs are high-value security records. If an attacker or careless admin can read, copy, or tamper with them, your detection and investigation capability degrades fast. CIS maps this expectation to AWS Security Hub (control CloudTrail.2), which is the easiest operational hook to measure and report on the requirement across accounts. ¹

Operationally, this requirement is about making sure the S3 bucket that receives CloudTrail logs enforces encryption, and that the encryption method is configured correctly for your organization’s risk profile. Many teams “turn on CloudTrail” and assume logs are protected, but CloudTrail’s durability does not equal confidentiality. Your job as a CCO/GRC lead is to (1) mandate encryption at rest for all CloudTrail destinations, (2) standardize how KMS keys are managed and who can decrypt, and (3) keep durable evidence that the control is continuously operating.

This page gives step-by-step implementation guidance, the artifacts to retain, and the audit questions you should expect.

Regulatory text

Requirement (excerpt): “Implement CIS AWS Foundations Benchmark v1.2 requirement 2.7 as mapped in AWS Security Hub.” ^{2 1}

What this means for the operator

• You must configure CloudTrail log storage so that CloudTrail logs are encrypted at rest.
• In practice, this means the CloudTrail S3 bucket must have default encryption enabled, and you should be able to show that objects delivered by CloudTrail are encrypted.
• You should operationalize this through AWS Security Hub’s CIS mapping (CloudTrail.2) so you can continuously detect noncompliant trails/buckets rather than relying on point-in-time screenshots. ¹

Plain-English interpretation

CloudTrail writes logs to S3 (and optionally CloudWatch Logs). This requirement expects that if someone gains access to the raw storage layer, they still cannot read CloudTrail log content without the appropriate decryption permissions. Your control objective is: CloudTrail log files land in S3 encrypted, and decryption is controlled and auditable.

Who it applies to

Entity scope

• Any organization operating workloads in AWS and using CloudTrail for security logging, compliance evidence, incident response, or audit support. ²

Operational scope (where it bites in real life)

• Multi-account AWS Organizations with a centralized logging account.
• Any account with one or more trails, including developer “temporary” trails that quietly write unencrypted logs to an unmanaged bucket.
• Environments where security tooling, a third party SOC, or an external incident response firm needs access to logs. Encryption changes how you grant access.

What you actually need to do (step-by-step)

Below is an operator-grade sequence that works for single-account and multi-account models.

Step 1 — Inventory all trails and destinations

1. List all CloudTrails in each account/region (include organization trails if you use them).
2. For each trail, record:
   • S3 bucket name and prefix (if used)
   • Whether CloudWatch Logs integration is enabled
   • The account that owns the bucket (central logging account vs local)

Outcome: you know every S3 location receiving CloudTrail logs.

Step 2 — Decide your encryption standard (SSE-S3 vs SSE-KMS)

• Preferred default for regulated environments: SSE-KMS with a customer managed KMS key (CMK). This gives you key policy control, separation of duties, and KMS audit logs.
• Acceptable baseline in many environments: SSE-S3 (AWS-managed keys) if your policy allows it and your auditors do not require customer managed keys.

Write the standard in a short control statement (one paragraph) so engineering can implement consistently.

Step 3 — Configure S3 default encryption on the CloudTrail bucket

For each S3 bucket that receives CloudTrail logs:

1. Enable default encryption.
2. Select:
   • aws:kms and specify your CMK (preferred), or
   • AES-256 (SSE-S3) if you approved that standard.
3. If you use SSE-KMS:
   • Confirm the key is in the correct region for the bucket.
   • Confirm key rotation posture aligns to your internal crypto standard.

Practical note: Default bucket encryption is the control point auditors recognize most consistently because it applies to future objects without relying on every writer to set encryption headers.

Step 4 — Make sure CloudTrail can write with KMS (SSE-KMS only)

SSE-KMS commonly fails due to missing permissions. Validate:

1. The KMS key policy allows the CloudTrail service (and/or the relevant AWS principals in your logging pipeline) to use kms:Encrypt / kms:GenerateDataKey as required for S3 object encryption.
2. The S3 bucket policy allows CloudTrail to s3:PutObject to the expected prefix.
3. If you use a centralized logging account, validate cross-account writes and encryption still succeed.

Acceptance test: force CloudTrail to deliver logs (or wait for normal delivery), then check a newly delivered object’s encryption properties in S3.

Step 5 — Verify that delivered log objects are encrypted (not just “settings say so”)

Auditors often push for objective evidence that:

• A current CloudTrail log object has ServerSideEncryption set, and
• If SSE-KMS is required, the object shows the correct KMS key ID.

How to do this operationally:

• Pull object metadata for a recent CloudTrail log file and record the encryption fields.
• Keep one or more samples per environment (prod/non-prod) as evidence.

Step 6 — Monitor continuously with Security Hub (CloudTrail.2) and handle drift

1. Enable AWS Security Hub and the CIS AWS Foundations benchmark mapping in the accounts you govern. ¹
2. Track findings for CloudTrail.2.
3. Define a simple remediation workflow:
   • Triage: confirm which trail/bucket is failing.
   • Fix: enable default encryption or correct KMS policy.
   • Prevent recurrence: push configuration through IaC and add guardrails (see next step).

Step 7 — Add preventive guardrails (so you don’t re-fail next quarter)

To keep this from becoming whack-a-mole:

• Infrastructure as Code: manage CloudTrail and the logging bucket via Terraform/CloudFormation so encryption is not optional.
• Policy guardrails: consider organization-wide controls to prevent creation of unencrypted S3 buckets for log storage, or to require specific encryption on buckets with cloudtrail prefixes (implementation method depends on your AWS governance model).
• Change management: require security review for any new trail or bucket that stores security logs.

Required evidence and artifacts to retain

Store evidence in your GRC system with clear timestamps and account identifiers.

Minimum evidence set (recommended):

• Screenshot or exported config showing S3 default encryption enabled on each CloudTrail destination bucket.
• KMS key details (if SSE-KMS): key ID/alias, rotation setting (if you enforce it), and the key policy excerpt granting required permissions.
• Bucket policy excerpt allowing CloudTrail writes to the bucket/prefix.
• Example of a recent CloudTrail log object’s metadata showing encryption at rest (SSE-S3 or SSE-KMS).
• Security Hub screenshot/export showing CloudTrail.2 passing (or findings with remediation tickets). ¹
• Change records: ticket or PR showing when encryption was enabled/updated.

Retention tip: keep evidence per account and per logging bucket. Central logging reduces evidence sprawl.

Common exam/audit questions and hangups

Questions you should expect:

• “Show me that CloudTrail logs are encrypted at rest. Where is that configured?”
• “Is encryption enforced by default on the bucket, or dependent on the writer?”
• “If you use SSE-KMS, who can decrypt? Show the KMS key policy and access review.”
• “How do you know encryption didn’t get turned off last month?”
• “Does this apply to all accounts and regions, including new accounts?”

Hangups that slow audits:

• Confusing CloudTrail “log file integrity validation” with encryption. They are different controls.
• Providing screenshots of CloudTrail settings without proving the S3 bucket encryption state and object-level encryption.
• KMS policies that are too broad (decrypt granted to many roles) or too narrow (CloudTrail cannot write).

Frequent implementation mistakes and how to avoid them

1. Turning on bucket default encryption but forgetting existing objects

   • Fix: Decide whether you need to remediate historical unencrypted log objects and document the decision. If required, re-encrypt or migrate older objects.

2. SSE-KMS enabled, but CloudTrail delivery fails silently

   • Fix: Set up operational alerting on CloudTrail delivery errors and periodically verify new objects arrive encrypted.

3. Using SSE-S3 where your internal policy requires customer managed keys

   • Fix: Put the encryption method choice into a written standard and enforce it via templates/IaC.

4. Central logging account with cross-account trails, but KMS key policy doesn’t allow cross-account usage

   • Fix: Design the key policy for the org model, then test delivery from a member account.

5. Evidence is scattered

   • Fix: Maintain a single evidence pack per environment: config exports, key policy, and a sample object’s metadata.

Enforcement context and risk implications

CIS AWS Foundations is a benchmark, not a law, but teams commonly adopt it to demonstrate a defensible security baseline and to satisfy customer audits. The concrete risk is straightforward: unencrypted CloudTrail logs can expose security events, identities, resource names, and API activity to anyone who gains read access to the bucket or the underlying storage path. Encryption at rest narrows the blast radius and strengthens your story during incident response and customer assurance.

Practical 30/60/90-day execution plan

First 30 days (stabilize and stop new gaps)

• Inventory all trails and identify every destination bucket.
• Pick and document the encryption standard (SSE-KMS preferred; SSE-S3 acceptable only if approved).
• Enable S3 default encryption on all known CloudTrail buckets.
• Validate that new CloudTrail objects are arriving and show encryption in object metadata.
• Turn on Security Hub CIS mapping and start tracking CloudTrail.2 findings. ¹

Days 31–60 (standardize and make it repeatable)

• Move CloudTrail + logging bucket configuration into IaC.
• Standardize KMS key management for logging (ownership, access review, break-glass).
• Centralize evidence collection: automated exports of Security Hub findings plus periodic spot checks of object metadata.
• Implement a lightweight exception process for edge cases (legacy accounts, M&A accounts).

Days 61–90 (prevent drift and audit-ready packaging)

• Add preventive controls in your AWS governance model to reduce creation of noncompliant logging buckets.
• Run an internal “mini-audit”: pick accounts at random and reproduce evidence within a single working session.
• Finalize the control narrative: scope, encryption standard, monitoring method (Security Hub CloudTrail.2), and evidence locations. ¹
• If you use Daydream for control management, link Security Hub CloudTrail.2 evidence to the requirement record and schedule recurring evidence pulls so quarterly audits become a review, not a scramble.

Frequently Asked Questions

Does this requirement mean CloudTrail itself must be configured to encrypt logs?

Practically, it means the storage destination must enforce encryption at rest. For most deployments that is the S3 bucket that receives CloudTrail logs, with default encryption enabled.

Is SSE-S3 enough, or do we need SSE-KMS?

CIS 2.7 is about encryption at rest being enabled, not necessarily customer managed keys. Many regulated programs still prefer SSE-KMS for stronger access control and auditability, so set a clear internal standard and be consistent.

How do I prove logs are encrypted for an audit?

Provide the S3 bucket default encryption configuration plus metadata from a recently delivered CloudTrail object showing server-side encryption. If you use SSE-KMS, include the KMS key ID and relevant key policy excerpts.

We have an organization trail writing to a central logging account. What’s the most common failure?

KMS permissions and bucket policy alignment. Cross-account delivery works only if the bucket policy allows the write path and the KMS key policy allows the needed encrypt/data key actions for the CloudTrail delivery flow.

Does CloudWatch Logs encryption matter for CIS 2.7?

CIS 2.7, as commonly operationalized via Security Hub CloudTrail.2, focuses on CloudTrail log files stored at rest, typically in S3. If you also send events to CloudWatch Logs, treat that as an additional logging control and apply your org’s encryption standards there too.

What if we have historical CloudTrail logs that were stored unencrypted?

Decide whether your risk posture requires retroactive remediation, then document it. At minimum, enforce default encryption going forward and retain evidence showing the change date and current encrypted state.

Related compliance topics

• 03.01.18: Access Control for Mobile Devices
• 03.01.19: Withdrawn
• 03.01.20: Use of External Systems
• 03.01.21: Withdrawn
• 03.01.22: Publicly Accessible Content

Footnotes

1. AWS Security Hub CIS AWS Foundations mapping table

2. CIS AWS Foundations Benchmark