Inspect existing trails' event selectors with get-event-selectors. Add a write-only S3 data-event selector to a multi-Region trail. Use advanced event selectors to scope to regulated buckets so the data-event volume (and bill) stays controlled. Confirm write events start appearing and monitor the volume.

Compliance Medium severity

AWS Security Hub · S3

S3.22: Buckets should log object-level write events

Written and reviewed by Emnode · Last reviewed 27 May 2026

What does AWS Security Hub S3.22 check?

S3.22 checks that a multi-Region CloudTrail trail logs S3 object-level write data events at the account level. It reports FAILED when no trail captures write data events for S3, because object writes are invisible to CloudTrail by default.

Why does S3.22 matter?

CloudTrail records management events but not object-level reads and writes unless you explicitly enable data events. Without write logging there is no record of objects being created, overwritten or deleted, so tampering or staging of exfiltrated data leaves no trail to investigate.

How do I fix S3.22?

Inspect existing trails' event selectors with get-event-selectors.
Add a write-only S3 data-event selector to a multi-Region trail.
Use advanced event selectors to scope to regulated buckets so the data-event volume (and bill) stays controlled.
Confirm write events start appearing and monitor the volume.

Remediation script · bash

# Enable server access logging on a flagged bucket, pointing at a central archive bucket.
aws s3api put-bucket-logging \
  --bucket fintech-customer-uploads \
  --bucket-logging-status '{"LoggingEnabled":{"TargetBucket":"fintech-s3-access-logs","TargetPrefix":"customer-uploads/"}}'

# Log object-level read and write data events on a multi-Region trail, scoped to the
# sensitive prefix to keep the CloudTrail bill proportionate to the risk. Note: a
# prefix-scoped selector does NOT clear S3.22/S3.23 -- those controls only pass when
# the trail logs data events for ALL S3 buckets (drop the resources.ARN field).
aws cloudtrail put-event-selectors \
  --trail-name acme-management-trail \
  --advanced-event-selectors '[{"Name":"Log read+write data events for customer-records","FieldSelectors":[{"Field":"eventCategory","Equals":["Data"]},{"Field":"resources.type","Equals":["AWS::S3::Object"]},{"Field":"resources.ARN","StartsWith":["arn:aws:s3:::acme-customer-records/"]}]}]'

Full walkthrough (console steps, edge cases and verification) in the lesson Enable S3 access and object-level logging.

Is S3.22 a false positive?

This is not all-or-nothing: you can scope write logging to specific buckets with advanced selectors rather than logging every bucket in the account.

Full lesson Enable S3 access and object-level logging Step-by-step remediation with CLI, code and persona-specific context.

AWS documentation for S3 controls ↗ Check your own account for S3.22 →

Part of the learning path See what's happening

S3.1 Account-level S3 public access is not fully blocked
S3.2 Public S3 buckets expose data to anyone on the internet
S3.3 Buckets can be written to by anyone on the internet
S3.5 S3 is accepting unencrypted HTTP requests
S3.6 Bucket policy grants broad access to other AWS accounts
S3.8 Buckets can still be made public; Block Public Access is off
S3.9 No S3 access logs, so reads and writes go unaudited
S3.10 Versioned buckets should have lifecycle configurations
S3.11 Buckets should have event notifications enabled
S3.12 ACLs should not be used to manage bucket access
S3.13 Buckets have no lifecycle rules and grow forever
S3.15 Buckets should have Object Lock enabled