CloudTrail for SOC 2: Setting Up Audit Logging on AWS

Why CloudTrail Is Essential for SOC 2

AWS CloudTrail records every API call made in your AWS account — who did what, from where, and when. It is the foundational audit log for cloud infrastructure and directly satisfies SOC 2 criteria: CC7.2 (anomaly detection), CC7.3 (incident investigation), CC8.1 (change management audit trail), and CC6.1 (access control verification).

Without CloudTrail, you cannot answer the auditor's most basic question: "Show me every change made to your production infrastructure during the audit period." With CloudTrail, that question is answerable with a filtered log query.

Setting Up a Multi-Region Trail

Create a trail that applies to all regions: in CloudTrail console, create a new trail, name it (e.g., "org-management-trail"), select "Apply trail to all regions: Yes," enable for all accounts in your organization (if using AWS Organizations), and specify an S3 bucket for log storage.

Enable CloudTrail in all AWS accounts — not just your management account. Use AWS Organizations CloudTrail to create an organization-level trail from the management account that automatically applies to all member accounts. This is the most efficient approach for multi-account environments.

Via CLI: aws cloudtrail create-trail --name org-management-trail --s3-bucket-name your-cloudtrail-bucket --is-multi-region-trail --include-global-service-events --enable-log-file-validation.

Securing CloudTrail Log Storage

The S3 bucket receiving CloudTrail logs must itself be secured — an attacker who can delete logs can cover their tracks. Required bucket settings: (1) Block all public access — enable all four "Block public access" settings. (2) Enable versioning — prevents overwriting or deleting log objects. (3) Enable MFA delete — requires MFA authentication to delete objects or disable versioning. (4) Enable server-side encryption (SSE-KMS) — encrypt logs at rest with a KMS key. (5) Enable S3 access logging to a separate bucket — logs access to the log bucket itself.

Restrict bucket policy so that only the CloudTrail service principal (cloudtrail.amazonaws.com) can write to the bucket, and only designated log reviewers or automated tools can read from it.

Log File Validation

CloudTrail log file validation creates a digitally signed digest file for each hour of logs. The digest references the log files and their SHA-256 hashes, and is signed with a public/private key pair. You can validate the integrity of any log file using the AWS CLI: aws cloudtrail validate-logs --trail-arn your-trail-arn --start-time start --end-time end.

If a log file was modified or deleted after delivery, validation will fail. This provides the non-repudiation and integrity assurance auditors expect for audit logs. Ensure "Enable log file validation" is checked when creating or updating your trail.

Data Event Logging

By default, CloudTrail only logs management events (API calls that manage AWS resources). For SOC 2, you should also enable data event logging for high-value resources: S3 data events (GetObject, PutObject, DeleteObject) on buckets containing customer data, and Lambda function invocations.

Warning: data events significantly increase log volume and cost. Be selective — enable data events only for S3 buckets containing PII or sensitive customer data, not all buckets. Use S3 bucket-level settings to specify which buckets to log.

DynamoDB and RDS data events are logged through different mechanisms — CloudTrail for DynamoDB data events, and RDS Enhanced Monitoring or database audit logs (pgaudit for PostgreSQL, MariaDB audit plugin) for RDS.

CloudWatch Alarms for SOC 2

CloudTrail integrates with CloudWatch Logs to create metric filters and alarms for high-risk events. The CIS AWS Foundations Benchmark (which maps to SOC 2 CC7.2) recommends alarms for: root account usage, MFA console sign-in failures, IAM policy changes, CloudTrail configuration changes, S3 bucket policy changes, and Security Group rule changes.

Create a CloudWatch Log Group linked to CloudTrail, then create metric filters for each event type, and CloudWatch Alarms that fire when the metric exceeds zero. Route alarms to SNS topics connected to Slack or PagerDuty.

Alternatively, use AWS Security Hub with the CIS AWS Foundations Benchmark standard enabled — it checks many of these conditions automatically and consolidates findings.

CloudTrail Evidence for Auditors

(1) CloudTrail trail configuration screenshot showing multi-region enabled, all management events, log file validation, and S3 bucket. (2) S3 bucket policy screenshot. (3) AWS Config rule "cloud-trail-enabled" showing compliant status. (4) Log file validation output: aws cloudtrail validate-logs run for a representative period. (5) CloudWatch alarm configurations for CIS benchmark events. (6) Sample CloudTrail log query results showing investigation of a specific event — demonstrates you can actually use the logs.