Skip to main content
INS // Insights

AWS Organization CloudTrail for Audit Evidence

Updated August 2026 · 5 min read

Account-level CloudTrail is how mid-market AWS orgs accidentally go dark. Someone disables a trail in a sandbox, a new account joins without a trail, or data events were never turned on for the one bucket that holds customer exports. AWS organization CloudTrail for audit evidence means one org trail in the management (or a delegated security) account, log-file validation on, S3 bucket policy that denies delete from member accounts, and queries you can rerun during sampling.

This is a bridge topic: infrastructure that compliance teams can explain. It is not a FedRAMP authorization claim. It is also not "we hold SOC 2." It is the logging architecture that supports a SOC 2 observation period.

Why Member-Account Trails Fail Sampling

SOC 2 CC7.x / logging criteria and CC6 sampling all assume you can answer "what happened in AWS during the window?" If trails are per-account:

  • New accounts from Control Tower or AFT ship without the same trail settings
  • A well-meaning engineer turns off logging "to save money"
  • Athena has no single database of events
  • Log-file integrity is inconsistent

An organization trail applies to current and future accounts. Pair it with Control Tower guardrails so nobody can create a competing trail that looks official but drops management events.

The Minimum Viable Evidence Trail

What we implement as the default:

  1. Organization trail, multi-region, management events on.
  2. Log file validation (digest files). Auditors ask; "we'll turn it on later" is a finding waiting to happen.
  3. S3 destination in a log-archive account. Bucket key encryption, Block Public Access, lifecycle to a cheaper class after the retention your policy named.
  4. SSE-KMS with a key the log account owns. Member accounts cannot decrypt-for-delete games.
  5. CloudWatch Logs optional. Useful for alarms; S3 is the evidence store. Do not let CloudWatch retention of 7 days become your only copy.

Data events (S3 object-level, Lambda) are scoped. Turning on all S3 data events org-wide is how the trail bill exceeds the compute bill. We enable data events on buckets that are in-scope for the audit (customer data, backups, log archive itself).

resource "aws_cloudtrail" "org" {
  name                       = "org-management"
  s3_bucket_name             = aws_s3_bucket.trail.bucket
  is_organization_trail      = true
  is_multi_region_trail      = true
  enable_log_file_validation = true
  kms_key_id                 = aws_kms_key.trail.arn

  event_selector {
    read_write_type           = "All"
    include_management_events = true
  }
}

Keep this resource in the security account's Terraform state, not in an app team's workspace.

Athena That an Auditor Can Repeat

Evidence is a query, not a screenshot of CloudTrail Event history (which is a 90-day convenience view). We ship:

  • Glue catalog on the trail prefix
  • Saved queries: root logins, ConsoleLogin without MFA, StopLogging, DeleteTrail, AssumeRole on break-glass, IAM CreateAccessKey
  • Access to those queries limited to GRC + security engineering

This is the same evidence-engineering layer as SOC 2 evidence automation — collectors and queries, not a new GRC vendor.

Cost and Noise

Org trails are cheap relative to a finding. What gets expensive is unmanaged data events and duplicate trails. We delete member-account trails after the org trail is proven (Event history still works; you are not blind). Tag the log-archive bucket for cost allocation.

SOC 2-ready AWS architecture starts with logs you cannot silently lose → rutagon.com/contact · 907-841-8407 · contact@rutagon.com.

Delegated Admin

Organizations can delegate CloudTrail admin to a security account. That is cleaner than using the management account for day-to-day. SCPs still prevent member StopLogging. The bucket policy denies s3:DeleteObject except a break-glass role with hardware MFA and a ticket.

New accounts from AFT/Control Tower must inherit the org trail automatically — that is the point of is_organization_trail. We verify by creating a vended account and querying Athena for its account ID within 15 minutes of first API call.

Data Event Scoping

In-scope: log-archive bucket (detect reads of evidence), customer-data buckets named in the system description, backup vaults. Out of scope until needed: high-churn asset buckets. Revisit quarterly. Turning all data events on "for SOC 2" is how the trail costs more than the app.

AWS organization CloudTrail architecture that members cannot mute

AWS organization CloudTrail architecture fails when every member account has a trail they can StopLogging. The org trail in the management or delegated-admin account, with SCPs, is the control. AWS documents organization trails. We add log-file integrity, a bucket policy that denies s3:DeleteObject except a hardware-MFA break-glass role, and Athena views an auditor can rerun.

Data-event scope is a cost control as much as a security control. In-scope: evidence bucket, named data buckets, backup vaults. Out of scope until needed: high-churn asset buckets. AFT-vended accounts must inherit the org trail automatically. We prove it by creating an account and querying Athena for its ID.

Management events without data events still catch IAM, STS, KMS admin, and CloudTrail API itself. That is the minimum viable SOC 2 trail. Pretending you need every S3 GetObject in every account is how the project dies in finance review.

Frequently Asked Questions

Does an organization trail replace AWS Config?

No. CloudTrail is API activity. Config is resource state over time. Auditors use both. See Config conformance packs for detective guardrails.

Should the management account be the trail owner?

Many orgs delegate to a security account. Either works if SCPs prevent member accounts from disrupting the trail and the bucket policy is correct. Do not put the bucket in an app account.

Do we need CloudTrail Lake?

Lake is convenient for some queries. It is not required for SOC 2. S3 + Athena is defensible and cheaper for many mid-market volumes. Choose on query pattern, not branding.

What retention is "enough"?

Whatever your policy and auditor agreed — often one year or the observation period plus a buffer. Lifecycle rules must match the policy. Infrequent Access after 30 days is fine; expiry at 30 days is not.

Can we turn off read events to save money?

You can, and you will regret it when an exfiltration investigation needs GetObject on an in-scope bucket. Scope data events; do not blindly drop reads on management events.