Why Your Startup Needs an AWS Landing Zone Before SOC 2

Your board just mandated SOC 2. Your biggest enterprise prospect won't sign without it. And someone on your team just asked whether your AWS setup is actually ready.

The honest answer, for most startups, is no. Not because you're missing a specific tool or service - but because of how your AWS Landing Zone (or lack of one) is structured.

I keep running into this pattern with clients: a startup running everything in a single AWS account, root account credentials shared among founders, CloudTrail maybe enabled in one region, Security Hub never configured. When a SOC 2 auditor looks at that environment, they don't see a few gaps. They see a structural problem that generates a dozen audit findings before they've even started the real work.

This post explains what an auditor actually finds in a typical startup AWS environment, why an AWS Landing Zone is the technical prerequisite (not just best practice), and why setting it up before your evidence window opens is the decision that determines your certification date. If you want to see what this looks like in practice, the Accolade case study shows exactly how we built a SOC 2 compliant Landing Zone for a startup in this exact position.

The 90-Day Clock Nobody Warns You About

Most guides skip this part. They jump straight to "here are the AWS services you need" without explaining why timing matters as much as the services themselves.

Here's the thing about SOC 2 Type II that changes the entire conversation: your evidence collection period starts when your controls start collecting evidence - not when you engage an auditor.

SOC 2 Type I vs. Type II: Why the Difference Matters for Your Timeline

SOC 2 Type I assesses whether your controls exist at a single point in time. You can get a Type I report relatively quickly - weeks, not months. But here's the problem: most enterprise buyers require Type II before they'll sign a deal.

SOC 2 Type II proves that your controls operated continuously and effectively over an observation period. That observation period is typically a minimum of six months, and many auditors prefer twelve months to produce a credible report. There is no shortcut. You cannot compress it.

This means the goal is not just "get compliant" - it's "start the clock as early as possible with a clean environment."

Why Day One of Your Evidence Window Defines Your Certification Date

If your Landing Zone is not in place when the evidence window opens, every day of delay has a direct cost: it pushes your Type II certification date further out.

There's a second problem that's worse than the delay. If your environment is misconfigured on day one and the evidence window is already open, your auditor isn't just seeing gaps - they're seeing a record of those gaps playing out over your entire observation period. You cannot retroactively clean up the evidence trail.

A Landing Zone deployed after your evidence window opens doesn't erase what came before. It just means your first SOC 2 Type II report contains findings from the period before the Landing Zone existed.

The math is straightforward: if your enterprise deal requires SOC 2 Type II and your audit window needs to open in 60 days, you are already late if you haven't started building the foundation.

What Auditors Find in a Single-Account AWS Setup

Let's look at the specific problem this creates. Not hypothetically - this is what I see when we do a gap analysis on a startup AWS environment before they've built a proper foundation.

The typical starting point: one AWS account, production and dev workloads sharing the same environment, the root account used for early deployments, and security services either disabled or configured inconsistently across regions. From an auditor's perspective, this isn't a minor gap - it's a structural problem that generates multiple findings across multiple Trust Service Criteria simultaneously.

The 12 Findings That Appear in Almost Every Single-Account Audit

These aren't edge cases. They appear consistently across the environments I review, and each one maps directly to a specific SOC 2 control failure:

1. CloudTrail not enabled organization-wide (CC7.2, CC8.1) - No record of who performed what API actions across all regions.
2. No centralized audit log repository - Logs stored in the same account they monitor create a conflict of interest and a tamper risk auditors flag immediately.
3. AWS Config not enabled - Without Config, Audit Manager's 15 automated controls produce zero evidence. This is a hard dependency.
4. GuardDuty disabled or not centralized (CC7.2) - Missing threat detection, and without a multi-account structure, findings from different accounts never aggregate.
5. No MFA on root and admin accounts (CC6.2) - One of the first things SOC 2 auditors check. Security Hub's CIS Benchmark check surfaces this as a critical finding.
6. Open security groups exposing management ports (CC6.6) - SSH or RDP open to 0.0.0.0/0 is a HIGH-severity Security Hub finding. It shows up in red on day one.
7. Stale IAM access keys without rotation (CC6.8) - Access keys older than 90 days. IAM Access Analyzer's unused access findings catch this automatically.
8. No account isolation between production and non-production - The entire account is in scope for the audit, including dev, test, and experimental work.
9. No preventive Service Control Policies (SCPs) (CC8.1) - Developers can accidentally disable GuardDuty or CloudTrail, destroying audit evidence with no technical barrier to stop them.
10. VPC Flow Logs not enabled (CC6.6, CC7.2) - Security Hub's EC2.6 control specifically checks this. Auditors cannot verify network-level access controls without it.
11. No centralized security monitoring - Without an Audit account with delegated admin for Security Hub, there's no single source of truth for the auditor to review.
12. Infrastructure changes made manually with no IaC (CC8.1) - Showing an auditor that you have a process for change control is far harder when changes are made by hand.

You can run a self-assessment against the 55+ item checklist before engaging an auditor to see exactly where you stand.

The Scope Problem: When Everything Is in One Account

Finding #8 deserves more attention because it's the one that surprises people most.

When production and development workloads share a single account, your auditor doesn't get to audit just the production environment. They audit everything - because everything is in scope. That developer's test S3 bucket with public access? In scope. The experimental Lambda function with overly permissive IAM? In scope. The staging database with a security group someone opened "temporarily"? Also in scope.

The AWS Organizing Your Environment whitepaper puts it directly: "it's far easier to talk to an auditor and point to a single account hosting the [in-scope] workload." The same logic that applies to PCI applies to SOC 2 - account boundaries are your most effective tool for controlling audit scope.

Without account isolation, you're not just increasing the number of controls to demonstrate. You're increasing the probability that a misconfiguration in a low-priority environment becomes a finding that applies to your entire audit.

SOC 2 and AWS: Where Your Responsibility Starts

There's a misconception I encounter regularly: teams assume that because AWS is SOC 2 certified, some of that compliance transfers to their own audit. It doesn't - not in the way they think.

AWS is audited by Ernst & Young LLP, and the Fall 2025 SOC 2 report covers 185 AWS services across a twelve-month period. AWS Control Tower itself is in scope for that report. You can download the report from AWS Artifact after signing an NDA. That report is real, and those controls are genuinely audited.

But that report covers AWS's infrastructure - the physical data centers, the hypervisors, the network substrate. It does not cover how you configured your cloud environment, how you secured your workloads, or whether your monitoring is actually running.

What You Inherit from AWS (and What You Can't)

The AWS shared responsibility model divides controls into three categories:

Inherited controls are what you fully receive from AWS - physical security, hypervisor controls, network infrastructure. For your SOC 2 audit, you reference the AWS SOC 2 report to demonstrate these. Your auditor accepts it.

Shared controls apply to both layers. AWS patches the underlying infrastructure; you patch your operating systems and applications. AWS secures the physical network; you configure your security groups and VPC.

Customer-specific controls are entirely yours - your IAM configuration, your CloudTrail setup, your account structure, your monitoring, your access management for your own users.

Your auditor will expect evidence for all three categories. For inherited controls, you reference the AWS report. For everything else, you need your own evidence. If you don't have it, you have a finding.

Complementary User Entity Controls: The Gap You Must Fill

The AICPA has a specific term for the controls AWS expects you to implement: Complementary User Entity Controls (CUECs). These are the customer-side controls that make AWS's infrastructure controls effective.

A simple example: AWS physically secures the data center (inherited control). You must configure IAM to prevent unauthorized access to the resources inside that data center (CUEC). The AICPA SOC 2 Compliance Guide on AWS (July 2025) maps specific CUECs to the AWS services and configurations that satisfy them. This is the most authoritative current reference for what auditors expect from an AWS environment. If you want a broader view of what SOC 2 auditors actually expect from your AWS controls, that post covers the framework in more depth.

What a Landing Zone Actually Gives You

AWS Control Tower sets up the baseline Landing Zone in under 60 minutes. The technical barrier isn't time - it's knowing what to build and configuring it correctly for your workload needs.

What Control Tower actually creates is a multi-account structure with mandatory controls that cannot be disabled, centralized logging that's protected from tampering, and security services wired together across accounts with delegated administration. That's the foundation Audit Manager needs to actually collect automated evidence.

Without this foundation, Audit Manager's 15 automated controls produce nothing useful. They depend on AWS Config, CloudTrail, and Security Hub being active and correctly configured. A Landing Zone is what provisions and connects those services.

For a fuller picture of the business case, the measurable ROI and time savings a Landing Zone delivers reinforces why this investment compounds beyond the audit itself.

The Account Structure That Reduces Your Audit Scope

The multi-account structure Control Tower creates has a direct SOC 2 implication for each account:

• Management Account: Runs Control Tower, billing, and account provisioning. Never used for workloads. SCPs don't apply here, which is why it's kept empty.
• Log Archive Account: All CloudTrail and Config logs from every account flow here automatically. Mandatory SCPs prevent anyone from modifying the S3 buckets, the lifecycle policies, or the encryption config. This is your tamper-proof audit evidence repository.
• Audit/Security Tooling Account: GuardDuty, Security Hub, and Amazon Detective run here with delegated admin across all member accounts. Findings aggregate from everywhere into one place - the single dashboard your auditor reviews for CC7 evidence.
• Production Account: The only account in scope for the audit. Isolated from development and testing, which means your auditor's scope is contained and your developers can work without turning every experiment into a potential finding.
• Development Account: Completely out of scope. A misconfiguration here doesn't appear in the audit.

Mandatory Controls That Run From Day One

Control Tower deploys mandatory controls that cannot be disabled by anyone in the member accounts. This is what separates "we have a policy saying don't disable CloudTrail" from "it is technically impossible to disable CloudTrail without management account intervention."

The key mandatory preventive controls (implemented as SCPs):

• CloudTrail enabled in all regions
• CloudTrail log file integrity validation enabled
• CloudTrail configuration changes blocked
• Log Archive S3 bucket modifications blocked (encryption, logging, bucket policy, lifecycle)
• Config aggregation deletion blocked
• CloudWatch Logs groups created by Control Tower protected

Three mandatory detective controls run as Config rules: they detect public read/write access on Log Archive S3 buckets, and verify that CloudTrail is active in the Security OU accounts.

Here's what the SCP pattern for protecting a critical security service looks like in practice - this is the pattern that makes GuardDuty impossible to disable within any member account:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "guardduty:DeleteDetector",
        "guardduty:DisassociateFromMasterAccount",
        "guardduty:StopMonitoringMembers"
      ],
      "Resource": "*"
    }
  ]
}

One important note for newer deployments: starting with Control Tower version 4.0, mandatory controls are no longer automatically applied to OUs on creation - they must be explicitly applied. This is a common setup gap I see in environments where someone set up Control Tower recently without fully reading the version notes. Verify your mandatory controls are applied to each OU after setup by checking the AWS Control Tower mandatory controls reference.

Also, a practical constraint worth knowing: AWS Organizations allows a maximum of 5 SCPs per OU. Control Tower consumes up to 3 of those slots, leaving you 2 for custom policies. If you need more, you'll need nested OUs - the hierarchy supports up to 5 levels deep.

The Auditor Evidence Map

SOC 2 auditors work through the Trust Service Criteria systematically. For most startups, CC6 (Logical and Physical Access), CC7 (System Operations), and CC8 (Change Management) are the most technically demanding because they require the most AWS-specific evidence.

Here's the mapping your auditor will follow - what the AICPA requires, what evidence they'll specifically ask for, and which Landing Zone component produces it.

CC6 - Logical and Physical Access Controls

CC6.3 is worth calling out specifically. The AICPA's exact language requires that access be "authorized based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties." Account-level isolation between production and development is one of the cleanest ways to demonstrate this to an auditor - you can point to a structural separation, not just a policy document.

CC7 - System Operations

CC7.4 and CC7.5 are important to note. The Landing Zone covers the technical monitoring controls for CC7.1 through CC7.3. The incident response and recovery controls require human documentation regardless of how well the AWS environment is configured.

CC8 - Change Management

The CloudTrail integrity piece is worth understanding. When enabled, CloudTrail creates a SHA-256 hash for every log file delivered, then every hour creates a signed digest file referencing the previous hour's logs using SHA-256 with RSA. Your auditor can run aws cloudtrail validate-logs to independently verify the entire digest chain. This is what makes the evidence tamper-proof, not just present. Without this, a determined actor could modify log files and there would be no cryptographic record of the tampering.

What the Landing Zone Doesn't Solve

I want to be direct about this because some guides gloss over it: deploying a Landing Zone does not mean you're audit-ready. It means the technical foundation is in place and your automated evidence collection has started.

AWS Audit Manager's prebuilt SOC 2 framework has 15 automated controls that collect evidence from CloudTrail, Config, Security Hub, and API calls. The Landing Zone is what makes those 15 controls work. But the framework also has 46 manual controls that require human evidence - and those don't change regardless of how good your AWS setup is.

AWS is direct about this in their own documentation: "The controls in the AWS Audit Manager framework aren't intended to verify if your systems are compliant. Moreover, they can't guarantee that you'll pass an audit. AWS Audit Manager doesn't automatically check procedural controls that require manual evidence collection."

The 46 Manual Controls You Still Own

These require human documentation regardless of what AWS services are running:

• Access review procedures (who reviews IAM access quarterly, and is there a record of those reviews?)
• Incident response policy with a documented procedure
• Change management process documentation
• Vendor management and third-party risk assessments
• Employee security awareness training records

The practical approach: get the Landing Zone in place to start the automated evidence collection, then work through the manual controls in parallel. Both clocks start on the same day.

One additional note on Audit Manager: AWS updated the SOC 2 framework in July 2025, improving evidence relevance and optimizing collection costs. If you have an assessment created before June 6, 2024, you need to recreate it to receive the updated framework. Assessments created after that date require no action.

The IAM and monitoring configurations that prevent most breaches post covers the manual security practices that sit alongside the automated controls - worth reading alongside this as you work through the Audit Manager manual control list.

The Implementation Timeline

AWS Control Tower sets up the baseline Landing Zone in under 60 minutes. That number is accurate for the initial setup - it's what AWS documents as the benchmark for a new landing zone provisioning.

What takes longer is everything around it: designing the account structure for your specific workloads, migrating existing workloads out of a single account into the new structure, configuring Audit Manager with an active SOC 2 assessment, and applying the strongly recommended controls beyond the mandatory set.

Here's what a realistic implementation timeline looks like based on what I've seen with clients:

What Getting Set Up Actually Involves

Week 1-2 (Gap Analysis): Document the current AWS environment, map every finding against the SOC 2 controls, and prioritize the remediation sequence. This is where you discover exactly how many of the 12 findings above apply to your environment and in what order to address them.

Week 2-4 (Landing Zone Deployment): Control Tower setup, OU structure configured for your workload types, mandatory and strongly recommended controls applied to each OU, Audit Manager SOC 2 assessment created and activated. This is also when the Type II evidence clock starts - the day Audit Manager goes active with clean controls.

Concurrent with Landing Zone (Workload Migration): Move production workloads from the single account into the new Production account. Configure Security Hub and GuardDuty in the Audit account with delegated admin. This is the part that varies most by environment - a simple two-tier web app migrates faster than a distributed system with dozens of services.

Parallel Track (Organizational Controls): Incident response policy, access review procedures, training records, vendor risk assessments. These don't depend on the technical work and can run at the same time.

Control Tower is straightforward for greenfield setups. Migrating an existing single-account environment into the new structure is a different conversation - the complexity scales with how much is already running and how it's deployed.

How Accolade Got to SOC 2 Ready

If you want to see how this plays out with a real startup, the Accolade case study walks through exactly what we built. Accolade came to us with a single-account AWS environment, no centralized logging, and an enterprise customer demanding SOC 2 certification on a fixed deadline. We deployed a multi-account Landing Zone with Control Tower, migrated their production workloads into the new account structure, and configured the full evidence pipeline: CloudTrail with integrity validation, Config rules, Security Hub with FSBP enabled, and GuardDuty across all accounts. They started collecting clean evidence from day one of the new structure, which meant their Type II observation period began immediately rather than after months of remediation.

Where to Go From Here

A few things worth keeping in mind as you plan next steps:

The SOC 2 Type II clock starts when your controls start collecting clean evidence - not when you hire the auditor. Every week without a Landing Zone is a week of delayed certification, and if your evidence window is already open, it's worse than a delay.

A single-account AWS environment generates 12 predictable audit findings across CC6, CC7, and CC8. These aren't edge cases from unusual configurations - they're structural gaps that require architectural change, not just tooling additions.

The Landing Zone handles the technical controls automatically. The 46 manual controls in Audit Manager still require human documentation and process work. Both tracks need to run in parallel from day one.

AWS Control Tower provisions the baseline in under 60 minutes. The complexity is in designing the right account structure for your workloads and migrating existing systems cleanly. That's where experienced implementation matters most.

If your audit window opens in less than 90 days and you don't have a Landing Zone in place, the first step is a gap analysis to understand exactly what needs to change and in what order. That conversation is free - and it will tell you precisely where you stand before you commit to a timeline.

Frequently Asked Questions