Picture a 45-person software company that sells to mid-size banks. It runs on AWS, with 14 engineers, one security-minded senior hire, and a CTO who has been the unofficial head of security for three years. A bank's procurement team sends a questionnaire. Question 31 asks for the company's most recent SOC 2 Type 2 report. The company has never had one.
The deal is worth more than the last two quarters combined. The bank's reviewer says a report "in progress" will keep it alive, but only for a few weeks. The CTO opens a browser and finds a hundred pages of vendor marketing, each promising SOC 2 in "as little as" some number of weeks.
This is a composite scenario, not one client, and the questions are always the same. What is the report, exactly? How long until we have one? What will the auditor ask for? What does AWS cover? What goes wrong? This guide answers them for a CTO, head of security, or founder at a startup or mid-size company on AWS. The expensive mistakes are made in the first month, before anyone has talked to an auditor.
A note on sources. The AICPA, which writes the standard, publishes criteria but not a price list or a project plan. Most published numbers on duration, sample sizes, and cost come from audit firms and compliance vendors, who sell these services. Where a number comes from them, this guide says so and gives a range. Where a number is arithmetic you can check, it shows the arithmetic.
We also wrote a companion guide, How Vantalect and Acumen Defensive take the AWS work off your SOC 2 plate. This guide stands alone and does not require you to hire anyone.
What a SOC 2 Report Is, and What It Isn't
SOC 2 is a report, not a certificate and not a pass/fail test. An independent CPA firm examines your controls against the AICPA's Trust Services Criteria and writes an opinion. The AICPA says SOC engagements are performed by CPAs, and that it acts against members who are unlicensed, not in peer review, or who ignore professional standards (AICPA SOC suite).
The report has these parts. Firms lay them out differently, so check the table of contents of the sample your auditor sends.
- The auditor's report. The opinion. The first page a buyer's reviewer reads.
- Management's assertion. Your leadership states in writing that the description is fair and the controls were suitably designed and, for Type 2, operated effectively. If management will not sign, the auditor cannot finish.
- The system description. Your account of the service: infrastructure, software, people, procedures, data, the subservice organizations you rely on (AWS is one), and which controls are yours versus your customers'. Management owns this section, not the auditor.
- Criteria, controls, tests, and results. The long section. For each control, what the auditor tested and what happened, including exceptions.
- Other information. Optional. Some firms put management's responses to exceptions here.
What it isn't:
Not a certification. You do not "get SOC 2." You receive a report. A careful buyer notices when a vendor says "SOC 2 certified."
Not a checklist. The criteria say what a control environment must achieve, not which tool to use. You write your own controls, such as "access reviews happen quarterly and are signed by the system owner," and the auditor tests whether you did what you said and whether what you said meets the criteria. The standard lets you fit controls to your business and penalizes controls you wrote but do not run.
Not pass or fail. There are four opinions. Unmodified: the description is fair and the controls were effective. Qualified: problems limited to parts of the description, design, or operation. Adverse: problems are pervasive. Disclaimer: the auditor could not gather enough evidence to form an opinion, for example because records for part of the period were missing or management would not provide the written representations the auditor requires (Cloud Security Alliance, republishing an A-LIGN article). A report can carry exceptions, which are tests where a control did not operate as described, and still have an unmodified opinion.
Not a guarantee. A company can hold a clean report and still be breached.
Not public. Reports are normally shared under NDA; AWS requires one for its own (AWS SOC FAQ). A SOC 3 is the public summary. SOC 1 is a different report, about controls relevant to financial reporting, so if a customer asks for a "SOC report," ask which.
The criteria in force, and a proposed change
Audits today use the 2017 Trust Services Criteria with revised points of focus (2022). The 2022 revision changed points of focus, which are guidance and not individual requirements.
On October 28, 2026, the AICPA announced exposure drafts of proposed 2027 criteria. They restructure the criteria (combining duplicates, removing some, adding some) and add points of focus on AI governance, model monitoring, prompt manipulation, data poisoning, transparency of AI-generated outputs, training data management, and automated decision-making risk. Comments run through January 15, 2027. If approved, the criteria would be effective for engagements beginning on or after December 31, 2027, with early adoption permitted (AICPA news release).
That is a proposal, and neither the release nor the exposure-draft page says the 2017 criteria are withdrawn. If your engagement will begin on or after December 31, 2027, or you are weighing early adoption, ask your auditor which criteria it will use.
Type 1 Versus Type 2
The difference is time.
A Type 1 report is an opinion on whether your description is fair and your controls are suitably designed as of a single date. The auditor does not test whether they ran.
A Type 2 report adds an opinion on whether controls operated effectively over a period, the observation window. The auditor tests samples from across it. That is why buyers ask for Type 2: it shows the access review happened in April and again in July, not that a policy says it should. The AICPA's suite page does not define the two types; this is the standard summary from audit firms and vendors (Drata's comparison).
Should you do a Type 1 first?
It depends on what the deal in front of you requires.
- If the buyer insists on Type 2, a Type 1 can be a stopgap with a committed date for the Type 2. Get the buyer's acceptance in writing.
- If the buyer accepts either, a Type 1 still takes months, but it forces the controls to exist and gets you first-time auditor feedback before the Type 2.
- If you know you need Type 2 and your window can start soon, going straight there avoids a second fee.
A Type 1 detour costs roughly one extra auditor fee, which vendors quote at $7,500 to $15,000 for small and mid-size companies (Drata), plus project time. Vendors put a Type 1 at about 3 to 6 months from start and a Type 2 at about 6 to 15 (Drata).
Choosing the observation window
Common practice is 3 to 12 months. One vendor calls 3 months the minimum most auditors accept, 6 months common for a first audit, and 12 months standard for renewals and enterprise buyers (Drata). One secondary source says the AICPA sets no minimum, and we found no primary statement either way. So 3 to 12 months is convention set by auditors and buyers, not a rule. Ask both.
How to choose:
- What do your buyers say? Some want a 12-month period, or a period that ended within the last 12 months.
- How long have the controls run? The window starts when controls are operating, not when you sign the engagement. If the first quarterly access review has not happened, the window cannot start. Opening early is the most common way to create exceptions on day one.
- What does the arithmetic say?
- A quarterly control in a 6-month window happens twice. One miss is 1 of 2, or 50 percent. In 12 months with four occurrences, one miss is 25 percent.
- What does the arithmetic say?
- An annual control, such as the risk assessment, penetration test, or policy review, must happen at least once inside the window. If a 3-month window opens just after your annual pen test, the auditor has nothing to test, or you run a new one.
- What does the arithmetic say?
- Per-event controls, such as code review, are sampled. A longer window means more samples and more chances to find a lapse.
- What does the arithmetic say?
- What happens after the window closes? The report covers only the window. Management can issue a bridge letter (gap letter), signed by management and not the CPA firm, that covers the span after the period, usually no more than about three months. It is not a substitute for a report, and the auditor performs no procedures on the gap (Linford & Co.). AWS's version is the SOC Continued Operations Letter in Artifact, updated monthly (AWS SOC FAQ).
- Security, also called the Common Criteria. Required.
- Availability. The system is available as committed.
- Processing Integrity. Processing is complete, valid, accurate, timely, and authorized.
- Confidentiality. Information designated confidential is protected as committed.
- Privacy. Personal information is collected, used, retained, disclosed, and disposed of as committed.
- Security, access control, change management, incident response, continuity and recovery, vendor management, risk management, acceptable use, classification, and retention policies, each approved, versioned, and reviewed on a stated cycle, normally yearly.
- An organization chart with named owners, and dated policy acknowledgments.
- A dated register, at least yearly, covering fraud, change, and vendor risk, with owners, a treatment decision for each risk, and evidence management reviewed it.
- Background checks for new hires where the law permits, and training completion for everyone with access, with dates.
- An HR list of all personnel during the window. This is the population the auditor samples.
- Identity provider settings showing MFA enforced and SSO for production, a list of AWS accounts, and a list of administrators.
- Provisioning tickets with approval by someone other than the requester.
- Termination tickets with timestamps showing removal within your stated period (24 hours is common, but you set it).
- Periodic access reviews (quarterly is common) with reviewer, date, accounts reviewed, and changes made.
- Evidence of credential rotation and of encryption in transit and at rest.
- A policy saying what needs review, and a population of production changes from source control or deployment. The auditor picks samples from it.
- For each sampled change: ticket or pull request, a reviewer who was not the author, test results, approval, and deployment record.
- Branch protection settings, and records of any emergency change.
- Vulnerability scans at your stated frequency, with tickets and closure above your severity threshold.
- A penetration test performed inside the window, with remediation, if you commit to one (the criteria do not name it, but most buyers and auditors expect it). A test from before the window shows history; it does not show the control operating during the period.
- Logging and alerting configuration, with evidence alerts were reviewed.
- A written plan with roles, severity levels, and communication steps, an incident log for the window (if none, evidence you looked), and post-incident reviews.
- A tabletop or test of the plan. Startups skip this one.
- A continuity and recovery plan, backup configuration, and successful job records.
- At least one restore or failover test inside the window, with results.
- An inventory, tiered by data access, with due diligence on the important vendors. Downloading a vendor's SOC report is not a review. The reviewer notes what was read, the exceptions, and whether the vendor's complementary user entity controls are covered on your side.
- A system description with an architecture diagram and data flows, a list of in-scope systems, and the signed management assertion near the end.
- The AWS SOC 2 report from Artifact, reviewed by a named person at your company, with notes.
- A mapping of AWS's report period to your window. AWS's SOC reports cover 12 months ending March 31 and September 30 (AWS SOC FAQ). For any gap, download the continued operations letter.
- A check that every AWS service you use is in scope, from Services in Scope by Compliance Program, and that your Regions are covered. The SOC FAQ points to the SOC 3 report for the Region list.
- A review of the complementary user entity controls in the AWS report.
- A licensed CPA firm in peer review. Ask.
- Independence, in writing. Readiness is a non-attest service. A firm that designs or runs your controls, or does penetration testing, vulnerability management, or incident response in the same environment, risks an independence threat, per a Sensiba summary of AICPA guidance (Sensiba). Another CPA firm, A-LIGN, argues a CPA firm can do limited readiness work if it does not design or implement controls. Ask how the firm separates readiness from the audit, and be careful about hiring one firm to build controls and then examine them.
- Experience with AWS. A team that does not know an SCP or IAM role asks more questions, and questions cost time.
- Testing approach and calendar. Sample sizes, interim testing, treatment of deviations, earliest fieldwork date, and time to report.
- Who does the work, and standing with your buyers. The partner on the proposal may not be on your engagement. Ask sales whether the firm's reports have caused friction.
- Fee structure. What triggers a change order. A low fixed fee that rises with every extra sample is not low.
- Does my auditor accept your exports?
- What does it collect from AWS automatically, and what stays manual?
- What does year two cost, and how does the price scale with headcount?
- If I leave, can I export my policies, evidence, and history?
- Ask your buyer, in writing, for Type 1 or Type 2, window length, categories, and date.
- Name one owner with real hours.
- Request quotes from two or three CPA firms, each with its independence position in writing.
- Download the AWS SOC 2 report from Artifact, read the cover and the CUECs, and make a one-row-per-CUEC table.
- List your AWS accounts, your administrators, and where CloudTrail delivers. Those three answers tell you most of what a gap assessment will find.
Plan renewals so one window ends and the next begins the next day. A gap between windows is what reviewers look for.
A worked example: Tidepost
Tidepost is a fictional social-video news startup we built for our sample reports, which started in one AWS account. It signed a Series A term sheet in December 2025, and the lead investor required a SOC 2 Type 2 report. Its CPA firm set the window from April 1 to September 30, 2026, which is 183 days, or six months. The window opened about twelve weeks after the start of its six-week security hardening engagement, which verified 47 findings.
Three things are worth copying. The window was six months, a normal first-report length. The hardening finished before the window opened, so most AWS-side controls ran from day one. Two Confidentiality controls did not, and the sample's SOC 2 map says so and leaves their effect on the report to the auditor. And of ten critical findings, nine were closed and the tenth was accepted in writing by a named signer with an end date, not hidden. Tidepost is a simulation, so none of its numbers is a benchmark, but the sequence is realistic.
The Criteria in Plain English
There are five categories:
Only Security is required. Management adds the others, typically when they matter to the service (Linford & Co.). Each adds criteria, controls, and testing, so add one when a customer asks or your service promises it. A contract that promises 99.9 percent uptime is a reason for Availability. Storing customers' contract text is a reason for Confidentiality.
The Common Criteria are numbered CC1 through CC9. The AICPA's criteria document needs a free account, which we did not have while writing this, so the titles below come from audit-firm summaries that agree with each other (Linford, Compass IT). They differ slightly on CC9. Check the wording in the text your auditor gives you.
| Criteria | Title | In plain English |
|---|---|---|
| CC1 | Control Environment | Leadership sets expectations and assigns responsibility |
| CC2 | Communication and Information | You use reliable information and communicate objectives, responsibilities, and security matters inside and outside the company |
| CC3 | Risk Assessment | You identify what could go wrong and decide what to do |
| CC4 | Monitoring Activities | You check controls work and track deficiencies |
| CC5 | Control Activities | Policies and technology that carry out the risk decisions |
| CC6 | Logical and Physical Access Controls | Who reaches systems and data, and how access is granted, reviewed, removed |
| CC7 | System Operations | You detect problems, respond, and recover |
| CC8 | Change Management | Changes are authorized, tested, approved |
| CC9 | Risk Mitigation | You manage business disruption and vendor risk |
CC6, CC7, and CC8 produce most of the work on AWS. CC1 through CC5 are about people, paperwork, and management attention, where engineering-led companies are weakest. The extra categories use prefixes A, PI, C, and P; for example, the Availability criteria A1.2 and A1.3 concern backup and recovery. Confirm numbering in the criteria text.
The Timeline From Decision to Report
Most ranges below come from vendors and audit firms. Adding up the shortest ranges is not a plan; the observation window and the auditor's calendar set the pace.
| Phase | What happens | Typical range | Source |
|---|---|---|---|
| 1. Scoping | Choose categories, systems, subservice organizations; start the system description | 1 to 3 weeks | Our estimate |
| 2. Auditor selection | Quotes, independence check, engagement letter | 2 to 6 weeks, parallel with phase 1 | Our estimate |
| 3. Readiness (gap) assessment | Compare controls to criteria, list gaps | About 2 to 8 weeks | Vendors |
| 4. Remediation | Write policies, build controls, fix findings | About 4 to 12 weeks | One vendor guide |
| 5. Observation window | Controls run, evidence accumulates | 3 to 12 months | Convention |
| 6. Fieldwork | Evidence requests, sample testing, interviews | About 1 to 6 weeks | Vendors |
| 7. Report | Draft, management review, signed assertion, issuance | About 2 to 6 weeks after fieldwork | Vendors |
Vendors total these as about 3 to 6 months for a Type 1 and 6 to 15 for a Type 2, and other vendor sources go as high as 18. Plan on roughly 6 to 18 months for a first Type 2 report.
Phases 3 and 4 are the ones you control, and the ones people shorten. The usual failure is opening the window before the controls exist. If time is short, shorten the window before you shorten remediation.
Ask about interim testing. An exception found in an interim test in month 3 still appears in the report, but you have time to fix the process and show it operating for the rest of the window. One found at fieldwork, after the window closes, leaves no time to show the fix.
The date your buyer cares about is the report date. Fieldwork (1 to 6 weeks) plus drafting (2 to 6) means a window ending September 30 yields a report between about 3 and 12 weeks later, late October to late December. Ask for the earliest fieldwork date when you sign. While you wait for a first report, a bridge letter has nothing to extend; give the buyer the expected report date and ask whether your CPA firm will write a short letter confirming the examination and its period.
What Auditors Ask For: An Evidence Checklist
An auditor tests that a control exists as described and that it ran. For Type 2, "ran" means evidence from inside the window. A walkthrough or interview alone does not test a control (Linford), and auditors must validate data from automation tools, not trust it (Sensiba).
How samples work
Sample size is the auditor's judgment. Linford describes tables built on the AICPA audit sampling guide at a minimum 90 percent confidence level (Linford). Their example: for 389 employees and a training control, start with 25 samples. One deviation expands to 40, a second to 60, and a third stops testing and concludes the control is not operating effectively. For a monthly control with a small population, three months are tested, and any deviation counts as a failure.
A widely repeated table for a 12-month period, from Glocert, suggests about 25 to 30 samples for daily controls, 15 to 20 weekly, 5 to 7 monthly, 2 to 4 quarterly, and 1 annual. Automated controls, such as enforced MFA, may need one sample plus proof the setting did not change. These are examples; your auditor sets the numbers, and they vary by firm.
The consequence: controls that run on every hire, termination, and change get sampled, and one miss can expand the sample. That is where exceptions come from.
The checklist, by area
Your list will differ in detail. Collect these as the window runs, not afterward.
Governance and policies (CC1, CC2, CC5)
Risk assessment (CC3, CC9)
People (CC1, CC2)
Access (CC6)
Change management (CC8)
Monitoring and operations (CC4, CC7)
Incident response (CC7.3 to CC7.5)
Continuity and recovery (CC7.5, CC9.1, and Availability if in scope)
Vendor management (CC9.2)
The system itself
If you take one idea from this section, take this one: the evidence has to show who did the thing and when, and come from a system, not a spreadsheet built afterward. Evidence that looks reconstructed after the fact is the hardest for an auditor to accept.
The AWS Side
Shared responsibility
AWS describes security of the cloud (AWS) versus security in the cloud (you). It also separates inherited controls that come entirely from AWS, such as physical and environmental; shared controls that split by context, such as patching, where AWS patches infrastructure and you patch guest operating systems and applications; and customer-specific controls (AWS shared responsibility model).
In SOC 2 terms, physical access, environmental controls, and the host layer are AWS's, and you cite its SOC report. Identity, network configuration, encryption choices, logging, instance patching, application code, change management, backups, and incident response are yours. With managed services, AWS takes more of the patching and you keep configuration, access, and backups.
AWS as a carved-out subservice organization
A provider whose controls matter to your criteria is a subservice organization. Under the carve-out method, your description names AWS, excludes its controls from testing, and lists the controls you expect AWS to perform (complementary subservice organization controls, or CSOCs). Your auditor then tests how you monitor AWS, which usually means your dated, named review of AWS's SOC report: its period, its opinion, its exceptions, whether it covers the CSOCs you listed, and the CUECs it expects you to run. Under the inclusive method, the auditor tests the subservice organization's controls too. That is less common and would need AWS's cooperation, so plan on carve-out.
Expect your auditor to want:
Artifact
AWS Artifact is a self-service console portal with on-demand downloads of AWS compliance reports, including SOC reports, which you can give to your auditors. AWS says you remain responsible for documents showing your own security and compliance. Artifact documents are free (Artifact guide). AWS suggests separate, limited IAM credentials for each auditor, and you may share reports with customers only where the report's first page permits (Artifact FAQ).
Two checks, from the sources we read on October 30, 2026. The AWS SOC FAQ says the SOC 2 report covers Security, Availability, Confidentiality, and Privacy, while an AWS Audit Manager page describes a SOC 2 Security, Availability and Confidentiality report and a separate SOC 2 Privacy Type I report. They do not match, so read the cover of your downloaded report for categories, type, and period. The FAQ also does not say whether it is Type 1 or Type 2; secondary sources say Type 2.
The CUECs you inherit
A provider's SOC 2 lists complementary user entity controls (CUECs): controls the report assumes the customer runs. If you do not run them, the provider's assurance does not fully apply to you. AWS's report has such a list. It is under NDA, so we do not reproduce it. Cloud providers' CUECs typically cover managing your own users and credentials, restricting and monitoring access to your resources, configuring services securely, and encrypting your data. Read the actual list in your copy.
Your auditor will check that you have a control for each one. Keep a small table: one row per CUEC, the control at your company that covers it, and the owner. It works the same for every vendor SOC report you review.
AWS capabilities auditors commonly look at
AWS tools do not make you compliant. AWS says its Config conformance pack samples "are not designed to ensure your compliance with a specific governance standard" and "neither replace your internal efforts nor guarantee that you will pass" (AWS Config). The Security Hub standards list has no SOC 2 standard (Security Hub). The mapping below is typical auditor practice, not a statement by AWS or the AICPA.
| AWS capability | What AWS says it does | Typical use |
|---|---|---|
| IAM Identity Center | Workforce access to accounts and applications from a connected identity provider; an organization instance is recommended for multiple accounts | CC6.1 to CC6.3 |
| CloudTrail | Records actions by users, roles, and services; event history shows 90 days of management events; trails deliver to S3; CloudTrail Lake retains up to 3,653 days (about 10 years) or 2,557 days (about 7 years) by pricing option | CC7.2; evidence for CC6 and CC8 |
| AWS Config | Records configurations and history, evaluates them with rules | CC6.1, CC7.1, CC8.1 |
| Security Hub CSPM | Aggregates findings and checks against standards such as AWS Foundational Security Best Practices, CIS, NIST 800-53, PCI DSS; needs Config for most controls | CC4.1, CC7.1 |
| GuardDuty | Threat detection from CloudTrail management events, VPC flow logs, and DNS logs | CC7.2, CC7.3 |
| KMS | Keys protected by FIPS 140-3 Security Level 3 validated HSMs; key policies limit use | CC6.1, CC6.7; C1.1 |
| AWS Backup | Central plans, cross-Region and cross-account copies, Vault Lock, job dashboard | A1.2, A1.3, CC7.5; auditors want the restore test |
| Infrastructure as code and pull requests | Not one service: approvals, CI/CD logs, and stack history together | CC8.1 |
Names change. AWS now calls the posture product "Security Hub CSPM," and AWS Audit Manager, which has a prebuilt SOC 2 framework, says it is no longer open to new customers and that the framework cannot verify compliance or guarantee an audit pass (Audit Manager). We would not build a new program around it.
Four AWS habits save the most audit time.
Separate accounts. If production, development, and experiments share one account, every access review and change sample has to explain what is in scope. Multiple accounts under AWS Organizations, with a separate log archive, give clean scope. The Tidepost Foundation sample shows that cleanup starting from one account, and the AWS Multi-Account Foundation page describes the structure.
Log for the whole window. CloudTrail event history covers only 90 days, so a trail delivering to S3 in a separate account, with restricted delete permissions, is what covers a 6- or 12-month window. If logging started in month 4, the auditor cannot test months 1 through 3.
Roles and SSO instead of long-lived keys. Every person's access then lives in one place, the permission-set assignments, so the quarterly review is one export and removal is one change, and no forgotten access key outlives an offboarding.
Write down what is automated and where its evidence lives. A service control policy blocking CloudTrail from being disabled may need one sample, but only if you can show it did not change in the window. Config history gives you that.
A 90-Day Readiness Plan
This assumes one product on AWS, 20 to 150 people, some security hygiene, and a leadership decision to proceed. With no identity provider, no change ticketing, or one shared account, month one takes longer. The plan ends with the window ready to open. Name one owner with real hours. When SOC 2 is everyone's job, it is no one's.
Days 1 to 30: decide, scope, measure
| Week | Work | Output |
|---|---|---|
| 1 | Ask the buyer: Type 1 or 2, window, categories, deadline. Name the owner and a sponsor | One written page |
| 1 to 3 | Default to Security alone unless a contract demands more. Request quotes from two or three CPA firms, with their independence position in writing, sampling approach, interim testing, and fieldwork calendar | Category decision, auditor choice |
| 2 to 3 | Decide on a compliance platform or a tracker | Decision with the reason |
| 2 to 4 | Inventory systems, accounts, vendors, and people; draw the architecture and data flows | Scope list and diagram |
| 3 to 4 | Gap assessment against the criteria, including a technical AWS review: accounts, IAM, logging, encryption, backups, exposure | Gap list by severity and effort |
Days 31 to 60: build and fix
| Week | Work | Output |
|---|---|---|
| 5 | Write core policies, short and true; do not promise a control you will not run | Approved policies |
| 5 to 6 | Close the highest-severity AWS gaps: root locked down, MFA everywhere, SSO and roles instead of user keys, CloudTrail in all Regions to a protected bucket, public exposure removed, encryption | Closed findings with before and after evidence |
| 6 to 7 | Stand up access (provisioning, termination checklist, review calendar) and change management (branch protection, required reviews, emergency path) | Working processes, settings exports |
| 7 to 8 | Risk register, vendor inventory and first reviews including AWS with the CUEC table, training and background checks | Signed register, reviewed vendors, completion records |
Days 61 to 90: rehearse and open
| Week | Work | Output |
|---|---|---|
| 9 to 10 | Incident plan and a tabletop with a written record; a backup restore test; a vulnerability scan; the pen test booked for a date inside the window | Records for each |
| 10 to 11 | A first access review with real sign-off; fix what it finds | Signed review |
| 11 | Mock evidence pull: someone who did not build the controls finds evidence for 10 random items, as an auditor would | A list of what took more than 10 minutes to find |
| 12 | Final readiness review; draft the system description; confirm the window start in writing | Signed engagement letter, agreed start date |
| 13 | Open the window | A start date everyone can state |
After day 90 the work is keeping the machine running: a monthly check that every recurring control happened, a calendar for quarterly and annual items, and a place to write an exception down the day you notice it.
Common Reasons for Exceptions
An exception is a test where a control did not operate as described. A report can contain them and still carry an unmodified opinion, but every reader sees each one, and a pattern can lead to a qualified opinion.
The best public data we found is a 2024 SOC Benchmark Study by CBIZ CPAs P.C., covering 193 SOC reports (SOC 1 and SOC 2 combined). It found an average of 1.73 exceptions per report, down from 2.7 the year before. By cause: business approvals and reviews 16.5 percent, user access reviews 15.6 percent, terminations 12 percent, and change management 11.7 percent (Legal 500 summary). It is one audit firm's study, and vendor sources disagree on which cause ranks first.
In practice they come from a few places:
Access reviews with no proof. The review happened in a meeting and nobody saved the list, the name, or the date. Fix: a review is a ticket with the user list attached, a reviewer, a date, and resulting changes.
Late removal of access. A former employee keeps GitHub or AWS access for four days because the ticket was late. The auditor compares HR's termination list to removal records. Fix: tie offboarding to the HR event, and check the identity provider against the HR list monthly.
Changes with no recorded approval. A hotfix is pushed by its author. Fix: branch protection that applies to administrators, and an emergency path that records approval afterward within a stated time.
Missing training. Say 11 of 400 people missed awareness training within 30 days of starting. Fix: assign it automatically at hire and check a monthly report.
Vendors with data and no review. Fix: no vendor gets data until it is inventoried and tiered.
Backups never restored. The jobs ran nightly and nobody tested a restore. Fix: one recorded restore test inside the window.
Excessive access and over-ambitious policies. Everyone is an AWS administrator, or the policy says 24 hours and you take 48. A-LIGN also names improper scoping, unaddressed incidents, missing documentation, and inconsistent execution (A-LIGN via Cloud Security Alliance). Fix: permission sets by role, and write the policy to what you actually do before you tighten it.
Give one person the monthly job of confirming each recurring control ran, with evidence, and logging "done" or "missed." An exception you record the day it happens is still an exception, and the auditor will usually report it, but it arrives with a root cause, a remediation, and evidence that your monitoring works (CC4). The same exception found first by the auditor suggests the monitoring failed too. When an exception happens, tell the auditor, record the root cause, and write a clear management response.
Choosing an Auditor and a Compliance Platform
The auditor
The auditor alone issues the report. Choose with more care than you choose the tool.
Get two or three quotes. The spread is informative.
Vantalect is not a CPA firm and does not audit, issue, predict, or influence a SOC 2 report. Our companion guide explains the AWS technical work we do around an audit. You still hire an auditor, and keeping that firm separate from the people who build your controls avoids the independence question above.
The compliance platform
A platform collects evidence from your cloud, identity provider, and ticketing, tracks tasks, stores policies, and gives the auditor a place to look. It does not issue the report and cannot by itself make you compliant (Linford). Most of its value is the calendar and the nagging.
It earns its fee for a small team with no compliance person, many recurring controls, and an auditor that accepts its exports. A spreadsheet with one owner and a monthly check works in year one for some companies, but evidence is slower to produce.
Ask any vendor:
A dashboard can show a control green that the auditor would fail. The auditor tests against the criteria. Treat the dashboard as preparation and the auditor's request list as the test.
Costs: Honest Ranges
There is no public price list. These figures come from vendors and audit-firm blogs that sell these services. Use them to calibrate quotes, not to budget.
| Item | Range quoted | Source |
|---|---|---|
| Type 1 auditor fee, small and mid-size | $7,500 to $15,000 | Drata |
| Type 2 auditor fee, small and mid-size | $12,000 to $20,000 (Drata); $12,000 to $45,000 (bdemerson) and $30,000 to $70,000 (Brightdefense), both unverified summaries | Vendor blogs |
| Type 2 auditor fee, large organization | $30,000 to $100,000 or more | Drata |
| Readiness or gap assessment | $5,000 to $25,000 | Drata |
| Penetration test | $5,000 to $15,000 | Drata |
| First-year total | About $25,000 to over $200,000 | Drata |
| Annual maintenance after year one | About $15,000 to $40,000 | Drata |
The spread is large because the variables are: categories, systems, company size, auditor tier, and remediation needed.
The table leaves out the largest cost for most companies, staff time, and we know of no trustworthy public figure for it. Track hours during readiness and use your own. It also leaves out platform subscriptions and outside technical help, for which we found no sourced ranges. Ask each vendor for the year-two price.
Compare what each quote includes (categories, interim testing, a readiness review, a second look if exceptions arise). Spend on remediation before the window, not during it. Budget for year two, because a missed renewal creates a gap in your reports.
FAQ
How long is a report good for? It describes a past period and has no formal expiry. Buyers usually want one whose period ended within the last 12 months, plus a bridge letter for the gap. Most companies audit every year.
Which categories? Security is required. Add Availability if you commit to uptime, Confidentiality for customers' confidential information, Processing Integrity if you are responsible for accurate processing, and Privacy if personal information is core to the service. Each adds work.
Does AWS's SOC 2 make us compliant? No. You inherit the physical and infrastructure layer by citing AWS's report and still run everything that is yours, including the CUECs. Audit Manager and Security Hub do not issue a report either.
SOC 2 or ISO 27001? SOC 2 is an attestation report with a full opinion letter. ISO 27001 is a certification of a management system, shown as a short certificate (Schellman). Controls overlap a great deal, and buyer requirements usually decide which comes first.
What changes under the 2027 criteria? As of October 30, 2026, they are an exposure draft with comments through January 15, 2027, and would apply to engagements beginning on or after December 31, 2027 if approved. Today's audits use the 2017 criteria. Ask your auditor which criteria apply if your engagement begins near December 31, 2027.
Where to Start This Week
If you want help with the AWS part of that list, How Vantalect and Acumen Defensive take the AWS work off your SOC 2 plate describes what we do and what we leave to your auditor. To see the work on a fictional company before its window, read the Tidepost sample and the AWS Security, Compliance & Governance Audit page behind it (a technical review of AWS, not a SOC 2 audit).
SOC 2 is a registered trademark of the American Institute of Certified Public Accountants. AWS and the AWS service names are trademarks of Amazon.com, Inc. or its affiliates. Vantalect is not a CPA firm and does not issue SOC 2 reports.