Most SOC 2 audits don’t fail because a company lacks controls. They fail because the company can’t produce evidence that the controls were running the whole time. An auditor asks for six months of access review logs, and the answer is a shrug, a spreadsheet someone half filled out in March, or an admin who left the company in February with their AWS console access still active.
That’s the difference between SOC 2 built into AWS infrastructure and SOC 2 bolted on after. One approach treats compliance as a byproduct of how the environment is architected from day one. The other treats it as a project you run once a year to pass an audit, then quietly let lapse until the next one is due.
If you’re a CTO at a growth stage company evaluating your AWS setup ahead of a SOC 2 audit, or you’ve already been through one and know how painful the evidence gathering was, this is about the architectural decisions that determine which category you fall into.
Why bolted on compliance costs you
Bolted on compliance usually looks like this: engineering builds the product first, sales starts closing enterprise deals that require SOC 2, and six weeks before the audit someone gets assigned to “make AWS compliant.” That person turns on CloudTrail, writes some IAM policies, and screenshots a few security group configs into a folder.
The problem isn’t that this fails the audit outright. Auditors have seen this pattern for years and know how to work around it. The problem is what happens in the Type II observation period, which is typically three to twelve months. SOC 2 Type II doesn’t ask whether your controls exist today. It asks whether they operated consistently across the entire window.
Here’s where bolted on setups fall apart in practice:
Incomplete CloudTrail configuration
A trail that only covers one region, or one that isn’t set to log data events for S3 and Lambda, leaves gaps that show up the moment an auditor asks for a specific event and it isn’t there. CloudTrail needs to be an org level, multi-region trail from the start, not something a single account owner switched on when they remembered.
IAM sprawl with no access reviews
Access control findings are the single largest category of SOC 2 exceptions, and for good reason. When provisioning and deprovisioning are manual, and HR offboarding isn’t synced with IAM, you end up with former employees holding console access weeks after they’ve left. Auditors don’t need to find a breach to write this up. They just need to find the stale account.
Undocumented infrastructure changes
If engineers can push changes to production AWS resources without a recorded approval trail, change management becomes an exception waiting to happen. This is rarely caught until an auditor samples a change and asks for the ticket, the review, and the deployment record, and none of it lines up.
Manual evidence gathering
Screenshotting the IAM console once a quarter isn’t evidence of a control operating continuously. It’s evidence that someone looked at the console once. Auditors increasingly expect continuous, system generated evidence, not point in time snapshots assembled the week before the audit starts.
None of these are exotic problems. They’re what happens when compliance is treated as paperwork applied after the infrastructure decisions have already been made.
What built in compliance actually looks like
Built in compliance, what’s often called AWS-native SOC 2 compliance, means the AWS account structure, logging, and access model are designed with SOC 2’s Trust Services Criteria in mind before the first production workload goes live. It’s not a separate initiative. It’s how the infrastructure gets built.
Start with an organizational structure that separates concerns
AWS Control Tower sets up a landing zone with a dedicated log archive account, a security tooling account, and guardrails that prevent common misconfigurations, like disabling CloudTrail or opening an S3 bucket to the public, before they happen. This matters because SOC 2 auditors care about prevention as much as detection. A guardrail that blocks a risky action is stronger evidence than a detection rule that flags it after the fact.
Turn on CloudTrail as an organization trail, not a per-account afterthought
One multi-region trail, logging to a locked down S3 bucket in the log archive account, covering management events and the data events you actually care about. This becomes your single source of truth for “who did what, when,” which is the first thing an auditor asks for.
Use AWS Config to enforce and record configuration state continuously
Config rules like s3-bucket-public-read-prohibited, iam-user-mfa-enabled, and restricted-ssh don’t just flag drift, they generate a timestamped compliance history you can hand an auditor directly. This is the difference between saying “our buckets are private” and being able to prove they’ve been private for the last nine months
Centralize findings in Security Hub
Security Hub aggregates output from GuardDuty, Inspector, Macie, and Config into a single dashboard with a standardized severity model. For SOC 2’s Trust Services Criteria around security monitoring, this is the control. You’re not managing four disconnected tools during an incident or an audit sample, you’re pointing to one system of record.
Layer in threat and data detection specific to your risk profile
GuardDuty for anomalous account and network behavior. Macie if you’re handling PII or PHI and need to know when sensitive data shows up somewhere it shouldn’t. These map directly to Trust Services Criteria around confidentiality and, if you’re also HIPAA regulated, they do double duty.
Automate access reviews instead of running them manually in a spreadsheet
IAM Access Analyzer can identify unused permissions and external access paths continuously, rather than relying on someone remembering to run a quarterly review. Pair this with automated deprovisioning tied to your HR system, so an offboarded employee’s access is revoked in hours, not weeks.
Feed all of it into AWS Audit Manager
Audit Manager has a prebuilt SOC 2 framework that maps directly to AWS Config rules and CloudTrail data, and it assembles evidence continuously instead of during a scramble. When the audit starts, you’re exporting a report, not building one from scratch.
The pattern across all of this: every control generates its own evidence as a side effect of operating normally. Nobody has to remember to document anything, because the infrastructure is already doing it.
The evidence problem is the real problem
It’s worth being specific about why “evidence” is the word that matters most in this whole conversation. A SOC 2 Type II report isn’t graded on whether you have a firewall or an access policy. It’s graded on whether an independent auditor can sample your environment across the observation period and consistently find proof that the control was operating.
This is where the architecture decision actually bites. If your evidence lives in a shared Google Doc that someone updates when they remember to, you are dependent on human diligence holding steady for six to twelve months straight. If your evidence is CloudTrail logs, Config rule evaluations, and Security Hub findings sitting in an S3 bucket with object lock enabled, the evidence exists whether or not anyone thought about compliance that week.
Auditors have started treating this distinction explicitly. AWS released an updated AICPA SOC 2 Compliance Guide that draws a sharper line between AWS’s own infrastructure controls, covered under the shared responsibility model, and what you’re responsible for proving on your side. The AWS side of that line has been solid for years. The customer side is where growth stage companies lose weeks of engineering time every audit cycle, because the evidence was never designed to be continuous.
What this costs you if you wait
Bolting on compliance after the fact isn’t just riskier. It’s more expensive, and the cost shows up in a specific place: engineering time pulled off the roadmap to reconstruct evidence that should have existed automatically.
Teams that build compliance in from the start spend a few weeks upfront on account structure, logging, and Config rules, then spend a few hours per quarter reviewing dashboards that are already populated. Teams that bolt it on spend that same few weeks every single audit cycle, because nothing they built the first time was designed to persist. The access review process gets rebuilt. The CloudTrail gaps get patched again. The change management documentation gets reconstructed from memory and Slack threads.
There’s also a harder cost: deals that stall. Enterprise buyers increasingly ask for a SOC 2 report as a gate before they’ll sign, and “we’re working on it” is a weaker answer than a report in hand. If your infrastructure wasn’t built with evidence generation in mind, “working on it” can mean another two to three months before you have anything to show.
SOC 2 built into AWS infrastructure: a before and after
The gap between these two approaches is easiest to see side by side, so picture two companies of similar size, both around 60 employees, both storing customer data in AWS, both starting a SOC 2 Type II observation period on the same day.
Company A treats compliance as a project. Six weeks before the audit, an engineer is pulled off feature work to “get AWS ready.” They enable CloudTrail in the account where production runs, but not in the two other accounts the company has spun up for staging and internal tools. They write a document describing the access review process, but no review has actually happened yet, so the document describes a process rather than evidence of one. When the auditor’s sample period starts, half the environment isn’t logging consistently, and there’s no historical record for the months before the engineer started, because nothing was capturing it.
Company B set up AWS Control Tower when they provisioned their second account, a year before SOC 2 ever came up. CloudTrail has been running as an org-level trail since then. Config rules have been evaluating S3 bucket policies and IAM configurations continuously, generating a compliance history with a timestamp on every check. IAM Access Analyzer has been flagging unused permissions monthly, and each flag has a resolution recorded in the same system. When the audit starts, the evidence already exists. The only new work is exporting it through Audit Manager and walking the auditor through the account structure.
Both companies can likely pass their SOC 2 Type II audit eventually. But Company A’s engineer just lost six weeks of roadmap time, the audit process surfaced findings that require remediation and re-testing, and the same six weeks of reconstruction will repeat next year. Company B spent that time twelve months earlier, in smaller increments, as part of normal infrastructure work, and now spends a few hours per quarter reviewing dashboards that are already current.
This is the actual choice a CTO is making when they decide how to approach AWS architecture ahead of a compliance push. It isn’t “SOC 2 or no SOC 2.” It’s whether the cost gets paid once, early, and in small pieces, or every year, late, and all at once.
Questions worth asking about your own environment
Before you decide whether your AWS setup treats compliance as infrastructure or as paperwork, a few diagnostic questions are more useful than a generic checklist:
Can you pull six months of CloudTrail history for a specific IAM principal right now, without asking three different people where the logs live? If a former employee’s AWS access were still active today, would anything alert you, or would you only find out during an access review someone remembers to run? When Config or Security Hub flags a misconfigured resource, is there a recorded remediation, or does it get fixed quietly with no trail? If an auditor asked for evidence that a control operated continuously for nine months, could you export it in an afternoon, or would you need to reconstruct it?
If more than one of those answers makes you uneasy, the underlying issue usually isn’t a missing tool. It’s that compliance was never part of the original architecture decision.
Where to go from here
SOC 2 built into AWS infrastructure isn’t a bigger lift than bolting it on later. It’s a different lift, done earlier, that pays for itself every audit cycle afterward instead of costing you the same weeks of engineering time on repeat. The account structure, the logging, and the evidence pipeline are architectural decisions, not compliance paperwork, and they’re a lot cheaper to get right before your first audit than to retrofit after your second.
If you’re heading into a SOC 2 audit and want a second opinion on whether your AWS environment is generating real evidence or just giving you something to screenshot in a hurry, book a discovery call with Aland Cloud. We build HIPAA and SOC 2 requirements into the infrastructure itself, on AWS exclusively, with engineers who’ve done this for companies your size before.