SOC 2 Compliance on AWS: A Practical 2026 Guide

Table of Contents

TL;DR:

SOC 2 compliance on AWS requires demonstrating that your account configuration controls meet auditor expectations and Trust Services Criteria. AWS’s SOC 2 report covers the infrastructure, but your team must manage controls like IAM, encryption, and logging to pass audits. Continuous monitoring and automated evidence collection help ensure control effectiveness during the entire observation period.

SOC 2 compliance on AWS is defined as demonstrating effective security controls within your AWS account configuration, separate from and in addition to the SOC 2 reports AWS publishes for its own infrastructure. The American Institute of Certified Public Accountants (AICPA) created SOC 2 as an attestation standard that evaluates organizational controls against Trust Services Criteria. AWS holds its own SOC 2 certification covering physical data centers and managed services. Your auditor, however, tests your specific account configuration. That distinction is the foundation of every successful AWS SOC 2 program.

What are the SOC 2 Trust Services Criteria for AWS?

Security is the only mandatory category in a SOC 2 evaluation. The remaining four criteria are optional, selected based on your service commitments and customer contracts. Choosing the wrong scope inflates audit cost without improving your security posture.

The five Trust Services Criteria are:

Security (Common Criteria CC1–CC9): Always required. Covers logical access, risk assessment, change management, and incident response.
Availability: Required when your SLA commits to uptime guarantees. Relevant for SaaS platforms and fintech APIs.
Confidentiality: Required when you handle confidential business data under NDA or contract terms.
Processing Integrity: Required when your system processes financial transactions or data where accuracy is contractually critical.
Privacy: Required when you collect, use, or retain personal information governed by privacy commitments.

The table below shows how each criterion maps to common AWS workload types.

Trust Services Criterion	Typical AWS Workload	Common AWS Controls Involved
Security (mandatory)	All workloads	IAM, CloudTrail, GuardDuty, KMS
Availability	SaaS, fintech APIs	Auto Scaling, Route 53, RDS Multi-AZ
Confidentiality	Data platforms, B2B SaaS	S3 encryption, VPC, KMS key policies
Processing Integrity	Payment processing	Lambda validation, audit logs, alerting
Privacy	Consumer apps, HR platforms	Data classification, retention policies

Adding optional criteria expands your audit scope and the number of controls auditors test. Select only the criteria your customer contracts or regulatory requirements demand.

How does the AWS shared responsibility model affect SOC 2 compliance?

Running this on your own AWS setup? IT-Magic is an AWS Advanced Tier Partner — we audit, fix, or fully manage it for you.

Get a free consultation

AWS’s SOC 2 report covers the security of the cloud itself: physical facilities, hypervisors, and managed service infrastructure. Your auditor tests only your AWS account configuration, not AWS’s underlying infrastructure. That boundary is the shared responsibility model in practice.

Compliance officers should treat AWS SOC 2 reports as sub-service organization documentation, cross-referencing them carefully with internal controls to clarify who owns each control. AWS proves it secures the hardware. You prove you configured the software layer correctly.

Customer responsibilities under the shared responsibility model include:

IAM policies and MFA: You configure who accesses what. AWS does not enforce least-privilege on your behalf.
Encryption at rest and in transit: AWS provides KMS and TLS. You must enable and enforce them.
CloudTrail and logging: AWS offers the service. You must activate it in every region and protect the log storage.
S3 bucket policies: AWS provides Block Public Access controls. You must apply them account-wide.
Drift detection: AWS Config can flag configuration changes. You must set up and monitor the rules.

Pro Tip: Request AWS’s current SOC 2 Type 2 report from AWS Artifact before your audit begins. Map each AWS control in that report to your own control list. Any gap you find is a finding your auditor will find first.

The most costly audit misunderstanding is assuming AWS’s SOC 2 report automatically covers your account configuration. It does not. AWS’s report is evidence for the infrastructure layer only.

What AWS configurations are critical for passing a SOC 2 audit?

Auditors focus on a predictable set of AWS controls. The most common SOC 2 audit findings on AWS are publicly accessible S3 buckets and over-permissioned IAM policies. Both are preventable with account-level settings.

The following configurations address the controls auditors test most frequently:

Enforce least-privilege IAM. Remove wildcard permissions from all IAM roles and users. Use AWS IAM Access Analyzer to identify overly broad policies. Require multi-factor authentication on every user account, including the root account.
Enable S3 Block Public Access account-wide. Apply the setting at the account level, not just per bucket. Auditors check this at the account level first.
Encrypt all data at rest with AWS KMS. Apply KMS encryption to S3, RDS, EBS, and DynamoDB. Document your key rotation policy. Auditors expect to see key rotation enabled and logged.
Enable CloudTrail in all regions with centralized, immutable storage. Store logs in a dedicated S3 bucket with Object Lock enabled. This prevents log tampering and satisfies the logging and monitoring requirements auditors check under Common Criteria CC7.
Deploy AWS Config rules for continuous drift detection. Use managed rules like iam-root-access-key-check, s3-bucket-public-read-prohibited, and encrypted-volumes. Config rules create a continuous record of compliance state.
Activate Amazon GuardDuty for threat detection. GuardDuty monitors CloudTrail, VPC Flow Logs, and DNS logs for anomalous behavior. Connect GuardDuty findings to your ticketing system so every alert has a documented response.

Pro Tip: Run the AWS Security Hub “AWS Foundational Security Best Practices” standard before your audit observation period begins. It maps directly to SOC 2 Common Criteria and surfaces misconfigurations you can fix before auditors see them.

For a broader view of AWS network security controls that support SOC 2 scope, the configuration principles extend beyond IAM and S3 to VPC design and traffic inspection.

How do you automate continuous evidence collection for SOC 2 on AWS?

Automated, continuous evidence collection is the difference between a smooth SOC 2 Type 2 audit and a scramble for screenshots. Auditors value a continuous automated record over manual point-in-time exports. The observation period for a first SOC 2 Type 2 report is typically six months, and control effectiveness must be demonstrated throughout that entire window.

AWS Audit Manager provides prebuilt SOC 2 frameworks that map AWS Config rules and CloudTrail events directly to Trust Services Criteria. This creates a live audit trail rather than a last-minute evidence collection effort. Mapping AWS Config rules and CloudTrail logs directly to Trust Services Criteria gives auditors a continuous record across the full observation period.

Key tools for continuous compliance monitoring include:

AWS Audit Manager: Prebuilt SOC 2 frameworks with automated evidence collection from Config, CloudTrail, and Security Hub.
AWS Config: Continuous configuration recording and managed rules that flag drift in real time.
AWS Security Hub: Aggregates findings from GuardDuty, Inspector, and Macie into a single compliance dashboard.
Third-party compliance platforms: Platforms that integrate with AWS APIs to collect evidence, track control owners, and generate audit-ready reports.

Continuous monitoring platforms that integrate directly with AWS services provide significant audit timeline reductions and reduce control failures by detecting configuration drifts early. The teams that pass SOC 2 Type 2 audits with minimal findings are the ones that treated compliance as an ongoing operational practice, not a pre-audit sprint.

Common pitfalls include gaps in drift detection when new AWS accounts are added to an organization without applying Config rules, and incomplete CloudTrail coverage when logging is enabled only in the primary region. Both issues surface as findings during the observation period review.

What practical steps prepare your team for a SOC 2 audit on AWS?

A structured preparation process reduces audit findings and shortens the time to your first report. The steps below apply to teams beginning their first SOC 2 Type 2 engagement as well as teams maintaining an existing program.

Conduct a readiness assessment. Map your current AWS controls to the Trust Services Criteria you have selected. Identify gaps between what you have configured and what auditors expect to see.
Implement mandatory controls first. Address IAM, MFA, encryption, CloudTrail, and S3 Block Public Access before the observation period begins. These are the controls where auditors expect comprehensive documentation across all security domains.
Set up continuous monitoring and alerting. Deploy AWS Config rules, GuardDuty, and Security Hub. Connect alerts to your incident response workflow so every finding has a documented owner and resolution.
Document Complementary User Entity Controls (CUECs). CUECs are the controls your customers must implement on their side for your service to remain secure. Document them clearly in your System Description. Using more managed AWS services, such as Lambda instead of self-managed EC2 fleets, reduces the number of CUECs you need to manage and document.
Plan your audit period and engage your auditor early. SOC 2 reports are valid for 12 months. Align your observation period start date with your auditor’s schedule. A six-month observation window is standard for a first Type 2 report.
Review and update controls after each audit cycle. AWS releases new services and deprecates old configurations regularly. Review your control set against AWS changes at least quarterly and after every major AWS re:Invent announcement.

The comparison below shows the difference between a reactive and a continuous compliance approach.

Approach	Evidence collection	Audit findings risk	Preparation time
Reactive (pre-audit sprint)	Manual screenshots, exports	High, gaps likely	6–8 weeks before audit
Continuous (automated monitoring)	Automated, always current	Low, drift caught early	Minimal, ongoing

The continuous approach requires upfront investment in tooling and process. It pays back in fewer findings, faster audits, and lower remediation costs.

Key Takeaways

SOC 2 compliance on AWS requires proving your own account configuration controls, not relying on AWS’s infrastructure-level SOC 2 report.

Point	Details
Security is always mandatory	The Common Criteria (CC1–CC9) apply to every SOC 2 engagement regardless of scope.
AWS’s SOC 2 report covers infrastructure only	Your auditor tests your IAM, encryption, logging, and drift detection separately.
Automate evidence collection early	AWS Audit Manager and Config rules create a continuous audit trail across the full observation period.
Select optional criteria carefully	Adding Availability, Confidentiality, or Privacy expands scope and audit cost.
Continuous monitoring beats pre-audit sprints	Teams that monitor controls daily pass audits faster and with fewer findings.

What I’ve learned from real AWS SOC 2 audits

Every team I have worked with underestimates how much of the SOC 2 burden sits on their side of the shared responsibility line. They assume AWS handles more than it does. The first time an auditor asks for evidence of MFA enforcement on all IAM users and the team realizes they enabled MFA for admins but not for service accounts, that assumption becomes expensive.

The teams that pass cleanly treat SOC 2 as a defense-in-depth exercise, not a checkbox exercise. They configure GuardDuty, set up Config rules, and connect alerts to their ticketing system before the observation period starts. They do not scramble for evidence at audit time because the evidence is already there.

The other mistake I see repeatedly is treating the AWS SOC 2 report as a substitute for internal controls documentation. It is not. It is evidence for one layer of a multi-layer control environment. Your System Description must clearly state where AWS’s responsibility ends and yours begins. Auditors read that boundary carefully.

My practical advice: start with the AWS cloud security essentials as your baseline, then layer SOC 2 Trust Services Criteria mapping on top. That sequence is faster than starting from a blank SOC 2 framework and working backward to AWS configurations.

— Oleksandr

IT-Magic’s AWS compliance expertise

IT-Magic has delivered compliance-ready AWS environments for fintech, SaaS, and enterprise clients since 2010, across 700+ projects.

IT-Magic’s certified AWS engineers set up the full control stack: IAM policies, KMS encryption, CloudTrail centralization, Config rules, GuardDuty, and Security Hub. The team maps every configuration directly to Trust Services Criteria and documents the shared responsibility boundary your auditor will review. For teams approaching their first SOC 2 Type 2 audit or maintaining an existing program, IT-Magic provides AWS compliance consulting that covers readiness assessment, continuous monitoring setup, and audit preparation support.

FAQ

What is SOC 2 compliance on AWS?

SOC 2 compliance on AWS means demonstrating that your AWS account configuration meets AICPA Trust Services Criteria through documented, auditor-tested controls. AWS’s own SOC 2 report covers infrastructure; your controls cover everything you configure.

Does AWS’s SOC 2 report cover my account?

No. AWS’s SOC 2 report covers physical infrastructure and managed services only. Your auditor separately tests your IAM policies, encryption settings, logging configuration, and drift detection controls.

How long does a SOC 2 Type 2 audit observation period last?

The observation period for a first SOC 2 Type 2 report is typically six months. SOC 2 reports are valid for 12 months, and control effectiveness must be demonstrated continuously throughout the observation window.

Which AWS services are most important for SOC 2?

IAM, AWS KMS, CloudTrail, AWS Config, GuardDuty, and Security Hub are the core services auditors examine. AWS Audit Manager adds prebuilt SOC 2 frameworks that automate evidence collection from these services.

What are the most common SOC 2 audit failures on AWS?

Publicly accessible S3 buckets and over-permissioned IAM policies are the most frequent findings. Both are preventable with account-level S3 Block Public Access and enforced least-privilege IAM policies with MFA.