Preparing a SOC2 audit on AWS without slowing your team down

The classic scenario: sales closes a US mid-market account, the contract requires a SOC2 report within 6 months, and the engineering team learns the news on a Monday morning. Three months later, the product roadmap is frozen, the team is exhausted, and the report still isn’t ready.

This article walks through the sequence we apply on Distribuée engagements to pass a SOC2 audit on AWS without freezing the roadmap — i.e., working alongside the product team, not in their place.

Scope, in two sentences

SOC2 (Service Organization Control 2) is a US framework run by the AICPA. It evaluates five Trust Service Criteria:

• Security (CC): mandatory, the foundation
• Availability (A): recommended for most SaaS
• Confidentiality (C): if you handle B2B customer data
• Processing Integrity (PI): if you handle financial transactions
• Privacy (P): rarely scoped in Europe (GDPR already covers it)

Type 1 = point-in-time state (~1 month report). Type 2 = evidence over 6 to 12 months (longer report, more credible commercially).

90 % of the SMBs we support start with a Type 1 on Security + Availability, then chain into a Type 2 the following year.

The timeline that works

Four overlapping phases. No Big Bang, no freeze. Each phase produces a concrete deliverable for the auditor.

Phase 1 — Mapping (Day 0 to 15)

Goal: produce a precise gap analysis. For each SOC2 control, the current state + the gap to close.

Tools used:

• AWS Audit Manager: pre-wired SOC2 framework that scans your account automatically
• AWS Security Hub with the “AWS Foundational Security Best Practices” standard
• A manual checklist for everything outside AWS (HR processes, vendor contracts)

# Activate Audit Manager with the SOC2 framework
aws auditmanager register-account
aws auditmanager create-assessment \
  --name "SOC2-Type1-2026" \
  --framework-id $(aws auditmanager list-assessment-frameworks \
    --framework-type Standard \
    --query 'frameworkMetadataList[?contains(name, `SOC 2`)] | [0].id' \
    --output text) \
  --assessment-reports-destination destination=s3://distribuee-com-audit-reports \
  --scope file://scope.json \
  --roles roleArn=arn:aws:iam::ACCOUNT_ID:role/AuditManagerRole,roleType=PROCESS_OWNER

Deliverable: a Gap Analysis table with 60 to 100 rows, each classified as in place / quick win / project / not applicable.

Phase 2 — Quick wins (Day 10 to 45)

Anything that resolves in less than a week, we ship during this phase. It’s the step where you catch up on accumulated security hygiene debt.

Typical AWS quick wins:

• MFA mandatory on root and every IAM user (often partial)
• Removing long-lived IAM access keys (and migrating to IAM Identity Center)
• Organization-wide CloudTrail with log file validation
• Default encryption on every S3 bucket and EBS volume
• TLS 1.2+ everywhere (audit Load Balancers and CloudFront distributions)
• CloudWatch Logs retention explicitly configured

Phase 3 — Control automation (Day 30 to 75)

This is the technical core of the engagement. We install the stack that continuously proves controls are in place.

Concretely, on AWS:

# Activate Security Hub with the SOC2 standard
resource "aws_securityhub_account" "main" {
  enable_default_standards = true
}

resource "aws_securityhub_standards_subscription" "aws_foundational" {
  standards_arn = "arn:aws:securityhub:::standards/aws-foundational-security-best-practices/v/1.0.0"
  depends_on    = [aws_securityhub_account.main]
}

# Activate GuardDuty with malware protection
resource "aws_guardduty_detector" "main" {
  enable                       = true
  finding_publishing_frequency = "FIFTEEN_MINUTES"

  datasources {
    s3_logs { enable = true }
    malware_protection {
      scan_ec2_instance_with_findings {
        ebs_volumes { enable = true }
      }
    }
  }
}

# Typical Config rules for SOC2
resource "aws_config_config_rule" "encrypted_volumes" {
  name = "encrypted-volumes"
  source {
    owner             = "AWS"
    source_identifier = "ENCRYPTED_VOLUMES"
  }
}

resource "aws_config_config_rule" "root_account_mfa" {
  name = "root-account-mfa-enabled"
  source {
    owner             = "AWS"
    source_identifier = "ROOT_ACCOUNT_MFA_ENABLED"
  }
}

resource "aws_config_config_rule" "iam_password_policy" {
  name = "iam-password-policy"
  source {
    owner             = "AWS"
    source_identifier = "IAM_PASSWORD_POLICY"
  }
  input_parameters = jsonencode({
    RequireUppercaseCharacters = "true"
    RequireLowercaseCharacters = "true"
    RequireSymbols             = "true"
    RequireNumbers             = "true"
    MinimumPasswordLength      = "14"
    PasswordReusePrevention    = "24"
    MaxPasswordAge             = "90"
  })
}

For each of these controls, evidence is automatic: Config records configuration changes continuously, Security Hub aggregates findings, and the auditor only needs to export the reports.

Phase 4 — Internal pre-audit (Day 60 to 90)

Two weeks before the external auditor’s engagement, we run an internal pre-audit simulating the real one. Same questions, same evidence requested, same format.

It’s the safety net that catches 80 % of surprises. Anything that doesn’t hold internally won’t hold in front of the auditor.

Common traps

A few we systematically see:

Trap 1 — Fuzzy scope. “Our SaaS app” isn’t enough. The auditor wants the precise list of in-scope AWS accounts, services, data flow, impacted vendors. Document this before phase 1.

Trap 2 — Underestimating HR. SOC2 isn’t only tech. Onboarding/offboarding, background checks, security training, code of conduct: all in scope. If HR isn’t aligned, you’ll burn weeks.

Trap 3 — Critical sub-processors. Any vendor touching your customer data needs their own SOC2 report (or equivalent ISO 27001). Exhaustive list: your IdP, PaaS, monitoring solution, transactional email provider, etc.

Trap 4 — Empty incident log. SOC2 expects you to document incidents and resolutions. An empty log is suspicious. Document even small ones (false-positive GuardDuty alerts, capacity warnings).

The internal pre-audit checklist

Before launching the auditor, verify:

If everything’s green, you’re ready.

Conclusion

SOC2 is less a technical question than an organizational one. AWS controls are now largely automatable (Audit Manager, Security Hub, Config) — what takes time is establishing the discipline of continuous evidence.

The good news: once the stack is in place, the second audit (Type 2 the following year) costs 30 % of the first one’s effort. And the business benefits — deal closures, simplified acquirer due diligences — outpace the cost.

If a SOC2 audit is coming up in the next 6 months, we typically take engineering teams through phases 1 to 3, leaving phase 4 and the auditor engagement to the internal team.