--- title: How to Achieve SOC 2 Type II Compliance on AWS (2026 Checklist) description: SOC 2 Type II certification proves your controls are effective over 6-12 months. This guide covers the compliance roadmap, AWS security controls, documentation requirements, and audit preparation for 2026 certification. url: https://www.factualminds.com/blog/how-to-achieve-soc2-compliance-aws-2026/ datePublished: 2026-04-03T00:00:00.000Z dateModified: 2026-04-16T00:00:00.000Z author: Palaniappan P category: Security & Compliance tags: how-to-guide, soc2, compliance, security, aws, frameworks, governance --- # How to Achieve SOC 2 Type II Compliance on AWS (2026 Checklist) > SOC 2 Type II certification proves your controls are effective over 6-12 months. This guide covers the compliance roadmap, AWS security controls, documentation requirements, and audit preparation for 2026 certification. 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](/services/cloud-compliance-services/) or [talk to our team](/contact-us/). ## 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 | Stage | Cost | Timeline | | ---------------------------------------------------- | ---------------------- | -------------------- | | **Preparation** (you implement controls) | ~$0 (your time) | 3 months | | **Auditor engagement** (Type II 6-month observation) | $20-40k | 6-9 months | | **Report and remediation** | $5-10k (if gaps found) | 1-2 months | | **Year 2+ annual re-audits** | $20-40k | 6-9 months per cycle | ## 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](/contact-us/) if you need a security architect to guide implementation ## FAQ ### What is the difference between SOC 2 Type I and Type II? Type I = snapshot in time. An auditor evaluates your controls *as they exist on a specific date*, documents their effectiveness, but doesn't observe them over time. Cost: ~$5-15k, timeline: 2-4 weeks. Type II = controls operating effectively over a period. An auditor evaluates controls and observes their operation for at least 6 months (often 12 months). Cost: ~$15-40k, timeline: 6-12 months minimum. For B2B SaaS, customers demand Type II because it proves controls survived 6+ months of real operations, not just snapshot compliance. Type II is harder (you need 6+ months of logs, change history, audit trails) but much more valuable. ### Do I need to hire an auditor immediately? No. Before hiring an auditor (costs $15-40k), spend 3-6 months implementing controls: IAM policies, encryption, access logs, change management, incident response procedures. Use this checklist to "self-assess" first. Once you've implemented 80%+ of controls and have 3+ months of logs showing compliance, *then* hire a CPA firm (Big 4 or mid-market) for the formal audit. Starting the audit too early wastes money (auditor finds gaps, you fix them, auditor re-audits). Starting too late means the 6-month observation period starts now — you'll be ready in 6 months. Optimal: implement 3 months, audit 6 months, certify at month 9. ### What is the AICPA Trust Service Criteria and how does it relate to SOC 2? The AICPA Trust Service Criteria (TSC) are 7 core principles: CC (Common Criteria, ~17 items) covering security, logical access, encryption, and change management; A (Availability, ~3 items) covering uptime, disaster recovery, backup; C (Confidentiality, ~3 items) covering data classification, retention, disposal; PI (Processing Integrity, ~4 items) covering data accuracy, completeness; and PR (Privacy, ~10 items) covering data collection, consent, usage, retention. SOC 2 audits typically cover CC + A (mandatory); add C for customer data, PI for transaction systems, PR for consumer-facing apps. Most startups target CC + A + C. Your auditor will specify which criteria to include based on your service type. ### How often do I need to recertify SOC 2 after initial Type II? SOC 2 is valid for 1 year from audit completion. After that, you need a new audit. Typical cycle: Year 1 audit (covers 6-month observation period from month 3-9, report issued month 10). Year 2 audit (covers 6 months from month 12-18 of the following year). You can do continuous audits (new observation period starts immediately after the previous one ends) or annual audits (one audit per year covering the most recent 12 months). Continuous is more expensive but reduces gaps. Annual audits are standard. Budget $20-40k annually for SOC 2 Type II after initial certification. ### Is SOC 2 required to do business on AWS? No. SOC 2 is customer-driven, not a requirement from AWS. B2B SaaS companies need SOC 2 because enterprise buyers demand it (they need proof of security controls before signing contracts). B2C apps don't usually need it (individual users don't require SOC 2). However, many enterprise contracts (finance, healthcare, government) require SOC 2 as a minimum. If 50%+ of your pipeline is enterprise, pursue SOC 2. If you're pre-product or serving small businesses, deprioritize it and focus on shipping. HIPAA, PCI-DSS, and FedRAMP are more strict and required for specific industries. --- *Source: https://www.factualminds.com/blog/how-to-achieve-soc2-compliance-aws-2026/*