SOC 2 Type II is a 6–12 month observation period. If you start building controls after the audit window opens, you're documenting a system that wasn't compliant for the first weeks of the observation period. That creates findings.
Build the SOC 2 ready AWS architecture before the clock starts. This post covers what auditors actually look at, what you need to build first, and the gaps that consistently delay readiness.
What SOC 2 Is Actually Checking
SOC 2 (Type II) auditors verify that controls were operating effectively over a defined period — typically 6 or 12 months. They're not checking that you clicked the right checkboxes. They're verifying evidence of consistent operation.
For a SaaS company on AWS, the controls that map to the Trust Service Criteria most directly:
CC6: Logical and Physical Access Controls - MFA on all human access to AWS - IAM roles with least-privilege policies (no wildcard permissions) - No long-lived access keys for production resources - VPC with private subnets for data stores - Security groups that restrict access to known sources
CC7: System Operations - GuardDuty enabled and alerts reviewed - CloudTrail enabled across all regions with integrity validation - CloudWatch alarms on key metrics (error rates, authentication failures) - Vulnerability scanning in CI/CD pipeline - Patch management process with documented evidence
CC8: Change Management - Infrastructure changes deployed via CI/CD (not manual console access) - Code review required before merge - Deployment approval process documented - Rollback capability demonstrated
CC9: Risk Mitigation - Incident response plan tested - Vendor risk assessments documented (AWS is not "auto-trusted") - Business continuity plan with RTO/RPO defined
A1: Availability - RDS Multi-AZ or equivalent redundancy - Backup and restore tested (not just enabled) - Auto-scaling configured for key services - Downtime alerting
SOC 2 Ready AWS Architecture: The Infrastructure Build
Access Control Layer
# Require MFA for console access via SCP
resource "aws_organizations_policy" "require_mfa" {
name = "require-mfa-for-console"
type = "SERVICE_CONTROL_POLICY"
content = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Deny"
Action = ["*"]
Resource = ["*"]
Condition = {
BoolIfExists = {
"aws:MultiFactorAuthPresent" = "false"
}
}
Principal = "*"
}]
})
}
# No long-lived access keys policy
resource "aws_config_config_rule" "no_access_keys_for_roles" {
name = "iam-no-inline-policy-check"
source {
owner = "AWS"
source_identifier = "IAM_NO_INLINE_POLICY_CHECK"
}
}
OIDC-federated CI/CD: No IAM users with long-lived keys for deployment. GitHub Actions, GitLab, and most CI platforms support OIDC federation with AWS. The role is assumed per-workflow, not stored as a secret.
Logging and Audit Trail
CloudTrail is table stakes. Beyond basic CloudTrail:
Multi-region CloudTrail with S3 Object Lock:
resource "aws_cloudtrail" "org_trail" {
name = "org-audit-trail"
s3_bucket_name = aws_s3_bucket.cloudtrail.id
include_global_service_events = true
is_multi_region_trail = true
enable_log_file_validation = true
is_organization_trail = true
event_selector {
read_write_type = "All"
include_management_events = true
data_resource {
type = "AWS::S3::Object"
values = ["arn:aws:s3:::prod-data-bucket/sensitive/"]
}
}
}
resource "aws_s3_bucket_object_lock_configuration" "cloudtrail" {
bucket = aws_s3_bucket.cloudtrail.id
rule {
default_retention {
mode = "GOVERNANCE"
days = 365
}
}
}
S3 Object Lock with GOVERNANCE mode means CloudTrail logs can't be deleted by accident or malice during the retention period — auditors can verify log integrity.
VPC Flow Logs: Required for network-level visibility. Store in S3 (cost-effective) with 90-day retention minimum.
Application-level audit logging: CloudTrail covers AWS API calls. Your application needs its own audit log for user actions — who logged in, what they accessed, what they changed. This is a code-level concern, not an AWS concern.
Vulnerability Management
Container scanning in CI:
# GitHub Actions snippet
- name: Scan container image
uses: aquasecurity/trivy-action@master
with:
image-ref: ${{ env.IMAGE_URI }}
severity: 'HIGH,CRITICAL'
exit-code: '1' # Fail pipeline on high/critical CVEs
Auditors want to see: scanning enabled, findings reviewed, critical/high CVEs have remediation SLAs, evidence of the process running consistently over the observation period.
AWS Inspector: Enable for EC2 and Lambda. Provides continuous vulnerability scanning with findings in Security Hub.
Security Hub: Aggregates findings from GuardDuty, Inspector, Macie, and Config. Configure a findings review process — at minimum, weekly triage of HIGH and CRITICAL findings.
Backup and Recovery Testing
Backup enabled is not sufficient — auditors want evidence of tested restores.
RDS automated backups: Enable with 7–35 day retention. Document the tested restore procedure and evidence of quarterly restore tests (CloudWatch Events → Lambda → RDS restore → validation → log to S3).
S3 versioning + cross-region replication: For critical data buckets.
Recovery runbook: Step-by-step instructions for restoring service from backup, with estimated RTO documented.
Change Management Evidence
Auditors verify that changes went through a controlled process:
- GitHub/GitLab: Required code review before merge. Branch protection rules that prevent direct pushes to main.
- CI/CD: All production deployments via pipeline. Deployment logs preserved.
- Infrastructure changes: Terraform plan reviewed and approved before apply. Terraform Cloud or similar provides audit logs of applies.
Common Gaps That Delay SOC 2 Readiness
No evidence collection automation: Auditors need evidence over 6–12 months. Collecting it manually at audit time is painful and incomplete. Automate evidence collection from day one: CloudWatch metrics to S3, Security Hub findings to a tracking system, deployment logs archived.
Personal accounts with production access: Any human with direct IAM user credentials for production (no MFA, no session constraints) is a finding. Enforce federated access (SSO, SAML) for all human access.
Untested backups: "We have backups" without a tested restore is a gap. Run a quarterly restore test and log the result.
Incident response plan that exists only as a document: Auditors ask whether it's been tested. Table-top exercises with evidence (meeting notes, outcomes, action items) satisfy this.
Vendor reviews missing: AWS is a vendor. You need documented vendor security reviews — typically using AWS's SOC 2 and ISO reports (available via AWS Artifact) as evidence.
For more on compliance-relevant architecture patterns, see our security automation capability and our article on HIPAA compliant AWS architecture. The AICPA's SOC 2 trust services criteria is the authoritative framework.
Frequently Asked Questions
How long does it take to build a SOC 2 ready AWS environment from scratch?
For a typical SaaS company starting from a basic AWS deployment: 8–14 weeks to implement all required controls, document procedures, and establish evidence collection. Then 6–12 months of observation before the Type II audit. Starting earlier gives you more time to identify gaps before the auditor does.
Do we need a SOC 2 readiness assessment before building?
A gap assessment is useful for understanding what you already have vs. what you need. For teams starting from scratch, the gap list is predictable enough that we build the standard control set and document the actual gaps found during implementation. Spending 4 weeks on assessment before building delays the observation period.
Can we achieve SOC 2 compliance without dedicated security staff?
Yes. The controls described here are infrastructure-level — GuardDuty, Config, CloudTrail, Security Hub — that run automatically once configured. The ongoing work is a weekly findings review and quarterly process reviews. An operations engineer with AWS experience can manage this alongside other responsibilities.
What's the difference between SOC 2 Type I and Type II?
Type I: a point-in-time assessment. Auditors verify that controls exist and are designed appropriately. Completed in days to weeks. Lower value to customers.
Type II: controls were operating effectively over an observation period (6–12 months). Much higher assurance. This is what enterprise customers and procurement teams actually require.
Does AWS compliance help with our SOC 2 audit?
AWS's compliance posture (AWS is SOC 2, ISO 27001, PCI certified) applies to the physical and hypervisor layer — not your applications or configurations. You're responsible for everything you build on top. AWS Artifact provides AWS's compliance reports, which satisfy the vendor review requirement.
Talk to us about your AWS architecture → rutagon.com/contact