Reference

The 35-control SOC 2 checklist for AWS startups

Q: How many controls are required for SOC 2?

None specifically. The AICPA publishes Trust Services Criteria, not a control list, and each company designs its own controls to meet them. A 5 to 100 person AWS-native SaaS company typically needs around 35 controls to cover the Security category (Common Criteria CC1 through CC9) in a way an auditor will accept.

Q: Which SOC 2 controls can be automated on AWS?

Roughly 70 to 80% of the technical remediation can be deployed as CloudFormation: organization CloudTrail, GuardDuty with a delegated administrator, AWS Config rules, S3 account-level public access block, account encryption defaults, VPC flow logs, EventBridge alert routing, AWS Backup plans, and Amazon Inspector. What cannot be automated is IAM least privilege on application-wired roles, encryption retrofits of existing data stores, environment separation, and every process control that a human has to run on a schedule.

This is the control catalog we deploy in every engagement. Each control lists the Common Criteria it maps to, the AWS service or process that satisfies it, and the evidence an auditor will ask you to produce. Work through it and you will know your own gap before anyone quotes you.

Updated 17 August 202635 controls, 6 groupsSecurity (Common Criteria)

Read this first

SOC 2 does not prescribe controls. The AICPA publishes criteria; you design controls that meet them. This catalog is our standard set for a 5 to 100 person AWS-native SaaS company, calibrated to what auditors examining companies like yours actually test. A larger or more complex environment gets scoped individually. Availability and Confidentiality controls are added when your customer contracts commit you to them.

How to score yourself

Mark each control Pass, Partial, Fail, or N/A. Then count the fails, and separately count the fails that require your engineers to change something inside the application (rather than something we can deploy alongside it). That second number is the one that drives your timeline.

Profile	Fails	What it means
Clean	8 or fewer, at most 2 needing application changes	Standard timeline. Most of the work is deployment and documentation
Typical	9 to 16, at most 4 needing application changes	Standard timeline, more ticket-and-verify cycles with your engineers
Complex	17 or more, or 5+ needing application changes, or no infrastructure-as-code at all	Scoped individually. A phased approach is usually cheaper than forcing one window

Two findings override the count entirely: encryption-at-rest retrofits of existing production data stores, and AWS account restructures. Either one is a project with a maintenance window, and any honest provider re-scopes rather than absorbing it into a fixed price.

A. Governance and policies

The group founders most want to skip and auditors examine first. None of it is technical, and all of it is evidence a CPA can test directly.

ID	Control	Criteria	How it's satisfied	Evidence
A1	Information security policy suite approved and published	CC1.1 to CC1.4, CC5.3	20+ policies written to how your team actually operates, approved by leadership, acknowledged by staff	Approved policies with version history, acknowledgement records
A2	Annual risk assessment performed and documented	CC3.1 to CC3.4	Facilitated session producing a risk register with treatment decisions	Risk register, documented treatment decisions
A3	Security awareness training at onboarding and annually	CC1.4, CC2.2	Training platform or a slide and quiz kit with automated reminders	Completion records for every employee
A4	Vendor management program and vendor register	CC9.2	Register of vendors with data access, review checklist, subprocessor tracking	Vendor register, vendor review records
A5	Background checks for new hires	CC1.4	Screening provider plus policy language covering scope and exceptions	Check confirmations per hire
A6	Leadership security oversight cadence	CC1.2, CC4.1	Quarterly security review with a standing agenda. No board is not a gap; oversight sits with whoever actually holds it	Meeting notes showing security topics discussed

B. Identity and access management

Where the most audit exceptions come from, and where the fixes take longest because application code depends on them.

ID	Control	Criteria	How it's satisfied	Evidence
B1	Centralized identity and SSO for core systems	CC6.1	Google Workspace, Okta, or equivalent as the identity provider, with applications federated to it	SSO configuration, application inventory showing coverage
B2	MFA enforced on the identity provider, AWS, and GitHub	CC6.1	Enforcement at the identity provider, plus AWS and source control settings. Not "encouraged", enforced	Enforcement settings, coverage report showing zero exempt users
B3	AWS IAM least privilege: no root use, password policy, no wildcard admin sprawl	CC6.1 to CC6.3	CloudFormation IAM baseline plus IAM Access Analyzer. Application-wired roles are tightened by your engineers from our findings	IAM credential report, policy diffs, Access Analyzer findings
B4	Quarterly access reviews across AWS, source control, and core SaaS	CC6.2 to CC6.3	Auto-generated access inventory plus a review workflow with reminders	Signed review records for every quarter in the window
B5	Offboarding within one business day	CC6.2	Offboarding checklist plus a deprovisioning script covering every system in the inventory	Offboarding tickets with timestamps proving the SLA was met
B6	Secrets management: no secrets in code, managed store in use	CC6.1	AWS Secrets Manager or SSM Parameter Store, plus repository scanning. Existing secrets rotated and migrated	Scan results, secret store inventory

B4 is the control most often failed retroactively. A quarterly review is easy to write into a policy and impossible to backfill: a Type 2 auditor will ask for the records covering every quarter of the observation window. If you write "quarterly", run it quarterly starting the day the window opens.

C. AWS infrastructure and monitoring

The largest group and the most automatable. Almost all of it deploys as CloudFormation in an afternoon; the exceptions are marked.

ID	Control	Criteria	How it's satisfied	Evidence
C1	Organization-wide CloudTrail to a central log archive	CC7.2	AWS Organizations trail delivering to a dedicated log archive account with S3 Object Lock	Trail configuration, log samples showing delivery
C2	GuardDuty enabled in all accounts and regions with a delegated administrator	CC7.2 to CC7.3	Delegated admin in the security account, auto-enable for new accounts	GuardDuty settings, findings workflow
C3	AWS Config with conformance rules	CC7.1	Config recorder in every region plus a curated rule set. A recorder with zero rules will not survive auditor scrutiny	Config dashboard, rule compliance summary
C4	S3 account-level public access block and default encryption	CC6.6	Account-level Block Public Access, plus remediation of any bucket-level exception	Account settings, full bucket inventory
C5	Encryption at rest by default for EBS, RDS, and S3	CC6.6	Account defaults set by template. Existing unencrypted resources need a migration, which is a maintenance window, not a setting	Encryption inventory across all resource types
C6	Encryption in transit on public endpoints	CC6.6 to CC6.7	TLS policy on load balancers and CloudFront. Application endpoints fixed by your engineers where needed	Scan results, load balancer and CloudFront configurations
C7	VPC flow logs on production VPCs	CC7.2	CloudFormation, delivering to the central archive with a defined retention period	Flow log configurations
C8	Centralized security alerting	CC7.2 to CC7.3	EventBridge routing GuardDuty, Config, and CloudWatch alarms to Slack or PagerDuty	Alert configuration, sample alerts with the responses to them
C9	Automated backups plus at least one documented restore test	CC7.5	AWS Backup plans by tag, plus a restore test you actually run. The test is the part that gets skipped	Backup configurations, restore test record with date and outcome
C10	Vulnerability management: Inspector, image scanning, patch cadence	CC7.1	Amazon Inspector and ECR scanning enabled, plus a triage workflow with a cadence you can meet	Scan reports, remediation records showing the cadence held
C11	Security group hygiene: no 0.0.0.0/0 on management ports	CC6.6	Scanner plus optional auto-remediation, and a documented exception register for the rules you keep	Security group audit report, exception register
C12	Production and development environment separation	CC8.1, CC6.6	Architecture work. Separate accounts or at minimum separate VPCs with distinct credentials. Not a template	Account and VPC structure documentation

D. Software development lifecycle

Auditors test change management by sampling actual production changes. If your process is real, this group is nearly free.

ID	Control	Criteria	How it's satisfied	Evidence
D1	Branch protection and required review on production repositories	CC8.1	Repository rulesets applied across every production repo, including the ones nobody remembers	Branch protection settings, sample pull requests showing review
D2	CI/CD-only deploys to production	CC8.1	Deploy credentials removed from humans; the pipeline is the only path	Pipeline configuration, deploy logs
D3	Dependency and static analysis scanning in CI	CC7.1, CC8.1	Dependabot or equivalent plus a static analyzer, wired into the pipeline	Scanner configuration, sample results with triage
D4	Documented change management process	CC8.1	A lightweight written policy that matches your real pull request workflow. Write what you do	Policy plus sample change records that match it

E. Endpoints and people operations

ID	Control	Criteria	How it's satisfied	Evidence
E1	Device management: disk encryption, screen lock, updates	CC6.7 to CC6.8	A lightweight MDM enrolling every laptop that touches production or customer data	Device compliance report showing full enrollment
E2	Onboarding checklist covering access, training, and policy acknowledgement	CC6.2, CC1.4	Checklist in your HR or task tooling, completed per hire	Completed checklists for every hire in the window
E3	Acceptable use and endpoint policy acknowledged by all staff	CC1.4	Policy plus an acknowledgement workflow, including contractors with access	Acknowledgement records, complete against the personnel list

F. Operations and incident response

ID	Control	Criteria	How it's satisfied	Evidence
F1	Incident response plan with roles and severity levels	CC7.3 to CC7.4	A plan written to your actual stack and on-call setup, not a generic template	Approved plan with version history
F2	Annual incident response tabletop exercise	CC7.5	A scenario walkthrough with the people who would actually respond	Exercise notes and the follow-up actions from them
F3	Incident tracking and postmortem process	CC7.4 to CC7.5	Ticket template and postmortem document, used for real incidents	Incident records, or a documented attestation of none in the period
F4	Uptime and operations monitoring on production services	CC7.2	CloudWatch dashboards and alarms on the services that matter	Dashboards, alert history showing the alarms fire

Availability and Confidentiality, when they apply

The 35 controls above cover Security, the Common Criteria that every SOC 2 report contains. Availability and Confidentiality bring additional criteria and about ten more controls, mostly around uptime commitments, capacity, replication, and the retention and disposal of confidential data.

The trigger is contractual, not technical. If your MSA carries an uptime SLA, you are already committed on Availability. If your DPA or MSA carries confidentiality obligations, the same applies to Confidentiality. We read the commitments you have actually signed during the gap assessment and scope in what they require, at no change in price. Privacy and Processing Integrity stay out of scope; they are separate programs.

One caution worth stating plainly: replication and retention retrofits of existing data stores are genuine engineering projects. Scoping Availability in because a contract requires it is routine. Discovering mid-engagement that meeting it needs a new replication architecture is a re-scope.

What can be automated and what can't

Category	Controls	Who does it
Deployable as infrastructure-as-code	C1, C2, C3, C4, C7, C8, C9, F4, plus baselines for B3 and B6	A CloudFormation stack deployed alongside your infrastructure, in its own state, owned by you
Scriptable with admin access to your SaaS	B1, B2, D1, D2, D3, E1	Configuration in your identity provider, source control, and device management
Process scaffolding	A1 to A6, B4, B5, E2, E3, F1, F2, F3	Templates, runbooks, and reminders we build; your team operates them. This is where Type 2 evidence is won or lost
Application-level, your engineers only	Parts of B3, B6, C5, C6, C10, C11, and all of C12	Exact-fix tickets to your team, verified by rescan. Nobody outside your team should be changing your application

That split is the whole basis of a fixed price. The first two categories are predictable. The third is predictable if someone owns the calendar. The fourth is where estimates go wrong, which is why no honest quote arrives before the environment has been scanned.

Frequently asked questions

How many controls are required for SOC 2?

None specifically. The AICPA publishes criteria, not controls, and every company designs its own. Thirty-five is what a 5 to 100 person AWS-native SaaS company typically needs to cover the Security category in a way an auditor will accept. A company with a smaller footprint may need fewer; a company with a complex estate will need more.

Which SOC 2 controls can be automated on AWS?

Roughly 70 to 80% of the technical remediation deploys as CloudFormation: organization CloudTrail, GuardDuty, AWS Config, S3 public access block, encryption defaults, VPC flow logs, EventBridge alert routing, AWS Backup, and Amazon Inspector. What cannot be automated: IAM least privilege on application-wired roles, encryption retrofits of existing stores, environment separation, and every process control a human has to run on a schedule.

What evidence does a SOC 2 auditor ask for on AWS?

Configuration exports and screenshots for technical controls, plus records proving the process controls ran. The second half is what teams underestimate: signed access reviews, offboarding tickets with timestamps, training completion records, approved policies with version history, restore test records, incident postmortems. A Type 2 needs all of it covering the entire observation window. The evidence checklist walks through a real request list item by item.

Can we just buy a compliance platform and follow its checklist?

You can, and many teams do. The platform will show you which of these controls are failing and give you policy templates. It will not tighten an IAM policy your application depends on, restructure your accounts, or run your quarterly access review. That remaining work is the reason most first-audit teams end up hiring engineering help anyway. More on the split in platform vs engineer.

Get this scored against your actual environment

The $2,500 gap assessment runs a read-only scan across all 35 controls, adds the process interview the scan cannot do, and returns a prioritized gap report with a fixed readiness quote. Credited in full toward the engagement; the report is yours either way.

Book a 30-minute scoping call

Read-only access, external-ID protected, revocable by you at any time.