According to Drata's 2025 State of GRC report, 84% of organizations report that customers request proof of compliance during the sales process. For SaaS companies and businesses handling sensitive customer data, SOC 2 has become the standard that enterprise buyers expect before signing contracts. The problem is that many teams assume running workloads on AWS means compliance is partially inherited. It isn't—at least not the parts that auditors care most about.
This guide covers exactly what you're responsible for, which AWS services to configure, and the five steps to go from current state to audit-ready.
Key Takeaways
- AWS secures the underlying infrastructure; you own IAM, encryption, logging, and application controls.
- SOC 2 has five Trust Service Criteria—Security is mandatory, the rest depend on your business.
- Type 1 assesses control design at a point in time; Type 2 tests effectiveness over 6–12 months.
- Core AWS services needed: IAM, CloudTrail, KMS, AWS Config, CloudWatch, Security Hub, and GuardDuty.
- Start your observation period only after all controls are live—gaps found mid-audit become findings.
SOC 2 and AWS: Understanding the Shared Responsibility Model
What SOC 2 Actually Evaluates
The AICPA defines SOC 2 as an examination of service organization controls across five Trust Service Criteria:
- Security (mandatory for all SOC 2 reports)
- Availability
- Processing Integrity
- Confidentiality
- Privacy
You choose which criteria apply based on your customers' requirements and your business risk profile. A healthcare SaaS company will typically include Security, Availability, and Confidentiality. A payment processor might add Processing Integrity.
Type 1 vs. Type 2: A Type 1 report assesses whether your controls are properly designed at a specific point in time. A Type 2 report adds operating effectiveness—auditors evaluate whether those controls actually worked consistently over a 6–12 month observation period. Most enterprise customers require Type 2.
Where AWS's Responsibility Ends
AWS's Shared Responsibility Model divides security into two distinct domains:
- AWS is responsible for security of the cloud: physical data centers, hardware, hypervisors, and the global network infrastructure.
- You are responsible for security in the cloud: data classification, IAM configuration, OS patching, network rules, encryption settings, and application security.
The "Carve-Out" Concept
AWS has its own SOC 2 report, available through AWS Artifact. This does not cover your application or data practices—it only demonstrates that AWS's infrastructure meets SOC 2 criteria.
In your SOC 2 report, AWS controls are "carved out" as a subservice organization. Your auditor will want to see AWS's SOC 2 report as evidence that the underlying infrastructure is controlled, but your report covers only what you operate directly.
In practice, this split means:
- AWS handles: physical security, hardware, and network infrastructure controls
- You handle: access management, encryption configuration, audit logging, and application-layer security
How to Achieve SOC 2 Compliance on AWS
Step 1: Define Scope and Select Your Trust Service Criteria
Before touching a single AWS service, decide what you're actually being audited on.
Factors to evaluate:
- Customer contract requirements (what are enterprise buyers specifically asking for?)
- Industry regulations (HIPAA for healthcare, financial regulations for fintech)
- Data types you handle (PHI, PII, financial records)
- Your current risk profile and where your controls are weakest
Start with Security only. Add Availability, Confidentiality, or Privacy when customers or regulations require it. Including all five criteria from day one can double audit complexity, cost, and timeline without proportional benefit for most companies.
Also decide on Type 1 vs. Type 2. Startups pursuing their first SOC 2 often use Type 1 as a faster initial step (typically achievable in 2–4 months), then move to Type 2 for enterprise customers who require demonstrated operating effectiveness.
Step 2: Conduct a Gap Assessment Against SOC 2 Controls
Map your current AWS configuration against each applicable Trust Service Criterion. You need to identify three categories:
- Controls already fully implemented (S3 encryption, MFA enforcement)
- Controls partially in place (CloudTrail enabled but not in all regions)
- Controls missing entirely (no formal incident response procedure)
Practical starting points:
- AWS Audit Manager includes a prebuilt SSAE-18 SOC 2 framework that maps controls to AWS resource evidence—check current availability for your account type
- AWS Security Hub's Foundational Security Best Practices (FSBP) standard continuously evaluates your environment against security controls and surfaces misconfigurations
Cloudtech's AWS Security Review (typically 2–3 weeks) delivers a compliance gap analysis covering SOC 2, HIPAA, and GDPR, plus a prioritized remediation roadmap — giving you a clear picture of what needs fixing before your observation period opens.
Step 3: Implement the Required AWS Security Controls
Most of the hands-on configuration work happens here. Get these controls in place before your observation period starts — any gap discovered during that window becomes an audit finding.
Identity and Access Management:
- Enforce least-privilege IAM policies; audit role permissions regularly
- Mandate MFA for all users, especially administrators
- Deploy IAM Identity Center for centralized access management
- Use IAM Access Analyzer to surface over-permissive policies
- Implement AWS Systems Manager Session Manager for auditable EC2 access (eliminates bastion hosts and their associated access risks)
- Enable AWS Organizations with Service Control Policies (SCPs) to prevent high-risk actions like disabling encryption or removing MFA across accounts
Encryption at Rest and In Transit:
- Use AWS KMS with customer-managed keys for S3, RDS, and EBS
- Configure S3 bucket policies to reject unencrypted uploads
- Enforce SSL/TLS via AWS Certificate Manager
- Establish regular key rotation schedules using KMS automated rotation
Network Security:
- Configure VPC with private subnets, security groups, and NACLs
- Enable VPC Flow Logs for traffic visibility
- Deploy AWS WAF for web application protection
Cloudtech's Cloud Foundation package ($5,000 fixed price) pre-configures IAM baselines, VPC setup, AWS Control Tower governance guardrails, and encryption defaults covering SOC 2, HIPAA, and GDPR alignment. For teams starting from scratch, it compresses weeks of setup into a single structured engagement.
Step 4: Enable Continuous Monitoring and Automate Evidence Collection
SOC 2 Type 2 auditors don't just want to see controls configured ; they want evidence those controls operated continuously throughout the observation period.
Core monitoring stack:
- AWS CloudTrail: Enable multi-region trails with S3 log storage, CloudWatch Logs delivery, and log file integrity validation. Integrity validation proves logs weren't modified after delivery, which is a direct auditor requirement.
- AWS Config: Deploy conformance packs with rules that automatically flag deviations (public S3 buckets, unencrypted EBS volumes). Configure remediation actions for critical violations.
- Amazon CloudWatch: Set up alarms for anomalies such as unusual login patterns, unauthorized IAM changes, and failed decryption attempts. Pair with Lambda for automated remediation.
- Amazon GuardDuty: Activates ML-based threat detection across your AWS accounts, identifying port scanning, credential compromise attempts, and data exfiltration patterns.
- AWS Security Hub: Centralizes findings from GuardDuty, Config, Inspector, and Macie into a single compliance dashboard.
Cloudtech integrates AWS Audit Manager into this stack to automate evidence collection and generate audit-ready reports throughout the observation period. Evidence is available on demand, not assembled in a scramble the week before your auditor arrives.
Step 5: Engage Your CPA Auditor and Prepare for the Audit
With monitoring in place and evidence collecting automatically, the next step is selecting an accredited CPA firm for the examination. Before the observation period starts, prepare:
- System Description: A written narrative covering your environment, data flows, control design, and the boundaries of what's in scope
- AWS Artifact download: Pull AWS's own SOC 2 report to provide to your auditor as evidence of subservice organization controls (requires agreeing to an NDA in the Artifact console)
- Evidence folders: Organize CloudTrail logs, Config compliance reports, CloudWatch alarm histories, and Security Hub findings by control category for auditor review
For Type 2, confirm your observation period start date once the clock starts, any gap discovered during that window becomes an audit finding.
Key AWS Services That Map to SOC 2 Trust Service Criteria
| SOC 2 Area | Primary AWS Services |
|---|---|
| Identity & Access (Security) | IAM, IAM Identity Center, IAM Access Analyzer, AWS Organizations + SCPs |
| Audit Logging (Security) | CloudTrail (multi-region, integrity validation), CloudWatch Logs |
| Threat Detection (Security + Availability) | GuardDuty, Security Hub, Amazon Detective |
| Configuration Compliance (Security) | AWS Config, conformance packs, AWS Control Tower |
| Encryption (Confidentiality + Privacy) | AWS KMS, AWS Certificate Manager, S3 bucket policies |
| Sensitive Data Discovery (Confidentiality) | Amazon Macie |
| Backup & Recovery (Availability) | AWS Backup, cross-region replication |
| Administrative Access Evidence (Security) | Systems Manager Session Manager |
Having these services available is only half the work — correct configuration before the observation period begins is what auditors actually evaluate. Cloudtech's AWS landing zone is built to satisfy these requirements from day one:
- Enables Security Hub and GuardDuty across all accounts and regions by default
- Centralizes CloudTrail logs to a dedicated Log Archive account with Object Lock enabled
- Applies SCPs as preventive guardrails at the AWS Organizations level
Common Mistakes to Avoid When Pursuing SOC 2 Compliance on AWS
Several missteps consistently derail SOC 2 engagements on AWS — most of them avoidable with a bit of upfront planning.
Assuming AWS's SOC 2 report covers your application. This is the most common and costly misconception. AWS's report covers only the underlying infrastructure. Your application-layer controls, IAM configurations, and data handling practices require a separate audit engagement entirely.
Opening the observation period before controls are in place. For Type 2, the clock starts immediately. Control gaps during the observation window become audit findings, which delay your report and can force remediation mid-audit. Run your gap assessment and fix everything before the observation period opens.
Treating compliance as a one-time project. SOC 2 Type 2 reports are valid for one year, so re-audit is annual. Letting quarterly access reviews slip, losing CloudTrail logging integrity, or allowing incident response procedures to go stale will surface as failed control tests in your next cycle.
Over-scoping from day one. Start with the Security TSC — it's mandatory. Add Availability, Confidentiality, Processing Integrity, or Privacy only when customers or regulations specifically require them. Including all five criteria unnecessarily inflates audit complexity, cost, and timeline.
Frequently Asked Questions
How do I get AWS's SOC 2 report?
AWS's SOC 2 report is available through AWS Artifact, a self-service compliance portal accessible from the AWS Management Console. You must agree to an NDA before downloading SOC 1 or SOC 2 reports. The SOC 3 (a public summary of the SOC 2) is available without an NDA.
What does a SOC 2 Type 2 checklist include?
A Type 2 checklist covers the five Trust Service Criteria (Security mandatory), requires documented implementation and continuous operation of controls over a 6–12 month observation period, and includes evidence such as access logs, encryption configurations, incident response records, and vendor monitoring documentation.
Is SOC 2 compliance legally required?
SOC 2 is not mandated by U.S. federal law, but enterprise customers, procurement teams, and regulated industries like healthcare and financial services routinely require it contractually. For SaaS companies handling sensitive customer data, it has become a de facto standard for closing enterprise deals.
How long does SOC 2 compliance take on AWS?
A SOC 2 Type 1 typically takes 2–4 months from readiness assessment to final report. Type 2 requires an additional 6–12 month observation period after controls are in place. An experienced AWS partner can cut the readiness phase to as little as a few weeks.
Does AWS's SOC 2 certification cover my application?
No. AWS's SOC 2 report covers only the infrastructure AWS manages—physical security, networking, and the hypervisor layer. Your application, data handling practices, IAM configuration, and operating procedures are carved out and require your own separate SOC 2 engagement with a licensed CPA firm.
Which AWS services are required for SOC 2?
The core stack includes:
- AWS IAM — access control
- AWS CloudTrail — audit logging
- AWS Config — configuration compliance
- Amazon CloudWatch — monitoring and alerting
- AWS KMS — encryption key management
- AWS Security Hub or Amazon GuardDuty — threat detection and centralized findings
