CIS AWS Foundations v1.2 2.6: Ensure S3 bucket access logging is enabled on the CloudTrail S3 bucket

This requirement exists to close a common visibility gap: you can have CloudTrail enabled and still be blind to who accessed (or attempted to access) the CloudTrail log files in S3. CloudTrail tells you about API activity across AWS services, but S3 server access logs provide object-level and request-level records for the bucket itself (for example, reads, writes, denies, requester identity, and source). For compliance teams, that means a stronger chain of custody for audit logs and better detection of log tampering attempts.

From an operator’s perspective, the work is straightforward but easy to get subtly wrong. You need (1) the correct CloudTrail destination bucket(s), (2) a separate “log-of-logs” target bucket, (3) the right permissions so S3 can deliver access logs, (4) controls to stop deletion or disabling, and (5) repeatable evidence collection for audits.

CIS maps this requirement through AWS Security Hub under the CIS AWS Foundations Benchmark mapping ¹. Your goal is simple: make the control provable, monitorable, and hard to bypass.

Regulatory text

Requirement (excerpt): “Implement CIS AWS Foundations Benchmark v1.2 requirement 2.6 as mapped in AWS Security Hub.” ²

What the operator must do: Enable S3 bucket access logging on the S3 bucket that receives CloudTrail logs, and configure delivery of those access logs to a designated logging target. Then, operationalize the control so it stays enabled, changes are monitored, and you can produce evidence on demand ¹.

Plain-English interpretation

If CloudTrail logs are stored in S3, you must also log access to that CloudTrail S3 bucket. That means you can answer: “Who accessed the audit logs?” and “Did someone try to delete or read them?” S3 server access logging becomes your audit trail for the audit trail.

Control intent: Detect and investigate unauthorized access or tampering with CloudTrail log objects stored in S3 ³.

Who it applies to

Entities

• Any organization operating AWS accounts where CloudTrail delivers logs to an S3 bucket ³.
• Teams using AWS Security Hub to track CIS AWS Foundations alignment ¹.

Operational contexts

• Single-account and multi-account AWS Organizations setups (centralized logging accounts are common).
• Environments with regulatory audit expectations (SOC 2, ISO 27001, PCI DSS) where audit-log integrity and monitoring are routinely tested. (Framework references are contextual; the CIS requirement itself is the enforceable baseline here.)

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

Step 1: Identify the CloudTrail S3 bucket(s)

1. In AWS CloudTrail, locate the trail(s) that deliver to S3.
2. Record each destination bucket name and AWS account/region context.
3. Confirm whether CloudTrail is centralized (one bucket) or distributed (multiple buckets across accounts).

Evidence tip: Export a screenshot or config capture showing the trail and its S3 bucket destination.

Step 2: Designate a separate S3 target bucket for access logs

CIS expects access logs for the CloudTrail bucket to be delivered somewhere else. In practice, use a dedicated access-logs target bucket (often in a logging account) with restricted access.

Decisions to make:

• Target bucket name and ownership (prefer a centralized logging account).
• Target prefix format (example: s3-access-logs/cloudtrail-bucket-name/).
• Retention and lifecycle rules for access log objects (retain long enough to satisfy your investigation and audit needs).

Step 3: Enable S3 server access logging on the CloudTrail bucket

Enable server access logging on each CloudTrail log bucket:

• Source bucket: the CloudTrail destination bucket.
• Target bucket: the access-logs bucket.
• Target prefix: a unique prefix to keep logs separated per source.

How to implement (operator options):

• S3 console: Bucket → Properties → Server access logging → Enable.
• Infrastructure as Code (preferred): Terraform/CloudFormation so the setting is versioned and enforced.
• AWS Organizations controls: if you standardize logging, roll it out via a baseline.

Step 4: Lock down permissions for delivery and integrity

Your main failure mode is “logging is enabled but delivery fails” or “logs are deliverable but tamperable.”

Minimum control points:

1. Target bucket policy allows S3 Log Delivery to write logs.
2. Block Public Access stays enabled on both the CloudTrail bucket and the target logging bucket.
3. Restrict delete and put-policy permissions to a small set of administrative roles (and require change control).
4. Consider S3 Object Lock / versioning for immutability patterns where your governance model supports it (implementation choice; CIS 2.6 focuses on access logging, but auditors often ask about integrity controls around logs).

Operational note: Put guardrails on s3:PutBucketLogging and s3:DeleteBucket actions via IAM and/or SCPs so a compromised admin role cannot silently disable logging without detection.

Step 5: Monitor continuously (don’t treat this as a one-time checkbox)

Implement detection that fires if:

• S3 server access logging is disabled on the CloudTrail bucket.
• Target bucket policy changes.
• Delivery errors occur (no new access log objects arriving).

Practical monitoring approaches:

• AWS Security Hub control alignment for CIS mapping ¹.
• Config rules / custom checks that validate bucket logging status and target configuration.
• SIEM alerts for changes to S3 logging configuration and bucket policies.

Step 6: Test like an auditor

Run a controlled test:

1. Attempt a read of a CloudTrail log object (authorized test role).
2. Attempt a denied access (unauthorized test role).
3. Verify server access log entries appear in the target bucket and include expected request details.

Document the test results and keep them as evidence of operational effectiveness.

Required evidence and artifacts to retain

Maintain a tight evidence pack that proves: (a) logging is enabled, (b) logs are delivered to the right place, and (c) changes are controlled.

Configuration evidence

• CloudTrail trail configuration showing the destination S3 bucket(s).
• S3 bucket “Server access logging” configuration for the CloudTrail bucket(s).
• Target bucket configuration and prefix strategy.

Policy and access evidence

• Target bucket policy permitting log delivery.
• IAM/SCP controls restricting who can change bucket logging and bucket policies.
• Block Public Access settings (export or screenshot).

Operational evidence

• Sample delivered access log objects (redact if needed).
• Monitoring/alert configuration for changes to bucket logging/policies.
• Periodic control check output (Security Hub finding history or equivalent) ¹.

Retention evidence

• Lifecycle/retention settings for the access-logs bucket (if used).
• Internal log retention standard mapping to the bucket lifecycle settings.

Common exam/audit questions and hangups

Auditors and internal assessors tend to push on these points:

1. “Which bucket is ‘the CloudTrail S3 bucket’?”
   If you have multiple trails/buckets, show an inventory and prove all are covered.

2. “Are access logs delivered to a separate bucket?”
   “Same bucket” designs raise integrity concerns. Expect scrutiny.

3. “How do you know logging hasn’t been disabled?”
   A screenshot from last year is not a control. Show monitoring and change detection.

4. “Who can change these settings?”
   If many engineers have s3:*, your control is fragile. Show role-based admin boundaries and change control.

5. “Can attackers delete the logs?”
   CIS 2.6 doesn’t require immutability, but the question often surfaces. Be ready with versioning/Object Lock decisions and compensating controls.

Frequent implementation mistakes (and how to avoid them)

Mistake	What happens	How to avoid
Logging enabled to the wrong target bucket/prefix	Logs are scattered or not findable during an investigation	Standardize prefixes per account/bucket; document naming
Target bucket policy missing required permissions	Silent failure: logging shows “enabled” but no objects arrive	Validate delivery with a real access test and confirm new objects
Logging enabled for some trails but not all	Audit gaps in multi-account setups	Maintain an inventory of trails and destination buckets; enforce via IaC
Too many admins can disable logging	One compromised role can blind detection	Restrict PutBucketLogging/policy changes; monitor changes aggressively
No evidence retention plan	You can’t prove the control operated historically	Keep periodic snapshots/exports and finding history 1

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific CIS requirement, so treat this as a baseline control expectation rather than a known, cited enforcement trigger.

Risk is still concrete:

• If an attacker can access or alter CloudTrail logs without leaving a trace, incident response slows and confidence in your audit trail drops.
• During external audits, inability to prove log integrity and access monitoring often turns into a control deficiency, remediation plan, or expanded sampling.

Practical 30/60/90-day execution plan

Days 0–30: Establish coverage and enable logging

• Inventory all CloudTrail trails and their S3 destination buckets.
• Create/validate a centralized target bucket for S3 access logs.
• Enable S3 server access logging on each CloudTrail bucket to the target bucket/prefix.
• Validate delivery by generating test access events and confirming log objects land in the target bucket.

Days 31–60: Add guardrails and monitoring

• Put IaC in place (or retrofit) so bucket logging settings are version-controlled.
• Tighten IAM/SCP permissions around PutBucketLogging and bucket policy changes.
• Turn on continuous monitoring with AWS Security Hub visibility for CIS mapping where applicable ¹.
• Create an evidence runbook: what to export, who exports it, and where it’s stored.

Days 61–90: Prove operations and scale across accounts

• Run an internal control test and document results (include both allowed and denied access cases).
• Add periodic reviews: confirm logs are arriving and findings are addressed.
• Roll out the pattern to newly onboarded AWS accounts via baseline templates.
• If you use Daydream for compliance operations, map this requirement to owner, evidence queries, and review cadence so audits become a repeatable pull instead of a scramble ².

Frequently Asked Questions

Does CIS 2.6 require enabling CloudTrail, or just S3 access logging on the CloudTrail bucket?

This requirement is specifically about enabling S3 bucket access logging on the bucket that stores CloudTrail logs ³. CloudTrail enablement is covered in other CIS checks; treat 2.6 as the “log access to the logs” control.

Can the CloudTrail bucket and the access-logs target bucket be the same bucket?

You can configure it, but it weakens integrity and complicates investigations because logs and log-access records co-reside. A separate target bucket is the operationally safer pattern and is what most auditors expect when they hear “access logs for the CloudTrail bucket” ³.

What evidence is strongest for auditors besides screenshots?

Exportable configuration proof (bucket logging settings and bucket policies), plus delivered log objects and monitoring outputs that show the control stayed enabled over time. Security Hub CIS mapping evidence is also useful if you rely on it for continuous compliance tracking ¹.

How do we handle multi-account AWS Organizations with a centralized CloudTrail bucket?

Treat the centralized CloudTrail destination bucket as the in-scope “CloudTrail S3 bucket,” then enable S3 server access logging on it and deliver to a dedicated target bucket (often in the same logging account). Keep an inventory showing that all accounts’ trails feed that bucket ¹.

What if our access logs contain sensitive data?

Restrict access to the access-logs target bucket, encrypt at rest, and apply least-privilege IAM for readers. If you forward logs to a SIEM, document redaction and access controls in the evidence pack.

How often should we verify the control is still enabled?

Verify continuously where possible (automated checks and alerts) and perform periodic evidence captures for audit readiness. If you use AWS Security Hub findings for CIS tracking, keep the finding history and remediation notes as your operational record ¹.

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; AWS Security Hub CIS AWS Foundations mapping table

3. CIS AWS Foundations Benchmark