AWS SOC 2 Compliance Checklist: Complete Evidence Guide

Achieving SOC 2 compliance on Amazon Web Services (AWS) requires more than just secure infrastructure; it demands verifiable evidence, including configuration logs, access reviews, and screenshots. While many organizations rely on GRC platforms to monitor settings via API, auditors frequently request visual proof of console configurations and workflows that APIs miss. This article provides a complete AWS SOC 2 checklist and explains how automation tools can capture audit-ready screenshots to streamline your evidence collection process.

What Evidence Is Required for AWS SOC 2 Compliance?

Answer: AWS SOC 2 compliance requires three distinct types of evidence: infrastructure configurations (JSON/YAML settings), access logs (CloudTrail/CloudWatch), and visual evidence (screenshots of the AWS Console). Auditors use this evidence to verify that controls are designed correctly and operating effectively over the audit period.

While AWS provides the "Shared Responsibility Model"—handling physical security controls—you remain responsible for documenting controls related to data access, encryption, and change management within your cloud environment.

The Complete AWS SOC 2 Evidence Checklist

The following checklist maps common AWS services to SOC 2 Trust Services Criteria (TSC), specifically Security (Common Criteria) and Availability.

1. Logical Access & IAM (CC6.1, CC6.2, CC6.3)

Controls in this category verify that only authorized personnel can access AWS resources.

Control Requirement	Required Evidence (Artifacts)	Automation Method
MFA Enforcement	Screenshot of IAM "MFA" column showing "Enabled" for all users.	API Monitor + Console Screenshot
Role-Based Access (RBAC)	JSON Policy documents showing least privilege (e.g., no `:` admin access).	API Monitor
Access Reviews	Quarterly export of IAM users/roles + tickets proving manager review.	Workflow Automation
Offboarding	Screenshot of CloudTrail log showing user deletion timestamp vs. HR ticket.	Screenata / Workflow Recorder
Root Account Security	Screenshot proving Root account has no access keys and MFA is enabled.	Console Screenshot

2. Security Groups & Networking (CC6.6)

Controls here ensure that network boundaries are protected against unauthorized traffic.

Control Requirement	Required Evidence (Artifacts)	Automation Method
Restricted Inbound Ports	Screenshot of Security Groups showing port 22/3389 restricted to VPN IPs.	API Monitor + Console Screenshot
WAF Configuration	Screenshot of AWS WAF rules blocking common exploits (SQLi, XSS).	Console Screenshot
VPC Flow Logs	Evidence that Flow Logs are "Active" and sending data to S3/CloudWatch.	API Monitor
Load Balancer TLS	Screenshot of ALB listeners showing HTTPS (Port 443) enforcement.	API Monitor

3. Encryption & Data Protection (CC6.1, CC6.7)

Controls to verify that data is encrypted at rest and in transit.

Control Requirement	Required Evidence (Artifacts)	Automation Method
S3 Encryption	Screenshot of S3 bucket properties showing "Default Encryption" enabled (AES-256/KMS).	API Monitor
EBS Volume Encryption	Console list view showing "Encrypted: Yes" for all attached volumes.	API Monitor
KMS Key Management	Screenshot of KMS Key Policy showing restricted usage permissions.	Console Screenshot
Database Encryption	Screenshot of RDS configuration tab showing encryption enabled.	API Monitor

4. Availability & Backups (CC7.3, CC7.4, CC7.5)

Controls ensuring systems can be restored in the event of a failure.

Control Requirement	Required Evidence (Artifacts)	Automation Method
Backup Schedule	Screenshot of AWS Backup plan showing daily/hourly frequency.	API Monitor
Restoration Test	Critical: Screenshot or log of a successful restore test (e.g., restoring RDS snapshot to test instance).	Screenata / Workflow Recorder
S3 Versioning	Screenshot of S3 bucket showing "Bucket Versioning" enabled.	API Monitor
Multi-AZ Deployment	Screenshot of RDS showing "Multi-AZ: Yes".	API Monitor

5. Change Management (CC8.1)

Controls verifying that infrastructure changes are authorized and tested.

Control Requirement	Required Evidence (Artifacts)	Automation Method
Infrastructure as Code (IaC)	Git history showing Pull Request approvals for Terraform/CloudFormation changes.	API Monitor (GitHub/GitLab)
Manual Changes	CloudTrail logs filtered by `EventName: Update` or `Create` showing user identity.	Log Export

Where Traditional AWS Automation Stops

Most companies use GRC platforms like Drata or Vanta to automate compliance. These tools are excellent for checking binary states via API (e.g., "Is MFA enabled? True/False"). However, they struggle with evidence that requires context or negative testing.

The Gap in Traditional Tools:

Contextual UI Settings: APIs can confirm a setting is "On," but auditors often ask for a screenshot of the AWS Console to see the context—for example, verifying that a specific S3 bucket policy effectively denies access to the public, which requires visualizing the policy editor or simulating access.
Restoration Testing: An API can check if backups exist, but it cannot prove you tested a restoration. Auditors require evidence of the restoration process itself—often a screenshot of the restored database instance running in a staging environment.
Complex IAM Workflows: Proving "Access Denied" for unauthorized users (Negative Testing) requires a screenshot of the error message when a test user tries to access a restricted resource. APIs cannot capture this user experience.

This is where evidence automation tools like Screenata bridge the gap by recording the actual workflow in the AWS Console and generating the screenshots automatically.

How to Automate AWS SOC 2 Evidence Collection with Screenshots

To fully automate your AWS SOC 2 evidence—including the manual screenshots auditors demand—follow this three-step workflow.

Step 1: Connect Your GRC Platform

Integrate Drata, Vanta, or Secureframe with your AWS account using a read-only IAM role. This automates the collection of ~70% of your controls (infrastructure configurations like encryption and MFA status).

Step 2: Automate "Computer-Use" Evidence

For the remaining 30%—specifically restoration tests, console configurations, and negative access tests—deploy an AI evidence agent like Screenata.

Action: Record the workflow of a restoration test in the AWS Console.
Automation: The agent captures timestamped screenshots of the "Restore Snapshot" action and the subsequent "Available" status of the new instance.
Result: A PDF evidence pack is generated, complete with control IDs (e.g., CC7.4) and metadata.

Step 3: Centralize Evidence in Evidence Library

Upload the generated PDF packs directly to your GRC platform's evidence library or map them to specific controls. This ensures your auditor sees a complete picture: API data verifying configuration and screenshot evidence verifying operation.

Example: Documenting AWS IAM Access Controls (CC6.1)

Control Objective: Prove that logical access to the production AWS environment is restricted to authorized personnel and that the "Principle of Least Privilege" is applied.

Manual Evidence Collection (Old Way):

Log into AWS Console.
Navigate to IAM > Users.
Take a screenshot of the user list.
Click on a specific user to show their policies.
Take a screenshot.
Paste into Word, add date/time manually.

Automated Evidence Collection (New Way):

Trigger: Run the "AWS IAM Review" workflow in Screenata.
Capture: The AI agent navigates to the IAM dashboard, captures the user list, and opens the policy simulator to test a "Deny" condition for a non-admin user.
Output: A ZIP file containing:
- iam_users_list.png (Timestamped)
- policy_simulation_denied.png (Proof of least privilege)
- report.pdf (Audit-ready summary)

Do Auditors Accept Automated AWS Screenshots?

Yes. Automated screenshots are widely accepted by AICPA-accredited auditors, provided they maintain integrity and authenticity.

To be auditor-ready, automated evidence must include:

Timestamps: Synced with a reliable NTP server, visible in the screenshot or metadata.
URL/Context: The browser URL bar (e.g., https://us-east-1.console.aws.amazon.com/iam/) must be visible to prove the source system.
Chain of Custody: Metadata indicating who (or what agent) captured the evidence and when.
Clarity: Images must be high-resolution and unalterable (e.g., PDF or Read-Only formats).

Frequently Asked Questions

Does AWS Artifact replace the need for my own evidence?

No. AWS Artifact provides AWS's own SOC 2 report, which covers physical security of data centers and the hypervisor layer. You must still provide evidence for the controls you manage, such as your IAM users, S3 bucket permissions, and EC2 security groups.

How often should I collect AWS evidence?

For SOC 2 Type II, evidence must be collected throughout the audit period (usually 6-12 months).

Continuous: Infrastructure settings (via Drata/Vanta).
Quarterly: Access reviews and restoration tests (via Screenata).
Ad-hoc: Onboarding/offboarding evidence (per occurrence).

Can I just use CloudTrail logs as evidence?

CloudTrail logs are excellent for detective controls (showing what happened), but auditors often require preventative evidence (showing the configuration that prevents bad things). For example, a screenshot of a Security Group rule blocking port 80 is often preferred over a log showing no traffic on port 80.

Key Takeaways

✅ AWS SOC 2 audits require a mix of configuration data, logs, and visual screenshots.
✅ The "Shared Responsibility Model" means you must document your own logical access, encryption, and backup controls.
✅ GRC tools automate API checks but often miss console-based workflows and negative testing evidence.
✅ AI agents can automate the capture of AWS Console screenshots, reducing manual audit prep time by over 90%.
✅ Restoration tests (CC7.4) are a common manual pain point that should be automated with workflow recorders.

Learn More About SOC 2 Compliance Automation

For a complete guide to automating SOC 2 evidence collection, see our guide on automating SOC 2 evidence collection, including how to handle application-level controls and close the manual evidence gap.

For more on this topic, see How Much Time Does SOC 2 Audit Preparation Actually Take? (Hours vs. Months).

For more on this topic, see How to Automate SOC 2 Access Control Evidence Collection with Screenshots.