Skip to main content
INS // Insights

CloudTrail Evidence Pipeline for SOC 2

Updated August 2026 · 5 min read

Having CloudTrail is not the same as having CloudTrail evidence pipeline for SOC 2. Auditors do not want your Event history click-path. They want repeatable queries over the observation window, proof logs were not tampered with, and a mapping from "this control" to "this event class."

We build that pipeline on top of an organization trail. The GRC platform stores the control narrative. Engineering stores the query pack and the job that fails if the trail goes quiet.

Control Mapping We Actually Ship

Mid-market SOC 2 on AWS does not need a SIEM program (we do not sell SOC operations). It needs a short list of detections with evidence exports:

Control theme Event classes Export
CC6 access CreateAccessKey, AttachUserPolicy, Identity Center assignment APIs Weekly CSV + ticket on hit
CC6 removal DeleteUser, DisableUser, permission set removal Join to HR termination file
CC7 monitoring StopLogging, DeleteTrail, PutBucketPolicy on the log bucket Page, not email
CC8 change PutBucketVersioning, console deploys without a change ticket ID in user-agent/session Sample pack

Queries live in version control. If the only copy is a saved Athena tab in someone's account, you do not have a control.

-- example: access key creation in the observation window
SELECT eventTime, userIdentity.arn, sourceIPAddress, json_extract_scalar(responseElements, '$.accessKey.accessKeyId')
FROM cloudtrail.mgmt
WHERE eventName = 'CreateAccessKey'
  AND eventTime BETWEEN DATE '2026-01-01' AND DATE '2026-03-31';

Date literals here are query parameters for a sample window, not a "current year" marketing claim. Swap the window to match the auditor's period.

Integrity Is Part of Evidence

Log file validation digest files are how you argue the S3 objects were not rewritten. Bucket policies that allow s3:DeleteObject from app roles are how you lose that argument. We treat the log-archive account like production: no human standing keys, OIDC for CI, SCP deny on trail disruption.

This is detective evidence, not a replacement for Config packs. Config answers "was encryption on?" CloudTrail answers "who turned it off?"

Do Not Build a Pseudo-SIEM

GuardDuty and Security Hub have a place. Dumping every CloudTrail event into a mashup "SOC" is how boutique engineering shops accidentally claim incident-response operations we do not sell. The pipeline:

  1. Org trail → S3
  2. Partitioned Athena
  3. Named queries + scheduled proofs
  4. Exceptions in the GRC tool

If you need 24/7 triage, that is a different vendor. We automate the evidence pack for the audit you already bought.

Ask us what your GRC platform isn't covering → rutagon.com/contact · 907-841-8407 · contact@rutagon.com.

Quiet Trail Detection

A scheduled query that expects >N management events per day (tuned per org size) pages if the trail goes quiet. That is cheaper than discovering silence at audit time. We also alert on StopLogging and DeleteTrail in near real time via EventBridge on CloudTrail itself — dogfooding the custom bus pattern.

Partition projection in Athena (date, region, account) keeps queries under timeout. Unpartitioned org trails at mid-market volume still work; at higher volume they do not. We add partitions before the observation window, not during sampling week.

Mapping File

controls.yaml in git maps CC6.2 → query names. GRC gets the rendered pack. When the auditor asks "show CreateAccessKey," we run the named query, not a new SQL someone invented in the console. Console-invented SQL is not a control.

CloudTrail evidence pipeline queries we pin in git

A CloudTrail evidence pipeline for SOC 2 is saved Athena SQL plus integrity, not a person who “knows how to filter the trail.” AWS documents org trails in the CloudTrail user guide. We add: log-file validation on, bucket in log-archive, SCP deny StopLogging/DeleteTrail in members, EventBridge alarm on those APIs, and a quiet-trail detector (expected management-event floor per day).

controls.yaml maps CC6.2 → query names (create_access_key_90d.sql). GRC gets the rendered pack. Console-invented SQL during sampling week is not a control. Partition projection (date, region, account) keeps queries under timeout before the observation window starts.

Data events are scoped: log-archive bucket (detect evidence reads), named customer-data buckets, backup vaults. Turning all data events on “for SOC 2” is how the trail costs more than the app. Revisit quarterly.

Delegated admin in a security account beats using the management account for day-to-day Athena. New AFT accounts must appear in the org trail within minutes of first API call — we test that when we vend a throwaway account.

CloudTrail evidence pipeline cost we warn finance about before we enable data events

Org management events for a mid-market AWS estate are usually cheap next to the app. Data events on every bucket are not. We price the trail in the same scorecard as the control. If finance will not pay for data events on the evidence bucket itself, we say so: you cannot detect silent reads of the audit store.

Athena scan bytes are a second bill. Partition or you will teach the auditor to fear running the query. Named workgroup with bytes scanned limits belongs in the runbook.

Frequently Asked Questions

Can we screenshot CloudTrail Event history instead?

The console view is short-retention and not a complete org picture. Athena over the org trail is what survives sampling six months later.

How is this different from AWS Audit Manager?

Audit Manager can attach evidence. Someone still has to define the queries and the trail architecture. We treat Audit Manager as a binder, optional.

Do we need data events for SOC 2?

For in-scope data stores, often yes — scoped. Org-wide S3 data events are a cost incident. Start with buckets named in the system description.

Who runs the queries during the audit?

Security engineering or GRC with read-only Athena access. We document the IAM permission set so the auditor is not using a shared admin role.

What if we are multi-account and trails were never centralized?

Centralize first (organization trail), then start the observation clock for logging. You cannot retroactively query accounts that never logged.