A practical SOC 2 on AWS checklist for startups: how the security criteria map to AWS access, logging and change controls, what evidence auditors ask for, and how to find gaps early.
SOC 2 on AWS is mostly an exercise in showing that access, logging, change and incident controls work consistently. This SOC 2 AWS checklist maps the SOC 2 security criteria to concrete AWS configuration and the evidence an auditor will ask for.
What is SOC 2 and what does it mean for an AWS startup?
SOC 2 is an attestation report issued by an independent CPA firm, not a certificate. It states whether your controls meet the AICPA Trust Services Criteria. Security, also called the Common Criteria, is always in scope; availability, confidentiality, processing integrity and privacy are optional and chosen to fit your customer commitments.
Enterprise customers ask for it as proof you handle their data responsibly. A Type 1 report describes whether controls are designed properly at a point in time. A Type 2 report also tests whether they operated over a period, commonly several months, and is the one most enterprise buyers prefer. Check the current wording on the AICPA website and agree the audit period with your auditor.
AWS is certified against many frameworks, including SOC 2, for its own services. That covers AWS’s side of the shared responsibility model. How you configure your accounts remains your part, and your auditor will test it.
What goes into a SOC 2 AWS checklist?
A SOC 2 AWS checklist groups the security criteria into access control, system operations and monitoring, change management and risk management. Each maps to concrete AWS services and settings, shown below with the evidence an auditor typically expects. Your auditor decides the exact controls, so treat this as a starting point.
Access control (logical access, CC6)
Who can reach your systems and data, and how you grant and remove that access.
- Single sign-on with MFA. Use IAM Identity Center with your identity provider and require MFA for everyone. Evidence: SSO configuration and MFA enforcement settings.
- Least privilege. Replace broad policies with scoped permission sets, and review them. Evidence: IAM Access Analyzer reports and a dated access review.
- Joiner, mover and leaver process. Removing access promptly when people leave is one of the most commonly tested controls. Evidence: tickets or logs showing removal within your stated time.
- Encryption. Encrypt data at rest with KMS and in transit with TLS. Evidence: default encryption settings and policies that deny non-TLS requests.
- Network boundaries. No open management ports, private subnets for databases. Evidence: security group and VPC configuration.
Monitoring and incident response (system operations, CC7)
Detecting and responding to problems.
- Central audit logging. CloudTrail in all regions with log file validation, delivered to a protected, separate account. Evidence: trail configuration and retention.
- Threat detection and alerting. GuardDuty and Security Hub enabled, with alerts routed to a monitored channel. Evidence: alert history and who responded.
- Vulnerability management. Amazon Inspector or an equivalent scans workloads, with a defined time to fix. Evidence: scan reports and remediation tickets.
- Incident response plan. A written plan, a named owner and at least one tested exercise. Evidence: the plan and notes from the test.
Change management (CC8)
Showing that changes are reviewed and authorised.
- Version control with protected branches. Require reviews before merging to main. Evidence: branch protection settings and pull request history.
- Infrastructure as code. Define infrastructure in Terraform or CloudFormation and apply it through a pipeline, not by hand. Evidence: pipeline runs and approvals.
- Separate environments. Development, staging and production in separate accounts. Evidence: account structure under AWS Organizations.
Governance and risk (CC1 to CC5, CC9)
The part that is not a setting in AWS.
- Written policies. Information security, access control, incident response, change management and vendor management policies, approved and reviewed.
- Risk assessment. A documented process for identifying and rating risks, repeated at least annually.
- Vendor management. A list of vendors that handle your data, with their own assurance reports reviewed.
- Security awareness training. Evidence that staff completed it, including new hires.
Which Trust Services Criteria should a startup include?
Include Security because it is mandatory, and add the others only if customers ask for them or your service makes the commitment. Availability suits services with uptime promises, confidentiality suits services that hold customers’ sensitive data, and privacy applies when you handle personal information in ways customers rely on you to protect.
Every extra criterion adds controls to design, operate and prove, so adding them speculatively raises the cost and the chance of an exception in the report. Ask your first enterprise customers which they expect before you decide.
What mistakes break a SOC 2 AWS checklist?
The common mistakes are starting the observation period before controls exist, doing access reviews once and never again, leaving manual steps that nobody records, and treating the report as a one-off project instead of a routine. Each shows up as an exception, and exceptions are visible to your customers.
- Controls that exist only on paper. A policy that says access is reviewed quarterly needs four dated reviews as evidence.
- Shared administrator accounts. They make it impossible to show who did what. Use named users and roles.
- Missing leaver evidence. Keep tickets or logs showing access removal on the day people leave.
- Logs that expire. Retain CloudTrail logs for at least the audit period.
Does a SOC 2 AWS checklist need a compliance automation platform?
Not necessarily. These platforms collect evidence automatically and can save time, but they do not fix your configuration. A team with a few accounts and a disciplined spreadsheet can pass an audit. Decide after you have fixed the technical gaps, because the platform then has something worth monitoring.
None of this requires expensive tooling to start. Most of the technical controls above are native AWS features that you switch on and configure once, then evidence over time.
How long does a SOC 2 AWS checklist take to complete?
Preparation commonly takes a few months, depending on how many controls you already have, and a Type 2 report then needs an observation period during which controls must operate consistently. Sources describe observation windows of about three to twelve months, so agree the period with your auditor early.
The fastest way to lose time is to start the audit period before your controls are in place, because a control that fails during the window shows up in the report. Fix the gaps first, then start the clock.
How do you find the gaps before the auditor does?
Run a security review of your AWS accounts before you work through the SOC 2 AWS checklist. It shows which technical controls are missing, such as weak IAM or absent logging, so you fix them before the observation period begins. Our AWS security audit produces a findings list mapped to CIS controls that shortens this step, and is quoted at a fixed price.
An audit does not make you SOC 2 compliant on its own, because an independent auditor issues the report, but it removes the most common technical surprises. See how we price, our cloud security and compliance services, and the AWS security audit checklist.
The bottom line
A SOC 2 AWS checklist is less about exotic tooling and more about consistent basics: single sign-on with MFA, least privilege, central logging, reviewed changes and written, followed policies. Book a free 20-minute assessment and we will tell you which technical gaps stand between your accounts and a clean audit.
Last updated: 11 October 2026 · Written by AegisElligent.