You're three weeks out from your SOC 2 Type II audit when your assessor requests "CloudTrail logs for the audit period, with evidence of review and investigation of anomalous activity." You've been collecting the logs, but have you been actively using them? And what counts as "anomalous" to an auditor who's seen hundreds of AWS environments?
These questions arise in every engagement where cloud infrastructure is in scope. Assessors don't just want to see that CloudTrail is enabled. They want evidence that you're actively monitoring it, that you can detect unauthorized access, and that your incident response procedures work when something goes wrong. Here's what they're really asking when they dig into your CloudTrail configuration and analysis capabilities.
Can You Detect Unauthorized Cross-Account Access?
"We have cross-account roles for our dev team to access production S3 buckets. How do I prove to an auditor that we're monitoring those roles and would catch unauthorized use?"
Start with the trust policy on every cross-account role. Your auditor will want to see documentation of which external accounts are trusted, why they need access, and what session naming conventions you enforce. When you assume a role, the session name becomes part of the CloudTrail userIdentity block. If your policy requires session names that match your naming standards (like github-actions-deploy), you can write detection rules that flag any session name that doesn't fit the pattern.
For SOC 2 CC6.1 (logical access controls), you need evidence that you're reviewing these assumed role sessions regularly. Set up a monthly query that pulls all AssumedRole events, groups them by session name and source IP, and flags anything that doesn't match your approved integration list. Save the query results and any follow-up investigation notes. That's your evidence trail.
The real test: can you explain what happened if an assessor points to a specific sts:AssumeRole event in your logs? You should be able to tell them which service or person initiated it, whether it was authorized, and what actions they took after assuming the role. If you can't reconstruct that event chain, your detective control isn't operating effectively.
What's Your Process for Unrecognized API Calls?
"I was reviewing CloudTrail and saw a bunch of ListBuckets calls from a role I didn't recognize. Is that normal reconnaissance, or should I escalate it?"
This is where ISO/IEC 27001 Annex A.8.16 (monitoring activities) comes into play. You need a documented baseline of what normal API activity looks like in your environment and a procedure for investigating deviations. A ListBuckets call by itself isn't malicious, but context matters. Was it followed by GetObject requests? Did the same session then execute DeleteObject operations? That sequence (list, read, delete) within a short timeframe is a classic attack pattern.
Your assessor wants to see that you've defined what constitutes "suspicious" in your environment. Document your investigation triggers: consecutive enumeration calls from the same session, API calls from unexpected AWS regions, rapid-fire operations that suggest scripted activity, or any privileged action (IAM changes, KMS key modifications) from a service account that normally only reads data.
When you investigate, capture the full event chain. Don't just look at the single API call that triggered your alert. Pull all events from that principalId and source IP for the surrounding timeframe. If someone listed your buckets at 14:31:22 UTC, what did they do at 14:31:25? At 14:45:12? The threat actor in the example above waited 14 minutes between reconnaissance and deletion, which you'd miss if you only looked at a five-minute window.
How Do You Prove You Reviewed CloudTrail During an Incident?
"We had a security event last quarter where someone deleted files from S3. We restored from backup and moved on. Now my auditor is asking for documentation of our investigation. What should I have?"
For both SOC 2 CC7.3 (incident response) and ISO/IEC 27001 A.5.24 (information security incident management planning and preparation), you need documented evidence that you used CloudTrail during your response. That means:
- The initial alert or detection that triggered your investigation
- The specific CloudTrail queries you ran (save the Athena SQL or CloudWatch Insights queries)
- Screenshots or exports of the relevant log entries, with annotations showing what you identified
- Your timeline reconstruction showing the sequence of events
- Any IOCs you extracted (IP addresses, session names, user agents)
- The root cause analysis linking the logs to your conclusion
The example scenario shows this in practice: the investigation started with a ListBuckets call at 14:31:22, found enumeration three seconds later, then documented a 14-minute gap before systematic deletions began at 14:45:12. Each deletion returned HTTP 204 (success). That level of detail, with timestamps and status codes from actual logs, demonstrates effective detective controls.
If you can't produce that documentation, your incident response procedure is theoretical, not operational. And that's a finding.
Do You Know What "Normal" Looks Like for Your IAM Roles?
"I'm trying to set up monitoring rules, but I don't know what API calls our application roles should be making. How do I baseline this without generating false positives constantly?"
This is a gap in most organizations' monitoring programs. You've enabled CloudTrail, maybe even set up some AWS Config rules, but you haven't documented the expected behavior for each role in your environment.
Start with your service accounts and application roles. For each one, spend two weeks collecting CloudTrail events where that role is the actor. Group the API calls by frequency: what does this role do every minute, every hour, every day? What regions does it operate in? What resources does it touch?
From that baseline, you can write exception rules. If your application-backend-prod role normally only calls dynamodb:GetItem and s3:GetObject in us-east-1, any iam:CreateUser call or any activity in ap-southeast-2 is worth investigating immediately. That's your detective control for CC6.1 and A.8.2 (privileged access rights).
Document this baseline in your ISMS or your SOC 2 system description. When your assessor asks how you detect unauthorized use of privileged roles, you can point to specific thresholds and deviation rules, not just "we have CloudTrail enabled."
What's Your Retention Policy, and Can You Prove You're Following It?
"My auditor asked for CloudTrail logs from eight months ago, but we only keep them for 90 days. Is that going to be a finding?"
It depends on your compliance requirements and what you documented. SOC 2 doesn't specify a retention period, but it does require that you retain logs long enough to support your incident response and forensic investigation needs. If your system description says you keep logs for 90 days, and you can actually produce logs from 90 days ago, you're meeting your stated control.
ISO/IEC 27001 A.8.15 (logging) requires that you determine the retention period based on legal, regulatory, and contractual requirements. If you're subject to specific data breach notification laws that give you 30 or 60 days to investigate, 90-day retention might not be sufficient. Document your rationale.
The technical piece: enable CloudTrail log file integrity validation, configure your trail to write to an S3 bucket with versioning and MFA Delete enabled, and set up lifecycle policies that match your documented retention period. Your assessor will check that the S3 bucket configuration matches what you described in your policies.
Next Steps
If these questions made you uncomfortable, you're not alone. Most organizations enable CloudTrail because it's required, then never look at the logs until an auditor asks for them.
Start small: pick one high-privilege role, document its normal behavior, and set up a weekly review of any deviations. Run that process for a month, document what you found (even if it's "no anomalies detected"), and use that as your template for expanding monitoring to other roles. That's evidence of operational effectiveness, which is what assessors actually care about.
Your CloudTrail logs aren't just a compliance checkbox. They're your detective control for unauthorized access, your evidence trail for incident response, and your proof that the access controls you designed are working in production. Treat them that way.
