# Ensure CloudTrail logs S3 object-level read events - Source: https://support.icompaas.com/support/solutions/articles/a_1793292193186567-ensure-cloudtrail-logs-s3-object-level-read-events - Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS_Checks_v5.39.1](https://support.icompaas.com/support/solutions/c_1793285913477877) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1793287194371224) - Last updated: 2026-10-29 - Publisher: iCompaas, Inc. (https://www.icompaas.com) **Description** Ensure that at least one AWS CloudTrail trail in the account records Amazon S3 object-level read data events, such as GetObject, for all current and future S3 buckets. Object-level events are configured as data events on the trail, using an event selector for the AWS::S3::Object resource type. **Rationale** CloudTrail does not record S3 object-level activity by default. Without object-level read logging, there is no record of who downloaded which objects, so data exfiltration by an attacker or insider can go unnoticed. This also limits forensics, anomaly detection and incident response. Logging S3 object read events (or all events) for all buckets on a multi-region trail provides an accountable record of data access. **Impact** - Records who accessed which S3 objects and when - Supports detection and investigation of data exfiltration - Data events are charged per event, and busy buckets can generate a large volume of events and log storage **Default Value** Trails do not log data events by default. Only management events are logged. **Pre-Requisites** - IAM permissions: cloudtrail:DescribeTrails, cloudtrail:GetEventSelectors and cloudtrail:PutEventSelectors - An existing trail, preferably a multi-region trail - Approval for the additional data event and storage costs **Remediation** **Test Plan** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the CloudTrail console and select **Trails** in the left menu. 3. Select each trail and review the **Data events** section. 4. Check whether S3 data events are logged for all current and future S3 buckets, including read events. 5. If no trail in the account logs S3 object-level read events for all buckets, follow the implementation steps. **CLI:** List the trails: aws cloudtrail describe-trails --region --query "trailList\[\].\[Name,HomeRegion,TrailARN\]" --output table Show the event selectors of a trail (run in its home region): aws cloudtrail get-event-selectors --trail-name --region The account fails if it has S3 buckets and no trail has either a basic event selector with ReadWriteType ReadOnly or All and a data resource of type AWS::S3::Object with the value arn:aws:s3, arn:aws:s3::: or arn:aws:s3:::\*/\*, or an advanced event selector with the field resources.type equal to AWS::S3::Object. **Implementation Steps** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the CloudTrail console and select **Trails** in the left menu. 3. Select the trail and, in the **Data events** section, choose **Edit**. 4. Select **Data events** and choose **S3** as the resource type. 5. Choose to log all current and future S3 buckets, and select read events (or both read and write events). 6. Choose **Save changes**. **CLI:** The suggested selector ReadWriteType: ReadOnly would also apply to management events and stop the logging of write management events, so the command below uses All and keeps management events. This command replaces the trail's existing event selectors; if the trail uses advanced event selectors or other data events, make the change in the console instead. aws cloudtrail put-event-selectors --trail-name --region --event-selectors '\[{"ReadWriteType":"All","IncludeManagementEvents":true,"DataResources":\[{"Type":"AWS::S3::Object","Values":\["arn:aws:s3"\]}\]}\]' **Backout Plan** Before making changes, save the current event selectors: aws cloudtrail get-event-selectors --trail-name --region > event-selectors-backup.json To roll back: 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the CloudTrail console and select the trail. 3. In the **Data events** section, choose **Edit**. 4. Remove the S3 data event selector, or restore the settings from the saved backup. 5. Choose **Save changes**. **CLI:** Restore a trail that previously logged only management events: aws cloudtrail put-event-selectors --trail-name --region --event-selectors '\[{"ReadWriteType":"All","IncludeManagementEvents":true}\]' Note: rolling back stops the recording of S3 object-level access. **Reference** - [https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html) - [https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html) - [https://docs.aws.amazon.com/securityhub/latest/userguide/s3-controls.html#s3-23](https://docs.aws.amazon.com/securityhub/latest/userguide/s3-controls.html#s3-23) - [https://docs.aws.amazon.com/cli/latest/reference/cloudtrail/put-event-selectors.html](https://docs.aws.amazon.com/cli/latest/reference/cloudtrail/put-event-selectors.html) ## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.