Someone asked you for a SOC 2 report. Maybe it was a prospect’s security team holding up a six figure deal. Maybe your board asked how long this takes before you burn a quarter on it. Whoever asked, they probably heard “90 days” from somebody selling compliance software, and that number is doing a lot of work it can’t actually deliver for a first time company with real gaps in IAM, logging, and access management.
Here’s the honest version. A SOC 2 Type I report, the point in time snapshot, runs 6 to 16 weeks from kickoff to signed report for most first time companies. A SOC 2 Type II report, the one enterprise security teams actually want because it proves your controls held up over months and not just on a slide, runs 6 to 12 months end to end. Which number applies to you depends on five variables you control and two you don’t, and almost nobody explains the difference before you’ve already signed an engagement letter.
I’ve walked engineering teams through this sequence enough times to know where the time actually goes. It’s rarely the audit itself. It’s everything that happens before an auditor ever logs into your AWS account.
The Two Clocks Everyone Confuses
“How long does SOC 2 take” is really two separate questions wearing one name. Mixing them up is why a CTO tells a prospect “we’ll have it in three months” and then delivers a report that doesn’t actually satisfy the prospect’s security team.
| Type I | Type II | |
|---|---|---|
| What it proves | Controls are designed correctly on one date | Controls actually operated correctly over months |
| Observation period | None | 3 to 12 months, 6 months is standard for a first report |
| Typical total timeline | 6 to 16 weeks | 6 to 12 months |
| What enterprise security teams think of it | Fine to open a conversation | What they actually want before signing |
Type I: the design snapshot
A Type I audit asks one question: on this specific date, are your controls designed the way you say they are? The auditor reviews your system description, checks that IAM policies, encryption, and logging exist and are configured the way your documentation claims, and issues an opinion. There’s no observation window, so fieldwork itself typically wraps in two to four weeks once your environment is ready, with another two to four weeks for the auditor to draft and issue the final report.
The standard advice is to run Type I first, get a report into your sales team’s hands fast, then roll straight into Type II. That’s usually right, but not always. If your AWS environment already has MFA enforced, least privilege IAM, CloudTrail logging, and a working access review cadence, a full Type I engagement, its own scoping call, its own fieldwork, its own report, can cost you six to eight weeks you didn’t need to spend on a report you’ll retire the moment your Type II lands. Ask your auditor directly whether skipping straight to Type II with a three month observation window gets you a usable report faster than doing both.
Type II: the operating proof
Type II adds an observation period, typically 3 to 12 months, where your controls have to run continuously and get evidenced the entire time. Six months has become the de facto floor most auditors and enterprise buyers expect out of a first report. This is the part first timers underestimate: nothing before the window started counts, and fixing a gap in month four doesn’t retroactively cover months one through three. If your access reviews were inconsistent in Q1, that’s a finding in the final report regardless of what you fix in Q2.
What Actually Sets Your Clock
Five variables move your timeline. Two of them, auditor availability and third party dependencies, you mostly can’t control. The other three are entirely on you.
Control maturity walking in the door
A team that already enforces MFA on every privileged account, runs least privilege IAM with no long lived access keys, has centralized CloudTrail logging with real retention, and does quarterly access reviews with named owners is starting the clock eight to ten weeks ahead of a team starting from zero. That gap doesn’t show up in marketing timelines because vendors quote the fast case as the default case.
Scope: how many criteria, how many AWS services touch customer data
SOC 2 has five Trust Services Criteria: security, availability, confidentiality, processing integrity, and privacy. Security is the only mandatory one, and enterprise buyers widely accept a Security only report for a first SOC 2. Adding criteria adds weeks of control mapping and evidence for something most first time buyers won’t require yet.
The bigger scope trap is technical, not contractual. Include only the AWS accounts, services, and data flows that actually touch customer data. One fintech startup pulled its internal HR system, its marketing website, and its Slack workspace into scope because nobody drew a line, and paid for it in both audit cost and months of unnecessary evidence collection. Draw the boundary around your production AWS environment and the systems that process customer data, not around everything your company happens to run.
The Realistic Timeline, Phase by Phase
This is the sequence I actually walk teams through.
| Phase | Typical Duration | What’s Actually Happening |
|---|---|---|
| Scoping and auditor selection | 2 to 6 weeks | Define which Trust Services Criteria and which AWS accounts and services are in scope. Talk to two or three CPA firms. Popular firms book out by the quarter, so start this conversation before you think you need to. |
| Gap assessment | 4 to 6 weeks | Compare your actual AWS environment, IAM, logging, encryption, network config, against SOC 2 criteria. Produces a prioritized remediation backlog, not a checklist. Skipping this step is the single biggest predictor of a blown timeline. |
| Remediation | 4 to 12 weeks | Fix what the gap assessment found: MFA enforcement, least privilege IAM, S3 Block Public Access at the account level, CloudTrail retention, KMS key rotation, a real access review cadence with a named owner per control. |
| Type I fieldwork and report | 2 to 4 weeks fieldwork, 2 to 4 weeks to final report | Auditor tests whether the controls you just built are designed correctly as of one date. |
| Type II observation window | 3 to 12 months, 6 months typical for a first report | Controls run and get evidenced continuously. This is calendar time you cannot compress by working harder in week eleven. |
| Type II fieldwork and report | 2 to 4 weeks fieldwork, 2 to 4 weeks to final report | Auditor samples evidence across the entire window and interviews the people who own each control. |
Weeks one through ten: readiness and the remediation backlog
Engage your auditor for scoping conversations early, CPA firms specializing in SOC 2 routinely carry six to eight week waiting lists, worse in Q3 and Q4 when everyone else is racing to close before year end. But don’t let them schedule fieldwork until your gap assessment and remediation are genuinely done. Teams that book fieldwork first and remediate second are the ones who slip four to eight weeks past their own target, because scope gets finalized after controls are already half built and evidence gets collected without anyone owning it.
The observation window and what follows it
Once your controls run cleanly, the Type II clock starts. Schedule penetration testing with eight to twelve weeks left in the window, not on the last day. Scoping and hiring a tester takes two to three weeks on its own, and if the test turns up a critical finding, you need time to fix it and generate fresh evidence that the fix actually held, not just that you patched it once. Budget four to eight weeks for that remediation buffer. Teams that schedule the pen test in the final month of their observation window routinely end up extending the window to cover a finding they didn’t have time to remediate and re-evidence.
Compressing the Timeline Without Cutting Corners
The parts of this timeline you can’t touch are fixed by the standard itself: a six month observation window is six months, no automation tool changes that math. What you can compress is everything before the clock starts, and that’s where most of the wasted time actually lives.
What a SOC 2 implementation partner actually changes
The time savings from a SOC 2 implementation partner come almost entirely from the readiness phase, not from the audit itself. A team doing this for the first time spends real weeks just learning what an auditor means by “sampling,” which AWS Config rules map to which Trust Services Criteria, and what evidence format a CPA firm will actually accept without a follow up request. A partner who has mapped AWS controls to SOC 2 criteria dozens of times skips that learning curve entirely and walks in already knowing which CloudTrail exports, IAM policy documents, and access review logs an auditor is going to ask for before they ask for them.
Compliance automation platforms help too, mainly by cutting the manual evidence gathering that otherwise eats a security engineer’s week in screenshots. But a platform without someone who owns the process is expensive shelfware. The most common failure isn’t a tooling gap, it’s a team that buys the automation, assumes it replaces ownership, and finds out at audit time that nobody was actually running the quarterly access reviews the dashboard said were scheduled.
Keeping AWS managed infrastructure stable while your team is heads down
Here’s the tradeoff nobody puts in the sales deck. During a six to twelve month observation window, your best engineers are the ones pulled into evidence collection, access reviews, and auditor follow ups. If those same people also own patching, scaling, and incident response for your production environment, something gives, usually either the audit slips or an on call incident takes three times longer to resolve because the engineer who’d normally own it is deep in a SOC 2 evidence request. Companies that hand day to day operations of their AWS managed infrastructure to a dedicated team during this window keep production stable and free their internal engineers to actually finish the audit on schedule, instead of treating compliance as a side project that keeps losing to production fires.
What AWS Hands You for Free, and What It Doesn’t
What you inherit from AWS’s own SOC 2 report
AWS maintains its own SOC 2 Type II report, covering more than 180 services, available through AWS Artifact under NDA. Your auditor can accept that report as evidence for the controls AWS itself owns: physical data center security, environmental controls, and the infrastructure layer underneath every service you run. That’s real time saved. Your auditor isn’t re-testing a data center, they’re accepting AWS’s own third party attestation and moving on.
What’s still entirely on you
Being on AWS does not make your company SOC 2 compliant, and this is the misconception that costs teams the most time when they finally realize it mid-audit. AWS’s report covers security of the cloud: the hardware, the network, the facilities. You own security in the cloud: every IAM policy, every S3 bucket configuration, every KMS key, every CloudTrail log retention setting, and every access review that proves someone actually checked who has access to what. The controls your auditor will spend the most time testing are IAM least privilege and MFA, S3 Block Public Access at the account level, encryption at rest through KMS, CloudTrail logging with adequate retention, and drift detection through AWS Config. None of that comes from AWS’s SOC 2 report. All of it comes from how you configured your account.
Where First Timers Actually Lose Months
Evidence built for the story, not the calendar
Auditors can tell the difference between a control that ran continuously and one that got reconstructed the week before fieldwork. Backdated access reviews, screenshots without timestamps or reviewer names, and evidence gaps where a quarter went unreviewed all turn into findings, sometimes a qualified opinion, the kind of report enterprise buyers reject outright. Poor offboarding is one of the most common causes of a delayed Type I report specifically: a former employee still holding AWS console access is the kind of finding that stops fieldwork cold while you explain it.
Treating the observation window as a formality
A handful of companies I’ve seen get the readiness phase right and then relax once the observation window opens, as if the hard part is over. It isn’t. Every control has to keep running for the entire window with a named owner responsible for it. When that owner changes roles or leaves mid-window and nobody hands off the responsibility, the review stops happening quietly, and it doesn’t surface until the auditor asks for six months of evidence and finds three.
Setting a Timeline Your Board and Sales Team Can Both Believe
The honest range is 6 to 16 weeks for a Type I and 6 to 12 months for a Type II, and the single biggest lever on where you land inside those ranges is how much of the readiness work is done before you sign an auditor engagement letter, not how fast the audit itself moves.
If you’re trying to figure out where your specific AWS environment actually stands before you commit to a date with an auditor, that’s a conversation worth having with people who’ve mapped this exact path before. We offer a free consultation to walk through your current AWS setup, flag the gaps that would actually slow an auditor down, and build a realistic week by week plan instead of a vendor’s marketing number.