SOC 2 on AWS: a technical checklist for startups

Not audit advice. Only a licensed CPA firm can issue a SOC 2 report, and your auditor decides what evidence satisfies each control. This post covers the engineering side: what to build on AWS so the audit goes smoothly.

SOC 2 is an attestation report, not a certificate. An independent CPA firm examines your controls against the AICPA's Trust Services Criteria and writes an opinion on them. For a startup selling to larger companies, that report is what turns a 200-question security questionnaire into "here is our SOC 2, plus a few follow-ups".

Most of the controls an auditor tests are organisational: policies, onboarding, background checks, risk assessments. But a large share live in your cloud account, and those are the ones engineers end up owning. This is the checklist we use for them on AWS.

SOC 2 in two minutes: Type I, Type II and the criteria

A Type I report says your controls are suitably designed at a single point in time. A Type II report says they were designed well and actually operated effectively over a period, which the auditor tests by sampling evidence across that window.

Customers usually want Type II, because it shows the controls work in practice rather than on paper. Many startups do a Type I first to get something in front of buyers, then start the Type II observation period. The length of that period is agreed with your auditor; first reports often use a shorter window than later ones.

The criteria come from the AICPA's 2017 Trust Services Criteria (with points of focus revised in 2022), which cover five categories:

• Security (the "common criteria"): required in every SOC 2 report.
• Availability: uptime, capacity, backups and recovery.
• Processing integrity: processing is complete, accurate and timely.
• Confidentiality: information designated confidential is protected.
• Privacy: personal information is handled according to your commitments.

Most startups start with Security alone, or Security plus Availability, and add categories when customers ask. One thing to watch: in October 2026 the AICPA published an exposure draft of updated 2027 criteria. It is a proposal open for comment, not yet in force, so build against the current criteria and ask your auditor when the change would affect you.

Shared responsibility: AWS's SOC report is not yours

AWS has its own SOC 2 report, but it covers AWS's controls, not your configuration. Your auditor will test how you set up and run your accounts.

AWS describes this split in its shared responsibility model: AWS secures the infrastructure ("security of the cloud"), you secure what you build on it ("security in the cloud"). Physical data-centre controls are fully inherited from AWS. Patching, configuration management and training are shared. Your IAM policies, your S3 bucket settings and your application are entirely yours.

In practice, your auditor will usually treat AWS as a subservice organisation and exclude its controls from your report, relying on AWS's own report instead. You can download AWS's SOC 1 and SOC 2 reports from AWS Artifact under NDA; keep a copy in your vendor folder, because the auditor will ask how you reviewed it. AWS's report also lists controls it expects customers to operate. Read that list; it is a useful sanity check against this one.

The technical controls, mapped to AWS

Each item below maps to one or more common criteria. Your auditor's control list will be worded differently, but these are the things they will ask to see.

1. Account structure and guardrails: AWS Organizations and SCPs

Separate production from everything else, and make the security baseline impossible to switch off. Use AWS Organizations with at least a management account, a log-archive account, a security account and separate workload accounts for production and non-production. We covered the layout in AWS Organizations from day one.

Then attach service control policies that stop anyone, including account admins, from disabling the controls your auditor relies on:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectSecurityBaseline",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "cloudtrail:UpdateTrail",
        "config:StopConfigurationRecorder",
        "config:DeleteConfigurationRecorder",
        "config:DeleteDeliveryChannel",
        "guardduty:DeleteDetector",
        "guardduty:DisassociateFromAdministratorAccount",
        "securityhub:DisableSecurityHub",
        "organizations:LeaveOrganization"
      ],
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:role/SecurityBreakGlass"
        }
      }
    }
  ]
}

SCPs don't apply to the management account, so keep workloads out of it and lock it down separately.

2. Identity: IAM Identity Center with MFA

Give each person exactly one identity, with MFA enforced. Connect IAM Identity Center to your identity provider (Google Workspace, Entra ID, Okta), assign permission sets per account, and remove IAM users with long-lived access keys. Our IAM Identity Center setup guide walks through it.

• Root user on every account: hardware MFA, no access keys, credentials stored offline.
• Quarterly access reviews: export who has which permission set, have a manager sign off, keep the record.
• Offboarding: disabling someone in the identity provider removes AWS access the same day. Auditors sample leavers and check the timestamps.
• CI/CD uses OIDC roles instead of stored keys; see GitHub Actions to AWS with OIDC.

3. Audit logging: CloudTrail across the organisation

One organisation trail, all regions, delivered to the log-archive account, with log file validation on. That gives you a tamper-evident record of every API call, which is what the auditor and any incident investigation will need.

resource "aws_cloudtrail" "org" {
  name                          = "org-trail"
  s3_bucket_name                = aws_s3_bucket.cloudtrail.id
  is_organization_trail         = true
  is_multi_region_trail         = true
  include_global_service_events = true
  enable_log_file_validation    = true
  kms_key_id                    = aws_kms_key.cloudtrail.arn
}

Put S3 Object Lock or a restrictive bucket policy on the log bucket so nobody in a workload account can delete history. Set a retention period that matches your policy, and if you handle EU personal data, keep logs in EU regions as described in our GDPR logging guide.

4. Configuration monitoring: AWS Config and Security Hub

Auditors want proof that misconfigurations are detected and fixed, continuously. AWS Config records resource configuration history; Security Hub CSPM with the AWS Foundational Security Best Practices standard checks it against a recognised baseline and scores each account. Enable both organisation-wide from the security account, with a delegated administrator.

The newer AWS Security Hub, generally available since December 2025, sits on top and correlates findings from Security Hub CSPM, GuardDuty and Inspector. Either way, the control is the same: findings get triaged, assigned and closed, and you can show the trend.

5. Threat detection: GuardDuty

Enable GuardDuty in every account and every region you use, managed from the security account, with auto-enable for new accounts. Route high-severity findings to the same place your on-call alerts go. An auditor will pick a finding and ask who looked at it and when.

6. Encryption: KMS at rest, TLS in transit

• Turn on EBS encryption by default in every region and account.
• Encrypt RDS, S3, DynamoDB and backups with KMS keys. Customer-managed keys let you separate who can use a key from who can administer it.
• TLS everywhere: ACM certificates on load balancers and CloudFront, and a bucket policy that denies non-TLS requests.
• S3 Block Public Access at account level, so public buckets need a deliberate exception.

7. Backups and restore tests

Backups are an Availability control, and auditors increasingly ask for proof of restores, not just backup jobs. Use AWS Backup plans with copies to a separate account, and AWS Backup restore testing to restore on a schedule automatically. Write down how long the restore took and compare it with the recovery time you promise customers.

8. Change management: pull requests and infrastructure as code

The SOC 2 change-management control is easiest to prove when every change goes through Git. Application and infrastructure changes are made by pull request, reviewed by someone other than the author, tested in CI and deployed by a pipeline, not from a laptop.

• Branch protection on the main branch: required review, required status checks, no force pushes.
• Terraform for all infrastructure, with state organised per environment (see how we organise Terraform state).
• Console write access in production limited to a break-glass role, with its use alerted.
• Emergency changes allowed, but reviewed after the fact and linked to the incident.

The audit evidence is then just the merged pull requests for a sample of deployments, which Git already keeps.

9. Vulnerability management: Inspector plus dependency scanning

Amazon Inspector continuously scans EC2 instances, ECR container images and Lambda functions for known vulnerabilities and network exposure. Add dependency scanning in CI (Dependabot or similar) for your application code. Then write a policy with remediation deadlines by severity and make overdue findings visible. The deadline numbers are yours to set; what the auditor tests is that you meet them.

10. Logging, alerting and incident response

Centralised application logs with a defined retention, alerts that reach a human, and a written incident process that you have actually used. If you don't have one yet, start from our incident response runbook template. Keep a log of incidents and postmortems even when they are small; an empty incident log for a whole year looks less credible than a few well-handled minor ones.

11. Vendor management

List every supplier that touches customer data or production (AWS, your CI provider, error tracking, email, payments), what data each holds, and their own SOC 2 or ISO 27001 report. Review the list yearly. This is mostly a spreadsheet, but it is a control, and it is tested.

Control-to-evidence map

Collect evidence as a side effect of how you work, not in a panic before the audit window closes.

Where compliance automation tools fit

Tools such as Vanta, Drata and Secureframe connect to AWS, your identity provider and Git through read-only access, run continuous checks, and package the evidence for your auditor. They also provide policy templates and track the people side: training, background checks, laptop encryption.

They save real time on evidence collection, and in our experience they are worth it for most startups going for a first Type II. What they don't do is fix anything. A dashboard full of red checks still needs someone to restructure accounts, write the SCPs and set up the backup plans. Pick the tool for its integrations with your stack and your auditor, then do the engineering work above.

If you were planning to use AWS Audit Manager: AWS closed it to new customers on 30 April 2026 and points people to AWS Config conformance packs instead. The same page notes there is no Config conformance pack equivalent to its SOC 2 framework, so plan on Security Hub CSPM, Config rules and either a third-party tool or your own evidence exports.

Reuse the work for NIS2 and GDPR

Most of these controls overlap with other frameworks. If you also sell into regulated EU sectors, our NIS2 checklist for AWS maps the same building blocks to Article 21, and adds what SOC 2 doesn't cover, like the 24 and 72-hour incident reporting deadlines.

A sensible order of work

1. Decide scope with your auditor: which systems and which criteria.
2. Fix identity first: Identity Center, MFA, no long-lived keys.
3. Turn on the organisation-wide baseline: CloudTrail, Config, Security Hub CSPM, GuardDuty, Inspector, protected by SCPs.
4. Move all changes to pull requests and Terraform.
5. Set up backup plans and the first restore test.
6. Write the policies, connect your evidence tool, and start the observation window.

If you want an outside view of where your AWS estate stands before the auditor gives you one, a cloud audit maps your accounts against these controls and gives you a prioritised gap list. And if nobody on the team has time to own the baseline after that, our managed DevOps service keeps it running and the evidence flowing through the audit window.

Frequently asked questions

What is the difference between SOC 2 Type I and Type II?

A Type I report assesses whether your controls are suitably designed at a single point in time. A Type II report also tests whether they operated effectively over a period, with the auditor sampling evidence across that window. Most enterprise customers ask for Type II; many startups do a Type I first to have something to share sooner.

Does hosting on AWS make us SOC 2 compliant?

No. AWS's SOC 2 report covers AWS's own controls, such as physical data-centre security. Your auditor tests how you configure and operate your accounts: identity and MFA, logging, encryption, backups, change management and vulnerability handling. You can download AWS's report from AWS Artifact to support your vendor review, but it doesn't replace your controls.

Which AWS services do we need for SOC 2?

There is no mandatory list, but a typical baseline is AWS Organizations with SCPs, IAM Identity Center with MFA, an organisation-wide CloudTrail trail, AWS Config, Security Hub CSPM, GuardDuty, Amazon Inspector, KMS encryption and AWS Backup with restore testing. Combined with pull-request-based change management, these cover most cloud-side controls auditors test.

Do we need Vanta or Drata for SOC 2?

Not strictly. You can pass a SOC 2 audit with spreadsheets and manual exports. Compliance automation tools save time by collecting evidence continuously and providing policy templates, which helps most for a first Type II. They don't fix configuration, though, so you still need someone to build the controls in AWS.