How to Achieve SOC 2 Type II Compliance on AWS (2026 Checklist)

SOC 2 Type II certification is the gold standard for B2B SaaS security. It demonstrates that your access controls, encryption, incident response, and change management practices are effective over a sustained period (6-12 months), not just theoretical.

This guide provides a step-by-step checklist to implement controls, track compliance, and prepare for audit.

Need Help with SOC 2? FactualMinds has guided 15+ startups through Type II certification in 6-9 months. We help with control design, AWS configuration, documentation, and audit prep. See our compliance services or talk to our team.

Step 1: Understand the Scope and Timeline

What Gets Audited?

SOC 2 audits your systems and processes that affect customer data:

• Infrastructure: EC2, RDS, S3, networks (VPCs, subnets, security groups)
• Access Control: IAM policies, MFA, SSH keys, role-based access (RBAC)
• Encryption: Data in transit (TLS), data at rest (KMS, EBS encryption)
• Logging: CloudTrail, VPC Flow Logs, application logs, access logs
• Incident Response: how you detect, investigate, and respond to security events
• Change Management: how you deploy changes to production (approval, rollback)
• Disaster Recovery: backup and recovery procedures, tested quarterly

NOT audited: your product’s business logic, feature completeness, performance.

Timeline

Realistic SOC 2 Type II timeline:

• Months 1-3: Implement controls (IAM, encryption, logging, incident response)
• Month 3: Hire auditor (they start observing now)
• Months 4-9: Auditor observes controls for 6 months, you collect evidence (logs, tickets, change history)
• Month 9-10: Auditor issues report
• Month 10+: Controls in place, report valid for 1 year

Total cost: $20-40k (auditor), ~300-400 hours (your team) for initial setup.

Step 2: Audit Preparation Checklist

Before hiring an auditor, implement these foundational controls. Use this checklist to track progress.

A. Identity and Access Management (IAM)

Basic Setup

• AWS root account: MFA enabled, access keys deleted
• All humans: IAM users with MFA enabled
• All apps: IAM roles (no access keys in code)
• Least privilege: No one has *:* permissions
• Admin users: Limited to <5 people, documented and approved
• Service accounts: Separate IAM roles per service (no shared credentials)

Documentation

• Access policy document: lists each person/service, their role, approval date, business justification
• Offboarding checklist: remove IAM user, rotate secrets, revoke SSH keys within 1 day
• Approval workflow: new access requests require manager + security sign-off

Audit Trail

• CloudTrail enabled: logs all API calls, stored in S3 (versioned, locked for 90+ days)
• CloudTrail integrity validation enabled: detect tampering
• IAM Access Analyzer: run monthly to find overly-permissive policies

B. Encryption and Key Management

Data at Rest

• RDS: encrypted with AWS KMS
• EBS volumes: encrypted with AWS KMS
• S3: default encryption enabled (KMS or SSE-S3)
• Sensitive data (PII, API keys): stored encrypted
• Database backups: encrypted, tested quarterly

Data in Transit

• All APIs: HTTPS/TLS 1.2+
• Internal services: mTLS or VPC isolation
• Database connections: TLS or VPC endpoints (not over internet)
• Backups: encrypted in transit and at rest

Key Management

• AWS KMS: separate key per service/environment
• Key rotation: enabled (automatic rotation annually)
• Key access: audit who can use each key
• No key hardcoding: use AWS Secrets Manager or Parameter Store for secrets

Documentation

• Encryption inventory: spreadsheet of what data is encrypted, which key, why
• Key rotation policy: document rotation schedule, procedure, testing

C. Logging and Monitoring

AWS CloudTrail

• CloudTrail enabled: logs API calls globally
• CloudTrail stored: S3 bucket with versioning, bucket policy locked
• CloudTrail integrity: validation enabled (detect tampering)
• CloudTrail retention: 90 days minimum (1+ years recommended)

Application Logging

• Application logs: written to CloudWatch Logs (centralized)
• Log levels: ERROR, WARN, INFO (at minimum ERROR and access logs)
• Sensitive data: NOT logged (no passwords, API keys, PII in logs)
• Log retention: 90 days minimum
• Search/alerting: CloudWatch Insights queries saved for common investigations

VPC Flow Logs

• VPC Flow Logs: enabled on all VPCs, stored in CloudWatch Logs or S3
• Retention: 90 days minimum

Detection and Alerting

• CloudWatch Alarms: for suspicious activity (multiple failed logins, policy changes, data exfiltration attempts)
• Security Hub: enabled, integration with third-party tools (Slack, email)
• GuardDuty: enabled for threat detection

Documentation

• Monitoring strategy: what events are logged, why, where stored
• Alert thresholds: how many failed logins triggers an alert, etc.
• Retention policy: how long logs are kept, why

D. Change Management

Code Deployment

• Approval workflow: all production changes require review + approval
• Audit trail: Git commits linked to Jira tickets, PR reviews documented
• Testing: staging environment matches production, changes tested before deploy
• Rollback procedure: documented, tested quarterly
• Frequency: document deployment frequency (daily, weekly, etc.)

Infrastructure Changes

• Terraform/CloudFormation: all infrastructure as code, versioned
• Code review: infrastructure changes reviewed by 2+ engineers
• Approval: infrastructure changes require security team approval
• Audit trail: who approved, when, reason documented

Database Changes

• Migration scripts: version controlled, tested in staging
• Approval: schema changes reviewed and approved
• Rollback: backwards-compatible migrations with rollback plan
• Backup before apply: automatic backup before schema changes

Documentation

• Change policy: defines what requires approval, who approves, timeline
• Change log: spreadsheet or tool logging all production changes

E. Incident Response

Detection

• Alert thresholds: defined for security events (unauthorized access, data exfiltration, etc.)
• Monitoring: active monitoring 24/7 (or on-call rotation)
• Response time: SLA for responding to incidents (e.g., <1 hour for critical)

Investigation

• Incident template: standard form for reporting (what, when, impact, root cause, remediation)
• Investigation procedure: how to gather logs, analyze, determine root cause
• Evidence preservation: logs, artifacts stored for audit trail

Remediation

• Remediation tracking: track fixes, timeline, verification
• Post-incident review: document what went wrong, preventive measures
• Communication: notify affected customers within SLA (usually 72 hours)

Documentation

• Incident log: spreadsheet of all incidents, investigation details, resolution
• Incident response plan: procedure for detecting, responding, remediating

F. Disaster Recovery and Backup

Backup Strategy

• Database backups: daily, encrypted, tested monthly
• Application backups: code stored in Git, infrastructure in Terraform
• Backup encryption: encrypted with KMS
• Backup retention: minimum 30 days

Recovery Testing

• Recovery time objective (RTO): e.g., “recover in 4 hours”
• Recovery point objective (RPO): e.g., “lose max 1 hour of data”
• Test schedule: quarterly recovery test (full restore from backup)
• Test results: documented, stored

Multi-AZ / Failover

• RDS Multi-AZ: enabled for production databases
• Load balancing: across multiple AZs
• Failover testing: quarterly test of failover, documented

Documentation

• Disaster recovery plan: RTO, RPO, recovery procedures, contact list
• Test results: when tested, what was recovered, issues found

G. Network and Physical Security

Network Isolation

• VPC: private subnets for databases and app servers
• Security groups: least privilege rules (e.g., database only accepts from app servers)
• NACLs: optional additional layer (most teams use security groups only)
• Bastion host: single point of SSH access to private resources (or SSM Session Manager)

Data Exfiltration Prevention

• VPC endpoints: CloudWatch, S3, KMS accessed via private endpoints (not internet)
• S3 bucket policies: prevent public access (even if ACLs are public)
• Database access: not internet-exposed (VPC or private endpoint only)

Physical Security

• AWS data centers: AWS handles physical security (part of their responsibility)
• Your premises: document any on-prem infrastructure (laptops with code, backups, etc.)
• Office access: badge system or visitor log (if applicable)

Documentation

• Network diagram: VPC, subnets, security groups, external connections
• Firewall rules: document each security group rule and justification

Step 3: Collect Evidence for the Audit

What Auditors Will Ask For

Access Control Evidence

• List of all IAM users, roles, policies (exported from AWS)
• MFA status for each user
• Offboarding records (people removed from IAM)
• Access request tickets (approval trail for new access)

Encryption Evidence

• List of all encrypted resources (RDS, EBS, S3)
• KMS key policies and rotation settings
• TLS certificate validity and expiration dates
• Encryption-at-rest and in-transit inventory

Logging and Monitoring Evidence

• CloudTrail logs (recent sample)
• Application logs (sample from production)
• VPC Flow Logs (sample)
• CloudWatch Alarms (list of rules and thresholds)

Change Management Evidence

• Git commit history (last 6 months)
• Pull request reviews (sample of 10 PRs with approvals)
• Deployment logs (who deployed, when, change details)
• Rollback documentation (did any rollbacks happen? document them)

Incident Response Evidence

• Incident log (all security incidents for last 6 months)
• Investigation notes (root cause, remediation, proof of fix)
• Customer notifications (if any incident affected customers)

Disaster Recovery Evidence

• Backup test results (quarterly tests documented)
• Recovery procedures (runbooks)
• Failover test results

Create a Compliance Repository

Store all evidence in one place:

compliance/
├── access-control/
│   ├── iam-users-list.csv
│   ├── access-requests.md
│   └── offboarding-checklist.md
├── encryption/
│   ├── encrypted-resources.md
│   ├── kms-policy.json
│   └── tls-certificates.md
├── logging/
│   ├── cloudtrail-policy.json
│   ├── cloudwatch-alarms.md
│   └── log-retention-policy.md
├── change-management/
│   ├── deployment-policy.md
│   └── git-commit-log.md
├── incident-response/
│   ├── incident-log.csv
│   └── incident-templates.md
└── disaster-recovery/
    ├── rto-rpo-policy.md
    └── backup-test-results.md

Step 4: Hire an Auditor and Complete Type II

Finding an Auditor

Search for “SOC 2 Type II auditor” + your region. Firms to consider:

• Big 4: Deloitte, EY, KPMG, PwC (expensive, $40-80k, but quick)
• Mid-market: CliftonLarsonAllen, CohnReznick, BPM ($20-40k, good balance)
• Boutique: smaller CPA firms specializing in startups ($15-30k, slower)

Contract and Scope

Agree on:

• Observation period: typically 6 months (can be split across 2 years)
• Criteria: CC (Common), A (Availability), C (Confidentiality), PI (Processing Integrity)?
  • Most SaaS: CC + A + C
• Report format: Attestation (formal document) or Report (for customer sharing)
• Cost: fixed fee vs. hourly? inclusive of revisions?
• Timeline: when starts, when report issued?

Audit Process

1. Entrance meeting (week 1): Auditor outlines scope, timeline, evidence needed
2. Kickoff (month 1): Auditor reviews your compliance repo, asks clarifying questions
3. Observation period (months 1-6): Auditor monitors your controls in action
   • Quarterly check-ins
   • You provide monthly evidence (deployment logs, incident records, backup tests)
4. Exit review (month 6-7): Auditor interviews key staff, reviews final evidence
5. Report issuance (month 7-10): Auditor drafts report, you review, revisions, final issue
6. Remediation (ongoing): If auditor finds gaps, you fix them and provide evidence

Cost Estimate

Step 5: Maintain Compliance Year-Round

Monthly Tasks

• Review CloudTrail logs for anomalies
• Check CloudWatch Alarms haven’t fired unexpectedly
• Verify all engineers have MFA enabled
• Run IAM Access Analyzer, remediate findings

Quarterly Tasks

• Test disaster recovery (full restore from backup)
• Review incident log, ensure all incidents documented
• Audit security groups and network policies
• Test failover (if multi-AZ)

Annual Tasks

• Re-audit with SOC 2 auditor
• Review and update policies
• Security training for all staff
• Penetration test (optional but recommended)

Avoid Common Pitfalls

1. Ignoring compliance after certification

   • Year 2 audit will ask for 12 months of evidence
   • Don’t assume “we were compliant once, we still are”

2. Logging personally identifiable information (PII)

   • Auditors will flag logs containing passwords, API keys, SSNs
   • Sanitize logs before storing

3. Underestimating the effort

   • Expect 300+ hours for initial setup
   • Budget 2-3 engineers for 3-4 months

4. Not involving security from the start

   • SOC 2 is not an IT checkbox
   • Security must be part of product decisions, not bolted on

Next Steps

1. This month: Form a security working group (eng lead, ops, product manager)
2. Month 1-3: Implement controls from the checklist above
3. Month 3: Request RFP from 3-5 auditors
4. Month 4: Auditor engagement begins
5. Month 10: Report issued, customers impressed
6. Talk to FactualMinds if you need a security architect to guide implementation