Security teams should inventory S3 buckets, then check whether each bucket that receives CloudTrail logs has server-side encryption enabled. Unencrypted log storage creates avoidable exposure because CloudTrail data can reveal account activity, access patterns, and investigation evidence. The practical goal is to identify logging destinations, verify encryption settings, and remediate any bucket that stores audit logs in clear text.
How to spot unencrypted CloudTrail log buckets
The first task is to identify every S3 bucket that is actually receiving CloudTrail delivery, not just every bucket in the account. In practice, that means checking trail configuration, S3 bucket policies, and the destination path for each trail, then confirming whether the bucket uses server-side encryption by default or on write. A bucket can look “logging-related” while still storing audit data in clear text.
For teams operating in AWS at scale, this is a configuration and inventory problem before it is a log-analysis problem. You want a repeatable way to map each CloudTrail trail to its storage target and then verify encryption settings at the bucket level, because CloudTrail can be delivered to multiple buckets or prefixes across accounts and environments.
One useful anchor point is AWS exposure seen in the Capital One breach 2019 case study, which shows how cloud control failures can cascade when storage, identity, and access controls are not tightly bounded.
What actually makes a CloudTrail bucket risky
CloudTrail logs are not just routine telemetry. They can contain account activity, API usage, role assumptions, access patterns, and evidence that supports investigation and incident response. If those logs sit unencrypted in S3, anyone who gains read access to the bucket, a replication target, or an exposed backup can inspect sensitive operational history without first breaking encryption.
The security concern is not only confidentiality. Unencrypted audit storage weakens trust in the evidence chain, especially when logs are used for forensics, compliance validation, or post-incident reconstruction. If the bucket is also broadly shared, cross-account accessible, or exposed through weak policy conditions, the lack of encryption increases the impact of any accidental or malicious read.
This is why teams should treat bucket encryption as a baseline control for audit data, not an optional hardening step. NIST SP 800-53 Rev 5 reinforces the need to protect audit information and to manage security controls around data storage and access, which fits the way CloudTrail logs are typically used in operations and investigations.
How teams should verify and remediate the finding
Start with the trail inventory, then check the destination bucket, not the other way around. For each bucket that receives CloudTrail data, verify default encryption, confirm the key type if a customer-managed key is used, and make sure any logging pipeline, replication rule, or cross-account delivery path preserves the same protection. A bucket-level check is more reliable than looking for encryption on individual objects after the fact.
If a destination bucket is unencrypted, remediate it by enabling server-side encryption and validating that new log objects are written under the expected policy. Where operational requirements allow, standardise the logging pattern so every CloudTrail destination follows the same encryption baseline. This reduces the chance that one trail, region, or account quietly diverges from the rest.
For control mapping, the most relevant external references are the NIST SP 800-53 Rev 5 Security and Privacy Controls catalog for storage and audit control expectations, and the NIST Cybersecurity Framework 2.0 for aligning the inventory, protection, and recovery workflow around logging data.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-9 — Protection of Audit Information | CloudTrail logs are audit records that need protection at rest. |
| SC-28 — Protection of Information at Rest | Unencrypted CloudTrail buckets are data-at-rest exposure in S3. | |
| AU-12 — Audit Record Generation | CloudTrail is the audit source whose storage destination must be governed. | |
| Recommendation — Protect audit records in S3 with encryption and access restrictions. Encrypt CloudTrail log objects and enforce default bucket encryption. Map each audit source to its S3 destination and verify protection on delivery. | ||
| NIST CSF 2.0 | ID.AM-01 — Inventory of Assets | Finding unencrypted CloudTrail buckets starts with identifying every log destination. |
| PR.DS-01 — Data-at-rest is protected | CloudTrail logs stored in S3 should be encrypted at rest. | |
| Recommendation — Inventory all CloudTrail destinations and reconcile them to S3 buckets. Enable encryption for every S3 bucket that stores CloudTrail logs. | ||
Practitioner Guidance
What to verify: Confirm the exact S3 bucket, prefix, and account that CloudTrail writes to, then verify bucket default encryption and any object-level encryption assumptions separately. Do not assume that because a trail is enabled, its destination is protected.
Common mistake: Teams often scan for “CloudTrail enabled” and stop there. The real control question is whether every logging destination is encrypted end to end, including any cross-account or replicated copy that may receive the same audit data.
Practitioner takeaway: Treat CloudTrail buckets as evidence stores, not ordinary application buckets; if the logs can explain who did what in the account, they deserve the same or stronger protection than the systems they document.
Related resources from NHI Mgmt Group
- How should security teams store logs for multi-year retention without SIEM cost blowouts?
- How should security teams scan S3 buckets for exposed secrets without creating unnecessary noise?
- How should security teams implement identity threat detection without relying on logs alone?
- How should security teams phase out 1024-bit encryption without breaking production services?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
