SOC 2 on AWS: The Complete Guide

Most SOC 2 audits don’t fail because companies lack security controls. They fail because companies can’t produce evidence those controls were working consistently over time. An alert that fired but wasn’t actioned. A CloudTrail log that was enabled six months into the audit window. An IAM policy that was “mostly” least-privilege.

The Audit Doesn’t Fail on Policy. It Fails on Evidence.

Most engineering teams preparing for a SOC 2 audit assume the same thing: get the policies written, document the procedures, show the auditor the binder. That assumption is expensive.

SOC 2 compliance on AWS isn’t primarily a documentation problem. It’s a proof problem. SOC 2 Type II requires demonstrating that controls operated effectively over a period of time, typically six to twelve months. Not that they exist. Not that you intended to run them. That they actually ran, consistently, and that you have the records to show it.

Here’s what that looks like in practice. Your auditor asks: “Show me who had access to your production environment last quarter.” If you can’t pull that answer from a system, a CloudTrail query, an IAM Identity Center access report, a change log, you fail. Not because your access control policy is poorly written. Because there’s no evidence the policy was enforced.

That’s the core tension in SOC 2: the Trust Services Criteria are written in abstract language, “the entity restricts logical access”, “changes are managed consistently”, but the proof auditors require is brutally concrete. Logs. Change records. Access events. Deployment histories. Timestamped, complete, tamper-resistant.

If your AWS environment can generate that proof on demand, you’re in good shape. If it can’t, no amount of documentation will save you.

What SOC 2 Actually Requires on AWS (And What It Doesn’t)

SOC 2 is scoped around five Trust Services Criteria: Security, Availability, Confidentiality, Processing Integrity, and Privacy. Security (CC6–CC9) is the only mandatory one. The others are scoped per engagement — most growth-stage companies start with Security only, sometimes adding Availability.

Here’s how the criteria map to AWS controls:

The important nuance: auditors don’t care that GuardDuty is enabled. They want to see findings reviewed, documented, and resolved or formally accepted with a rationale. The difference between a control that exists and a control that produces evidence is exactly where most companies fail.

SOC 2 Is Not a Checkbox. It’s an Architecture Decision.

The most common mistake teams make is treating SOC 2 as something you layer onto existing infrastructure. You finish building the product, land an enterprise prospect who asks for the report, and then begin “getting compliant.”

If you designed your AWS environment without SOC 2 in mind, you’re not preparing for an audit. You’re doing a redesign and expensive architectural changes. These changes are expensive, not just in time and engineering effort, but in the harder cost of what you can’t retroactively create.

Companies that treat SOC 2 as a documentation exercise are the ones that fail Type II. Because Type II doesn’t test whether you have controls. It tests whether your controls ran consistently over the audit period. You can’t backfill six months of CloudTrail logs. You can’t reconstruct a deployment history you didn’t capture. The evidence either exists or it doesn’t.

Tools like AWS Audit Manager, Vanta, or Drata connect to AWS via APIs and surface evidence in a format auditors can work with, reducing the manual burden of evidence collection significantly. But they only work well if the underlying infrastructure is correctly configured. Vanta can surface your CloudTrail logs; it can’t create them if CloudTrail wasn’t enabled. Drata can pull your GuardDuty findings; it can’t invent six months of continuous monitoring you didn’t run. These tools are only as good as the infrastructure underneath them.

The question to ask isn’t “how do we get compliant?” It’s “did we build infrastructure that can prove compliance over time?”

For teams in the “we’ll handle SOC 2 once we close the enterprise deal” camp: the audit window is time-based. The earliest your Type II period can close is six months after your controls start running. The clock starts when the infrastructure is ready, not when the audit is scheduled.

Start with the Control Plane: IAM and Access Governance

Access control failures are the most common SOC 2 audit finding. Most software companies run staging, testing, and production workloads within the same AWS account, which requires significant ongoing work to keep access boundaries clean and auditable. As an AWS best practice, each environment should have its own dedicated AWS account. For more complex architectural needs, AWS organizational units can provide a better structural foundation.

Start with IAM Access Analyzer. It identifies resources exposed to external access, cross-account roles, S3 buckets with public policies, KMS keys accessible outside your org. Enable it across every account. More importantly, document that you review findings on a defined cadence. Running the tool isn’t the control. The review process is.

Enforce least-privilege at the organization level using Service Control Policies via AWS Organizations. This is overlooked step.

Require MFA for all human identities. IAM Identity Center federated through your IdP (Okta, Azure AD, Google Workspace) is the clean implementation which centralizes access, produces clean audit logs, and eliminates the credential rotation problem.

Document your break-glass accounts. Auditors will ask about emergency access procedures. You need: the accounts exist, they’re MFA-protected, access is alerted on via CloudWatch, and credentials are rotated on a defined schedule.

IAM Access Analyzer running isn’t evidence. A documented review process with findings resolved or formally accepted is.

Environment Reproducibility: Why Infrastructure as Code Makes SOC 2 Evidence Easier to Produce

One area that often gets overlooked in SOC 2 preparation is environment reproducibility. Auditors evaluating CC6 and CC8 want to know that your production environment is what you say it is. An environment that was assembled through a combination of console clicks, manual adjustments, and undocumented tweaks over eighteen months cannot make that claim convincingly.

Infrastructure as Code changes that dynamic. When your AWS environment is defined in Terraform, AWS CloudFormation, or AWS CDK, the configuration of every resource lives in version-controlled source code like Git. Every change goes through the same review process as application code: a pull request, a peer review, a merge, and an automated apply. The history of your infrastructure is the history of your repository. IaC is not a hard SOC 2 requirement, but it makes documentation, audit history, change traceability, and access control management significantly easier to maintain over time.

First, it provides a complete, auditable record of every infrastructure change without relying on manual documentation. A Terraform state file combined with Git history tells the auditor exactly what your environment looked like at any point in the audit window. Second, it eliminates the class of configuration drift that comes from ad hoc console access. When infrastructure is provisioned and updated exclusively through code, a manually changed security group or an undocumented S3 bucket policy becomes immediately visible as drift, which AWS Config can flag. Third, it supports CC6.1’s requirement that access configurations are known and controlled. If your IAM policies, VPC security groups, and S3 bucket policies are all defined in code, you can prove their configuration at any point in time without reconstruction.

Without IaC, proving your environment matches its documented configuration is largely guesswork. Auditors will notice.

Build Logging and Monitoring You Can Actually Prove

CC7.2 requires continuous monitoring. SOC 2 Type II covers a 6–12 month audit window. That means you need logging infrastructure that was in place, uninterrupted, for the entire period — not enabled three months before the auditor arrives.

CloudTrail is non-negotiable. Enable it in every region, including regions you don’t think you’re using. Log to a dedicated S3 bucket in a separate account if possible — this prevents an attacker (or a mistake) from disabling logging and destroying the evidence. Enable MFA delete on the bucket. Set a minimum 12-month retention policy. Auditors pull specific date ranges; gaps are findings.

AWS Config is your configuration compliance layer. Enable Config Rules to detect drift — unrestricted SSH ingress, unencrypted EBS volumes, public S3 buckets. AWS ships a SOC 2 conformance pack natively; it maps Config Rules directly to Trust Services Criteria and gives you a compliance dashboard you can screenshot for evidence. Document what happens when a rule turns non-compliant: who gets alerted, what the remediation SLA is, and where that’s tracked.

Security Hub aggregates findings from GuardDuty, Inspector, Macie, and Config into a single view. Enable it. Then build a findings triage process — a weekly review, a Jira integration, a Slack alert for critical findings. “Enabled but unreviewed” is an audit finding. Auditors will ask to see the findings history and what you did with it.

GuardDuty detects threats across CloudTrail, VPC Flow Logs, and DNS logs. Enable it in every region and every account. Route high-severity findings through EventBridge to your incident response workflow — even if that workflow is a Slack channel and a runbook right now.

AWS Audit Manager is worth enabling once your logging foundation is solid. It maps continuously collected evidence from CloudTrail, Config, and Security Hub directly to SOC 2 controls — so when the audit window opens, you’re not scrambling to export six months of logs manually. It won’t fix a broken logging setup, but it makes a good one dramatically easier to audit.

The audit question isn’t “are alerts firing?” It’s “show me what you did when they fired.”

Encryption At Rest and In Transit, Without Exceptions

Encryption is table stakes. The audit risk isn’t usually “encryption is off” — it’s inconsistency. One unencrypted RDS snapshot, one S3 bucket without SSE-KMS, one service talking over HTTP internally. Auditors sample, and gaps surface.

RDS: Encryption must be enabled at instance creation. You cannot enable it on a running instance — you need to snapshot, restore encrypted, and swap. If you’re spinning up new databases, make encryption a hard requirement in your Terraform modules or CI pipeline checks. Also confirm automated backups are enabled and retained for a minimum of 7 days.

S3: Enable default encryption with SSE-KMS on every bucket. Add a bucket policy that enforces aws:SecureTransport: true — this blocks HTTP access and satisfies the in-transit encryption requirement for S3 operations. Block public access at the account level via S3 Block Public Access settings.

AWS KMS: Use customer-managed keys (CMKs) for S3, RDS, EBS, and Secrets Manager wherever you handle sensitive data. Enable automatic key rotation (annual minimum). Document your key management policy — auditors ask about rotation cadence.

Secrets Manager over environment variables, always. Hardcoded credentials or secrets in Lambda environment variables are a SOC 2 finding. Secrets Manager handles rotation, access logging, and fine-grained IAM controls. The AWS Config rule no-secrets-in-lambda can detect this automatically.

ACM for TLS certificates. Use AWS Certificate Manager for all public-facing endpoints. ACM auto-renews — manual certificate management introduces expiry risk, which is an availability finding.

Encryption isn’t a configuration you turn on once. KMS key rotation, certificate renewal, and secrets rotation are ongoing controls — and auditors check the cadence.

Vulnerability Management That Produces Evidence

CC7.1 requires a formal vulnerability management program. Not just scanning — a documented process with defined SLAs that you can demonstrate you followed consistently.

Amazon Inspector v2 is your starting point. Enable it for EC2 instances and Lambda functions. It integrates natively with Security Hub, so findings flow into your centralized triage process automatically. Inspector v2 takes about 10 minutes to enable. Not having it running is an unforced audit error.

ECR image scanning should be enabled on push for every container registry. Go further: build a pipeline gate that blocks deployment if a critical CVE is detected in an image. Document this in your SDLC policy. Auditors want to see that vulnerabilities caught in scanning actually prevent deployment, not just generate a report.

AWS Systems Manager Patch Manager handles OS-level patching for EC2. Configure patching baselines that match your severity SLAs. SSM generates compliance reports natively — you can pull a point-in-time view of which instances were compliant on any given date. That’s audit evidence without manual effort.

Define your remediation SLAs in a written policy and document that you follow them:

• Critical: 15 days
• High: 30 days
• Medium: 90 days

The specific numbers matter less than consistency. Auditors want to see a written policy and evidence that findings were remediated within it.

The Approach That Actually Works: Compliance Built Into the Foundation

There are two ways to approach SOC 2 on AWS. The first: build fast, ship features, add compliance controls before the audit. The second: build with compliance-aware architecture from the start.

The second approach is not slower. It’s cheaper, cleaner, and produces dramatically better audit evidence.

Here’s the practical difference. A company that enables CloudTrail on day one walks into a SOC 2 Type II audit with a complete, unbroken evidence trail. A company that enables CloudTrail three months before the audit window opens has a gap. Auditors note gaps. Gaps become findings. Findings delay certification, and delayed certification costs sales.

This is why AWS-exclusive depth matters. SOC 2 on AWS is not a generic compliance exercise. It requires knowing how Config conformance packs map to Trust Services Criteria, how to structure SCPs to prevent compliance drift at the org level, and how to configure Security Hub so it produces useful findings rather than noise. Purpose-built AWS Managed Services focused entirely on AWS, not spread across three clouds — bring that depth to every engagement. A generalist provider who also handles Azure and GCP won’t. It shows in the audit.

Ready to find out exactly where your AWS environment stands against SOC 2 criteria? Book a discovery call with Aland Cloud. We’ll tell you what to prioritize before the audit window opens.